设计模式——模板方法模式、策略模式(行为型模式)

1.模板方法模式

模式包含以下主要角色:

  • 抽象类(Abstract Class):负责给出一个算法的轮廓和骨架。它由一个模板方法和若干个基本方法构成。

    • 模板方法:定义了算法的骨架,按某种顺序调用其包含的基本方法。

    • 基本方法:是实现算法各个步骤的方法,是模板方法的组成部分。基本方法又可以分为三种:

      • 抽象方法(Abstract Method) :一个抽象方法由抽象类声明、由其具体子类实现。

      • 具体方法(Concrete Method) :一个具体方法由一个抽象类或具体类声明并实现,其子类可以进行覆盖也可以直接继承。

      • 钩子方法(Hook Method) :在抽象类中已经实现,包括用于判断的逻辑方法和需要子类重写的空方法两种。

        一般钩子方法是用于判断的逻辑方法,这类方法名一般为isXxx,返回值类型为boolean类型。

  • 具体子类(Concrete Class):实现抽象类中所定义的抽象方法和钩子方法,它们是一个顶级逻辑的组成步骤。

抽象类:

//抽象类:定义模板方法和基本方法
public abstract class AbstractClass {

    //模板方法
    public final void cookProcess() {
        pourOil();
        heatOil();
        pourVegetable();
        pourSauce();
        fry();
    }
    
    //具体方法
    //第二步:倒油是一样的,所以直接实现
    public void pourOil() {
        System.out.println("倒油");
    }

    //第二步:热油是一样的,所以直接实现
    public void heatOil() {
        System.out.println("热油");
    }

    //第三步:倒蔬菜是不一样的(一个下包菜,一个是下菜心)
    public abstract void pourVegetable();

    //第四步:倒调味料是不一样
    public abstract void pourSauce();

    //第五步:翻炒是一样的,所以直接实现
    public void fry(){
        System.out.println("炒啊炒啊炒到熟啊");
    }
}

具体子类:

//炒包菜类
public class ConcreteClass_BaoCai extends AbstractClass {

    public void pourVegetable() {
        System.out.println("下锅的蔬菜是包菜");
    }

    public void pourSauce() {
        System.out.println("下锅的酱料是辣椒");
    }
}


//炒菜心类
public class ConcreteClass_CaiXin extends AbstractClass {

    public void pourVegetable() {
        System.out.println("下锅的蔬菜是菜心");
    }

    public void pourSauce() {
        System.out.println("下锅的酱料是蒜蓉");
    }
}

测试类:

//测试类
public class Client {
    public static void main(String[] args) {
        //炒包菜
        //创建对象
        ConcreteClass_BaoCai baoCai = new ConcreteClass_BaoCai();
        //调用炒菜的功能
        baoCai.cookProcess();
    }
}

适用场景

  • 算法的整体步骤很固定,但其中个别部分易变时,这时候可以使用模板方法模式,将容易变的部分抽象出来,供子类实现。

  • 需要通过子类来决定父类算法中某个步骤是否执行,实现子类对父类的反向控制

2.策略模式

策略模式的主要角色如下:

  • 抽象策略(Strategy)类:这是一个抽象角色,通常由一个接口或抽象类实现。此角色给出所有的具体策略类所需的接口。

  • 具体策略(Concrete Strategy)类:实现了抽象策略定义的接口,提供具体的算法实现或行为。

  • 环境(Context)类:持有一个策略类的引用,最终给客户端调用。

抽象策略类:

//抽象策略类
public interface Strategy {
    void show();
}

具体策略类:

//具体策略类,封装算法
public class StrategyA implements Strategy {
    public void show() {
        System.out.println("买一送一");
    }
}

//具体策略类,封装算法
public class StrategyB implements Strategy {
    public void show() {
        System.out.println("满200元减50元");
    }
}

//具体策略类,封装算法
public class StrategyC implements Strategy {
    public void show() {
        System.out.println("满1000元加一元换购任意200元以下商品");
    }
}

环境类:

//促销员:环境类,最终给客户端调用。
public class SalesMan {
    //聚合策略类对象
    private Strategy strategy;

