《大话设计模式》学习笔记25[完结]:模式总结

一、创建型模式(5):原型、建造者、单例、工厂、抽象工厂。

  1.原型模式:建立相应数目的原型并克隆它们通常比每次用合适的状态手工实例化该类更方便。

  2.建造者模式:将一个复杂对象的构建与它的表示分离,用同样的构建过程创建不同的产品。

  3.单例模式:让类自身负责保存它的唯一实例。这个类可以保证没有其他实例可以被创建,并且提供一个访问该实例的方法。这样对唯一的实例就可以严格地控制客户怎样以及何时访问它。

  创建型模式隐藏了类的实例是如何被创建和放在一起的,整个系统关于这些对象所知道的是由抽象类所定义的接口。这样,创建型模式在创建了什么、谁创建它、它是怎么被创建的,以及何时创建这些方面提供了很大的灵活性。

  创建型模式抽象了实例化的过程。它们帮助一个系统独立于如何创建、组合和表示它的那些对象。创建型模式都会将关于该系统使用哪些具体的类的信息封装起来。允许用结构和功能差别很大的“产品”对象配置一个系统。配置可以是静态的,即在编译时指定,也可以是动态的,即在运行时指定。

  通常设计应该是从工厂模式开始,当设计者发现需要更大的灵活性时,设计便会向其他创建型模式演化。当设计者在设计标准之间进行权衡的时候,了解多个创建型模式可以给设计者更多的选择余地。

二、结构型模式(7):适配器、桥接、装饰、组合、外观、代理、享元。

  1.适配器模式:让接口不同的类通过适配后协同工作。

  2.桥接模式:解耦不同方向的变化,通过对象组合的方式,把两个角色之间的继承关系改为了组合的关系,从而使这两者可以应对各自独立的变化。

  3.装饰模式:以动态、透明的方式给单个对象添加职责,并在不需要时撤销相应的职责。

  4.组合模式:可以一致地使用组合结构和单个对象。任何用到基本对象的地方都可以使用组合对象。

  5.外观模式:应该让一个软件中的子系统间的通信和相互依赖关系达到最小,而具体办法就是引入一个外观对象,它为子系统间提供了一个单一而简单的屏障。

  

  代理与外观的主要区别在于,代理对象代表一个单一对象而外观对象代表一个子系统;代理的客户对象无法直接访问目标对象,由代理提供对单独的目标对象的访问控制,而外观的客户对象可以直接访问子系统中的各个对象,但通常由外观对象提供对子系统各元件功能的简化的共同层次的调用接口。

  代理与适配器的区别在于,代理是一种原来对象的代表,其他需要与这个对象打交道的操作都是和这个代表交涉。而适配器不需要虚构出一个代表者,只需要为应付特定使用目的,将原来的类进行一些组合。

三、行为型模式(11):模板方法、命令、职责链、状态、解释器、中介者、访问者、策略、备忘录、迭代器、观察者。

  1.模板方法模式:由一个抽象类组成,这个抽象类定义了需要覆盖的可能有不同实现的模板方法,每个从这个抽象类派生的具体类将为此模板实现新方法。

  2.命令模式:将错做调用的对象与指导如何实现该操作的对象解耦,可以在不同的时刻指定、排列和执行请求。

  3.职责链模式:让客户在不明确指定接收者的情况下提交一个请求,然后由所有能处理这请求的对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它为止。

  4.状态模式:提供了一个更好的办法来组织与特定状态相关的代码,决定状态转移的逻辑不在单块的if或switch中,而是分布在各个状态子类之间,由于所有与状态相关的代码都存在于某个状态子类中,所以通过定义新的子类可以很容易地增加新的状态和转换。

  5.解释器模式:如果一种特定类型的问题发生的频率足够高,那么久可以考虑将该问题的各个实例表述为一个简单语言中的句子。也就是说,通过构建一个解释器,该解释器解释这些句子来解决该问题。

  6.中介者模式:将集体行为封装一个单独的中介者对象,中介者负责控制和协调一组对象间的交互。中介者充当一个中介以使组中的对象不再相互显示引用。这些对象仅知道中介者,从而减少了相互连接的数目。

  7.访问者模式:访问者增加具体的Element是困难的,但增加依赖于复杂对象结构的构件的操作就变得容易。仅需增加一个新的访问者即可在一个对象结构上定义一个新的操作。

  8.策略模式:将算法封装在独立的策略类中使得可以独立于其类改变它,使它易于切换、易于理解、易于扩展。

  9.备忘录模式:可以避免暴露一些只应由对象A管理却又必须存储在对象A之外的信息。备忘录模式把可能很复杂的对象的内部信息对其他对象屏蔽起来,从而保持了封装边界。

  10.迭代器模式:将对列表的访问和遍历从列表对象中分离出来并放入一个迭代器对象中,迭代器类定义了一个访问该列表元素的接口。迭代器对象负责跟踪当前的元素,并且知道哪些元素已经遍历过。

时间: 2024-10-07 06:47:27

《大话设计模式》学习笔记25[完结]:模式总结的相关文章

[大话设计模式]学习笔记——简单工厂模式

序 说好的每天进步一点点的,结果工作太忙,一直在加班,都没有学习新东西.我还要进BAT呢. 坚持每天学习新东西. 写代码时,意识到在代码结构上还是有点欠缺.赶紧补上. 纪录对设计模式的认识.小菜变大鸟.进攻BAT. 应用场景: 编写一个计算器控制台程序,要求输入两个数和运算符号,得到结果. 这本书使用C#写的.已有博主用JAVA写出来,参考:http://blog.csdn.net/ghsau/article/details/8163418 常见的做法: 写一个方法封装计算机的功能,我们只需传参

