Episode 10 – Open-Closed Principle

Clean Code

Episode 10

Episode ten talks about the Open-Closed principle where it is possible for source code to be open for extension but closed for modification.

  • Open and Closed
    • Software module should be open for extension but closed for modification
    • Open for extension means it should be very easy to change the behavior of the module
    • Closed for modification means the source code should not be change
    • Use abstraction and inversion by inserting abstract interface between the high level module and the low level module so that both modules are depend on the abstract interface.
    • Whenever there is a module whose behind you like to extend without modifying it, you separate the extendable behavior behind an abstract interface, and turn the dependency around.
  • Point of Sale Example
  • Implications
    • If a module is open for extension but closed for modification, then each new feature will only need additional new code and not modifying the exiting code.
  • Is this possible?
    • It is hard to be able to completely adhere to open-closed principle
    • The difficulty of conforming to open-closed principle is due to size. Small function, classes and small component are easy to conform but not with larger component.
  • A Smelly Design
  • De-Oderizing the Design
  • The Lie
    • Only protect you from changes if you can predict what they are
  • Two Solutions
  • Big Design Up-Front (BDUF)
    • Think of all possible extension before hand and build the system assuming these extension may be happening.
    • Problem with BDUF is that a major part of the system is unnecessary.
    • Abstraction create indirection and make it hard to follow the call.
  • Agile Design
    • Get a simple design out and then let the customer tell you what need to change and change that. Thus, it is an iterative process with lots of feedback.
    • By understanding what type of change is likely base on the pass changes, we can use the knowledge to predict future changes.
  • Agile Design in Practice
    • In real life, establish basis shape of the system but not over think that implement unnecessary abstraction.
  • Example
  • Reprise
  • References
    • Bertand Meyer, Object-oriented software construction