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
- 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
- See example here
- 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.
- Bertand Meyer, Object-oriented software construction