S.O.L.I.D. Princeiples Review

Software Coupling and Cohesion

Coupling

• Measures how much each of the program modules are dependent on the other program modules
• Loosely-coupled programs are high in flexibility and extensibility.
• Strong couple is never good because one object can be highly depend on some other object.

Cohesion

• Measures how strongly each of the functions are related within a program module.
• If a certain class is performing a set of highly related functions, that class is said to be cohesion.
• If a class is performing a bunch of totally unrelated functions, that means the class is not cohesive at all

What is S.O.L.I.D. Principles

The S.O.L.I.D. Principles were introduced by Bob Martin 15 years ago

• Single Responsibility Principle (SRP)
• Open-Close Principle (OCP)
• Liskov Substitution Principle (LSP)
• Interface Segregation Principle (ISP)
• Dependency Inversion Principle (DIP)

The Goal

• Tolerate change.
• Are easy to understand, and
• Are the basis of components that can be used in many software system.

Single Responsibility Principle (SRP)

• A Class should have one and only one reason to change.
• If a Class serves to tow ore more requirements, changes for one requirement may affect the others.
• Two ore more programmers are working on one class may cause frequently code merge, and code merges are risky affairs.
• How to fix:
  • Separate complicated methods into small simple methods with reasonable names.
  • Regroup the small methods those serve the same actor into a class.
• Design patterns
  • Adapter
  • Decorator
  • Strategy
  • State

Open-Close Principle (OCP)

• Meyer’s Definition
  • A software artifact should be open for extension, but close for modification
• Robert C. Martin’ Definition
  • ”Open for extension .” This means that the behavior of the module can be extended . As the requirements of the application change, we are able to extend the module with new behaviors that satisfy those changes . In other words, we are able to change what the module does .
  • “Closed for modification.” Extending the behavior of a module does not result in changes to the source or binary code of the module . The binary executable version of the module, whether in a linkable library, a DLL, or a Java .jar, remains untouched .
• Extension points: in OO language, such as C#, Java…
  • Virtual method
  • Abstract method
  • Interface (Preferred), it only defines the contract between models.

Liskov Substitution Principle (LSP)

• In 1988, Barbara Liskov wrote the following as a way of defining subtypes.
  • What is wanted here is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.

Interface Segregation Principle (ISP)

• Don’t depend on things those you don’t need.

Dependency Inversion Principle (DIP)

• The most flexible systems are those in which source code dependencies refer only to abstractions not to concretions.
• Stable abstraction rules:
  • Do not refer to volatile concrete classes.
  • Do not derive from volatile concrete classes.
  • Do not override concrete functions.
  • Never mention the name of anything that concrete and volatile.