设计模式的六大原则

程序开发中， 需要使程序有高内聚， 低耦合的特性，才会使得程序易维护， 可扩展， 又可靠。 而如何保证程序符合这个要求呢？ 我们则设计中需要尽量遵守6大原则。

单一职责原则

对类来说， 一个类只负责单一职责。 当然也可以宽泛的说， 微服务中一个服务只负责单一的功能。 对于数据库来说， 一个库只负责记录单一的一类数据。

这个原则的理解很简单，但是难的地方就是则单一职责的划分上。现实中往往有很多的类即属于职责A 又可以归类于职责B， 此时很难划分职责。

也有可能如果强行遵守单一职责原则，代码的调用组织就很麻烦， 还不如把功能写在一个类中。

在实际的开发中我们就需要根据未来的可能进行考量了，如果未来A和B两个功能肯定会发生变动，那么你再设计开始的时候，就应该遵守， 不要把他们写在一个类（模块，微服务）中。

根据我现实中的经验， 随着项目的发展，接口越来越多了， 我们往往新增接口的时候就在controller中增加一个方法， 导致的结果就是一个controller中包含四五十个接口， 对应的Service类中方法更多， 越来越臃肿。 所以我们设计的时候有两种办法。

1. 根据接口的参数不同， 使得同一个接口实现多个功能，
   比如： 新增和修改使用同一个接口 ； 分页查询和单个查询使用同一个接口；
   但是这样就会导致方法的功能庞大， 高度耦合， 让人看不懂一个方法的功能。
2. 每个不同的功能新增一个接口， 这样会使得接口数量爆炸， controller中方法很多， 这个时候就需要考虑单一职责的原则， 进行拆分了。

这个职责主要维护程序的可扩展性。

接口隔离原则

这个接口是指宽泛的接口， 一个类只要依赖他需要的最小接口就可以了， 不要依赖他不需要的接口方法。

我们应该都知道面向抽象编程，而这个抽象就是广义上的接口。 如果一个接口A中方法很多 ，但是其实现类C只需要实现其中的几个方法就可以， 此时直接C继承接口A来编程， 就会把不相关的接口也必须实现，此时就违反了接口隔离职责了。

此时的做法就是把A接口拆分成更小的多个接口， 接口拆分的越小就越容易符合接口隔离原则。 但是接口越小就会导致程序中结构越复杂，维护有点困难。

这个原则主要是为了维护程序的健壮性的。 但是不利于可维护性。

依赖倒置原则

• 高层模块不要依赖低层模块
• 依赖抽象， 不要依赖具体的实现， 面向接口编程
• 依赖的对象是由外部传入。

Spring的依赖注入就是典型的这个原则的应用， 这个原则就是就A类的依赖不要A类来创建， 要由外部传入依赖， 并且A类要依赖抽象，不要是具体的实现类。

里式替换原则

子类可以扩展父类的功能， 但是不要修改父类的功能。 符合这个要求，如果依赖A类来实现功能， 那么依赖A类的子类一样也没有问题。

继承是一个很好的代码复用和扩展功能的方式，但是如果我们使用继承的时候没有约束，随意的复写扩展方法， 由于java的多态性， 会导致程序容易出现问题， 所以遵守里式替换原则就会大大提高程序的健壮性了。

迪米特原则

最少知道原则， 一个类对于依赖的类知道的功能最少， 这样他只能调用他知道的少量方法，不会出现问题。 提高的程序的健壮性。

这个原则和接口隔离原则相互配合， 相得益彰。

程序开发中，我们往往为了图方便把一个大类直接作为依赖传入， 这是不符合这个原则的， 因为你传入了太多的不需要的功能（方法）， 如果被乱调用了会危害程序的安全， 所以你只要传入最少的依赖功能进去就可以了。

开闭原则

最基础， 最重要的设计原则。 对扩展开放，对修改关闭。

对修改关闭： 是对于使用方说的， 使用方无法修改功能，并且功能变化了时候，使用方式也不用改。

对扩展开发: 是对提供方说的， 提供方不要修改原有功能， 要通过扩展的方式进行提供新功能。

理解： 程序中需求是变化的， 那么对于程序的功能也是经常改变的， 而这个原则就是要求我们对于程序功能的改变 不要通过直接修改功能代码来实现， 而是通过扩展相关的类（模块）来实现。

而要符合这个要求， 就需要我们有良好的设计， 并且前面的5个原则也是为了实现 这一个原则的。 同时大量的设计模式也是未来保证这个原则的。