组合模式 -Java描述

概述

树形结构在软件中随处可见,例如操作系统中的目录结构、应用软件中的菜单、办公系统中的公司组织结构等等,如何运用面向对象的方式来处理这种树形结构是组合模式需要解决的问题,组合模式通过一种巧妙的设计方案使得用户可以一致性地处理整个树形结构或者树形结构的一部分,也可以一致性地处理树形结构中的叶子节点(不包含子节点的节点)和容器节点(包含子节点的节点)。下面将学习这种用于处理树形结构的组合模式。

对于树形结构,当容器对象(如文件夹)的某一个方法被调用时,将遍历整个树形结构,寻找也包含这个方法的成员对象(可以是容器对象,也可以是叶子对象)并调用执行,牵一而动百,其中使用了递归调用的机制来对整个结构进行处理。由于容器对象和叶子对象在功能上的区别,在使用这些对象的代码中必须有区别地对待容器对象和叶子对象,而实际上大多数情况下我们希望一致地处理它们,因为对于这些对象的区别对待将会使得程序非常复杂。组合模式为解决此类问题而诞生,它可以让叶子对象和容器对象的使用具有一致性。
就是叶子和容器都实现一个接口,当遍历是判断是叶子就调用,容器就继续往下遍历。

  • 组合模式定义如下:
    组合模式(Composite Pattern):组合多个对象形成树形结构以表示具有“整体—部分”关系的层次结构。组合模式对单个对象(即叶子对象)和组合对象(即容器对象)的使用具有一致性,组合模式又可以称为“整体—部分”(Part-Whole)模式,它是一种对象结构型模式。在组合模式中引入了抽象构件类Component,它是所有容器类和叶子类的公共父类,客户端针对Component进行编程。组合模式结构如图
    在这里插入图片描述
  • 在组合模式结构图中包含如下几个角色:
  1. Component(抽象构件):它可以是接口或抽象类,为叶子构件和容器构件对象声明接口,在该角色中可以包含所有子类共有行为的声明和实现。在抽象构件中定义了访问及管理它的子构件的方法,如增加子构件、删除子构件、获取子构件等。
  2. Leaf(叶子构件):它在组合结构中表示叶子节点对象,叶子节点没有子节点,它实现了在抽象构件中定义的行为。对于那些访问及管理子构件的方法,可以通过异常等方式进行处理。
  3. Composite(容器构件):它在组合结构中表示容器节点对象,容器节点包含子节点,其子节点可以是叶子节点,也可以是容器节点,它提供一个集合用于存储子节点,实现了在抽象构件中定义的行为,包括那些访问及管理子构件的方法,在其业务方法中可以递归调用其子节点的业务方法。

**组合模式的关键是定义了一个抽象构件类,它既可以代表叶子,又可以代表容器,而客户端针对该抽象构件类进行编程,无须知道它到底表示的是叶子还是容器,可以对其进行统一处理。**同时容器对象与抽象构件类之间还建立一个聚合关联关系,在容器对象中既可以包含叶子,也可以包含容器,以此实现递归组合,形成一个树形结构。

如果不使用组合模式,客户端代码将过多地依赖于容器对象复杂的内部实现结构,容器对象内部实现结构的变化将引起客户代码的频繁变化,带来了代码维护复杂、可扩展性差等弊端。组合模式的引入将在一定程度上解决这些问题。

  • 示例代码来分析组合模式的各个角色的用途和实现。
  1. 抽象构件角色:一般将抽象构件类设计为接口或抽象类,将所有子类共有方法的声明和实现放在抽象构件类中。对于客户端而言,将针对抽象构件编程,而无须关心其具体子类是容器构件还是叶子构件。
abstract class Component {
public abstract void add(Component c); //增加成员
public abstract void remove(Component c); //删除成员
public abstract Component getChild(int i); //获取成员
public abstract void operation(); //业务方法
}
  1. 叶子构件:作为抽象构件类的子类,在叶子构件中需要实现在抽象构件类中声明的所有方法,包括业务方法以及管理和访问子构件的方法,但是叶子构件不能再包含子构件,因此在叶子构件中实现子构件管理和访问方法时需要提供异常处理或错误提示。当然,这无疑会给叶子构件的实现带来麻烦。
