Simple Object-Oriented Design: Create clean, maintainable applications cover
welcome to this free extract from
an online version of the Manning book.
to read more
or

7 Achieving modularization

 

This chapter covers

  • Designing modules that provide complex features through simple interfaces
  • Reducing the dependencies between modules
  • Defining ownership and engagement rules

Up to this point in our journey through simple object-oriented design, our discussions have primarily focused on simplicity, consistency, abstractions, and extension points. We discussed how to apply these ideas from small methods to a set of classes. However, as we venture into large, multifaceted systems, our scope must broaden. We must consider not just classes within a single component but also how different components that perform entirely different business operations interact and integrate.

Think of a large-scale business system that takes care of an e-commerce shop. The billing system, which handles charging customers, is complex and most likely developed by one dedicated team. The same is true for the delivery system, which ensures that goods get to their buyers, and for the inventory system, which controls whether items are still available or if the shop has to restock them. Although these systems are different from each other, they must collaborate. The delivery system must consult with the inventory system before delivering goods. Billing must notify delivery that the invoice was paid and the goods can be delivered.

7.1 Build deep modules

7.1.1 Find ways to reduce the effects of changes

7.1.2 Keep refining your domain boundaries

7.1.3 Keep related things close

7.1.4 Fight accidental coupling, or document it when you can’t

7.2 Design clear interfaces

7.2.1 Keep the module’s interface simple

7.2.2 Backward-compatible modules

7.2.3 Provide clean extension points

7.2.4 Code as if your module will be used by someone with different needs

7.2.5 Modules should have clear ownership and engagement rules

7.3 No intimacy between modules

7.3.1 Make modules and clients responsible for the lack of intimacy

7.3.2 Don’t depend on internal classes

7.3.3 Monitor the web of dependencies