Month: March 2015

Episode 13 – The Dependency Inversion Principle

Clean Code

Episode 13

This episode talks about the Dependency Inversion principle.

  • Dependency Inversion Begins
  • Independent Deployability
  • What is dependency
    • Run Time Dependency exist whenever two module interact at run time.
    • Compile Time (Source Code) Dependency exist when a name is define in one module but use in another module.
      • If Module A uses the name from Module B, then you can’t compile Class A only, you must also compile both A and B because Class A depends on Class B.
  • Structured Design
    • A top-down methodology by start with main and design what main should call and so on down the tree.
    • The source code dependency follows the same path as the run time dependency.
  • Dependency Inversion
    • The purpose is to have source code dependency going the opposite of the run time dependency path.
    • The solution is polymorphism.
    • Example,
      • A –> B [+f()], if A call f() in B, then A has both run-time and source-code dependency on B.
      • A–> Interface[+f()] <– B [+f()], insert an interface between A and B by having A uses the Interface while B implement it. Then A has run-time dependency on the Interface but not compile time dependency. And B has source-code dependency on the Interface.
  • Plugins
    • Dependency Inversion create a boundary for the software. We want all the dependency across the boundary are pointing to the same direction, the application.
    • This is by creating plugin that depend on the application.
  • Architectural Implications
    • High level policy should not depend on low level details
    • Low level details should depend on high level policy.
    • High level like use cases.
    • Low level like web pages and database.
    • Therefore, design the low level details as plugin to the application.
  • A Reusable Framework
    • Building the reusable framework should be done parallel between those application that uses it.
  • The Inversion
  • Independent Developability
    • Developers can work separately without interfere each other’s module.
  • Dependence Inversion Example
  • The Furnace Example
  • Plugins
  • References

Episode 12 – The Interface Segregation Principle

Clean Code

Episode 12

This episode talks about the Interface Segregation principle.

  • Interfaces
    • Example: A light switch
    • switch —>> Interface <|—- light
    • The interface is couple with the switch more than the light object. Should call switchable.
    • Interfaces have more to do with the class that use them then the class that implement them.
           /--- D1 <---\
B (v) <---|             |--- M
           \--- D2 <---/
  • The Interface Rant
    • Deadly diamond of death
    • M could either have one instance variable v or two coming from each D1 and D2.
  • Fat Classes
    • The main class multiple inheritance many interface classes. Isolate fat classes by isolated each client specific interfaces and deploy them separately and able to develop separately.
  • The ATM example
  • Physical Structure
    • Ensure you don’t depend on method that you don’t call, otherwise, unnecessary coupling.
  • Factory
  • Dynamics and Injection
    • Dependency Injection
    • Main should create the messenger instance, all of the interactors, and main should takes the interactors and pass them across the boundary to the application.
  • The Need to know
    • Don’t force the user to depend on thing that you need
  • References

Episode 11 – Liskov Substitution Principle

Clean Code

Episode 11

This episode talks about the principle govern inheritance, polymorphism and subtyping.

Part 1:

  • Type Theory
    • “This statement is false” is a paradox.
  • Types
    • Solution is typing to avoid paradox loop.
  • What is a Type?
    • A Type is a bag of operations and how the data is stored is not matter to us as long as the operation is done correctly.
    • Similar to a class, a class is nothing but its methods and the data is hidden as private.
  • Subtypes
    • A subtype relationship of described point as a subtype of point is when described point can be cast into point but not visa versa.
  • Liskov & subtypes
    • What is wanted here is something like the following substitution property: If for each object 01 of type of S there an object 02 of type T such that for all programs P defined in term of T, the behavior of P is unchanged when 01 is substituted for 02 then S is a subtype of T.
  • Duck typing
    • Invoking method vs Send Message (Static vs dynamic language)
  • Refused Bequest
    • Refused Bequest is when an object invoke a method or send a message that is not expected.
    • Exception and side effect by the subtype that the base type didn’t expect
  • The Representative Rule
    • Rectangle and subtype Square with setHeight and setWidth vs setSide
  • Refused Bequest!
    • When program setHeight on an object of square, there is an undefined behavior of how to handle a setHeight in a square.
  • Latent OCP Violation
    • Dependency will be created when fixing the problem by checking if a Rectangle is a Square in the program. This is a violation of Open Close Principle.
  • Solution
    • Treat square and rectangle completely different type.
  • The Representative Rule
    • Representative does not share the same relationship of the objects that they represent
  • Number
    • Integer is subtype of Real and Real is subtype of Complex
    • However, complex number has two parts of Real number, one for the real value, and the other for the imaginary.
    • In programming, this complex and real relationship will create a recursive definition similar to the paradox at the beginning of the episode.
    • This is an example where real world model does not work with a computer representation
  • Lists
    • If S is subtype of T, List of S is not a subtype of List of T
    • For example, a Circle is a subtype of Shape but List of Circle is not a subtype of List of Shape because a List of Shape could include Rectangle, Square and other Shapes.

Part 2:

  • Heuristics
    • If base class does something, the derived class must do it too in a way that does not violate the expectation of the caller. This is appearance when a derived class throw an unconditional exception for a method or override with an empty method that the base class implemented.
    • Another indicator is the usage of if instanceof is being used.
    • Only use instanceof when you know the type to help the complier.
  • Typecases
    • The use of if instanceof can lead to additional else if instanceof and should replace with polymorphic dispatch.
  • Statics vs Dynamics
    • Dynamics language use TDD to help with type checking
  • Design by Contract
    • invariant, precondition and postcondition.
  • The Modem Problem
  • Long Distance Rigidity
  • Adapter
    • Adapter is derive from the Modem and delegate to the Ded Modem in the example.
    • If you need an ugly hack, make sure to isolate it from the system by pointing all the dependency away from it.
  • Conclusion
  • References
    • The Annotated Turing by Charles Petzold
    • Advanced C++ Programming Style and Idiom by James Coplien
    • Refactoring: Improving the design of existing code by Martin Fowler
    • Object-oriented Software Construction by Bertrand Meyer