class Leaf extends Component {
public void add(Component c) {
//异常处理或错误提示
}
public void remove(Component c) {
//异常处理或错误提示
}
public Component getChild(int i) {
//异常处理或错误提示
return null;
}
public void operation() {
//叶子构件具体业务方法的实现
}
}
  1. 容器构件:容器构件中实现了在抽象构件中声明的所有方法,既包括业务方法,也包括用于访问和管理成员子构件的方法,如add()、remove()和getChild()等方法。需要注意的是在实现具体业务方法时,由于容器构件充当的是容器角色,包含成员构件,因此它将调用其成员构件的业务方法。在组合模式结构中,由于容器构件中仍然可以包含容器构件,因此在对容器构件进行处理时需要使用递归算法,即在容器构件的operation()方法中递归调用其成员构件的operation()方法。
class Composite extends Component {
private ArrayList<Component> list = new ArrayList<Component>();
public void add(Component c) {
list.add(c);
}
public void remove(Component c) {
list.remove(c);
}
public Component getChild(int i) {
return (Component)list.get(i);
}
public void operation() {
//容器构件具体业务方法的实现
//递归调用成员构件的业务方法
for(Object obj:list) {
((Component)obj).operation();
}
}
}

实例操作

某教育机构组织结构如下图所示:
在这里插入图片描述
在该教育机构的OA系统中可以给各级办公室下发公文,试采用组合模式设计该机构的组织结构,绘制相应的类图并编程模拟实现,在客户端代码中模拟下发公文。

public interface ServiceComponent {
    public void sendfiles();
    public void addservice(ServiceComponent service);
    public void removeservice(ServiceComponent service);
}
public class CompositeService implements ServiceComponent{
    public String servicename ;
    private ArrayList<ServiceComponent> compositelist=new ArrayList<>();

    public CompositeService(String servicename) {
        this.servicename = servicename;
    }

    @Override
    public void sendfiles() {
        System.out.println(servicename+"下发文件");
        for (ServiceComponent service :compositelist) {
            service.sendfiles();
        }
    }

    @Override
    public void addservice(ServiceComponent service) {
        compositelist.add(service);
    }

    @Override
    public void removeservice(ServiceComponent service) {
        compositelist.remove(service);
    }
}
public class LeafService implements ServiceComponent  {
    public String servicename ;

    public LeafService(String servicename) {
        this.servicename = servicename;
    }

    @Override
    public void sendfiles() {
        System.out.println("文件送到了"+servicename);
    }

    @Override
    public void addservice(ServiceComponent service) {

    }

    @Override
    public void removeservice(ServiceComponent service) {

    }
}
public class Client {
    public static void main(String[] args) {
        ServiceComponent serviceBeiJing=new CompositeService("北京总部");
        ServiceComponent serviceHuNan=new CompositeService("湖南分校");


        ServiceComponent teachofficeBeijing=new LeafService("北京教务处");
        ServiceComponent administrationBeijing=new LeafService("北京行政");
        ServiceComponent teachofficeHuNan=new LeafService("湖南教务处");
        ServiceComponent administrationHuNan=new LeafService("湖南行政");
        //北京加
        serviceBeiJing.addservice(administrationBeijing);
        serviceBeiJing.addservice(teachofficeBeijing);
        serviceBeiJing.addservice(serviceHuNan);
        //湖南加
        serviceHuNan.addservice(teachofficeHuNan);
        serviceHuNan.addservice(administrationHuNan);

        serviceBeiJing.sendfiles();

    }
}

在这里插入图片描述

总结

