Episode 16 – Component Cohesion

Clean Code

Episode 16

This episode talks about how components should work together.

  • Overview
    • Release Reuse Equivalency Principle
    • Common Closure Principle
    • Common Reuse Principle
  • Cohesion
    • What is inside a component? The pieces is functions and the force to bind them is cohesion
  • False Cohesion
    • A group class work together to achieve a common goal is not a good reason to bind them together as a component.
    • Base class and their derivative are often package into separate component, with class that use base class package with the base class.
    • When one class polymorphic uses another class, those classes should be separate into different components.
    • Goal is interdependent deployability
  • Release Reuse Equivalency Principle
    • The granulate of reuse is granulate of release, you can’t reuse a component unless the author is willing to manage it thru a release cycle
    • You want a few strategic components instead of managing hundreds of tiny components
  • Common Closure Principle
    • Component don’t cross boundary
    • When requirement change, best outcome is one component per layer changes.
    • Minimize the number of component change when requirement changes.
    • The classes we grouped together should be closed to the same kind of changes.
    • We gather the classes that change for the same reason and separate the classes that changes for different reason.
    • This is similar to interface Segregation Principle
    • Those class that group into a component should have same responsibility, serve the same actor.
  • Common Reuse Principle
    • Group together classes that are using together, separate classes that are not. In another word, when you use a component, you use all the classes within that component.
  • The Tension Diagrams
    • CRP & REP → component affected by many responsibility
    • CRP & CCP → component aren’t reusable
    • CCP & REP → component are needlessly affected
    • As project mature, it moves from CRP & CCP to REP.
    • Component partitioning changes with project maturity
  • References