Related
I'm getting confused by these two. What I learned is that Abstract data type is a mathematical model for data type, where it specifies the objects and the methods to manipulate these objects without specifying the details about the implementation of the objects and methods. Ex: an abstract stack model defines a stack with push and pop operations to insert and delete items to and from the stack. We can implement this in many ways, by using linked lists, arrays or classes.
Now, coming to the definition of abstract class, its a parent class which has one or more methods that doesn't have definition(implementation?) and cannot be instantiated (much like we can't implement an abstract stack as it is, without defining the stack's underlying mechanism through one of the concrete data structures). For ex: if we have an abstract class called Mammal which includes a function called eat(), we don't know how a mammal eats because a mammal is abstract. Although we can define eat() for a cow which is a derived class of mammal. Does this mean that mammal serves as an adt and cow class is an implementation of the mammal adt?
Correct me if I'm wrong in any way. Any kind of help would be really appreciated.
Abstract data type is a mathematical model for data type...
Now, coming to the definition of abstract class...
You need to distinguish between theoretical mathematical models and a practical implementation techniques.
Models are created by people in order to reason about problems easily, in some comprehensible, generalized way.
Meanwhile, the actual code is written in order to work and get the job done.
"Abstract data type" is a model. "Abstract class" is a programming technique which some programming languages (C++, C#, Java) support on the language level.
"Abstract data type" lets you think and talk about the solution of a problem, without overloading your brain with unnecessary (at this moment) implementation details. When you need a FIFO data structure, you say just "stack", but not "a doubly-linked list with the pointer to the head node and the ability to...".
"Abstract class" lets you write the code once and then reuse it later (because that is the point of OOP - code reuse). When you see that several types have a common interface and functionality - you may create "an abstract class" and put the intersection of their functionality in inside, while still being able to rely on yet unimplemented functions, which will be implemented by some concrete type later. This way, you write the code once and when you need to change it later - it's only one place to make the change in.
Note:
Although, in C++ ISO Standard (at least in the draft) there is a note:
Note: The abstract class mechanism supports the notion of a general concept,
such as a shape, of which only more concrete variants, such as circle
and square, can actually be used.
but it is just a note. The real definition is:
A class is abstract if it has at least one pure (aka unimplemented) virtual function.
which leads to the obvious constraint:
no objects of an abstract class can be created except as subobjects of
a class derived from it
Personally, I like that C++ (unlike C# and Java) doesn't have the keyword "abstract". It only has type inheritance and virtual functions (which may remain unimplemented). This helps you focus on a practical matter: inherit where needed, override where necessary.
In a nutshell, using OOP - be pragmatic.
The term "abstract data type" is not directly related to anything in C++. So abstract class is one of the potential implementation strategies to implement abstract data types in the given language. But there are a lot more techniques to do that.
So abstract base classes allow you to define a set of derived classes and give you the guarantee that all interfaces ( declarations ) have also an implementation, if not, the compiler throws an error, because you can't get an instance of your class because of the missing method definition.
But you also can use compile time polymorphism and related techniques like CRTP to have abstract data types.
So you have to decide which features you need and what price you want to pay for it. Runtime polymorphism comes with the extra cost of vtable and vtable dispatching but with the benefit of late binding. Compile time polymorphism comes with the benefit of much better optimizable code with faster execution and less code size. Both give you errors if an interface is not implemented, at minimum at the linker stage.
But abstract data types with polymorphism, independend of runtime or compile time, is not a 1:1 relation. Making things abstract can also be given by simply defining an interface which must be somewhere fulfilled.
In a short: Abstract data types is not a directly represented in c++ while abstract base class is a c++ technique.
Is Abstract class an example of Abstract data type?
Yes, but in C++, abstract classes have become an increasingly rare example of abstract data types, because generic programming is often a superior alternative.
Ex: an abstract stack model defines a stack with push and pop
operations to insert and delete items to and from the stack. We can
implement this in many ways, by using linked lists, arrays or classes.
The C++ std::stack class template more or less works like this. It has member functions push and pop, and it's implemented in terms of the Container type parameter, which defaults to std::deque.
For an implementation with a linked list, you'd type std::stack<int, std::list<int>>. However, arrays cannot be used to implement a stack, because a stack can grow and shrink, and arrays have a fixed size.
It's very important to understand that the std::stack has absolutely nothing to do with abstract classes or runtime polymorphism. There's not a single virtual function involved.
Now, coming to the definition of abstract class, its a parent class
which has one or more methods that doesn't have
definition(implementation?) and cannot be instantiated
Yes, that's precisely the definition of an abstract class in C++.
In theory, such a stack class could look like this:
template <class T>
class Stack
{
public:
virtual ~Stack() = 0;
virtual void push(T const& value) = 0;
virtual T pop() = 0;
};
In this example, the element type is still generic, but the implementation of the container is meant to be provided by a concrete derived class. Such container designs are idiomatic in other languages, but not in C++.
much like we can't implement an abstract stack as it is, without defining the stack's underlying mechanism through one of the concrete data structures
Yes, you couldn't use std::stack without providing a container type parameter (but that's impossible anyway, because there's the default std::deque parameter), and you cannot instantiate a Stack<int> my_stack; either.
I was reading "Design Patterns: Elements of Reusable Object-Oriented Software", (specifically the chapter about the prototype design pattern) and it stated that...
"Prototype is particularly useful with static languages like C++ where classes are not objects, and little or no type information is available at run-time." (pg 121)
(emphasis mine)
I had always thought that classes were synonymous to objects, and I'm confused as to what this statement means. How are classes not objects, and why does it matter if a language is static?
A class in C++ is not an object: a class is a description of how to build an object, and a reference to a type of an object.
Compare with a language like Python: in python, like in C++, you instantiate an object from a class. Unlike C++, the class you used is also an object: it usually has type type, and you can create new ones at runtime, manipulate them like any other object, or even create objects which are classes which themselves have different types.
You may be wondering why you'd want this, and usually you don't need it -- it's like C++ template meta-programming, you only need it when you need it because you can't achieve your goal in any other way. It's probably also the case that problems you'd solve in Python with meta-classes you'd solve in C++ using template meta-programming.
In C++, this declares a class:
class A {
public:
int a;
};
whereas this declares an object:
A a;
One cannot interrogate a class a run-time, as one can interrogate an object. It makes sense to say, "object 'a', what is your address? Please invoke operator+. etc." In C++, with its static typing, it makes no sense to say, "Class A, what is your list of members? Please add a new member, "b"."
In other languages (Python comes to mind), one can manipulate classes in this way, because each class is also an object. In addition to serving as a template for objects, the class itself is an object -- it can be printed, modified, etc.
For example, a class could describe what a book is: Name, Author, Date of Publishing, Description.
An object of the "Book" class would be a specific book: C++ Primer Plus, Stephen Prata, 2005, A book that teaches C++.
So, classes are not the same as objects.
To expand on what Andrew Aylett said.
A class in C++ is not an object: a class is a description of how to build an object, and a reference to a type of an object.
Furthermore, in languages like Python or smalltalk. Everything is an object. A function is a object, a class is a object. As such these languages are Dynamically Typed, meaning that types are checked during runtime and variables can take on any type.
C++ is statically typed. Variables can only take on one type, and type checking is performed at compile time.
So in python for instance, you can modify a class on the fly. Add functions and fields, because it is an object, and can be modified.
What that sentence refers is to is the fact that classes are not first-order entities in a language like C++. In other languages, you can pass a class as a parameter to a function, e.g., the same way as you can pass an object or a function as a parameter.
There are many more implications of being classes first-order entities or not, e.g., the possibility of modifying a class at runtime, or inspecting the full internals of a class, etc.
Usually classes are found to be first-order entities in dynamic languages like ruby, or in the meta object protocol for lisp, etc.
Hope this clarifies it a bit.
Classes are not the same as Objects. A class is (more or less) the type, and an Object is the instance, simmiliar to the following:
int i;
YourClass object;
Here you wouldn't say i and int are the same -- neither are YourClass and object.
What the statement wants to say: Many object orientated languages are very object orientated, so that they start making everything (or nearly everything) an object (of one or another class). So in many languages a class would be an instance (hence an object) of some class class (which can be confusing).
This sometimes has advantages, as you can treat classes (that's types) in such languages like you could treat any other object. You can than do very dynamic stuff with them, like store them in variables or even manipulate the classes during runtime (e.g. to create new classes your program finds the need to have).
Take a look at this c++-similiar pseudo code:
YourClass myObject = new YourClass(); // creates an object (an instance)
Class baseClass = myObject.get_class(); // store the class of myObject in baseClass. That's storing a type in a variable (more or less)
Class subClass = myObject.inherit(); // dynamically create a new class, that only exists in variable subClass (a Class-object), inheriting from baseClass
subClass.add_method(some_function); // extend the new class by adding a new method
subClass.get_class() subClass.create_instance(); // declare a new variable (object) of your newly created type
BaseClass another_onne = subClass.create_instance(); // also valid, since you inherited
This obviously doesn't translate well to c++, because of c++'s strict typing. Other languages are more dynamic in typing, and there this flexibility can come in handy (and make thinks more complicated; sometimes both at the same time). Still I think it explains the principle, if you understand c++.
I had always thought that classes were synonymous to objects
The language in OOP literature is sometimes not specific. It doesn't help either that programming languages have somewhat different notions of what an object is.
A class is a template or definition from where objects (instances of that class) are created. That is, a class provides the structure, type signatures and behaviors that objects of that class (or type... more on that later.)
An object is just a location in memory of an instance of that class.
Wikipedia provides good documentation on this. I suggest you read it:
http://en.wikipedia.org/wiki/Class_(computer_programming)
http://en.wikipedia.org/wiki/Object_(object-oriented_programming)
Also, there is the concept of a type. A type (or interface as sometimes called in some literature or programming languages) is typically the collection of type/method signatures (and possibly behavior). Things like Java interfaces and C++ pure virtual classes tend to represent types (but aren't exactly the same).
Then a class that conforms to that type (be it interface or pure virtual class) is an implementation of that type.
That class, that type implementation is just a recipe of how to construct objects of that class/type in memory.
When you instantiate a class/type, you reify, construct an instance (object) of that class in memory.
In C++, a class is not an object since a class itself is not instantiated. A C++ class is not an instance of some other class (see the definitions I put above.)
OTH, in languages like Java, a class itself is represented by instances of a primordial class (java.lang.Class). So a class X has an object in memory (an java.lang.Class instance) associated with it. And with it, with that "class" object, you can (in theory) instantiate or manufacture another instance (or object) of class/type X.
It can get confusing. I strongly suggest you search and read the literature on classes, types, prototypes and objects/instances.
and I'm confused as to what this statement means. How are classes not
objects,
As explained above. A class is not an object. An object is an instance, a piece of memory constructed and initialized by the "recipe" of a class or type.
and why does it matter if a language is static?
That part of the book is a bit misleading because Java, for example, is statically typed and yet, classes can be object themselves. Perhaps the text is refering to dynamically typed languages (like JavaScript) where classes can also be objects or instances.
My suggestion is to never use the word object, and to simply limit the vocabulary to "classes" and "instances". But that's my personal predilection. Other people might disagree, and so be it.
The simpler I can put it for you to understand it:
An object is a "physical" instance of a class. It consumes memory while the program is running.
A class describes an object: Hierarchy, properties, methods. A class it's like a "template" for creating objects.
When a class is said to be an object, it means that there's an object that represents that class at runtime. In C++, classes are dissolved at compile time. Their instances (i.e. objects) are merely sequences of bytes holding the object's fields, without any reference to the class itself. Now, C++ does provide some type information at runtime via RTTI, but that's only for polymorphic types, and is not considered a class object.
The lack of having objects that represent classes at runtime is the reason there's no reflection in C++ - there's just no way to get information about a certain class, as there's no object that represent it.
BTW, C++ is considered a 2-level language: objects are instances of classes, but classes are not instances of anything, because they only exist at compile type. On 3-level languages such as C# and Java, classes are also objects at runtime, and as such, are themselves instances of yet another class (Class in Java, Type in C#). The last class is an instance of itself, hence the language only has 3 levels. There are languages with more levels, but that's beyond the scope of this question...
I'm quite new to c++ development and design and so I apologize in advance in my question is vague or poorly structured. I have several distinct and unrelated hierarchies in my code and I would like to use a generic factory as described and implemented by Alexandrescu to instantiate objects from these hierarchies .
The part I am having difficulty with is the initialization phase. The classes have very different initialization needs. Sometimes the data needed for initialization can be looked up from storage (DB) and in those cases I can encapsulate the initialization procedure in some Init() method of the specific class. But other times the data is known only locally an the moment of instantiation and needs to be passed to the object manually. I'm struggling to come up with a uniform way to do this. Does anyone have any inputs on approaching problems of this kind?
Thanks
You are hurtling down the Over-Engineering highway... head first.
Factories are seldom required, and no two Factories are alike (as you noticed).
It is useless to try and provide a base class for all your Factories, because this base class will have no clear semantic. What does it build ? Birds ? Cars ? They are unrelated... Objects ? This is not Java!
If you wish to use Factories (for some reason), then a Factory should produce 1 kind of objects, all deriving from a common base class. If you have several kinds of objects, then you will need several kinds of Factories.
And if you find the Factory code repetitive, use a template to hoist the common code.
If I guessed correctly, your problem is that you don't know how to pass different sets of arguments to your factory methods. If so it is, I can advise you to create one more hierarchy/ Let's call it FactoryHelper. The concrete class of this hierarchy will contain spesific data for instanciation of your concrete classes, for example FactoryHelperA for ConcreteProductA will contain a string and FactoryHelperB for ProductB will contain int. An abstact method of your factory must accept abstract base class - FactoryHelper as an argument. Concrete methods of your factory will cast this argument to concrete FactoryHelperA or FactoryHelperB and get specefic data for instanciation of specefic Product
But it's not very good design. I guess you're trying to use factory methods the wrong way.
I am relatively new to "design patterns" as they are referred to in a formal sense. I've not been a professional for very long, so I'm pretty new to this.
We've got a pure virtual interface base class. This interface class is obviously to provide the definition of what functionality its derived children are supposed to do. The current use and situation in the software dictates what type of derived child we want to use, so I recommended creating a wrapper that will communicate which type of derived child we want and return a Base pointer that points to a new derived object. This wrapper, to my understanding, is a factory.
Well, a colleague of mine created a static function in the Base class to act as the factory. This causes me trouble for two reasons. First, it seems to break the interface nature of the Base class. It feels wrong to me that the interface would itself need to have knowledge of the children derived from it.
Secondly, it causes more problems when I try to re-use the Base class across two different Qt projects. One project is where I am implementing the first (and probably only real implementation for this one class... though i want to use the same method for two other features that will have several different derived classes) derived class and the second is the actual application where my code will eventually be used. My colleague has created a derived class to act as a tester for the real application while I code my part. This means that I've got to add his headers and cpp files to my project, and that just seems wrong since I'm not even using his code for the project while I implement my part (but he will use mine when it is finished).
Am I correct in thinking that the factory really needs to be a wrapper around the Base class rather than the Base acting as the factory?
You do NOT want to use your interface class as the factory class. For one, if it is a true interface class, there is no implementation. Second, if the interface class does have some implementation defined (in addition to the pure virtual functions), making a static factory method now forces the base class to be recompiled every time you add a child class implementation.
The best way to implement the factory pattern is to have your interface class separate from your factory.
A very simple (and incomplete) example is below:
class MyInterface
{
public:
virtual void MyFunc() = 0;
};
class MyImplementation : public MyInterface
{
public:
virtual void MyFunc() {}
};
class MyFactory
{
public:
static MyInterface* CreateImplementation(...);
};
I'd have to agree with you. Probably one of the most important principles of object oriented programming is to have a single responsibility for the scope of a piece of code (whether it's a method, class or namespace). In your case, your base class serves the purpose of defining an interface. Adding a factory method to that class, violates that principle, opening the door to a world of shi... trouble.
Yes, a static factory method in the interface (base class) requires it to have knowledge of all possible instantiations. That way, you don't get any of the flexibility the Factory Method pattern is intended to bring.
The Factory should be an independent piece of code, used by client code to create instances. You have to decide somewhere in your program what concrete instance to create. Factory Method allows you to avoid having the same decision spread out through your client code. If later you want to change the implementation (or e.g. for testing), you have just one place to edit: this may be e.g. a simple global change, through conditional compilation (usually for tests), or even via a dependency injection configuration file.
Be careful about how client code communicates what kind of implementation it wants: that's not an uncommon way of reintroducing the dependencies factories are meant to hide.
It's not uncommon to see factory member functions in a class, but it makes my eyes bleed. Often their use have been mixed up with the functionality of the named constructor idiom. Moving the creation function(s) to a separate factory class will buy you more flexibility also to swap factories during testing.
When the interface is just for hiding the implementation details and there will be only one implementation of the Base interface ever, it could be ok to couple them. In that case, the factory function is just a new name for the constructor of the actual implementation.
However, that case is rare. Except when explicit designed having only one implementation ever, you are better off to assume that multiple implementations will exist at some point in time, if only for testing (as you discovered).
So usually it is better to split the Factory part into a separate class.
I need to finish others developer work but problem is that he started in different way...
So now I found in situation to use existing code where he chooses to inherit a non-abstract class (very big class, without any virtual functions) that already implements bunch of interfaces or to dismiss that code (which shouldn't be to much work) and to write another class that implements interfaces I need.
What are the pros and cons that would help me to choose the better approach.
p.s. please note that I don't have to much experience
Many Thanks
Although it is very tempting to say write it from scratch again, don't do it! The existing code may be ugly, but it looks like it does work. Since the class is big, I assume there is fair bit of history behind it as well. It might have solutions for some very obscure cases which you might not have imagined till now. What I suggest is, if possible first talk to the person who developed that class, understand how it works, then derive from it (after making its destructor virtual of course) and complete your work. Then as and when time permits slowly refactor the parts of the class into smaller more manageable classes. Also, don't forget to write a good unit-tester before you start so that you can validate the new behavior against the existing class's behavior. One more thing, there is nothing wrong in inheriting from a non-abstract base class as long as it makes sense and the base class destructor is virtual.
If the other developer has written a base-class with no virtual functions, then those functions do not need to be overridden, and it is correct to define them in a non-abstract base class.
If those functions define functionality that all the child-classes require then it would be a mistake to get rid of the base class, as you would then need to implement those functions individually in each of the child classes.
I've seen a lot of developers go 'interface-mad' in the last couple of years, but base classes still serve a function over interfaces - to provide a concrete implementation that is common to all child classes. It would be a mistake to get rid of the base class and have seperate implementations of these functions in each of the child classes.
HOWEVER, if the child classes are inheriting functionality that they do not require, or require a separate implementation of, then the Base class is a mistake and interfaces would seem like the better option to divide the functionality between the child classes.
Despite this, I would agree with Naveen that its probably not worth the extra work this will give you, it may seem simple, but if this is a big class with a lot of inheritors then it could turn out to be a nightmare. Quite often in Software Engineering you have to deal with another developer's code that you might have implemented differently. If you re-implemented it ever time you will be a very unproductive developer. I say work with what you've got and get the project finished on time.
Is there anything at all you want to use from the base class or would you end up overriding everything?
Does it define some sort of type that you want to use for an "is-a" relationship?
(for example, base class is "animal" and you want to make "cat", but if it doesn't add any behavior to its interface, that doesn't seem likely)
Is the base class used in other interfaces you need to use? (like if someone is passing objects through a reference/pointer to the base class)
If not, I'd say there's no advantage in inheriting from that class over implementing the interface(s) yourself.
What are the pros and cons that would help me to choose the better approach.
It's legal to derive from a class with no virtual functions, but that doesn't make it a good idea. When you derive from a class with virtual functions, you often use that class through pointers (eg., a class Derived that inherits from Base is often manipulated through Base*s). That doesn't work when you don't use virtual functions. Also, if you have a pointer to the base class, delete-ing it can lead to a memory leak.
However, it sounds more like these classes aren't being used through pointers-to-the-base. Instead the base class is simply used to get a lot of built in functionality, although the classes aren't related in the normal sense. Inversion of control (and has-a relationships) is a more common way to do that nowadays (split the functionality of the base class into a number of interfaces -- pure virtual base classes -- and then have the objects that currently derive from the base class instead have member variables of those interfaces).
At the very least, you'll want to split the big base class into well-defined smaller classes and use those (like mixins), which sounds like your second option.
However, that doesn't mean rewrite all the other code that uses the blob base class all in one go. That's a big undertaking and you're likely to make small typos and similar mistakes. Instead, buy yourself copies of Working Effectively With Legacy Code and Large-Scale C++ Software Design, and do the work piecemeal.
From you question it is not too clear what the problem is - looking at the title (Using non-abstract class as base) I can tell you that using an abstract class (non pure virtual - when you talk about interfaces in C++ I am assuming pure virtual abstract classes) as base makes sense only if there is common functionality you can share between subclasses - meaning that a number of classes extend the same abstract class inheriting the common implementation. If that's not the case (and you're pretty confident it's never gonna happen) then it doesn't make sense to use an abstract class.
If you can extract out some of the functionality in you big class in such a way that leads to (even potential) code reuse then it could make sense - otherwise I wouldn't see the point.