组合模式使用面向对象的思想来实现树形结构的构建与处理,描述了如何将容器对象和叶子对象进行递归组合,实现简单,灵活性好。由于在软件开发中存在大量的树形结构,因此组合模式是一种使用频率较高的结构型设计模式,Java SE中的AWT和Swing包的设计就基于组合模式,在这些界面包中为用户提供了大量的容器构件(如Container)和成员构件(如Checkbox、Button和TextComponent等)。

  • 主要优点
  1. 组合模式可以清楚地定义分层次的复杂对象,表示对象的全部或部分层次,它让客户端忽略了层次的差异,方便对整个层次结构进行控制。
  2. 客户端可以一致地使用一个组合结构或其中单个对象,不必关心处理的是单个对象还是整个组合结构,简化了客户端代码。
  3. 在组合模式中增加新的容器构件和叶子构件都很方便,无须对现有类库进行任何修改,符合“开闭原则”。
  4. 组合模式为树形结构的面向对象实现提供了一种灵活的解决方案,通过叶子对象和容器对象的递归组合,可以形成复杂的树形结构,但对树形结构的控制却非常简单。
  • 主要缺点
    在增加新构件时很难对容器中的构件类型进行限制。有时候我们希望一个容器中只能有某些特定类型的对象,例如在某个文件夹中只能包含文本文件,使用组合模式时,不能依赖类型系统来施加这些约束,因为它们都来自于相同的抽象层,在这种情况下,必须通过在运行时进行类型检查来实现,这个实现过程较为复杂。

  • 适用场景
    (1) 在具有整体和部分的层次结构中,希望通过一种方式忽略整体与部分的差异,客户端可以一致地对待它们。
    (2) 在一个使用面向对象语言开发的系统中需要处理一个树形结构。
    (3) 在一个系统中能够分离出叶子对象和容器对象,而且它们的类型不固定,需要增加一些新的类型。

扩展:

在使用组合模式时,根据抽象构件类的定义形式,我们可将组合模式分为透明组合模式和安全组合模式两种形式:

透明组合模式

(1) 透明组合模式
透明组合模式中,抽象构件Component中声明了所有用于管理成员对象的方法,包括add()、remove()以及getChild()等方法,这样做的好处是确保所有的构件类都有相同的接口。在客户端看来,叶子对象与容器对象所提供的方法是一致的,客户端可以相同地对待所有的对象。透明组合模式也是组合模式的标准形式,虽然上面的解决方案一在客户端可以有不透明的实现方法,但是由于在抽象构件中包含add()、remove()等方法,因此它还是透明组合模式,透明组合模式的完整结构如图
在这里插入图片描述
透明组合模式的缺点是不够安全,因为叶子对象和容器对象在本质上是有区别的。叶子对象不可能有下一个层次的对象,即不可能包含成员对象,因此为其提供add()、remove()以及getChild()等方法是没有意义的,这在编译阶段不会出错,但在运行阶段如果调用这些方法可能会出错(如果没有提供相应的错误处理代码)。
这样就产生了一种不透明的使用方式,即在
客户端不能全部针对抽象构件类编程,需要使用具体叶子构件类型来定义叶子对象。

将叶子构件的add()、remove()等方法的实现代码移至AbstractFile类中,由AbstractFile提供统一的默认实现,代码如下所示:

//提供默认实现的抽象构件类
abstract class AbstractFile {
public void add(AbstractFile file) {
System.out.println("对不起,不支持该方法!");
}
public void remove(AbstractFile file) {
System.out.println("对不起,不支持该方法!");
}
public AbstractFile getChild(int i) {
System.out.println("对不起,不支持该方法!");
return null;
}
public abstract void killVirus();
}

如果客户端代码针对抽象类AbstractFile编程,在调用文件对象的这些方法时将出现错误提示。如果不希望出现任何错误提示,我们可以在客户端定义文件对象时不使用抽象层,而直接使用具体叶子构件本身,客户端代码片段如下所示:

class Client {
public static void main(String args[]) {
//不能透明处理叶子构件
ImageFile file1,file2;
TextFile file3,file4;
VideoFile file5;
AbstractFile folder1,folder2,folder3,folder4;
//其他代码省略
}
}

安全组合模式

