Dependency

Comparing and contrasting relations

Now that we’ve explored the various types of class relations, let’s compare and contrast them to better understand when to use each:

1. Association vs Aggregation vs Composition

   • Association is the most general relationship, representing any connection between classes.
   • Aggregation is a specialised association representing a whole-part relationship where the part can exist independently.
   • Composition is the strongest whole-part relationship where the part cannot exist independently of the whole.

2. Inheritance vs Composition

   • Inheritance represents an “is-a” relationship (e.g., a Dog is an Animal).
   • Composition represents a “has-a” relationship (e.g., a Car has an Engine).
   • The principle of “composition over inheritance” suggests favouring composition for more flexible designs.

3. Realisation vs Inheritance

   • Realisation is about implementing an interface, focusing on behaviour.
   • Inheritance is about extending a class, inheriting both state and behaviour.

4. Dependency vs Association

   • Dependency is a weaker, often temporary relationship (e.g., a method parameter).
   • Association implies a more permanent relationship, often represented by a class attribute.

Here’s a comparison table summarising these relationships:

Common pitfalls

While class relationships are powerful tools in OOP, they can also lead to common pitfalls if not used carefully. Here are some common issues and how to avoid them:

1. Overuse of inheritance

   • Problem: Creating deep inheritance hierarchies that are hard to understand and maintain.
   • Solution: Prefer composition over inheritance. Use inheritance only for genuine “is-a” relationships.

2. Tight coupling

   • Problem: Creating strong dependencies between classes, making the system rigid and hard to change.
   • Solution: Use interfaces and dependency injection to reduce coupling. Depend on abstractions rather than concrete classes.

3. God objects

   • Problem: Creating classes that try to do too much, violating the Single Responsibility Principle.
   • Solution: Break large classes into smaller, more focused classes. Use composition to bring functionality together.

4. Circular dependencies

   • Problem: Creating mutual dependencies between classes, leading to complex and hard-to-maintain code.
   • Solution: Refactor to remove circular dependencies. Consider using interfaces or introducing a new class to break the cycle.

5. Leaky abstractions

   • Problem: Exposing implementation details through interfaces or base classes.
   • Solution: Design interfaces and base classes carefully. Hide implementation details and expose only what’s necessary.

6. Inappropriate intimacy

   • Problem: Classes that know too much about each other’s internal details.
   • Solution: Encapsulate data and behaviour. Use public interfaces to interact between classes.

7. Brittle base classes

   • Problem: Changes to base classes breaking derived classes in unexpected ways.
   • Solution: Design base classes for extension. Document how derived classes should interact with base classes.

8. Diamond problem in multiple inheritance

   • Problem: Ambiguity in method resolution when a class inherits from two classes with a common ancestor.
   • Solution: Avoid multiple inheritance if possible. Use interfaces or mixins instead.

9. Overuse of getters and setters

   • Problem: Breaking encapsulation by providing unrestricted access to internal state.
   • Solution: Use meaningful methods that represent behaviors rather than exposing internal data directly.

10. Violation of Liskov Substitution Principle

    • Problem: Derived classes that can’t be used interchangeably with their base classes.
    • Solution: Ensure that derived classes truly represent specialisations of their base classes. Use composition if the “is-a” relationship doesn’t hold.

By being aware of these pitfalls and following best practices, you can create more robust and maintainable object-oriented designs.

Conclusion

Key takeaways:

1. Association is a general relationship between classes.
2. Aggregation represents a whole-part relationship where parts can exist independently.
3. Composition is a stronger whole-part relationship where parts cannot exist independently.
4. Inheritance represents an “is-a” relationship and promotes code reuse.
5. Realisation is about implementing interfaces and focusing on behaviour.
6. Dependency is a weak, often temporary relationship between classes.

Remember that good object-oriented design is not just about using these relationships, but about using them appropriately. Always consider the SOLID principles and the “composition over inheritance” guideline.

References

1. Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley.
2. Martin, R. C. (2017). Clean Architecture: A Craftsman’s Guide to Software Structure and Design. Prentice Hall.
3. Fowler, M. (2002). Patterns of Enterprise Application Architecture. Addison-Wesley.
4. Bloch, J. (2018). Effective Java (3rd ed.). Addison-Wesley.
5. Phillips, D. (2018). Python 3 Object-Oriented Programming (3rd ed.). Packt Publishing.
6. Lott, S. F. (2020). Object-Oriented Python: Master OOP by Building Games and GUIs. No Starch Press.
7. Booch, G., Rumbaugh, J., & Jacobson, I. (2005). The Unified Modeling Language User Guide (2nd ed.). Addison-Wesley.