a very lucid explanation of inheritance vs composition by Servant of the Lord, from a recent thread:
[color=rgb(40,40,40)][font=helvetica]
[background=rgb(250,251,252)]Classes should favor [/background]
[/font][/color]composition[color=rgb(40,40,40)][font=helvetica][background=rgb(250,251,252)] over inheritance.[/background]
[/font][/color][color=rgb(40,40,40)][font=helvetica]
[background=rgb(250,251,252)]
This is composition:[/background]
[/font][/color][color=rgb(0,0,136)]class[/color][color=rgb(0,0,0)] [/color][color=rgb(102,0,102)]ClassA[/color]
[color=rgb(102,102,0)]{[/color]
[color=rgb(0,0,0)] [/color][color=rgb(102,0,102)]ClassB[/color][color=rgb(0,0,0)] memberVariable[/color][color=rgb(102,102,0)];[/color][color=rgb(0,0,0)] [/color]
[color=rgb(102,102,0)]};[/color]
[color=rgb(40,40,40)][font=helvetica]
[background=rgb(250,251,252)]
Composition is when a class has other classes as member-variables.[/background]
[/font][/color][color=rgb(40,40,40)][font=helvetica]
[background=rgb(250,251,252)]
Classes should be composed of multiple classes that they own as member variables.[/background]
[/font][/color][color=rgb(40,40,40)][font=helvetica][background=rgb(250,251,252)]
A car should never inherit wheels. A car should own wheels.[/background]
[/font][/color][color=rgb(40,40,40)][font=helvetica]
[background=rgb(250,251,252)]
Most classes should use composition and avoid inheritance, except where inheritance is necessary or desirable for a specific purpose.[/background]
[/font][/color][color=rgb(40,40,40)][font=helvetica]
[background=rgb(250,251,252)]
One common purpose for inheritance is when you need to treat two or more different classes - with their own different logic - as if they behaved the same on the surface. Basically, each having different logic, but sharing the same interface.[/background]
[/font][/color][color=rgb(40,40,40)][font=helvetica]
[background=rgb(250,251,252)]
A typical beginner and intermediary-level rule of thumb is to say "Has-A" (composition) and "Is-A" (inheritance).[/background]
[/font][/color][color=rgb(40,40,40)][font=helvetica]
[background=rgb(250,251,252)]
A tiger has a tail (composition). A tiger is a animal (inheritance).[/background]
[/font][/color][color=rgb(40,40,40)][font=helvetica]
[background=rgb(250,251,252)]
A car has a wheel. Therefore the four wheels should be owned by the car via composition.[/background]
[/font][/color][color=rgb(40,40,40)][font=helvetica][background=rgb(250,251,252)]
A car is a vehicle. Therefore the car should inherit the vehicle's interface.[/background]
[/font][/color][color=rgb(40,40,40)][font=helvetica]
[background=rgb(250,251,252)]
If you want to park a Car and a Truck into a Garage, then you make the Garage own (as member variables - composition) space for two or more MotorVehicles which provide the interface. And you make Car and Truck both be (inherit) MotorVehicle so they can both provide their own data and logic.[/background]
[/font][/color][color=rgb(40,40,40)][font=helvetica]
[background=rgb(250,251,252)]
But often times, your code doesn't even need to care about different logic between the Car and Truck - in that case, just initialize a single class type with different values.[/background]
[/font][/color][color=rgb(102,0,102)]Vehicle[/color][color=rgb(0,0,0)] myTruck[/color][color=rgb(102,102,0)]([/color][color=rgb(0,136,0)]"TruckImage.jpg"[/color][color=rgb(102,102,0)],[/color][color=rgb(0,0,0)] [/color][color=rgb(102,0,102)]TruckData[/color][color=rgb(102,102,0)]);[/color][color=rgb(0,0,0)] [/color][color=rgb(136,0,0)]//If they only differ by their *data*, just pass them different data.[/color]
[color=rgb(102,0,102)]Vehicle[/color][color=rgb(0,0,0)] myCar[/color][color=rgb(102,102,0)]([/color][color=rgb(0,136,0)]"CarImage.png"[/color][color=rgb(102,102,0)],[/color][color=rgb(0,0,0)] [/color][color=rgb(102,0,102)]CarData[/color][color=rgb(102,102,0)]);[/color]
[color=rgb(40,40,40)][font=helvetica]
[background=rgb(250,251,252)]
Has-A and Is-A is not the 100% best way to think of architecture, but it is the best way I know of to begin learning it. As you program, you'll expand your understanding of architecture and begin to see that this rule-of-thumb doesn't always hold true. But when starting out, it's good to force yourself to follow it whenever tempted to use inheritance unnecessarily.[/background]
[/font][/color][color=rgb(40,40,40)][font=helvetica]
[background=rgb(250,251,252)]
Avoid inheritance entirely at first - any program you can write with inheritance, you can also write without it. It's a tool to make things easier, but it can also make things alot more complicated if you use it the wrong way. When you feel the need to use inheritance, challenge yourself to first come up with a way of not using inheritance. And then only if the inheritance way is cleaner, use it. That's my recommendation. 
[/background]
[/font][/color][color=rgb(40,40,40)][font=helvetica]
[background=rgb(250,251,252)]
[Edit:] #include doesn't mean anything in code logic. It just copy-pastes two files together. Files don't mean anything - only the code they contain matter. A file is not a class. The class is the class. A file might maybe happen to contain a class. Or it could contain something entirely unrelated. Filenames and #includes don't affect the logic of your code - they only tell the compiler where to find the code.[/background]
[/font][/color][color=rgb(40,40,40)][font=helvetica]
[background=rgb(250,251,252)]
You can fit an entire program like Halo or Call of Duty into a single .cpp file. It'd be silly to do, but it is possible. The file doesn't affect the program, only the code affects the program. The files and #includes affect only the compiling of the program, not the program's behavior.[/background]
[/font][/color][color=rgb(40,40,40)][font=helvetica]
