Episode 15 – Solid Component

Clean Code

Episode 15

This episode gives an overview of the component principles.

  • What is a Component
  • Relocatable Module
    • The creation of linker to link the subroutine library and create executable binary
  • Explosion of Libraries
    • Application call subroutines
    • Framework call applications
    • Dependency inversion of Framework and Application
    • Framework → flow of control → Application
    • Application → source code dependency → Framework
  • Linker’s Demise
    • Component is an independent deployable library (dll, gem, or jar)
    • Independent deployable mean change in one doesn’t cause another to recompile or redeploy.
    • The key is Application depends on Subroutine and Framework but not the other way around.
  • Coffee Maker Requirements
    • void setBoiler(bool);
    • void setWarmer(bool);
    • void setValve(bool);
    • void setLight(bool);
    • bool getBoiler();
    • int getPlate():
    • bool getButton();
  • The Architect’s Solution
  • A Real Design
    • Apply Single Responsibility Principle first
    • Who is the actor?
    • Brewer, Hot Drinker, Now Drinker
  • High Level Modules
    • Three Actors means at least 3 modules. One Module per Actor
    • Describe abstract purpose of component because High level module should not depend on low level details.
  • Methods and Relationships
    • Examine the methods and relationships of the modules by moving up and down the abstractions.
    • First, the actor send a start message to UI module.
    • Then, if UI not brewing? and HotWaterSource & ContainmentVessel ready? then send start message to HotWaterSource
    • This shows there is a start method for UI and HotWaterSource and ready?method for HotWaterSource and ContainmentVessel.
  • Brewing Begins
    • When the pot is removed, ContainmentVessel send suspend message to HotWaterSource
    • When the pot is replaced, HotWaterSource send resume message to ContainmentVessel
    • The take away is that message being send between module on high level abstraction
  • Implementation
    • Use Open-Close Principle
    • Creating a derivative for each of the modules.
    • Main call the derivative.
  • Components
    • All the dependency crossing from main to the application is pointing inward to the application
    • Benefit from good component design: Interchangeability, Interdependent deployability, the physical separation from high level policy to low level details.
  • Conclusion
    • Component Cohesion
    • Component Coupling
  • References

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s