PHP的SOLID设计原则

SOLID Design Principles，

这是一个比设计模式更高级别的概念，

以构建良好代码为目标，真正掌握了就是大师级别了。

我~~~仅知晓~

/*SOLID Design Principles
• S: Single responsibility principle (SRP)
• O: Open/closed principle (OCP)
• L: Liskov substitution principle (LSP)
• I: Interface Segregation Principle (ISP)
• D: Dependency inversion principle (DIP)

The single responsibility principle deals with classes that try to do too much.
The responsibility in this context refers to reason to change. As per the Robert C.
Martin definition:
"A class should have only one reason to change."

The open/closed principle states that a class should be open for extension but closed
for modification, as per the definition found on Wikipedia:
"software entities (classes, modules, functions, etc.) should be open for extension,
but closed for modification"
The open for extension part means that we should design our classes so that new
functionality can be added if needed. The closed for modification part means that
this new functionality should fit in without modifying the original class. The class
should only be modified in case of a bug fix, not for adding new functionality.

The Liskov substitution principle talks about inheritance. It specifies how we
should design our classes so that client dependencies can be replaced by subclasses
without the client seeing the difference, as per the definition found on Wikipedia:
"objects in a program should be replaceable with instances of their subtypes
without altering the correctness of that program"
While there might be some specific functionality added to the subclass, it has to
conform to the same behavior as its base class. Otherwise the Liskov principle
is violated.
When it comes to PHP and sub-classing, we have to look beyond simple concrete
classes and differentiate: concrete class, abstract class, and interface. Each of the three
can be put in the context of a base class, while everything extending or implementing
it can be looked at as a derived class.

The Interface Segregation Principle states that clients should only implement
interfaces they actually use. They should not be forced to implement interfaces
they do not use. As per the definition found on Wikipedia:
"many client-specific interfaces are better than one general-purpose interface"
What this means is that we should split large and fat interfaces into several small and
lighter ones, segregating it so that smaller interfaces are based on groups of methods,
each serving one specific functionality.

The dependency inversion principle states that entities should depend on
abstractions and not on concretions. That is, a high level module should not
depend on a low level module, rather the abstraction. As per the definition
found on Wikipedia:
"One should depend upon abstractions. Do not depend upon concretions."
This principle is important as it plays a major role in decoupling our software.
*/