SOLID

SRP   

A Single Responsibility Principle   

A class should have one, and only one, reason to change.

OCP   

A module should be open for extension but closed for modification.    polymorphism is a way to implement it.    Q: what's the difference between static polymorphism and dynamic polymorphism?

The Liskov Substitution Principle(LSP)   

Subclasses should be substitutable for their base classes. we should note the canonical Ellipse/Circle dilemma

The Dependency Inversion Principle(DIP)   

Depend upon Abstractions instead of concretions. we should note the difference between procedural architecture and OO architecture.

The Interface Segregation Principle(ISP)   

Many Client specific interfaces are better than one general purpose interface. so we can isolate the individule interface change. we can define interface according to the client category. Any change needed to be made on the existing interfaces, we can add a new interface instead of changing the existing interfaces. So we can avoid the issue of recompilation and redeployment.

Principles of Package Architecture

how to group together package

The Release Reuse Equivalency Principle(REP)

The granule of resue is the granule of release

The Common Closure Principle(CCP)

Classes that change together, belong together. So the package impact from release will be minimized.

The Common Reuse Principle(CRP)

Classes that aren't resued together should not be grouped together

The Acyclic Dependencies Principle(ADP)

The dependencies between packages must not form cycles. Cycles can be broken in two ways:

• create a new package
• make use of the DIP and ISP add a interface on the user side(who use the function) and the other side implement the interface.

The Stable Dependencies Principle(SDP)

Depend in the direction of stability.

I(Instability) = Ce/(Ca+Ce)

• Ce: Efferent Coupling, outgoing dependencies
• Ca: Afferent Coupling, incoming dependencies

So SDP can be rephrased as: Depend upon package whose I metric is lower than yours.

The Stable Abstractions Principle(SAP)

stable package should be abstract packages. The stable package maybe hard to change, so it is not flexible; But we can make the stable package abstract, so it is easy to extend. This is just a restatement of the DIP. That is , the package that the most depended upon should also be the most abstract.

A(Abstractness) = Na/Nc

• Na: Number of abstract classes in the package
• Nc: Number of classes in the package

KISS

Keep it simple and stupid. Less is more.

CoC Convention over Configuration, e.g. ROR

YAGNI

You Ain't Gonna need it. 极限编程中的一个概念，只实现目前需要的功能。