solid原则由如下5个原则组合而成。
S:单一职责原则
一个类只代表一种对象定义，只做一种类型责任。如果某个类承担了其他类型责任的时候，就需要分解这个类了。如果将多个功能放在同一个类中，功能之间就形成了关联，改变其中一个功能，就可能影响到另一个功能，就需要新一轮的测试来避免可能出现的问题，非常耗时耗力。
O:开闭原则
软件实体应该是可扩展的，而不是可修改的。对扩展开放，对修改封闭。对于该原则可解释为：
通过增加代码来扩展功能，而不是修改已经存在的代码；
若客户模块和服务模块遵循同一个接口来设计，则客户模块可以不关心服务模块的类型，服务模块可以方便扩展代码。
OCP支持替换的服务，而不用修改客户模块。
L：里式替换原则
凡是父类出现的地方，都可以用子类替换。另外，不应该 在代码中出现if/else之类对子类类型进行判断的条件。子类可以代替基类，客户使用基类，他们不需要知道派生类所做的事情。这是一个针对行为职责可替代的原则，如果S是T的子类型，那么S对象就应该在不改变任何抽象属性情况下替换所有T对象。
I：接口隔离原则
使用多个专门的接口比使用单一的总接口总要好。注意：在代码中应用ISP并不一定意味着服务就是绝对安全的。仍然需要采用良好的编码实践，以确保正确的验证与授权。
对于一个大型的系统功能，需要拆分为多个小功能，那么这个时候我们是写一个庞大的类来实现所有的功能接口呢，还是拆分多多个接口，并建立不同的实现类呢？
正确的选择是把单个接口分开，客户可以按需继承单一功能接口子类。
D：依赖反转原则
依赖反转原则认为一个类或者方法应该遵从”依赖抽象而不是一个实例“的概念。高层模块不应该依赖于底层模块，二者都应该依赖于抽象。
抽象不应该依赖于细节，细节应该依赖于抽象。
类可能依赖于其他类来执行其工作。但是，它们不应当依赖于该类的特定具体实现，而应当是它的抽象。这个原则实在是太重要了，社会的分工化，标准化都 是这个设计原则的体现。显然，这一概念会大大提高系统的灵活性。如果类只关心它们用于支持特定契约而不是特定类型的组件，就可以快速而轻松地修改这些低级 服务的功能，同时最大限度地降低对系统其余部分的影响。
标签：功能,原则,solid,依赖于,抽象,接口,模块 来源： https://www.cnblogs.com/andy0816/p/16355245.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。