类设计常归于SOLIP原则，虽然早有耳闻，但是一直未曾探其究竟，最近看这本书看到了作者相关的理解，遂加上自己的理解做为笔记。
1、S-SRP 单一职责原则
书中关于此原则讲解
①具象化概念为“职责”，比如快递员的工作职责有分包、快递、收款、开会，是从公司、部门等更上级单位定义而来；（这一点跟面向对象开发的抽象思想差不多）。
②“一个类只负责一组相关的事情”，一个类有多个方法，且这些方法是相关的。
③适用于基础类，而不适用于聚合类；比如办公一体机包含的模块打印机、复印机、扫描仪、传真机，虽说办公一体机是一个整体，但是模块之间并没什么关联，也就不适用此原则了。
笔者理解
①小作坊公司对于设计原则其实并不会太在意，说出这个名词也没几个人懂，但是有一定开发经验的人，其实都会一定程度的遵循此原则做类设计；
如果类的定义不明确，新人接手维护、读代码都会很困难，就算是作者，时间久了也会忘了某个方法在哪，所以类划分的清晰就是便人便己。
②常规业务系统开发其实不太适用，业务系统面向的是各种业务流程，或者第三方接口的共享扩展；
在此场景下，习惯性是将一类业务属性相近、或者隶属同一个模块的方法放到一个类，类里面的方法都没什么相关。
③此原则在实际工作中比较适用于共享接口的整合类，比如一个电子证照需要经过创建、签发、归档的3个基本流程，封装成证照签发类的方法，就比较合适了；或者就是对单表、单数据源的简单维护，CURD工作。
2、O-OCP 开闭原则
书中关于此原则讲解
①对提供者扩展开放，对使用者修改封闭。前辈的通俗化：不修改代码就可以增加新功能！
②所谓的增加新功能，并是增加一个全新的功能，而是说能完全替代现有功能。比如说赛车游戏中的player类，当传参car供驾驶的时候，这个car可以是卡车、跑车、家用车，只要他们的功能都是一样的加速、刹车、转向，就能兼容。
③适用于接口完全不变的情况，包括函数名、函数参数、函数返回值等。当有任何一个变化，则无法应用。
④此概念也可用于系统交互，类之间用interface交互，系统与系统、模块与模块之间通过HTTP、SOAP等协议交互。
笔者理解
①核心逻辑其实是使用一个抽象类作为入参，然后对这个类进行派生，实现兼容，这样子使用者无需考虑兼容问题。
②类似概念的应用主要用于一个查询结果聚合类，多个来源、不同格式的数据查询，抽象出关键信息，记录查询日志用作数据分析、审计，需要抽象类的逻辑大部分都会适用。
③这个概念更适用于类交互、模块交互、系统交互；比如通过interface做类交互适用于团队开发，这样子大家互不干扰，也不担心代码没写完这边就进行不下去，或是通过Http做系统交互，对于前后端分离时基于Http做Json串的交互，也就能实现互不干扰。
3、L-LSP 里氏替换原则
书中关于此原则讲解
①简单概括：子类必须能替换成它们的父类。
从实现的角度就是子类必须实现或者继承父类所有的公有方法，且子类的方法入参要与父类一致，方法的输出要多于等于父类的输出，此输出包括返回值、修改全局变量、插入数据库、发送网络数据等。
②父类与子类的区别在于内部的处理过程。比如有个数据抓取的父类，可以派生成从XML获取数据，从数据库获取数据，入参都是查询条件，输出都是相同格式的查询结果。
③判断子类是否符合LSP，可对父类、子类进行同一个单元测试，如果输出结果一致，则说明符合LSP。
笔者理解
①总体跟OCP概念没什么区别，还是那句“对提供者扩展开放，对使用者修改封闭”。可以不调整原有代码，把有特殊需求的方法的入参类，从父类修改为特定的子类。
4、I-ISP 接口隔离原则
书中关于此原则讲解
①客户端不应该被强迫去依赖它们并不需要的接口。
②ISP应用的场景是某些类不满足SRP，但使用这些类的客户端（即调用类）应该根据父类来使用它们，而不是直接使用它们。如第一个SRP原则中的矛盾类“办公一体机”。
笔者理解
①简单来说就是当类不适用SRP，类内部不能只有相关的基础方法时适用这个原则。
②感觉就是圆一下SRP设计模式，毕竟那个模式太理想了，具体原因可以看下笔者对于SRP的理解。
5、D-DIP 依赖反转原则
书中关于此原则讲解
①高层模块不应该直接依赖低层模块，两者都应该抽象层。
②抽象不能依赖细节，细节必须依赖抽象。
笔者理解
①这个模式比较出名，从我理解来说就是软件开发分个层；
高层就是各个抽象类，比如常见的数据库操作抽象类、日志抽象类；
低层就是各个调用类，这些类的入参就是高层的抽象类，接收到入参后再实例化抽象成所需的派生类，这样子可以实现入口的统一，并且不用依赖高层代码必须实现就可以先进行开发。
②这个概念最清晰，且最接地气，本文读者看下真正的项目代码应该都能看到类似痕迹，就算不是刻意应用这个原则，实现出来也是差不多意思。
引用下书中的关于各个原则的场景总结：
①SRP：用于类的设计
②OCP：总的指导思想
③LSP：用于指导类继承的设计
④ISP：用于指导接口的设计
⑤DIP：用于指导如何抽象
⑥NOP：不要过度设计原则
再加上笔者的总结，最有用的就是DIP跟NOP，DIP是实实在在解决团队开发问题，NOP也是实实在在的帮助公司赚钱~
标签：一书,原则,子类,编程,SRP,抽象类,父类,交互,原证 From： https://www.cnblogs.com/PoliElena/p/17251212.html