Java单体应用 - 架构模式 - 03.设计模式

Posted 2021-03-06

原文地址：http://www.work100.net/training/monolithic-architecture-design-patterns.html
更多教程：光束云 - 免费课程

简介

序号	文内章节	视频
1	概述	-
2	设计原则	-

请参照如上章节导航进行阅读

1.概述

设计模式（Design pattern）代表了最佳的实践，通常被有经验的面向对象的软件开发人员所采用。
设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。
这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。
这些模式或者可以简化代码，或者可以使代码逻辑看起来清晰，或者对功能扩展很方便。

设计模式按照使用场景可以分为三大类：

1.1.创建型模式（Creational Patterns）- 5个

这些设计模式提供了一种在创建对象的同时隐藏创建逻辑的方式，而不是使用 new 运算符直接实例化对象。
这使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活。

• 工厂模式（Factory Pattern）
• 抽象工厂模式（Abstract Factory Pattern）
• 单例模式（Singleton Pattern）
• 建造者模式（Builder Pattern）
• 原型模式（Prototype Pattern）

1.2.结构型模式（Structural Patterns）- 8个

这些设计模式关注类和对象的组合。继承的概念被用来组合接口和定义组合对象获得新功能的方式。

• 适配器模式（Adapter Pattern）
• 桥接模式（Bridge Pattern）
• 过滤器模式（Filter、Criteria Pattern）
• 组合模式（Composite Pattern）
• 装饰器模式（Decorator Pattern）
• 外观模式（Facade Pattern）
• 享元模式（Flyweight Pattern）
• 代理模式（Proxy Pattern）

1.3.行为型模式（Behavioral Patterns）- 12个

行为模式不仅表达了对象和类，还表达了他们之间的交互，涉及到了对象和算法的分配。

• 责任链模式（Chain of Responsibility Pattern）
• 命令模式（Command Pattern）
• 解释器模式（Interpreter Pattern）
• 迭代器模式（Iterator Pattern）
• 中介者模式（Mediator Pattern）
• 备忘录模式（Memento Pattern）
• 观察者模式（Observer Pattern）
• 状态模式（State Pattern）
• 空对象模式（Null Object Pattern）
• 策略模式（Strategy Pattern）
• 模板模式（Template Pattern）
• 访问者模式（Visitor Pattern）

2.设计原则

为了便于记忆，我们可以使用一个口诀来记忆面向对象设计原则：开口合里最单依

• 开：开闭原则
• 口：接口隔离原则
• 合：组合/聚合原则
• 里：里式替换原则
• 最：最少知识原则（迪米特法则）
• 单：单一职责原则
• 依：依赖倒置原则

2.1.开闭原则(Open-Closed Principle, OCP)

开闭原则的意思是：对扩展开放，对修改关闭。

在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。
简言之，是为了使程序的扩展性好，易于维护和升级。
想要达到这样的效果，我们需要使用接口和抽象类，这是面向对象设计（OOD）的基石，也是最重要的原则。

2.2.接口隔离原则(Interface Segregation Principle, ISP)

一个类对另外一个类的依赖是建立在最小的接口上。

使用多个专门的接口比使用单一的总接口要好。根据客户需要的不同，而为不同的客户端提供不同的服务是一种应当得到鼓励的做法。
就像"看人下菜"一样，要看客人是谁，再提供不同档次的饭菜。
胖接口会导致他们的客户程序之间产生不正常的并且有害的耦合关系。
当一个客户程序要求该胖接口进行一个改动时，会影响到所有其他的客户程序。
因此客户程序应该仅仅依赖他们实际需要调用的方法。

2.3.组合/聚合复用原则(Composite/Aggregate Reuse Principle，CARP)

在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分。
新的对象通过这些向对象的委派达到复用已有功能的目的。

这个设计原则有另一个简短的表述：要尽量使用合成/聚合，尽量不要使用继承。

2.4.里氏代换原则(Liskov Substitution Principle，LSP)

由 Barbar Liskov (芭芭拉.里氏) 提出，是继承复用的基石。

所有引用基类的地方必须透明的使用其子类的对象。只要父类能出现的地方子类也可以出现，而且替换为子类不会产生任何错误或异常，但是反过来就不行，有子类出现的地方，父类未必就能适应。

2.5.最少知识原则(Least Knowledge Principle，LKP)

一个对象应当对其他对象有尽可能少的了解。
没有任何一个其他的 OO 设计原则象迪米特法则这样有如此之多的表述方式,如下几种：

• 只与你直接的朋友们通信(Only talk to your immediate friends)
• 不要跟"陌生人"说话(Don‘t talk to strangers)
• 每一个软件单位对其他的单位都只有最少的知识,而且局限于那些本单位密切相关的软件单位

就是说，如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用，如果其中的一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。

2.6.单一职责原则(Simple responsibility pinciple，SRP)

就一个类而言，应该仅有一个引起它变化的原因，如果你能想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责。
应该把多于的指责分离出去，分别再创建一些类来完成每一个职责。

2.7.依赖倒置原则(Dependence Inversion Principle)

这个原则是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体。

要求客户端依赖于抽象耦合：

• 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的。
• 接口或抽象类不依赖实现类
• 实现类依赖接口或抽象类

采用依赖倒置原则可以减少类间的耦合性，提高系统的稳定，降低并行开发引起的风险，提高代码的可读性和可维护性。

---

上一篇：MVC架构
下一篇：工厂模式

---

如果对课程内容感兴趣，可以扫码关注我们的 公众号 或 QQ群，及时关注我们的课程更新