我对软件设计原则的理解

1. 开闭原则

软件实体（class，模块，功能或业务，微服务etc）对修改关闭，对拓展开放。

抽象构建框架，实现拓展细节。

面向抽象编程，而不是面向具体实现编程。因为抽象相对来说是稳定的，让类去依赖于固定的抽象，所有对于修改来说就是封闭的，通过OO的继承，多态机制就可以实现对抽象体的拓展，通过重写改变固有的方法或者实现新的拓展方法。

2. 依赖倒置原则

高层实现不应该直接依赖于低层实现，它们应该依赖于共同的抽象（低层接口）。

越基础的模块发生变化影响的范围越大。

service（高层） -> dao（低层）

service的实现类不应该直接依赖于dao的实现类，而是应该依赖dao的接口。这样做的好处就是在不需要修改service实现类和dao实现类的情况下，对dao的实现类进行拓展，符合开闭原则。

service实现类和dao实现类是解耦合的，但service实现类和dao接口是低耦合的，符合高内聚低耦合。

举例：

service实现类中的dao本来使用jdbc实现，现在需要使用hibernate实现。我们就可以在保留原来jdbc实现的dao，通过拓展dao接口的方式，开发hibernate实现的dao。

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

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

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

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

TODO 李智慧

不要存在多于一个导致类变更的原因。

一个类只负责一种职责，从类的方法上来考虑就是一个类可能存在多个方法，但这些方法的功能类似，都是为了完成同一种职责。

适用于类、接口、方法等，减少复杂度、提高可读性和可维护性。

该原则针对接口。要求在适度该原则的情况下，尽量细化接口（接口中的方法尽量少，完成的功能尽量单一），过大的接口不利于维护，过小的接口会提高系统的复杂性，也不利于后期维护。

一个类不应该实现不需要的接口方法。

细粒度可组装，粗粒度不可拆分。

高内聚低耦合：高内聚要求减少对外交互，使接口中最少的方法去完成最多的事情。低耦合要求降低依赖关系。

最少知道原则，一个对象应对其他对象保持最少的了解。

减少类之间不必要的依赖，尽量降低类之间的耦合，提高类的复用率。

适当使用访问权限。

该原则要求只和朋友交流，不和陌生人交流。那么对于一个类来说，哪些是朋友？哪些是陌生人？

最后编辑于：2019.08.07 17:31:09