我对软件设计原则的理解

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. 迪米特原则

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

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

适当使用访问权限。

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

  • 朋友
    • 对象组合
    • 对象依赖。输入参数,输出返回值。
  • 陌生人
    • 方法体内中的类

你可能感兴趣的:(我对软件设计原则的理解)