SOLID Principles

1. Intention: more understandable, easier to maintain and easier to extend.(通过良好的设计使得代码easy and simple,从而实现将复杂的事情简单化)
2. S — Single responsibility principle
   1. every module or class should have responsibility over a single part of the functionality provided by the software
   2. 一个class就让它做一件事,保持类的简单
   3. 比如现在处理一个将输入数据处理并传送到前端的业务,在这里就至少有两个类,一个类负责数据的处理,一个类负责将数据输出成不同的形式(xml,json…)
3. O — Open/closed principle
   1. software entities (classes, modules, functions, etc.) should be open for extensions, but closed for modification
   2. how to: utilizing(利用) inheritance and/or implementing interfaces that enable classes to polymorphically substitute(替代) for each other
   3. 当需求发生变更时优先考虑扩展(比如使用继承或实现接口产生新的class)而不是修改原有的代码
4. L — Liskov substitution principle
   1. if S is a subtype of T, then objects of type T may be replaced (or substituted) with objects of type S.
   2. 确保子类在各方面都能替代父类
      1. 子类可以实现父类的抽象方法，但不能重写父类的非抽象方法(请考虑这种情况下怎么实现多态)
      2. 子类中可以增加自己特有的方法
      3. 当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松
      4. 当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格
   3. 请考虑"正方形 IS-A 长方形"的问题(假如它们之间有继承关系,那么计算面积或者周长的时候怎么办?)
   4. 请考虑该原则和开闭原则之间存在的冲突(假如现在需要对父类的非抽象方法进行重写)
5. I — Interface segregation principle
   1. Clients should not be forced to implement interfaces they do not use
   2. 接口应该定义得足够小,子类在实现的时候不应该觉得某个方法是多余的
6. D — Dependency inversion principle
   1. High-level modules and low-level modules should depend on abstractions. Details should depend on abstractions.
   2. how to: dependency injection 使用IOC容器来管理class之间的依赖关系