大话设计模式学习笔记——面向对象基础

前言 好记性不如烂"笔头"系列--大话设计模式学习笔记 目录 面向对象基础 面向对象基础 什么是类与实例 一切事物皆为对象,即所有的东西老师对象,对象就是可以看到.感觉到.听到.触摸到.尝到.或闻到的东西.准确地说,对象是一个自包含的实体,用一组可识别的特性和行为来标识.面向对象编程,英文叫 Object-Oriented Programming,其实就是针对对象来进行编程的意思.类就是具有相同属性和功能的对象的抽象集合.实例就是一个真实的对象.比如我们属于'人'类,而个人就是'人'类

大话设计模式读书笔记2——策略模式

策略模式是一种定义一系列算法的方法,从概念上来看,所有这些算法完成的都是相同的工作,只是实现不同,它可以以相同的方式调用所有的算法,减少了各种算法类与使用算法类直接的耦合. UML 图: 根据<大话设计模式>——第二章 商场促销这个案例代码来简单的记录一下策略模式的使用方式: /// <summary> /// 现金收费抽象类 /// </summary> public abstract class CashSuper { /// <summary> ///

设计模式学习笔记--备忘录(Mamento)模式

写在模式学习之前 什么是设计模式:在我们进行程序设计时,逐渐形成了一些典型问题和问题的解决方案,这就是软件模式:每一个模式描述了一个在我们程序设计中经常发生的问题,以及该问题的解决方案:当我们碰到模式所描述的问题,就可以直接用相应的解决方法去解决这个问题,这就是设计模式. 设计模式就是抽象出来的东西,它不是学出来的,是用出来的:或许你根本不知道任何模式,不考虑任何模式,却写着最优秀的代码,即使以"模式专家"的角度来看,都是最佳的设计,不得不说是"最佳的模式实践",这

设计模式学习笔记--状态(State)模式

写在模式学习之前 什么是设计模式:在我们进行程序设计时,逐渐形成了一些典型问题和问题的解决方案,这就是软件模式:每一个模式描述了一个在我们程序设计中经常发生的问题,以及该问题的解决方案:当我们碰到模式所描述的问题,就可以直接用相应的解决方法去解决这个问题,这就是设计模式. 设计模式就是抽象出来的东西,它不是学出来的,是用出来的:或许你根本不知道任何模式,不考虑任何模式,却写着最优秀的代码,即使以"模式专家"的角度来看,都是最佳的设计,不得不说是"最佳的模式实践",这

设计模式学习笔记--迭代(Iterator)模式

写在模式学习之前 什么是设计模式:在我们进行程序设计时,逐渐形成了一些典型问题和问题的解决方案,这就是软件模式:每一个模式描述了一个在我们程序设计中经常发生的问题,以及该问题的解决方案:当我们碰到模式所描述的问题,就可以直接用相应的解决方法去解决这个问题,这就是设计模式. 设计模式就是抽象出来的东西,它不是学出来的,是用出来的:或许你根本不知道任何模式,不考虑任何模式,却写着最优秀的代码,即使以"模式专家"的角度来看,都是最佳的设计,不得不说是"最佳的模式实践",这

设计模式学习笔记--访问者(Visitor)模式

写在模式学习之前 什么是设计模式:在我们进行程序设计时,逐渐形成了一些典型问题和问题的解决方案,这就是软件模式:每一个模式描述了一个在我们程序设计中经常发生的问题,以及该问题的解决方案:当我们碰到模式所描述的问题,就可以直接用相应的解决方法去解决这个问题,这就是设计模式. 设计模式就是抽象出来的东西,它不是学出来的,是用出来的:或许你根本不知道任何模式,不考虑任何模式,却写着最优秀的代码,即使以"模式专家"的角度来看,都是最佳的设计,不得不说是"最佳的模式实践",这

大话设计模式学习笔记

大话设计模式笔记 1. 使用简单工厂模式(使用反射可以解决避免分支判断问题) 注重创建不同的对象 2. 使用策略模式处理 不同的时间应用不同的业务规则 3. 单一原则:一个类仅有一个变化的原因  发现职责并把职责分离 4. 开放-封闭原则:软件实体可以扩展但不能修改  对扩展开放 对更改封闭 开发人员对程序中呈频繁变化的那部分做出抽象 5. 依赖倒转原则: A.高层模块不应依赖底层模块.两者都应该依赖抽象. B.抽象不应该依赖细节,细节应该依赖于抽象.即针对接口编程, 不应针对实现编程. 里氏替

设计模式学习笔记--工厂方法模式

学习过简单工厂模式,感觉很好用.在创建对象时,可以将复杂的初始化操作从客户端分离出来,简化客户端代码.大大的减少了代码修改的难度.而且可以通过参数不同,创建不同的对象. 但是简单工厂模式也有一些弊端,违背了开放--封闭原则.即如果我们增加了一个产品,对应的工厂也要进行修改,即switch---case中要新增加一些分支条件,不利于扩展.所以就有了下面的工厂方法模式: 工厂方法模式:定义了一个用于创建对象的接口,子类决定实例化哪一个类,工厂方法模式使一个类的实例化延迟到子类. // 设计模式Dem