设计模式
设计模式
池慕睡不着设计模式
设计模式(Design pattern)代表了最佳的实践,通常被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。
创建型模式
工厂方法、抽象工厂、生成器、原型、单例
1.工厂模式
工厂模式是Java中最常用的设计模式之一,他提供了一种创建对象的方式,使得创建对象的过程分离,到达解耦的效果。
通过使用工厂模式,可以将对象的创建逻辑封装在一个工厂类中,而不是在业务代码中直接实例化对象,这样可以提高代码的可维护性和可拓展性。
工厂模式的类型
- 简单工厂模式(Simple Factory Pattern):
- 简单工厂模式不是一个正式的设计模式,但它是工厂模式的基础。它使用一个单独的工厂类来创建不同的对象,根据传入的参数决定创建哪种类型的对象。
- 工厂方法模式(Factory Method Pattern):
- 工厂方法模式定义了一个创建对象的接口,但由子类决定实例化哪个类。工厂方法将对象的创建延迟到子类。
- 抽象工厂模式(Abstract Factory Pattern):
- 抽象工厂模式提供一个创建一系列相关或互相依赖对象的接口,而无需指定它们具体的类。
概要
意图
定义一个创建对象的接口,让其子类决定实例化哪一个具体的类。工厂模式使对象的创建过程延迟到子类。
主要解决
接口选择的问题。
何时使用
当我们需要在不同条件下创建不同实例时。
如何解决
通过让子类实现工厂接口,返回一个抽象的产品。
关键代码
对象的创建过程在子类中实现。
应用实例
- 汽车制造:你需要一辆汽车,只需从工厂提货,而不需要关心汽车的制造过程及其内部实现。
- Hibernate:更换数据库时,只需更改方言(Dialect)和数据库驱动(Driver),即可实现对不同数据库的切换。
优点
- 调用者只需要知道对象的名称即可创建对象。
- 扩展性高,如果需要增加新产品,只需扩展一个工厂类即可。
- 屏蔽了产品的具体实现,调用者只关心产品的接口。
缺点
每次增加一个产品时,都需要增加一个具体类和对应的工厂,使系统中类的数量成倍增加,增加了系统的复杂度和具体类的依赖。
使用场景
- 日志记录:日志可能记录到本地硬盘、系统事件、远程服务器等,用户可以选择记录日志的位置。
- 数据库访问:当用户不知道最终系统使用哪种数据库,或者数据库可能变化时。
- 连接服务器的框架设计:需要支持 “POP3”、”IMAP”、”HTTP” 三种协议,可以将这三种协议作为产品类,共同实现一个接口。
注意事项
工厂模式适用于生成复杂对象的场景。如果对象较为简单,通过 new 即可完成创建,则不必使用工厂模式。使用工厂模式会引入一个工厂类,增加系统复杂度。
结构
工厂模式包含以下几个主要角色:
- 抽象产品(Abstract Product):定义了产品的共同接口或抽象类。它可以是具体产品类的父类或接口,规定了产品对象的共同方法。
- 具体产品(Concrete Product):实现了抽象产品接口,定义了具体产品的特定行为和属性。
- 抽象工厂(Abstract Factory):声明了创建产品的抽象方法,可以是接口或抽象类。它可以有多个方法用于创建不同类型的产品。
- 具体工厂(Concrete Factory):实现了抽象工厂接口,负责实际创建具体产品的对象。
实现
我们将创建一个 Shape 接口和实现 Shape 接口的实体类。下一步是定义工厂类 ShapeFactory。
FactoryPatternDemo 类使用 ShapeFactory 来获取 Shape 对象。它将向 ShapeFactory 传递信息(CIRCLE / RECTANGLE / SQUARE),以便获取它所需对象的类型。
结构型模式
适配器模式、桥接模式、组合模式、装饰模式、外观模式、享元模式、代理模式
组合模式
行为模式
责任链模式、命令模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板模式、访问者模式
责任链模式
责任链模式(Chain of Responsibility Pattern)为请求创建了一个接收者对象的链。这种模式给予请求的类型,对请求的发送者和接收者进行解耦。
责任链模式通过将多个处理器(处理对象)以链式结构连接起来,使得请求沿着这条链传递,直到有一个处理器处理该请求为止。
责任链模式允许多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链,并沿着这条链传递请求,直到有一个对象处理它为止。
优点
- 降低耦合度:发送者和接收者之间解耦。
- 简化对象:对象不需要知道链的结构。
- 灵活性:通过改变链的成员或顺序,动态地新增或删除责任。
- 易于扩展:增加新的请求处理类很方便。
缺点
- 请求未被处理:不能保证请求一定会被链中的某个处理者接收。
- 性能影响:可能影响系统性能,且调试困难,可能导致循环调用。
- 难以观察:运行时特征不明显,可能妨碍除错。
使用建议
- 在处理请求时,如果有多个潜在的处理者,考虑使用责任链模式。
- 确保链中的每个处理者都明确知道如何传递请求到链的下一个环节。
注意事项
- 在Java Web开发中,责任链模式有广泛应用,如过滤器链、拦截器等。
结构
主要涉及到以下几个核心角色:
- 抽象处理者(Handler):
- 定义一个处理请求的接口,通常包含一个处理请求的方法(如
handleRequest
)和一个指向下一个处理者的引用(后继者)。
- 定义一个处理请求的接口,通常包含一个处理请求的方法(如
- 具体处理者(ConcreteHandler):
- 实现了抽象处理者接口,负责处理请求。如果能够处理该请求,则直接处理;否则,将请求传递给下一个处理者。
- 客户端(Client):
- 创建处理者对象,并将它们连接成一条责任链。通常,客户端只需要将请求发送给责任链的第一个处理者,无需关心请求的具体处理过程。
模板模式
在模板模式中,一个抽象类公开定义了执行它的方法的方式/模板。它的子类可以按需重写方法的实现,但调用将以抽象类中的方法进行。
介绍
意图
在父类中定义了算法的骨架,并允许子类在不改变算法结构的前提下重定义算法的某些特定步骤。
主要解决的问题
解决在多个子类中重复实现相同方法的问题,通过将通用方法抽象到父类中来避免代码重复。
使用场景
当存在一些通用的方法,可以在多个子类中共用时。
实现方式
定义抽象父类:包含模板方法和一些抽象方法或具体方法。
实现子类:继承抽象父类 并实现抽象方法,不改变算法结构。
策略模式
在策略模式(Strategy Pattern)中一个类的行为或其算法可以在运行时更改。这种类型的设计模式属于行为型模式。
在策略模式定义了一系列算法或策略,并将每个算法封装在独立的类中,使得它们可以互相替换。通过使用策略模式,可以在运行时根据需要选择不同的算法,而不需要修改客户端代码。
在策略模式中,我们创建表示各种策略的对象和一个行为随着策略对象改变而改变的 context 对象。策略对象改变 context 对象的执行算法。
介绍
意图
将每个算法封装起来,使它们可以互换使用。
主要解决的问题
- 解决在多种相似算法存在时,使用条件语句(如if…else)导致的复杂性和难以维护的问题。
使用场景
- 当一个系统中有许多类,它们之间的区别仅在于它们的行为时。
实现方式
- 定义策略接口:所有策略类都将实现这个统一的接口。
- 创建具体策略类:每个策略类封装一个具体的算法或行为。
- 上下文类:包含一个策略对象的引用,并通过该引用调用策略。
关键代码
- 策略接口:规定了所有策略类必须实现的方法。
- 具体策略类:实现了策略接口,包含具体的算法实现。
应用实例
- 锦囊妙计:每个锦囊代表一个策略,包含不同的计策。
- 旅行方式选择:骑自行车、坐汽车等,每种方式都是一个可替换的策略。
- Java AWT的LayoutManager:不同的布局管理器实现了相同的接口,但提供了不同的布局算法。
优点
- 算法切换自由:可以在运行时根据需要切换算法。
- 避免多重条件判断:消除了复杂的条件语句。
- 扩展性好:新增算法只需新增一个策略类,无需修改现有代码。
缺点
- 策略类数量增多:每增加一个算法,就需要增加一个策略类。
- 所有策略类都需要暴露:策略类需要对外公开,以便可以被选择和使用。
使用建议
- 当系统中有多种算法或行为,且它们之间可以相互替换时,使用策略模式。
- 当系统需要动态选择算法时,策略模式是一个合适的选择。
注意事项
- 如果系统中策略类数量过多,考虑使用其他模式或设计技巧来解决类膨胀问题。
结构
策略模式包含以下几个核心角色:
- 环境(Context):维护一个对策略对象的引用,负责将客户端请求委派给具体的策略对象执行。环境类可以通过依赖注入、简单工厂等方式来获取具体策略对象。
- 抽象策略(Abstract Strategy):定义了策略对象的公共接口或抽象类,规定了具体策略类必须实现的方法。
- 具体策略(Concrete Strategy):实现了抽象策略定义的接口或抽象类,包含了具体的算法实现。
策略模式通过将算法与使用算法的代码解耦,提供了一种动态选择不同算法的方法。客户端代码不需要知道具体的算法细节,而是通过调用环境类来使用所选择的策略。
实现
我们将创建一个定义活动的 Strategy 接口和实现了 Strategy 接口的实体策略类。Context 是一个使用了某种策略的类。
StrategyPatternDemo,我们的演示类使用 Context 和策略对象来演示 Context 在它所配置或使用的策略改变时的行为变化。