When to Use Composition

1. Part-Whole Relationships:
   • Use composition when one class is logically a part of another. For example, a Car might contain an Engine, Wheels, and Seats. Composition models this part-whole relationship where the existence of parts depends on the whole.
2. Behavioral Delegation:
   • When a class needs to exhibit certain behaviors but doesn't want to implement them itself, it can compose objects that already provide those behaviors. This allows for delegation of responsibilities, like a Robot using a MovementController for navigation.
3. Code Reusability:
   • If you want to reuse functionality across different classes without resorting to multiple inheritance (which might not be available or desirable in some languages), composition lets you include the same objects in different classes, thereby promoting code reuse.
4. Flexibility and Maintainability:
   • When anticipating changes or extensions to the class's behavior or structure, composition allows for easy modifications. You can change or extend functionality by altering or adding composed objects without changing the class's interface.
5. Encapsulation:
   • To maintain encapsulation while providing complex functionality, use composition to hide internal complexities behind a simpler interface. This is particularly useful when you want to control how data or methods are accessed.
6. Avoiding Deep Inheritance:
   • If your design leads to deep inheritance hierarchies, which can make maintenance difficult, composition can help flatten this structure. It allows for combining behaviors from different classes without creating a deep tree of subclasses.
7. Dynamic Behavior:
   • When behavior needs to be changed at runtime, composition is advantageous. You can swap out composed objects or add new ones dynamically, which is harder to achieve with inheritance alone.
8. Testing:
   • Composition can make unit testing easier since you can mock or replace composed objects to test different scenarios without changing the class under test.
9. Design Patterns:
   • Certain design patterns like Strategy, Decorator, or Composite are inherently based on composition, advocating for its use in specific scenarios to achieve particular design goals.

• Game Design: A Character might compose a Weapon, Armor, and Inventory to manage different aspects of gameplay without the Character class directly handling all these details.
• Software Systems: In a system for managing documents, a Document class might compose Text, Image, and Table classes, each handling their specific rendering and manipulation logic.

• Granularity: How detailed should your composition be? Fine-grained composition can lead to more modular code but might increase complexity.
• Ownership and Lifespan: Decide whether the composed object should be owned by the container class or if it should exist independently. This affects memory management and object lifecycle.
• Performance: While composition provides many benefits, excessive use can lead to performance overhead due to indirection or increased memory usage.

• Class Relationship Implementation
  In the video store example, the Customer class has attributes that are just strings and numbers. But consider the Rental class:
  It should know what video has been rented and by whom. This means that each Rental object is connected to a Video object and a Customer object, like this:
  

  

• C++ Composition:
  In C++, you have a choice of three types for your attributes: as pointers, as references, or as solid objects.
  Pointers: Example 1
  If you use pointers in C++, the class definition will look like the code below.
  

  class Rental{
  private:
    Date startDate, returnDate, actualreturnDate;
   Customer* rentedby;
   Video* itemrented;
    // remainder of class omitted
  };
  

  
  When you use these attributes, you will have to dereference the pointers.
  References: Example 2
  View the code below to see how references are used in C++.
  

   
  class Rental{
  private:
    Date startDate, returnDate, actualreturnDate;
  Customer& rentedby;
    Video& itemrented;
    // remainder of class omitted
  };
  

  
  If you use references for the attributes, the class definition will look like the example shown above. You do not need to dereference references; more important, you cannot change them to refer to a different object. Pointers can be changed to point to something else. Because it makes little sense for the Rental object to change the customer who is renting or the item that is rented, references are probably a better choice than pointers for this class.

class Rental{
private:
  Date startDate, returnDate, actualreturnDate;
Customer rentedby;
Video itemrented;
// remainder of class omitted
};

class Rental{
  private Date startDate, returnDate, actualreturnDate;
  private Customer rentedby;
  private Video itemrented;
  // remainder of class omitted
}

1. A floating-point number, like 57.35, but then there would be round-off issues to consider
2. An integer, like 5735, representing the number of pennies the check was for, but then you'd have to divide by 100 whenever you had calculations to do
3. Two integers, like 57 and 35, for the dollars and the cents, but then you'd have to be careful they didn't get "out of sync." What would it mean if the dollars were 57 and the cents were -35?