28: Composition. The Has-A Relationship.

Composition allows you to specify very different kinds of relationships between classes. This is sometimes also called containment. If you’re building a racing game and have a car class and a wheel class, you wouldn’t want to say that cars are wheels but instead that cars have wheels. Proper use of composition will even allow you to substitute what kind of wheels your cars have. This can not only simplify your designs but make your code easier to test. You want to make sure that inheritance is right for your situation before using it and this episode will give you another option to consider. One reason to use composition is to hide certain methods on another class and just expose a limited set of functionality. Or maybe you want to be able to perform some extra validation. Instead of inheriting from the other class, you can contain an instance of the other class inside your new class and have your own methods that do whatever you need. Your methods could call methods on the embedded class to do some or all of the real work. Outside code will have no knowledge that you’re using the other class for this. You can also expose a collection of instances of the other class. the introduction to this episode mentioned cars and wheels. Your car class can contain however many wheels you need and can expose as much or as little flexibility to change this to outside code as you want. If you allow outside code to provide new wheels, then you also provide some real flexibility to test your code. This is because your test code can supply wheels that are specifically designed to test certain conditions or to record information that can be analyzed later. You can also use containment to simplify your class hierarchies and move what used to require extra classes into data. This allows you to extend your application at runtime and can be used to modify your program after it’s been written. You do lose the ability to easily change behavior. Overriding methods is one of the main benefits of inheritance so going with data instead makes it harder to change behavior. In the end, the choice is yours. There is no one right answer for all scenarios. Listen to the full episode or read the full transcript below. Transcript When you declare a class that derives from another class, that relationship is fixed in code. This might be exactly what you need. But make sure that inheritance is right before you start using it. This episode will help you make that decision by explaining another option you have. Composition allows you to reduce the number of classes you need and is often a good choice when you just want to reuse some code that’s in another class. Instead of inheriting from that other class with the useful code, you just declare a member variable of that type and use it whenever you need to. Let’s take the armor example that’s been mentioned in previous episodes and assume for a moment that the armor class has all kinds of methods that you don’t really need but it does have some really good ones that you’d like to make use of. You want a simpleArmor class and public inheritance is out of the question because that would not only make your simpleArmor class just another armor type but it would also expose all the methods of the armor class that you don’t want. You could use private inheritance if this is C++ but unless you need to override methods or gain access to protected members, I’d advise against this. If all you want is to expose just a few of the public members of the armor class in your simpleArmor class, then you can declare a private data member of type armor in your simpleArmor class. Then you just need to declare the methods you want to expose and in your method implementation, all you need to do is call into the embedded armor data member methods to do the actual work. This approach keeps the fact that you’re using another class private. But sometimes, you want it to b