如何评判OOD设计 --- SOLID原则

单一责任原则 — Single Responsibility principle

一个类应该只有一个工作,并且只能有一个改变它的理由

假设我们有这样一个类

• 现在多了一个需求，需要将结果用json输出
  
• 增加的这个函数就违反了单一责任原则。
• 假设我们现在提出更多的需求，比如将结果输出为txt，xml格式，则这个类会变得很臃肿
• 正确的做法是增加一个Printer类
  

开放封闭原则 — Open Close principle

• 对象或实体应该对拓展开放，对修改封闭 – Open to extension, close to modification
• 假设我们有一个计算面积的类
  
• 这个类的设计就违反了open close principle，因为当需求发生变化需要计算更多图形的面积时，需要不断往类里添加函数，这个不断添加的过程就违反了open close principle，这样是不对拓展开放的

• 正确的做法如下，一般需要用abstract class和interface
• 当需要计算新的形状面积时，只需要增加新的类就可以了，不需要修改AreaCalculator这个类
  

里氏替换原则 – Liskov Substitution principle

• 任何一个子类或派生类应该额可以替换它们的基类或父类
  通俗的来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。它包含以下4层含义:

• 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
• 子类中可以增加自己特有的方法。
• 当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。
• 当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。
• 原文链接：https://blog.csdn.net/zhengzhb/article/details/7281833

接口分离原则 – Interface Segregation principle

• 不应该强迫一个类实现它用不上的接口, 也就是接口的功能要和类的功能高度匹配
• 所以接口不要定义过多的行为，防止出现“Fat Interface”的情况
• 要将接口的功能细分

依赖反转原则 – Dependecny inversion principle

• 抽象不应该依赖于具体实现，具体实现应该依赖于抽象
• High-level的实体不应该依赖于low-level的实体
• 假设我们有下面这个类，AreaCalculator作为一个high-level的类，依赖于Triangle类，
  如果Triangle类被删除或者将h和b设置为private，AreaCalculator类将报错
• 所以不要让抽象的high-level类依赖于具体的实现
  
• 正确的做法是