目录

开发中用到的设计模式

工厂模式

设计理念

好处

体现的编程思想

适配器模式

概念

策略模式和适配器模式的区别

选择策略模式而非适配器模式的原因

设计模式的开发原则

---

开发中用到的设计模式

在开发过程中，常见的设计模式会根据不同的业务场景和需求被广泛使用，以下是一些例子：

• 单例模式：确保一个类只有一个实例，并提供一个全局访问点。比如在配置管理类、日志记录器等场景中，使用单例模式可以避免多个实例造成的资源浪费和数据不一致问题。
• 工厂模式：将对象的创建和使用分离，通过一个工厂类来创建对象。在需要创建多种不同类型对象的场景中，如创建不同数据库连接对象时，使用工厂模式可以提高代码的可维护性和可扩展性。
• 观察者模式：定义了一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖它的对象都会得到通知并自动更新。常见于事件处理系统、消息通知系统等。
• 装饰器模式：动态地给一个对象添加一些额外的职责。在 Java 的 I/O 流体系中就广泛使用了装饰器模式，通过不同的装饰器类可以为基本的输入输出流添加缓冲、加密等功能。

工厂模式

设计理念

工厂模式的核心设计理念是将对象的创建逻辑封装在一个工厂类中，而不是在客户端代码中直接实例化对象。客户端只需要向工厂类请求所需的对象，而不需要关心对象是如何创建的。这样可以将对象的创建和使用分离，提高代码的可维护性和可扩展性。

好处

• 解耦对象的创建和使用：客户端代码只需要使用对象，而不需要关心对象的创建细节，降低了代码的耦合度。例如，在一个游戏开发中，不同类型的武器有不同的创建逻辑，使用工厂模式可以将武器的创建逻辑封装在工厂类中，游戏代码只需要从工厂获取武器，而不需要了解每种武器的具体创建过程。
• 提高代码的可维护性：当对象的创建逻辑发生变化时，只需要修改工厂类的代码，而不需要修改所有使用该对象的客户端代码。比如，如果要修改某个对象的初始化参数，只需要在工厂类中进行修改即可。
• 便于扩展：当需要添加新的对象类型时，只需要在工厂类中添加相应的创建逻辑，而不需要修改客户端代码。例如，在一个图形绘制系统中，如果要添加一种新的图形类型，只需要在图形工厂类中添加创建该图形的方法。

体现的编程思想

工厂模式体现了面向对象编程中的 “依赖倒置原则” 和 “开闭原则”。依赖倒置原则强调高层模块不应该依赖低层模块，两者都应该依赖抽象。工厂模式通过抽象工厂和具体工厂的设计，使得客户端代码依赖于抽象的工厂接口，而不是具体的工厂实现类。开闭原则要求软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。工厂模式在添加新的对象类型时，只需要扩展工厂类，而不需要修改已有的客户端代码，符合开闭原则。

适配器模式

概念

适配器模式是一种结构型设计模式，它允许将一个类的接口转换成客户端所期望的另一个接口。适配器模式可以让原本不兼容的类能够一起工作。常见的有类适配器和对象适配器两种实现方式。例如，在 Java 中，将一个旧的日志记录类的接口适配成新的日志框架的接口，就可以使用适配器模式。

策略模式和适配器模式的区别

• 目的不同
  • 策略模式：主要用于定义一系列的算法，并将每个算法封装起来，使它们可以相互替换。策略模式让算法的变化独立于使用算法的客户端。例如，在一个电商系统中，对于不同的促销活动（如满减、折扣、赠品等）可以使用策略模式，将每种促销算法封装成一个策略类，客户端可以根据不同的需求选择不同的策略。
  • 适配器模式：主要用于解决接口不兼容的问题，使原本不兼容的类能够协同工作。例如，将一个第三方库的接口适配成自己系统所需的接口。
• 使用场景不同
  • 策略模式：适用于需要在运行时动态选择不同算法的场景，算法的选择由客户端决定。
  • 适配器模式：适用于需要复用已有的类，但该类的接口与当前系统不兼容的场景。

选择策略模式而非适配器模式的原因

如果需求是在多个可互换的算法中进行动态选择，以满足不同的业务场景，那么策略模式是更合适的选择。而适配器模式主要是解决接口不兼容问题，如果没有接口不兼容的情况，使用策略模式可以更好地实现算法的封装和替换，提高代码的灵活性和可维护性。例如，在一个图像处理系统中，对于不同的图像压缩算法（如 JPEG、PNG 等），使用策略模式可以方便地在不同算法之间切换，而不需要考虑接口不兼容的问题。

设计模式的开发原则

设计模式遵循一些基本的开发原则，这些原则有助于提高代码的可维护性、可扩展性和可复用性，以下是一些常见的原则：

• 单一职责原则（SRP）：一个类应该只有一个引起它变化的原因。也就是说，一个类应该只负责一项职责。例如，一个用户管理类应该只负责用户的增删改查操作，而不应该同时负责用户的权限验证和日志记录等其他职责。
• 开闭原则（OCP）：软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。即当需求发生变化时，应该通过扩展代码来实现，而不是修改已有的代码。例如，在一个图形绘制系统中，当需要添加新的图形类型时，应该通过扩展图形类和绘制方法来实现，而不是修改已有的图形绘制代码。
• 里氏替换原则（LSP）：子类可以替换父类并且不会影响程序的正确性。也就是说，子类应该能够完全替代父类，并且不会破坏程序的原有功能。例如，在一个动物类层次结构中，子类猫和狗应该能够替代父类动物，并且不会影响程序的正常运行。
• 依赖倒置原则（DIP）：高层模块不应该依赖低层模块，两者都应该依赖抽象。抽象不应该依赖细节，细节应该依赖抽象。例如，在一个电商系统中，订单处理模块（高层模块）不应该直接依赖具体的数据库操作类（低层模块），而是应该依赖一个抽象的数据库操作接口。
• 接口隔离原则（ISP）：客户端不应该依赖它不需要的接口。一个类对另一个类的依赖应该建立在最小的接口上。例如，在一个系统中，如果一个客户端只需要使用某个接口的部分方法，那么应该将这个接口拆分成多个更小的接口，让客户端只依赖它需要的接口。
• 迪米特法则（LoD）：一个对象应该对其他对象有最少的了解。也就是说，一个类应该尽量减少与其他类的交互，只与直接的朋友进行通信。例如，在一个社交网络系统中，一个用户类应该只与直接相关的好友类、消息类等进行交互，而不应该与其他不相关的类进行过多的交互。