    public SalesMan(Strategy strategy) {
        this.strategy = strategy;
    }

    public Strategy getStrategy() {
        return strategy;
    }

    public void setStrategy(Strategy strategy) {
        this.strategy = strategy;
    }

    //由促销员展示促销活动给用户
    public void salesManShow() {
        strategy.show();
    }
}

测试类:

//测试类
public class Client {
    public static void main(String[] args) {
        //春节来了,使用春节促销活动
        SalesMan salesMan = new SalesMan(new StrategyA());
        salesMan.salesManShow();

        System.out.println("==============");
        //中秋节到了,使用中秋节的促销活动
        salesMan.setStrategy(new StrategyB());
        salesMan.salesManShow();

        System.out.println("==============");
        //圣诞节到了,使用圣诞节的促销活动
        salesMan.setStrategy(new StrategyC());
        salesMan.salesManShow();
    }
}

优缺点

1,优点:

  • 策略类之间可以自由切换

    由于策略类都实现同一个接口,所以使它们之间可以自由切换。

  • 易于扩展

    增加一个新的策略只需要添加一个具体的策略类即可,基本不需要改变原有的代码,符合“开闭原则“

  • 避免使用多重条件选择语句(if else),充分体现面向对象设计思想。

2,缺点:

  • 客户端必须知道所有的策略类,并自行决定使用哪一个策略类。

  • 策略模式将造成产生很多策略类,可以通过使用享元模式在一定程度上减少对象的数量。

使用场景

  • 一个系统需要动态地在几种算法中选择一种时,可将每个算法封装到策略类中。

  • 一个类定义了多种行为,并且这些行为在这个类的操作中以多个条件语句的形式出现,可将每个条件分支移入它们各自的策略类中以代替这些条件语句。

  • 系统中各算法彼此完全独立,且要求对客户隐藏具体算法的实现细节时。

  • 系统要求使用算法的客户不应该知道其操作的数据时,可使用策略模式来隐藏与算法相关的数据结构。

  • 多个类只区别在表现行为不同,可以使用策略模式,在运行时动态选择具体要执行的行为。

Comparator中的策略模式

public class demo {
    public static void main(String[] args) {     

        Integer[] data = {12, 2, 3, 2, 4, 5, 1};
        // 实现降序排序
        Arrays.sort(data, new Comparator<Integer>() {
            public int compare(Integer o1, Integer o2) {
                return o2 - o1;
            }
        });//匿名内部类,Comparator子实现类

        System.out.println(Arrays.toString(data)); //[12, 5, 4, 3, 2, 2, 1]
    }
}