安全组合模式中,在抽象构件Component中没有声明任何用于管理成员对象的方法,而是在Composite类中声明并实现这些方法。这种做法是安全的,因为根本不向叶子对象提供这些管理成员对象的方法,对于叶子对象,客户端不可能调用到这些方法,这就是解决方案二所采用的实现方式。安全组合模式的结构如图
在这里插入图片描述
安全组合模式的缺点是不够透明,因为叶子构件和容器构件具有不同的方法(叶子构建加了一些和实现接口中不同的方法),且容器构件中那些用于管理成员对象的方法没有在抽象构件类中定义,因此客户端不能完全针对抽象编程,必须有区别地对待叶子构件和容器构件。在实际应用中,安全组合模式的使用频率也非常高,在Java AWT中使用的组合模式就是安全组合模式。

除此之外,还有一种解决方法是在抽象构件AbstractFile中不声明任何用于访问和管理成员构件的方法,代码如下所示:

abstract class AbstractFile {
public abstract void killVirus();
}

此时,由于在AbstractFile中没有声明add()、remove()等访问和管理成员的方法,其叶子构件子类无须提供实现;而且无论客户端如何定义叶子构件对象都无法调用到这些方法,不需要做任何错误和异常处理,容器构件再根据需要增加访问和管理成员的方法,但这时候也存在一个问题:客户端不得不使用容器类本身来声明容器构件对象,否则无法访问其中新增的add()、remove()等方法,如果客户端一致性地对待叶子和容器,将会导致容器构件的新增对客户端不可见,客户端代码对于容器构件无法再使用抽象构件来定义,客户端代码片段如下所
示:

