文章目录
基本定义
S: Single Responsibility Principle（SRP），单一职责原则。
A class or module should have a single reponsibility.
一个类或模块，只负责完成一项职责。
O: Open Closed Principle（OCP），开闭原则
software entities (modules, classes, functions, etc.) should be open for extension, but closed for modification.
软件实体（模块，类，方法等）应该对扩展开放，对修改关闭。
L: Liskov Substitution Principle（LSP），里式替换原则
Functions that use pointers of references to base classes must be able to use objects of derived classes without knowing it.
子类对象可以替换程序中父类对象出现的任何地方，并且保证原来程序的逻辑行为不变及正确性不被破坏。
I: Interface Segregation Principle（ISP），接口隔离原则
Clients should not be forced to depend upon interfaces that they do not use.
客户端不应该被强制依赖它不需要的接口。
D: Dependency Inversion Principle（DIP），依赖反转原则
High-level modules shouldn’t depend on low-level modules. Both modules should depend on abstractions. In addition, abstractions shouldn’t depend on details. Details depend on abstrations.
高层模块不要依赖于低层模块，高层模块和低层模块应该通过抽象来相互依赖，另外，抽象不要依赖具体实现细节，具体实现细节依赖抽象。
细则说明
SRP：单一职责原则
该原则建议设计功能合理的类，避免将不相关的功能耦合在一起形成一个大而全的类，来提高单个类的内聚性，同时也由于功能简单而减少相互依赖，进而减少了耦合性。
当然，也不是要将类拆分的越细越好，而是需要根据业务来调整，其中有一些问题可以帮助来判断是否一个类设计的过大：
- 类中的代码行数、函数或者属性过多
- 当前类跟较多类有依赖关系
- 私有方法过多
- 很难定位类的功能，或者很难给类起一个合适的名字
- 类中太多的方法集中操作类中某几个属性
OCP：开闭原则
该原则目标是在实现一个高扩展的类，即以最小的修改代价来完成新功能的开发，避免因为新功能对原有功能或程序产生较大的影响。
在设计时候考虑到未来需求变化的扩展性，提高扩展意识、抽象意识、封装意识是写出好扩展性代码的重要条件，有一些提高代码扩展性的思路：
- 使用多态
- 依赖注入
- 基于接口而非实现编程
- 学习使用设计模式（装饰器、策略等）
LSP：里式替换原则
该原则目标是保留父类原有的行为约定，即子类可以根据自己的功能约定实现自己的逻辑，但子类的实现不能修改父类原来的行为约定。
常见的行为约定包括：
- 函数声明要实现功能
- 对输入、输出、异常的约定
- 注释种罗列的任何特殊说明
ISP：接口隔离原则
该原则的目标是建立一个功能纯粹的接口，对于只是被部分调用者使用的功能需要从接口中拆分出来，避免让不需要该功能的调用者依赖。
使用接口隔离是需要在接口层面定义更细的粒度，使得程序更灵活、易扩展、易复用。
DIP：依赖反转原则
该原则一般用于指导框架层面的设计，即将程序的控制权由框架来完成（反转给了框架），避免程序员自己通过面向过程思想实现整个程序。
程序示例
SRP：单一职责原则
// 用户信息类
public class UserInfo {
//author: suoxd123@126.com
private long Id;
private String name; //姓名
private String email;
private String phone;
private long lastLoginTime;
private String province; // 省
private String city; // 市
private String region; // 区
private String address; // 详细地址
}
如果该类信息每次使用都只是用于显示，直接这么设计没问题。
如果业务需要地址信息经常被其它模块单独使用，可以考虑将地址信息（province, city, region, address）拆分出来，然后这里引用
如果业务需要对账号信息单独使用，可以考虑将账户信息（name, email, phone)拆分出来，然后这里引用
OCP：开闭原则
//author: suoxd123@126.com
public interface IRun { //... }
public class TwoLegRun : IRun { //... }
public class FourLegRun : IRun { //... }
public class Demo {
private IRun animal; // 基于接口而非实现编程
public Demo (IRun animal) { // 依赖注入
this.animal = animal;
}
}
如果后期增加一个单腿跑的功能，当前的设计修改就不多，只需要继承接口IRun后，直接调用即可。
相反，如果不用当前的设计，而是基于不同参数（几条腿）来实现不同的行为，那改函数就比较臃肿，而且新功能引入的改动可能会对原有功能稳定程序带来风险。
LSP：里式替换原则
//author: suoxd123@126.com
public class Run {
public virtual void moveOn(int speed){}
}
public class SlowRun : Run {
public override void moveOn(int speed){}
}
SlowRun中的MoveOn方法跟父类中的方法在输入输出上完全一致，即对于父类Run使用的场景，如果替换成子类SlowRun也完全可以调用
ISP：接口隔离原则
//author: suoxd123@126.com
public interface IRun{void Moveon(int speed);}
public interface IFly{void Flyon(int speed);}
public class Sparrow:IRun, IFly {
public void Moveon(int speed){}
public void Flyon(int speed){}
}
public class Dog:IRun {
public void Moveon(int speed){}
}
如上定义了IRun和IFly两个接口，因此可以分别对于具有IRun和IFly能力的动物进行继承和实现。
相反，如果定义一个接口中含有Moveon和Flyon的函数，那么在Dog中对Flyon的实现就容易让人误解。
DIP：依赖反转原则
public class Demo {
public static void main(String args[]) {
Runner runner = new Runner(); //创建对象
Sports sport = new sport(runner);//依赖注入
sport.showInfo();
}
}
上面程序展示了依赖注入，即对于对象的使用不是在程序内部实例化，而是通过构造函数或者参数的方式，对实例对象进行传递和调用。
//author: suoxd123@126.com
public class Runner
{
public static void Run()
{// ... }
}
public static void main(String[] args)
{//这部分逻辑可以放到框架中
Run();
}
}
//=================================
// 上面：程序执行流程是由程序开发者来启动和执行
// 下面：程序反转给了框架，开发者仅需要实现功能
//=================================
public interface Runner
{
void Run();
}
public class Marathon : Runner
{
public void Run()
{//...
}
}
public class CrossCountry : Runner
{
public void Run()
{//...}
}
}
public class AutoApplication
{
private static List<Runner> runnerList = new List<Runner>();
public static void register(Runner runner)
{
runnerList.Add(runner);
}
public static void main(String[] args)
{
foreach (Runner runner in runnerList)
{
runner.Run();
}
}
}
程序中间的注释已经表示了，上面的情况，开发者自己按流程进行开发，容易成为面向过程的方式进行开发。
对比，下面的情况，开发者只需要实现程序的功能，具体的调用和实例化可以有框架完成