Object-oriented – Avoiding vtable pointers in objects in C++

1. Singleton

You restrict the number of instances because the constructor will be private meaning only static methods can create instances of that class (there are other dirty tricks actually to accomplish that but let's not get carried away).

Creating a class that will have only 2 or 3 instances is perfectly feasible. You should be using singleton whenever you feel the necessity to have only one instance of that class in the entire system. That usually happens to classes that have a 'manager' behavior.

If you want to learn more about Singletons you can start in Wikipedia and particularly for C++ in this post.

There is definitely some good and bad things about this pattern but this discussion belongs somewhere else.

2. Abstract Classes

Yes, that's right. Only a single virtual method will mark the class as abstract.

You'll be using those kind of classes when you have a bigger class hierarchy in which the top classes should not really be instantiated.

Let's supposed you're defining a Mammal class and then inheriting it to Dog and Cat. If you think about it, there's no much sense to have a pure instance of a Mammal since you first need to know what kind of Mammal it really is.

Potentially there's a method called MakeSound() that will only make sense in the inherited classes but there's no common sound that all mammals can make (It's just an example not trying to make a case for mammal's sounds here).

So that means Mammal should be an abstract class since it will have some common behavior implemented to all mammals but it's not really supposed to be instantiated. That's the basic concept behind abstract classes but there's definitely more to it that you should learn.

3. Interfaces

There are no pure interfaces in C++ in the same sense that you have in Java or C#. The only way to create one is by having a pure abstract class which mimics most of the behavior you want from an interface.

Basically the behavior you're looking for is to define a contract where other objects can interact with without caring about the underlying implementation. When you make a class purely abstract it mean all implementation belongs somewhere else so the purpose of that class is only about the contract it defines. This is a very powerful concept in OO and you should definitely look more into it.

You can read about the interface specification for C# in MSDN to have a better idea:

http://msdn.microsoft.com/en-us/library/ms173156.aspx

C++ will provide the same kind of behavior by having a pure abstract class.

First things first, this can be a code smell. The point of using composition for the parent/children is that the parent knows about the children but not vice versa. Especially if the relation is more of a 'contains' than 'is composed of'.

A reference to the parent is possible and fairly common in C++. In other languages, a function object or event is more often used to allow the child to communicate things that outsiders might want to know. This is a common publish-subscriber sort of pattern. I suspect that which is more idiomatic depends on which version of C++ you're using and the standards of your codebase.