solid原则

solid原则由如下5个原则组合而成。

S:单一职责原则
一个类只代表一种对象定义，只做一种类型责任。如果某个类承担了其他类型责任的时候，就需要分解这个类了。如果将多个功能放在同一个类中，功能之间就形成了关联，改变其中一个功能，就可能影响到另一个功能，就需要新一轮的测试来避免可能出现的问题，非常耗时耗力。

O:开闭原则
软件实体应该是可扩展的，而不是可修改的。对扩展开放，对修改封闭。对于该原则可解释为：

通过增加代码来扩展功能，而不是修改已经存在的代码；
若客户模块和服务模块遵循同一个接口来设计，则客户模块可以不关心服务模块的类型，服务模块可以方便扩展代码。
OCP支持替换的服务，而不用修改客户模块。
L：里式替换原则
凡是父类出现的地方，都可以用子类替换。另外，不应该 在代码中出现if/else之类对子类类型进行判断的条件。子类可以代替基类，客户使用基类，他们不需要知道派生类所做的事情。这是一个针对行为职责可替代的原则，如果S是T的子类型，那么S对象就应该在不改变任何抽象属性情况下替换所有T对象。

I：接口隔离原则
使用多个专门的接口比使用单一的总接口总要好。注意：在代码中应用ISP并不一定意味着服务就是绝对安全的。仍然需要采用良好的编码实践，以确保正确的验证与授权。
对于一个大型的系统功能，需要拆分为多个小功能，那么这个时候我们是写一个庞大的类来实现所有的功能接口呢，还是拆分多多个接口，并建立不同的实现类呢？
正确的选择是把单个接口分开，客户可以按需继承单一功能接口子类。

D：依赖反转原则
依赖反转原则认为一个类或者方法应该遵从”依赖抽象而不是一个实例“的概念。高层模块不应该依赖于底层模块，二者都应该依赖于抽象。
抽象不应该依赖于细节，细节应该依赖于抽象。
类可能依赖于其他类来执行其工作。但是，它们不应当依赖于该类的特定具体实现，而应当是它的抽象。这个原则实在是太重要了，社会的分工化，标准化都 是这个设计原则的体现。显然，这一概念会大大提高系统的灵活性。如果类只关心它们用于支持特定契约而不是特定类型的组件，就可以快速而轻松地修改这些低级 服务的功能，同时最大限度地降低对系统其余部分的影响。

标签：功能,原则,solid,依赖于,抽象,接口,模块
来源： https://www.cnblogs.com/andy0816/p/16355245.html