在调用Arrays的sort方法时,第二个参数传递的是Comparator接口的子实现类对象。所以Comparator充当的是抽象策略角色,而具体的子实现类充当的是具体策略角色。环境角色类(Arrays)应该持有抽象策略的引用来调用。Arrays类的sort方法使用的是Comparator子实现类中的Compare() 方法

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
总体来说设计模式分为三大类: 创建模式,共五种:工厂方法模式、抽象工厂模式、单例模式、建造者模式、原模式。 结构模式,共七种:适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式行为模式,共十一种:策略模式模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。 二、设计模式的六大原则 1、开闭原则(Open Close Principle) 开闭原则就是说对扩展开放,对修改关闭。在程序需要进行拓展的时候,不能去修改原有的代码,实现一个热插拔的效果。所以一句话概括就是:为了使程序的扩展性好,易于维护和升级。想要达到这样的效果,我们需要使用接口和抽象类,后面的具体设计中我们会提到这点。 2、里氏代换原则(Liskov Substitution Principle) 里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。 里氏代换原则中说,任何基类可以出现的地方,子类一定可以出现。 LSP是继承复用的基石,只有当衍生类可以替换掉基类,软件单位的功能不受到影响时,基类才能真正被复用,而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现,所以里氏代换原则是对实现抽象化的具体步骤的规范。—— From Baidu 百科 3、依赖倒转原则(Dependence Inversion Principle) 这个是开闭原则的基础,具体内容:真对接口编程,依赖于抽象而不依赖于具体。 4、接口隔离原则(Interface Segregation Principle) 这个原则的意思是:使用多个隔离的接口,比使用单个接口要好。还是一个降低类之间的耦合度的意思,从这儿我们看出,其实设计模式就是一个软件的设计思想,从大软件架构出发,为了升级和维护方便。所以上文中多次出现:降低依赖,降低耦合。 5、迪米特法则(最少知道原则)(Demeter Principle) 为什么叫最少知道原则,就是说:一个实体应当尽量少的与其他实体之间发生相互作用,使得系统功能模块相对独立。 6、合成复用原则(Composite Reuse Principle) 原则是尽量使用合成/聚合的方式,而不是使用继承。
书名: 设计模式可复用面向对象软件的基础 英文原书名: Design Patterns:Elements of Reusable Object-Oriented software 作者: Erich Gamma 等 译者: 李英军 马晓星 蔡敏 刘建中 书号: 7-111-07575-7 页码: 254 定价: ¥35.00 会员价: ¥31.50 币值: 315 出版日期: 2000-9-1 本书设计实例从面向对象的设计中精选出23个设计模式,总结了面向对象设计中最有价值的经验,并且用简洁可复用的形式表达出来。本书分类描述了一组设计良好,表达清楚的软件设计模式,这些模式在实用环境下有特别有用。 -------- 目 录 序言 前言 读者指南 第1章 引言 1 1.1 什么是设计模式 2 1.2 Smalltalk MVC中的设计模式 3 1.3 描述设计模式 4 1.4 设计模式的编目 5 1.5 组织编目 7 1.6 设计模式怎样解决设计问题 8 1.6.1 寻找合适的对象 8 1.6.2 决定对象的粒度 9 1.6.3 指定对象接口 9 1.6.4 描述对象的实现 10 1.6.5 运用复用机制 13 1.6.6 关联运行时刻和编译时刻的 结构 15 1.6.7 设计应支持变化 16 1.7 怎样选择设计模式 19 1.8 怎样使用设计模式 20 第2章 实例研究:设计一个文档编 辑器 22 2.1 设计问题 23 2.2 文档结构 23 2.2.1 递归组合 24 2.2.2 图元 25 2.2.3 组合模式 27 2.3 格式化 27 2.3.1 封装格式化算法 27 2.3.2 Compositor和Composition 27 2.3.3 策略模式 29 2.4 修饰用户界面 29 2.4.1 透明围栏 29 2.4.2 Monoglyph 30 2.4.3 Decorator 模式 32 2.5 支持多种视感标准 32 2.5.1 对象创建的抽象 32 2.5.2 工厂类和产品类 33 2.5.3 Abstract Factory模式 35 2.6 支持多种窗口系统 35 2.6.1 我们是否可以使用Abstract Factory 模式 35 2.6.2 封装实现依赖关系 35 2.6.3 Window和WindowImp 37 2.6.4 Bridge 模式 40 2.7 用户操作 40 2.7.1 封装一个请求 41 2.7.2 Command 类及其子类 41 2.7.3 撤消和重做 42 2.7.4 命令历史记录 42 2.7.5 Command 模式 44 2.8 拼写检查和断字处理 44 2.8.1 访问分散的信息 44 2.8.2 封装访问和遍历 45 2.8.3 Iterator类及其子类 46 2.8.4 Iterator模式 48 2.8.5 遍历和遍历过程中的动作 48 2.8.6 封装分析 48 2.8.7 Visitor 类及其子类 51 2.8.8 Visitor 模式 52 2.9 小结 53 第3章 创建模式 54 3.1 Abstract Factory(抽象工厂)— 对象创建模式 57 3.2 Builder(生成器)—对象创建 模式 63 3.3 Factory Method(工厂方法)— 对象创建模式 70 3.4 Prototype(原)—对象创建 模式 87 3.5 Singleton(单件)—对象创建 模式 84 3.6 创建模式的讨论 89 第4章 结构模式 91 4.1 Adapter(适配器)—类对象结构 模式 92 4.2 Bridge(桥接)—对象结构 模式 100 4.3 Composite(组成)—对象结构 模式 107 4.4 Decorator(装饰)—对象结构 模式 115 4.5 FACADE(外观)—对象结构 模式 121 4.6 Flyweight(享元)—对象结构 模式 128 4.7 Proxy(代理)—对象结构 模式 137 4.8 结构模式的讨论 144 4.8.1 Adapter与Bridge 144 4.8.2 Composite、Decorator与Proxy 145 第5章 行为模式 147 5.1 CHAIN OF RESPONSIBIL ITY(职责链) —对象行为模式 147 5.2 COMMAND(命令)—对象行为 模式 154 5.3 INTERPRETER(解释器)—类行为 模式 162 5.4 ITERATOR(迭代器)—对象行为 模式 171 5.5 MEDIATOR(中介者)—对象行为 模式 181 5.6 MEMENTO(备忘录)—对象行为 模式 188 5.7 OBSERVER(观察者)—对象行为 模式 194 5.8 STATE(状态)—对象行为模式 201 5.9 STRATEGY(策略)—对象行为 模式 208 5.10 TEMPLATE METHOD(模板方法) —类行为模式 214 5.11 VISITOR(访问者)—对象行为 模式 218 5.12 行为模式的讨论 228 5.12 1 封装变化 228 5.12.2 对象作为参数 228 5.12.3 通信应该被封装还是被分布 229 5.12.4 对发送者和接收者解耦 229 5.12.5 总结 231 第6章 结论 232 6.1 设计模式将带来什么 232 6.2 一套通用的设计词汇 232 6.3 书写文档和学习的辅助手段 232 6.4 现有方法的一种补充 233 6.5 重构的目标 233 6.6 本书简史 234 6.7 模式界 235 6.8 Alexander 的模式语言 235 6.9 软件中的模式 236 6.10 邀请参与 237 6.11 临别感想 237 附录A 词汇表 238 附录B 图示符号指南 241 附录C 基本类 244 参考文献 249
目录: 前 言 第一部分 大旗不挥,谁敢冲锋——热身篇 第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个设计模式
针对23种设计模式,分别写了demo并画了类图帮助理解。 总体来说设计模式分为三大类: 创建模式,共五种:工厂方法模式、抽象工厂模式、单例模式、建造者模式、原模式。 结构模式,共七种:适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式行为模式,共十一种:策略模式模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。 其实还有两类:并发模式和线程池模式。 二、设计模式的六大原则 1、开闭原则(Open Close Principle) 开闭原则就是说对扩展开放,对修改关闭。在程序需要进行拓展的时候,不能去修改原有的代码,实现一个热插拔的效果。所以一句话概括就是:为了使程序的扩展性好,易于维护和升级。想要达到这样的效果,我们需要使用接口和抽象类,后面的具体设计中我们会提到这点。 2、里氏代换原则(Liskov Substitution Principle) 里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。 里氏代换原则中说,任何基类可以出现的地方,子类一定可以出现。 LSP是继承复用的基石,只有当衍生类可以替换掉基类,软件单位的功能不受到影响时,基类才能真正被复用,而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现,所以里氏代换原则是对实现抽象化的具体步骤的规范。—— From Baidu 百科 3、依赖倒转原则(Dependence Inversion Principle) 这个是开闭原则的基础,具体内容:真对接口编程,依赖于抽象而不依赖于具体。 4、接口隔离原则(Interface Segregation Principle) 这个原则的意思是:使用多个隔离的接口,比使用单个接口要好。还是一个降低类之间的耦合度的意思,从这儿我们看出,其实设计模式就是一个软件的设计思想,从大软件架构出发,为了升级和维护方便。所以上文中多次出现:降低依赖,降低耦合。 5、迪米特法则(最少知道原则)(Demeter Principle) 为什么叫最少知道原则,就是说:一个实体应当尽量少的与其他实体之间发生相互作用,使得系统功能模块相对独立。 6、合成复用原则(Composite Reuse Principle) 原则是尽量使用合成/聚合的方式,而不是使用继承。

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值