![](https://img-blog.csdnimg.cn/20201014180756780.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
设计模式
平静大海
这个作者很懒,什么都没留下…
展开
-
第4讲:Builder 生成器模式
Builder模式的缘起假设创建游戏中的一个房屋House设施,该房屋的构建由几个部分组成,且各个部分要富于变化。如果使用最直观的设计方法,每一个房屋部分的变化,都将导致房屋构建的重新修正…… 动机(Motivation)在软件系统中,有时候面临着“一个复杂对象”的创建工作,其通常由各个部分的子对象用一定的算法构成;由于需求的变化,这个复杂对象的各个部分经常面临着剧烈的变化,但转载 2013-07-02 10:29:54 · 657 阅读 · 0 评论 -
第18讲:Iterator 迭代器模式
2006.7.12 李建忠集合内部结构与外部访问 动机(Motivation)在软件构建过程中,集合对象内部结构常常变化各异。但对于这些集合对象,我们希望在不暴露其内部结构的同时,可以让外部客户代码透明地访问其中包含的元素;同时这种“透明遍历”也为“同一种算法在多种集合对象上进行操作”提供了可能。使用面向对象技术将这种遍历机制抽象为“迭代器对象”为“应对变化中的集合对象”提转载 2013-07-02 10:46:14 · 585 阅读 · 0 评论 -
第20讲:Chain Of Responsibility 职责链模式
请求的发送者与接受者某些对象请求的接受者可能多种多样,变化无常…… 动机(Motivation)在软件构建过程中,一个请求可能被多个对象处理,但是每个请求在运行时只能有一个接受者,如果显示指定,将必不可少地带来请求发送者与接受者的紧耦合。如何使请求的发送者不需要指定具体的接受者?让请求的接受者自己在运行时决定来处理请求,从而使两者解耦。 意图(Intent)使多转载 2013-07-02 10:47:31 · 665 阅读 · 0 评论 -
第15讲:Command 命令模式
2006.5.12 李建忠耦合与变化耦合是软件不能抵御变化灾难的根本性原因。不仅实体对象与实体对象之间存在耦合关系,实体对象与行为操作之间也存在耦合关系。创建型设计模式解决的创建者和被创建对象的耦合问题;结构型设计模式解决的是实体对象和实体对象的耦合问题;行为型设计模式解决的是实体对象和行为操作之间的耦合问题。 动机(Motivation)在软件构建过程中,转载 2013-07-02 10:43:47 · 647 阅读 · 0 评论 -
第17讲:Mediator 中介者模式
依赖关系的转化 动机(Motivation)在软件构建过程中,经常会出现多个对象互相关联交互的情况,对象之间常常会维持一种复杂的引用关系,如果遇到一些需求的更改,这种直接的引用关系将面临不断地变化。在这种情况下,我们可使用一个“中介对象”来管理对象间的关联关系,避免相互交互的对象之间的紧耦合引用关系,从而更好地抵御变化。 意图(Intent)用一个中介对象来封装转载 2013-07-02 10:45:43 · 678 阅读 · 0 评论 -
第19讲:Observer 观察者模式
2006.7.19 李建忠发布-订阅模型当我们账户的金额有任何的操作,如果我们订阅了服务,例如手机、Email等,那么我们都会得到通知。 动机(Motivation)在软件构建过程中,我们需要为某些对象建立一种“通知依赖关系”——一个对象(目标对象)的状态发生改变,所有的依赖对象(观察者对象)都将得到通知。如果这样的依赖关系过于紧密,将使软件不能很好地抵御变化。使用面向转载 2013-07-02 10:46:33 · 634 阅读 · 0 评论 -
第23讲:Strategy 策略模式
算法与对象的耦合对象可能经常需要使用多种不同的算法,但是如果变化频繁,会将类型变得脆弱…… 动机(Motivation)在软件构建过程中,某些对象使用的算法可能多种多样,经常改变,如果将这些算法都编码到对象中,将会使对象变得异常复杂;而且有时候支持不使用的算法也是一个性能负担。如何在运行时根据需要透明地更改对象的算法?将算法与对象本身解耦,从而避免上述问题? 意图(转载 2013-07-03 18:05:34 · 665 阅读 · 0 评论 -
C#面向对象设计模式纵横谈
第I章 开篇第1讲:面向对象设计模式与原则第II章 创建型模式第2讲:Singleton 单件第3讲:Abstract Factory 抽象工厂模式第4讲:Builder 生成器模式第5讲:Factory Method 工厂方法模式第6讲:Prototype 原型模式第III章 结构型模式第7讲:Adapter 适配器模式第8讲:Bridge 桥接模式第转载 2013-07-03 18:05:04 · 727 阅读 · 0 评论 -
第21讲:Memento 备忘录模式
2006.8.29 李建忠对象状态的回溯对象状态的变化无端,如何回溯/恢复对象在某个点的状态如果我们想恢复对象的状态,那么我们可能首先想到的是把对象保存下来,但是这样会破坏对象的封装性。因为对象有状态有操作,如果我们为了保存对象而留着原来的对象,做一个深拷贝,那么其他对象也能通过这个对象的接口访问这个对象状态,这并不是我们所希望的。而我们需要它的职责只是保存和恢复对象状态,而不应在转载 2013-07-03 18:05:52 · 570 阅读 · 0 评论 -
第25讲:设计模式总结
创建型模式Singleton模式解决的是实体对象个数的问题。除了Singleton之外,其他创建型模式解决的都是new所带来的耦合关系。Factory Method,Abstract Factory,Builder都需要一个额外的工厂类来负责实例化“易变对象”,而Prototype则是通过原型(一个特殊的工厂类)来克隆“易变对象”。如果遇到“易变类”,起初的设计通常从Factory M转载 2013-07-03 18:05:14 · 590 阅读 · 0 评论 -
第24讲:Visitor 访问者模式
2006.10.13 李建忠类层次结构的变化类层次结构中可能经常由于引入新的操作,从而将类型变得脆弱…… 动机(Motivation)在软件构建过程中,由于需求的改变,某些类层次结构中常常需要增加新的行为(方法),如果直接在基类中做这样的更改,将会给子类带来很繁重的变更负担,甚至破坏原有设计。如何在不更改类层次结构的前提下,在运行时根据需要透明地为类层次结构上的各个类动转载 2013-07-03 18:05:23 · 639 阅读 · 0 评论 -
第22讲:State 状态模式
对象状态影响对象行为对象拥有不同的状态,往往会行使不同的行为…… 动机(Motivation)在软件构建过程中,某些对象的状态如果改变,其行为也会随之而发生变化,比如文档处于只读状态,其支持的行为和读写状态支持的行为就可能完全不同。如何在运行时根据对象的状态来透明地更改对象的行为?而不会为对象操作和状态转化之间引入紧耦合? 意图(Intent)允许一个对象在其内转载 2013-07-03 18:05:43 · 635 阅读 · 0 评论 -
第16讲:Interpreter 解释器模式
动机(Motivation)在软件构建过程中,如果某一特定领域的问题比较复杂,类似的模式不断重复出现,如果使用普通的编程方式来实现将面临非常频繁的变化。在这种情况下,将特定领域的问题表达为某种语法规则下的句子,然后构建一个解释器来解释这样的句子,从而达到解决问题的目的。 意图(Intent)给定一个语言,定义它的文法的一种表示,并定义一种解释器,这个解释器使用该表示来解释语言中转载 2013-07-02 10:44:36 · 594 阅读 · 0 评论 -
第10讲:Decorator 装饰模式
子类复子类,子类何其多假如我们需要为游戏中开发一种坦克,除了各种不同的型号的坦克外,我们还希望在不同场合中为其增加以下一种或多种功能:比如红外线夜视功能,比如水陆两栖功能,比如卫星定位功能等等。如果再添加一种功能D,那么需要增加的T50子类的数量可想而知,而这只是T50这个类型,如果还有其他T70等类型,那么需要新添加的子类将不可计数。 动机(Motivation)上述转载 2013-07-02 10:40:21 · 560 阅读 · 0 评论 -
第9讲:Composite 组合模式
对象容器的问题在面向对象系统中,我们常会遇到一类具有“容器”特征的对象——即它们在充当对象的同时,又是其他对象的容器。如果我们要对这样的对象容器进行处理:上面是客户代码,客户代码里面必须要知道对象的结构,有可能还要使用递归的方法来处理这个对象,这样写耦合性就比较高。客户代码如果能只和IBox发生依赖就很好了,但是现在它还和ContainerBox和SingleBox发生转载 2013-07-02 10:39:23 · 594 阅读 · 0 评论 -
第5讲:Factory Method 工厂方法模式
从耦合关系谈起耦合关系直接决定着软件面对变化时的行为-模块与模块之间的紧耦合使得软件面对变化时,相关模块都要随之更改-模块与模块之间的松耦合使得软件面对变化时,一些模块更容易被替换或者更改,但其他模块保持不变 抽象部分变化慢,细节(具体)部分变化快;高层部分变化慢,底层部分变化快。当我们对于系统的认识无法梳理出上面的图时,最好不要一开始就用设计模式,设计模式转载 2013-07-02 10:31:10 · 931 阅读 · 0 评论 -
第6讲:Prototype 原型模式
依赖关系的倒置抽象不应该依赖于实现细节,实现细节应该依赖于抽象。-抽象A直接依赖于实现细节b(软件易脆,很容易需要重新编译)-抽象A依赖于抽象B,实现细节b依赖于抽象B 动机(Motivation)在软件系统中,经常面临着“某些结构复杂的对象”的创建工作;由于需求的变化,这些对象经常面临着剧烈的变化,但是它们却拥有比较稳定一致的接口。如何应对这种变化?如转载 2013-07-02 10:33:01 · 674 阅读 · 0 评论 -
第11讲:Facade 外观模式
系统的复杂度假设我们需要开发一个坦克模拟系统用于模拟坦克车在各种作战环境中的行为,其中坦克系统由引擎、控制器、车轮、车身等各子系统构成。 如何使用这样的系统 动机(Motivation)上述A方案的问题在于组件的客户(即外部接口,或客户程序)和组件中各种复杂的子系统有了过多的耦合,随着外部客户程序和各子系统的演化,这种过多的耦合面临很多变化的挑战。如何简化外转载 2013-07-02 10:41:04 · 449 阅读 · 0 评论 -
第12讲:Flyweight 享元模式
面向对象的代价面向对象很好地解决了系统抽象性的问题,同时在大多数情况下,也不会损及系统的性能。但是,在某些特殊的应用中,由于对象的数量太大,采用面向对象会给系统带来难以承受的内存开销。比如图形应用中的图元等对象、字处理应用中的字符对象等。 动机(Motivation)采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中,从而带来很高的运行时代价——主要指内存需求方面转载 2013-07-02 10:41:44 · 568 阅读 · 0 评论 -
第13讲:Proxy 代理模式
直接与间接人们对于复杂的软件系统常常有一种处理手法,即增加一层间接层,从而对系统获得一种更为灵活、满足特定需求的解决方案。假设A要访问B三次。如果A和B是分布式中的两个机器,那么A需要跨机器调用B三次就不是很好。如果在A和B之间加一个代理对象C,并且A和C处于同一个地址空间,即同一个机器。那么A和C之间通讯是非常高效的,现在A和C之间调用三次,到某个触发点的时候,和B只需要一次的通转载 2013-07-02 10:42:33 · 779 阅读 · 0 评论 -
第14讲:Template Method 模板方法
无处不在的Template Method如果你只想掌握一种设计模式,那么它就是Template Method! 变与不变变化——是软件设计的永恒主题,如何管理变化带来的复杂性?设计模式的艺术性和复杂度就在于如何分析,并发现系统中的变化点和稳定点,并使用特定的设计方法来应对这种变化。 动机(Motivation)在软件构建过程中,对于某一项任务,转载 2013-07-02 10:43:11 · 484 阅读 · 0 评论 -
第3讲:Abstract Factory 抽象工厂模式
new的问题常规的对象创建方法: new的问题:-实现依赖,不能应对“具体实例化类型”的变化解决思路:-封装变化点——哪里变化,封装哪里-潜台词:如果没有变化,当然不需要额外的封装! 工厂模式的缘起变化点在“对象创建”,因此就封装“对象创建”面向接口编程——依赖接口,而非依赖实现最简单的解决方法: 创建一系列相互依赖的对象假设一个游戏转载 2013-07-02 10:27:27 · 583 阅读 · 0 评论 -
第8讲:Bridge 桥接模式
抽象与实现抽象不应该依赖于实现细节,实现细节应该依赖于抽象。问题在于如果抽象B由于固有的原因,本身并不稳定,也有可能变化,怎么办? 举例来说假如我们需要开发一个同时支持PC和手机的坦克游戏,游戏在PC和手机上功能都一样,都有同样的类型,面临同样的功能需求变化,比如坦克可能有很多种不同的型号:T50,T75,T90……对于其中的坦克设计,我们可能很容易设计出来一个Ta转载 2013-07-02 10:38:06 · 611 阅读 · 0 评论 -
第1讲:面向对象设计模式与原则
设计模式简介每一个模式描述了一个在我们周围不断重复发生的问题,以及该问题的解决方案的核心——Christopher Alexander 设计模式描述了软件设计过程中某一类常见问题的一般性的解决方案。面向对象设计模式描述了面向对象设计过程中、特定场景下、类与相互通信的对象之间常见的组织关系。 人是一个经验性的动物 GoF 23种设计模式转载 2013-07-02 10:25:02 · 822 阅读 · 0 评论 -
第2讲:Singleton 单件
模式分类从目的来看:-创建型(Creational)模式:负责对象创建-结构型(Structural)模式:处理类与对象间的组合-行为型(Behavioral)模式:类与对象交互中的职责分配从范围来看:-类模式处理类与子类的静态关系-对象模式处理对象间的动态关系动机(Motivation)在软件系统中,经常有这样一些特殊的类,必须保证它们在系统中只存在一个实转载 2013-07-02 10:26:36 · 750 阅读 · 0 评论 -
JAVA设计模式--单例模式
单例设计模式Singleton是一种创建型模式,指某个类采用Singleton模式,则在这个类被创建后,只可能产生一个实例供外部访问,并且提供一个全局的访问点。核心知识点如下:(1) 将采用单例设计模式的类的构造方法私有化(采用private修饰)。(2) 在其内部产生该类的实例化对象,并将其封装成private static类型。(3) 定义一个静态方法返转载 2017-03-03 15:01:52 · 242 阅读 · 0 评论