【设计模式】设计模式简述

最新推荐文章于 2021-09-23 08:43:52 发布

原创最新推荐文章于 2021-09-23 08:43:52 发布 · 269 阅读

0 ·

CC 4.0 BY-SA版权

设计模式专栏收录该内容

2 篇文章

订阅专栏

部署运行你感兴趣的模型镜像

设计模式的六大原则

开闭原则、里氏代换原则、依赖倒转原则、单一职责原则、接口隔离原则、迪米特法则

开闭原则（Open Close Principle）：
应该对于扩展是开放的，对修改是关闭的。在程序需要进行拓展的时候，不能去修改原有的代码，实现热插拔的效果。通常需要制定需要使用接口和抽象类。

好处：为了使程序的扩展性好，易于维护和升级

参考：https://www.cnblogs.com/az4215/p/11489712.html

里氏代换原则(Liskov Substitution Principle LSP)：
子类型必须能够替换掉他们的父类型。如果子类继承自父类，那么子类就应该能以父类的身份出现。简单说，如果一个软件实体使用的是一个父类的话，那么就肯定适用其子类，并且该软件实体察觉不到父类对象和子类对象的区别。

举个例子，有个很厉害的老木匠，周边的邻居都找他做家具，老木匠还有个大徒弟，不但学全了老木匠的本事还青出于蓝而胜于蓝。后来老木匠干不动了，所以每次有人找上门来都是老木匠接活儿，大徒弟去做家具，而对做家具的人来说，他们并不关心具体谁做的，只要能拿到家具就好。

参考：https://blog.youkuaiyun.com/icerain_520/article/details/77611271
优点缺点：https://baijiahao.baidu.com/s?id=1590530739538094942&wfr=spider&for=pc

依赖倒置原则
抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。在语言中表现，模块间的依赖是通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的

好处：可以减少类间的耦合性，提高系统的稳定性，减少并行开放引起的风险，提高代码的可读性和可维护性。并行开发就要解决模块之间的项目依赖关系

参考：https://blog.youkuaiyun.com/u013862108/article/details/79054620

没有进行依赖倒置的图

依赖倒置的图

单一职责原则
一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。
单一职责原则是实现高内聚、低耦合的指导方针，它是最简单但又最难运用的原则
单一职责原则是最简单的面向对象设计原则，它用于控制类的粒度大小

好处：减少代码的冗余，同时做到易修改。职责单一，可以复用。

参考：https://www.cnblogs.com/Gang-Bryant/p/10761077.html

接口隔离原则
客户端不应该依赖它不需要的接口，类间的依赖关系应该建立在最小的接口上。想把接口用好，关键在于隔离。接口中没有多余的方法，所以这里的隔离是指和多余的方法隔离。

好处：避免接口污染，提高灵活性（一个类是可以同时实现多个接口的，所以将一个臃肿的接口分割为若干个小接口，通过小接口的不同组合可以满足更多的需求），提供定制服务

参考：https://www.jianshu.com/p/4ce9db323348

迪米特法则
一个对象应该对其他对象有最少的了解。迪米特法则的意义在于降低类之间的耦合。只和直接的朋友交流。只出现在方法体内部的类就不是直接的朋友，如果一个类和不是直接的朋友进行交流，就属于违反迪米特法则。说白了就是两个点：
暴露该暴露的接口
只和直接朋友进行交互，直接朋友就是全局变量或者方法的入参

好处：面向对象编程中，类之间的相互调用是很常见的，我们经常需要在一个类中访问另一个类的成员或方法。问题是，如果类经常被调用的话，我们就要考虑到代码的可维护性和复用性。程序中代码的耦合过高可不是一件好事

参考：
https://segmentfault.com/a/1190000017779269

总体来说设计模式分为三大类：

创建型模式 - 共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。
结构型模式 - 共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。
行为型模式 - 共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

您可能感兴趣的与本文相关的镜像