Clean Code

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

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

Episode 09 – Single Responsibility Principle

Clean Code

Episode 09

The ninth episode talks about the Single Responsibility principle.

  • Responsibility
    • Function and module.
    • Best module has only one responsibility
  • It’s about user
    • Responsibility that classes and function has to the user, who will request changes.
    • Responsibility can be view as the sources of change.
    • e.g. Employee class with method calculatePay, save, empolyeeInfo.
      • user for calculatePay maybe from accountants.
      • user for save maybe from DBA if the data is save in the database.
      • user for employeeInfo maybe from people who request the report.
  • It’s about role
    • Avoid coupling software, separate the user of the software from the role they play.
    • When user play a certain role, they are call actor. Responsibility is tied to actor and not to individual.
  • Reprise
    • Responsibility is a family of function serve one particular actors.
  • The two values of software
    • Secondary value is its behavior (no bug, no crashes).  Achieve by meeting the user’s need.
    • Primary value is the ability to change.
  • Friction
  • CM Collision
    • When a software with multiple responsibility is being changed by multiple users, changes would collide.
  • Fan out
    • Multiple responsibility will force the class to use multiple API. Thus, a large fan out is sensitive to changes in large array of API and cause the software its stability.
  • Collocation is coupling
    • When a software with multiple responsibility, changes from one of the users may force all other users calling this module to have to recompile and re-deploy when the changes has nothing to do with them.
  • Encroaching Fragility
    • Changes come from one user in module with multiple responsibility can affect another user when the two users initially share the usage of the same function.
  • SRP
    • Gather things that changes for the same reason and separate things that are not change for the same reason.
  • Invert Dependency
    • Separate the employee class into implementation and interface but the actors are still coupling
  • Extract Class
    • Separate the employee into three classes for each actors. However, its hard to find the right function for an employee class since it is now three different classes.
  • Facade
    • All users are using the facade class which delegate the implementation to different classes (like previously). However, actors still coupled.
  • Interface Segregation
    • Create 3 interface classes but one implementation class (see Invert dependency). Each actor is entirely decouple from the other because each actor uses its own interface. But developer need to hunt for the interface they need (see Extract Class) and implement still coupled because they are in the same implementation class.
  • Welcome to Engineering
    • No one solution fit all, balance the tradeoff.
  • Faking it
    • The episode follows a waterfall development cycle but in fact, it was done using TDD.
  • References

Episode 08 – SOLID Principle

Clean Code

Episode 08

The eighth episode talks about the SOLID principle.

  • The source code is the design
    • The cost of design is expensive for software vs building a software
  •  Design smell
    • Rigidity, Fragility Immobility
  • Rigidity
    • System is hard to change.
    • Reduce build and test time
    • Long build time is a function of coupling
  • Fragility
    • Small change in one module affect another module
    • Manage the dependency in the module and isolate them from each other
  • Immobility
    • Internal component cannot be easily extracted and re-use in new environment
    • Immobility is due to coupling and dependency between the module of the system.
    • Decouple the central abstract in the application from database, UI and framework… etc.
  • Viscosity
    • Necessary operation like build and test, check-in, check-out, merge are difficult to perform and take a long time to execute
    • Exist due to irresponsible tolerance
    • Cause by tight coupling
    • decoupling module and manage remaining dependency
  • Needless Complexity
    • Coding additional needless complexity because anticipating change for the future that are not required
    • Use TDD so code changes in the future can be trusted with tests and no need for needless complexity now. Focus on current requirement.
    • Needless complexity related to tight coupling because we anticipate relationship of modules which currently are not related.
  • Code Rot
  • Dependency Inversion
    • Avoid having the dependency pointing to the same direction of the flow of control
    • Having dependency oppose the flow of control, prevent code rot by preventing application fan out from growing and coupling with low level.
    • Example, C++ v-table for virtual function, polymorphic dispatch mechanism in Java, C# and Ruby.
    • Inverse key dependency by using dynamic polymorphism.
  • What is OO?
    • Dependency inversion
    • Protecting high level policy from low level detail
  • Dependency Management
    • SOLID principle (Dependency related)
      • Single Responsibility Principle
      • Open Closed Principle
      • Liskov Substitution Principle
      • Interface Segregation Principle
      • Dependency Inversion Principle
    • Component Cohesion Principles
      • Release-Reuse Equivalency Principle
      • Common Closure Principle
      • Common Reuse Principle
    • Component Coupling Principle
      • Acyclic Dependencies Principle
      • Stable Dependencies Principle
      • Stable Abstraction Principle
  • References

Episode 07 – Architecture

Clean Code

Episode 07

The seventh episode talks about how architecture encompass the highest level of abstract decision to the lower level of implementation.

  • What is architecture
    • Architecture is about usage
      • Architecture should expose the use case and not the delivery mechanism. Use case that should not be couple with the delivery mechanism.
      • Architecture should show the intent
    • Deferring decision
      • Good Architecture maximize the number of decision not make
      • Defer to make the decision by designing a structure that decouple from them and make the decision irrelevant.
      • Decouple tool, frame work and database by focuses the architecture on the use cases not on the software environments.
    • Separation of value
      • Make UI as a plug in to the use cases. By separating them, it is easy to understand the cost of UI and use cases individually. All system component should be isolated because of this.
  •  Use cases
    • What really is Architecture
      • The system of an accounting system should scream accounting and not web system, which is a delivery mechanism to the accounting.
      • How the user interact the system with the delivery mechanism. Use cases that does not use word to imply delivery mechanism.
      • Use cases should be the central structure of the system where the abstraction is build upon. This is the intent of the system.
    • What are Use cases
      • Its a formal description on how the user interact with the system. It talks about what data and command that goes into the system and how the system response to them.
      • Primary course is normal interaction between user and system while Exception course is where error handling uses.
  • Partitioning
    • Three fundamental objects
      • Business object – Entities
        • application independent business rules
        • the method on Entity objects performance is valid on any application that the entity can be use in.
        • Entity object should not have any application specific method. Any such method should be in the interactor object.
      • User Interface object – Boundaries
        • Boundaries object shoulder one of the job of use case is to accept data from user and output data back to user.
        • Boundaries object isolate the use cases from the delivery mechanism to the system use cases.
      • Use case object – Interactors
        • Use cases are application specific business rules and implement by interactor object.
      • User <–> Delivery Mechanism <–> [ ( Boundary <–> Interactor <–> Entity ) System Architecture ]
  • Isolation
    • The delivery mechanism should have source code dependency pointing toward the system.
    • Model View Controller.
    • Database
  • Case Study
    • The stalk holder meeting
    • Analysis
      • Make use cases agnostic by separate what is matter (how to response to commands and data) and what is not (delivery mechanism)
    • Interaction and Databases
    • The underlying abstraction
  • References
    • Object-Oriented Software Engineering, by Ivar Jacobson
    • Writing Effective Use Cases by Alistair Cockburn
    • User Stories Applied by Mike Cohns
    • Agile Software Development by Robert Martin
    • Agile Principles, Pattern and Practices in C# by Robert Martin