class Client {
public static void main(String args[]) {
AbstractFile file1,file2,file3,file4,file5;
Folder folder1,folder2,folder3,folder4; //不能透明处理容器构件
//其他代码省略
}
}
  • 1
    点赞
  • 18
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
目录: 前 言 第一部分 大旗不挥,谁敢冲锋——热身篇 第1章 单一职责原则 1.1 我是“牛”类,我可以担任多职吗 1.2 绝杀技,打破你的传统思维 1.3 我单纯,所以我快乐 1.4 最佳实践 第2章 里氏替换原则 2.1 爱恨纠葛的父子关系 2.2 纠纷不断,规则压制 2.3 最佳实践 第3章 依赖倒置原则 3.1 依赖倒置原则的定义 3.2 言而无信,你太需要契约 3.3 依赖的三种写法 3.4 最佳实践 第4章 接口隔离原则 4.1 接口隔离原则的定义 4.2 美女何其多,观点各不同 4.3 保证接口的纯洁性 4.4 最佳实践 第5章 迪米特法则 5.1 迪米特法则的定义 5.2 我的知识你知道得越少越好 5.3 最佳实践 第6章 开闭原则 6.1 开闭原则的定义 6.2 开闭原则的庐山真面目 6.3 为什么要采用开闭原则 6.4 如何使用开闭原则 6.5 最佳实践 第二部分 我惹了谁——真刀实枪篇 第7章 单例模式 7.1 我是皇帝我独苗 7.2 单例模式的定义 7.3 单例模式的应用 7.4 单例模式的扩展 7.5 最佳实践 第8章 工厂方法模式 8.1 女娲造人的故事 8.2 工厂方法模式的定义 8.3 工厂方法模式的应用 8.3.1 工厂方法模式的优点 8.3.2 工厂方法模式的使用场景 8.4 工厂方法模式的扩展 8.5 最佳实践 第9章 抽象工厂模式 9.1 女娲的失误 9.2 抽象工厂模式的定义 9.3 抽象工厂模式的应用 9.3.1 抽象工厂模式的优点 9.3.2 抽象工厂模式的缺点 9.3.3 抽象工厂模式的使用场景 9.3.4 抽象工厂模式的注意事项 9.4 最佳实践 第10章 模板方法模式 10.1 辉煌工程—制造悍马 10.2 模板方法模式的定义 10.3 模板方法模式的应用 10.4 模板方法模式的扩展 10.5 最佳实践 第11章 建造者模式 11.1 变化是永恒的 11.2 建造者模式的定义 11.3 建造者模式的应用 11.4 建造者模式的扩展 11.5 最佳实践 第12章 代理模式 12.1 我是游戏至尊 12.2 代理模式的定义 12.3 代理模式的应用 12.3.1 代理模式的优点 12.3.2 代理模式的应用 12.4 代理模式的扩展 12.4.1 普通代理 12.4.2 强制代理 12.4.3 代理是有个性的 12.4.4 虚拟代理 12.4.5 动态代理 12.5 最佳实践 第13章 原型模式 13.1 个性化电子账单 13.2 原型模式的定义 13.3 原型模式的应用 13.3.1 原型模式的优点 13.3.2 原型模式的使用场景 13.4 原型模式的注意事项 13.4.1 构造函数不会被执行 13.4.2 浅拷贝和深拷贝 13.4.3 clone与final两个冤家 13.5 最佳实践 第14章 中介者模式 14.1 进销存管理是这个样子的吗? 14.2 中介者模式的定义 14.3 中介者模式的应用 14.4 中介者模式的实际应用 14.5 最佳实践 第15章 命令模式 15.1 项目经理也难当 15.2 命令模式的定义 15.3 命令模式的应用 15.3.1 命令模式的优点 15.3.2 命令模式的缺点 15.3.3 命令模式的使用场景 15.4 命令模式的扩展 15.4.1 未讲完的故事 15.4.2 反悔问题 15.5 最佳实践 第16章 责任链模式 16.1 古代妇女的枷锁—“三从四德” 16.2 责任链模式的定义 16.3 责任链模式的应用 16.3.1 责任链模式的优点 16.3.2 责任链模式的缺点 16.3.3 责任链模式的注意事项 16.4 最佳实践 第17章 装饰模式 17.1 罪恶的成绩单 17.2 装饰模式的定义 17.3 装饰模式应用 17.3.1 装饰模式的优点 17.3.2 装饰模式的缺点 17.3.3 装饰模式的应用 17.4 最佳实践 第18章 策略模式 18.1 刘备江东娶妻,赵云他容易吗 18.2 策略模式的定义 18.3 策略模式的应用 18.3.1 策略模式的优点 18.3.2 策略模式的缺点 18.3.3 策略模式的应用 18.3.4 策略模式的注意事项 18.4 策略模式的扩展 18.5 最佳实践 第19章 适配器模式 19.1 业务发展—上帝才能控制 19.2 适配器模式的定义 19.3 适配器模式的应用 19.3.1 适配器模式的优点 19.3.2 适配器模式的应用 19.3.3 适配器模式的注意事项 19.4 适配器模式的扩展 19.5 最佳实践 第20章 迭代器模式 20.1 整理项目信息—苦差事 20.2 迭代器模式的定义 20.3 迭代器模式的应用 20.4 最佳实践 第21章 组合模式 21.1 公司的人事架构是这样的吗 21.2 组合模式的定义 21.3 组合模式的应用 21.3.1 组合模式的优点 21.3.2 组合模式的缺点 21.3.3 组合模式的应用 21.3.4 组合模式的注意事项 21.4 组合模式的扩展 21.4.1 真实的组合模式 21.4.2 透明的组合模式 21.4.3 组合模式的遍历 21.5 最佳实践 第22章 观察者模式 22.1 韩非子身边的卧底是谁派来的 22.2 观察者模式的定义 22.3 观察者模式的应用 22.3.1 观察者模式的优点 22.3.2 观察者模式的缺点 22.3.3 观察者模式的应用 22.3.4 观察者模式的注意事项 22.4 观察者模式的扩展 22.4.1 Java世界中的观察者模式 22.4.2 项目中真实观察者模式 22.4.3 订阅发布模型 22.5 最佳实践 第23章 门面模式 23.1 我要投递信件 23.2 门面模式的定义 23.3 门面模式的应用 23.3.1 门面模式的优点 23.3.2 门面模式的缺点 23.3.3 门面模式的应用 23.4 门面模式的注意事项 23.4.1 一个子系统可以有多个门面 23.4.2 门面不参与子系统内的业务逻辑 23.5 最佳实践 第24章 备忘录模式 24.1 如此追女孩子,你还不乐 24.2 备忘录模式的定义 24.3 备忘录模式的应用 24.3.1 备忘录模式的应用 24.3.2 备忘录模式的注意事项 24.4 备忘录模式的扩展 24.4.1 clone方式的备忘录 24.4.2 多状态的备忘录模式 24.4.3 多备份的备忘录 24.4.4 封装得更好一点 24.5 最佳实践 第25章 访问者模式 25.1 员工的隐私何在? 25.2 访问者模式的定义 25.3 访问者模式的应用 25.3.1 访问者模式的优点 25.3.2 访问者模式的缺点 25.3.3 访问者模式的应用 25.4 访问者模式的扩展 25.4.1 统计功能 25.4.2 多个访问者 25.4.3 双分派 25.5 最佳实践 第26章 状态模式 26.1 城市的纵向发展功臣—电梯 26.2 状态模式的定义 26.3 状态模式的应用 26.3.1 状态模式的优点 26.3.2 状态模式的缺点 26.3.3 状态模式的应用 26.3.4 状态模式的注意事项 26.4 最佳实践 第27章 解释器模式 27.1 四则运算你会吗 27.2 解释器模式的定义 27.3 解释器模式的应用 27.3.1 解释器模式的优点 27.3.2 解释器模式的缺点 27.3.3 解释器模式使用的场景 27.3.4 解释器模式的注意事项 27.4 最佳实践 第28章 享元模式 28.1 内存溢出,司空见惯 28.2 享元模式的定义 28.3 享元模式的应用 28.3.1 享元模式优点和缺点 28.3.2 享元模式的应用 28.4 享元模式的扩展 28.4.1 线程安全的问题 28.4.2 性能平衡 28.5 最佳实践 第29章 桥梁模式 29.1 我有一个梦想…… 29.2 桥梁模式的定义 29.3 桥梁模式的应用 29.3.1 桥梁模式的优点 29.3.2 桥梁模式的应用 29.3.3 桥梁模式的注意事项 29.4 最佳实践 第三部分 谁的地盘谁做主—模式PK篇 第30章 创建类模式大PK 30.1 工厂方法模式VS建造者模式 30.1.1 按工厂方法建造超人 30.1.2 按建造者模式建造超人 30.1.3 最佳实践 30.2 抽象工厂模式VS建造者模式 30.2.1 按抽象工厂模式生产车辆 30.2.2 按建造者模式生产车辆 30.2.3 最佳实践 第31章 结构类模式大PK 31.1 代理模式VS装饰模式 31.1.1 代理模式 31.1.2 装饰模式 31.1.3 最佳实践 31.2 装饰模式VS适配器模式 31.2.1 按装饰模式描述丑小鸭 31.2.2 按适配器模式实现丑小鸭 31.2.3 最佳实践 第32章 行为类模式大PK 32.1 命令模式VS策略模式 32.1.1 策略模式实现压缩算法 32.1.2 命令模式实现压缩算法 32.1.3 小结 32.2 策略模式VS状态模式 32.2.1 策略模式实现人生 32.2.2 状态模式实现人生 32.2.3 小结 32.3 观察者模式VS责任链模式 32.3.1 责任链模式实现DNS解析过程 32.3.2 触发链模式实现DNS解析过程 32.3.3 小结 第33章 跨战区PK 33.1 策略模式VS桥梁模式 33.1.1 策略模式实现邮件发送 33.1.2 桥梁模式实现邮件发送 33.1.3 最佳实践 33.2 门面模式VS中介者模式 33.2.1 中介者模式实现工资计算 33.2.2 门面模式实现工资计算 33.2.3 最佳实践 33.3 包装模式群PK 33.3.1 代理模式 33.3.2 装饰模式 33.3.3 适配器模式 33.3.4 桥梁模式 33.3.5 最佳实践 第四部分 完美世界—混编模式 第34章 命令模式+责任链模式 34.1 搬移UNIX的命令 34.2 混编小结 第35章 工厂方法模式+策略模式 35.1 迷你版的交易系统 35.2 混编小结 第36章 观察者模式+中介者模式 36.1 事件触发器的开发 36.2 混编小结 第37章 规格模式 37.1 规格模式的实现 37.2 最佳实践 第38章 MVC框架 38.1 MVC框架的实现 38.1.1 MVC的系统架构 38.1.2 模型管理器 38.1.3 值栈 38.1.4 视图管理器 38.1.5 工具类 38.2 最佳实践 附录:23个设计模式
好的,下面是一些 Java 设计模式的重点内容,供您参考: 1. 设计模式的定义和分类 - 设计模式是对软件设计中普遍存在的问题的解决方案的描述。 - 设计模式可以分为三类:创建型模式(Creational Patterns)、结构型模式(Structural Patterns)和行为型模式(Behavioral Patterns)。 2. 创建型模式 - 创建型模式用于处理对象的创建过程,封装了对象的实例化过程,并提供了更加灵活的对象创建方式。 - 创建型模式包括单例模式、工厂方法模式、抽象工厂模式、建造者模式和原型模式。 3. 结构型模式 - 结构型模式用于处理类或对象的组合,以便更好地实现系统的功能。 - 结构型模式包括适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式和享元模式。 4. 行为型模式 - 行为型模式用于处理类或对象之间的通信,以及对算法和流程的控制。 - 行为型模式包括策略模式、模板方法模式、观察者模式、迭代器模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式和中介者模式。 5. 单例模式 - 单例模式是一种创建型模式,它保证一个类只有一个实例,并提供了一个全局访问点。 - 单例模式的核心在于将类的构造方法私有化,并提供一个静态方法来获取类的唯一实例。 6. 工厂方法模式 - 工厂方法模式是一种创建型模式,它将对象的创建委托给子类。 - 工厂方法模式的核心在于定义一个抽象工厂类,它包含一个抽象的工厂方法,用于创建产品;然后定义一个具体的工厂类,实现抽象工厂方法,并且创建具体的产品。 7. 抽象工厂模式 - 抽象工厂模式是一种创建型模式,它提供一个接口,用于创建一系列相关或相互依赖的对象。 - 抽象工厂模式的核心在于定义一个抽象工厂接口,它包含一些抽象的工厂方法,用于创建一系列相关或相互依赖的对象;然后定义一个具体的工厂类,实现抽象工厂接口,并且创建具体的产品。 8. 建造者模式 - 建造者模式是一种创建型模式,它将一个复杂对象的构建过程分解为多个简单对象的构建过程。 - 建造者模式的核心在于定义一个抽象的建造者类,它包含一些抽象的建造方法,用于构建不同的部件;然后定义一个具体的建造者类,实现抽象建造者类,并且构建具体的部件;最后定义一个指挥者类,它用于控制建造过程,以及返回最终构建的对象。 9. 原型模式 - 原型模式是一种创建型模式,它通过复制已有的对象来创建新的对象。 - 原型模式的核心在于定义一个抽象的原型类,它包含一个克隆方法,用于复制自身;然后定义一个具体的原型类,实现抽象原型类,并且实现克隆方法。 10. 适配器模式 - 适配器模式是一种结构型模式,它将一个类的接口转换成客户希望的另外一个接口。 - 适配器模式的核心在于定义一个适配器类,它包含一个客户所期望的接口,以及一个适配者对象,用于实现这个接口。 11. 装饰器模式 - 装饰器模式是一种结构型模式,它动态地给一个对象添加一些额外的职责,而不需要修改它的代码。 - 装饰器模式的核心在于定义一个装饰器类,它包含一个被装饰者对象,并且实现与被装饰者相同的接口;然后定义一个具体的装饰器类,用于添加额外的职责。 12. 代理模式 - 代理模式是一种结构型模式,它给一个对象提供一个代理对象,并由代理对象控制对原对象的访问。 - 代理模式的核心在于定义一个代理类,它包含一个与被代理类相同的接口,并且持有一个被代理对象的引用;然后在代理类中控制对被代理对象的访问。 13. 外观模式 - 外观模式是一种结构型模式,它为一组复杂的子系统提供一个简单的接口,以方便客户端的访问。 - 外观模式的核心在于定义一个外观类,它包含一组与子系统相关的操作方法,用于简化客户端的访问。 14. 桥接模式 - 桥接模式是一种结构型模式,它将抽象部分和实现部分分离,以便它们可以独立地变化。 - 桥接模式的核心在于定义一个抽象部分的接口,以及一个实现部分的接口,然后在抽象部分中持有一个实现部分的引用,用于将两者关联起来。 15. 组合模式 - 组合模式是一种结构型模式,它将对象组合成树形结构以表示“部分-整体”的层次结构,使得客户端可以统一地处理单个对象和组合对象。 - 组合模式的核心在于定义一个组件抽象类,它包含一些公共的操作方法,然后定义一个叶子组件类和一个容器组件类,分别实现组件抽象类。 16. 策略模式 - 策略模式是一种行为型模式,它定义了一系列算法,并将每个算法封装起来,使得它们可以相互替换。 - 策略模式的核心在于定义一个策略接口,它包含一个算法方法;然后定义一系列具体的策略类,分别实现策略接口中的算法方法。 17. 模板方法模式 - 模板方法模式是一种行为型模式,它定义了一个算法的框架,并将一些步骤延迟到子类中实现。 - 模板方法模式的核心在于定义一个抽象类,它包含一个算法框架方法,以及一些抽象的步骤方法;然后定义具体的子类,实现抽象的步骤方法。 18. 观察者模式 - 观察者模式是一种行为型模式,它定义了一种一对多的依赖关系,使得多个观察者对象同时监听某一个主题对象。 - 观察者模式的核心在于定义一个主题接口,它包含一些注册和移除观察者对象的方法,以及一个通知观察者的方法;然后定义一个具体的主题类,实现主题接口,并且维护一个观察者列表。 19. 迭代器模式 - 迭代器模式是一种行为型模式,它提供一种方法来访问聚合对象中的各个元素,而又不暴露该对象的内部表示。 - 迭代器模式的核心在于定义一个迭代器接口,它包含一些访问聚合对象中元素的方法;然后定义一个具体的迭代器类,实现迭代器接口,并且维护一个指向当前元素的指针。 20. 责任链模式 - 责任链模式是一种行为型模式,它将请求的发送者和接收者解耦,并且沿着一条链传递该请求,直到有一个接收者处理它。 - 责任链模式的核心在于定义一个处理请求的抽象类,它包含两个方法:处理请求和设置下一个处理者;然后定义具体的处理者类,实现抽象类中的处理请求方法。 21. 命令模式 - 命令模式是一种行为型模式,它将一个请求封装成一个对象,使得可以将请求的参数化、队列化、记录化,并且支持可撤销操作。 - 命令模式的核心在于定义一个命令接口,它包含一个执行方法和一个撤销方法;然后定义一个具体的命令类,实现命令接口,并且持有一个接收者对象的引用。 22. 备忘录模式 - 备忘录模式是一种行为型模式,它将一个对象的状态保存在一个备忘录对象中,以便可以恢复到之前的状态。 - 备忘录模式的核心在于定义一个备忘录类,它用于保存对象的状态;然后定义一个发起人类,它包含一个备忘录对象的引用,以及一些用于修改状态的方法。 23. 状态模式 - 状态模式是一种行为型模式,它允许对象在内部状态发生改变时改变它的行为。 - 状态模式的核心在于定义一个状态接口,它包含一些方法,用于在状态发生改变时改变对象的行为;然后定义具体的状态类,实现状态接口,并且在状态发生改变时改变对象的状态。 24. 访问者模式 - 访问者模式是一种行为型模式,它将算法与对象结构分离,使得可以在不改变对象结构的情况下定义新的操作。 - 访问者模式的核心在于定义一个访问者接口,它包含一些访问不同类型元素的方法;然后定义一个元素接口,它包含一个接受访问者的方法;最后定义具体的访问者类和元素类,分别实现访问者接口和元素接口。 25. 中介者模式 - 中介者模式是一种行为型模式,它定义一个中介对象,用于封装一组对象之间的交互。 - 中介者模式的核心在于定义一个中介者接口,它包含一些用于交互的方法;然后定义一个具体的中介者类,实现中介者接口,并且维护一组相关的对象。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值