我对软件设计原则的理解我对软件设计原则的理解

1. 开闭原则软件实体（class，模块，功能或业务，微服务etc）对修改关闭，对拓展开放。
抽象构建框架，实现拓展细节。
面向抽象编程，而不是面向具体实现编程。因为抽象相对来说是稳定的，让类去依赖于固定的抽象，所有对于修改来说就是封闭的，通过OO的继承，多态机制就可以实现对抽象体的拓展，通过重写改变固有的方法或者实现新的拓展方法。
2. 依赖倒置原则高层实现不应该直接依赖于低层实现，它们应该依赖于共同的抽象（低层接口）。
越基础的模块发生变化影响的范围越大。
案例1：三层架构 service（高层） -> dao（低层）
【我对软件设计原则的理解】service的实现类不应该直接依赖于dao的实现类，而是应该依赖dao的接口。这样做的好处就是在不需要修改service实现类和dao实现类的情况下，对dao的实现类进行拓展，符合开闭原则。
service实现类和dao实现类是解耦合的，但service实现类和dao接口是低耦合的，符合高内聚低耦合。
举例：
service实现类中的dao本来使用jdbc实现，现在需要使用hibernate实现。我们就可以在保留原来jdbc实现的dao，通过拓展dao接口的方式，开发hibernate实现的dao。

service实现

public class UserServiceImpl { private UserDao userDao; public List getUserList() { return userDao.findAll(); } }

使用hibernate实现的dao

public class userDaoHibernateImpl { public User findAll() { // hibernate... } }

使用jdbc实现的dao

public class userDaoJdbcImpl { public User findAll() { // jdbc... } }

service实现类获取dao实现类的一些变式：

方法参数。eg：getUserList(UserDao userDao)
构造器注入
setter注入

案例2：框架原理 TODO 李智慧
3. 单一职责原则不要存在多于一个导致类变更的原因。
一个类只负责一种职责，从类的方法上来考虑就是一个类可能存在多个方法，但这些方法的功能类似，都是为了完成同一种职责。
适用于类、接口、方法等，减少复杂度、提高可读性和可维护性。
4. 接口隔离原则该原则针对接口。要求在适度该原则的情况下，尽量细化接口（接口中的方法尽量少，完成的功能尽量单一），过大的接口不利于维护，过小的接口会提高系统的复杂性，也不利于后期维护。
一个类不应该实现不需要的接口方法。
细粒度可组装，粗粒度不可拆分。
高内聚低耦合：高内聚要求减少对外交互，使接口中最少的方法去完成最多的事情。低耦合要求降低依赖关系。
5. 迪米特原则最少知道原则，一个对象应对其他对象保持最少的了解。
减少类之间不必要的依赖，尽量降低类之间的耦合，提高类的复用率。
适当使用访问权限。
该原则要求只和朋友交流，不和陌生人交流。那么对于一个类来说，哪些是朋友？哪些是陌生人？