李建忠老师讲的<面向对象设计模式纵横谈>,早就看过了,现在有了时间重新整理一下,以前的博客[赛迪网]没有了,现在搬到博客园,重新过一遍,也便于以后浏览. 设计模式从不同的角度分类会得到不同的结果.设计模式可以从[目的]和[范围]两个角度来看看. 模式分类 从目的来看[这个分来是广泛使用的]: -创建型(Creational)模式:负责对象的创建 -结构型(Structural)模式:处理类与对象间的组合关系 -行为型(Behavioral)模式:类与对象交互中的职责分配的问题 从范围来看…

一:设计模式简介 每一个模式描述了一个在我们周围不断重复发生的问题,以及该问题的解决方案的核心. ---- Christopher Alexander 软件设计领域设计模式: 设计模式描述了软件设计过程中某一类常见问题的解决方案. 面向对象的设计模式: 面向对象的设计模式描述了面向对象设计过程中,特定场景下,类与相互通信的对象之间常见的组织关系. 二: GOF 23种设计模式 历史性著作 <设计模式 : 可复用面向对象软件的基础>一书中描述了23种经典面向对象设计模式,创立了模式在软件设计中的…

     今天是设计模式的第二讲,抽象工厂的设计模式,我们还是延续老办法,一步一步的.演变的来讲,先来看看一个对象创建的问题. 1.如何创建一个对象 常规的对象创建方法: 这样的创建对象没有任何问题,也可以很好的使用.但是如果有需求的变化,比如,如果我们换了一种道路呢,这时候就出现了问题. new的问题: -实现依赖,不能应对"具体实例化类型"的变化,Road是具体类型,所有使用到Road的地方都需要变化.如果经常变化,怎么解决具体类型的变化呢? 解决思路: -封装变化点--哪里变化,…

为什么学习设计模式: 1,更深入的了解面向对象的思想 2,有利于开发出扩展性强的东西 什么是设计模式:经常出现的典型场景的典型解决方案,就是设计模式.举个例子生活中的设计模式:比如泡妞思路,象棋招数等.那么如何学习设计模式?典型场景-->典型问题-->典型解决方法 多态 多态是一个生物学上的概念,指同一种类的多种表现形态,如:鲫鱼一般在一斤左右,鲢鱼普遍在十斤以上,在面向对象中,指某种对象(比如一种老虎)实例的不同表现形态,比如有的虎会爬树,有的则不会.在强类型语言java中,函数参数,函数的…

动机:采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中,从而带来很高的运行代价——主要指内存需求方面的代价.如何在避免大量细粒度对象问题的同 时,让外部客户程序仍然能够透明地使用面向对象的方式来进行操作?意图:运用共享技术有效地支持大量细粒度的对象. UML图解: Flyweight模式现实中的应用: 1.现行的博客.企业.商务网站中其网站的代码本质上是一样的,不一样的只是具体的数据和模板而代码核心和数据库却是共享的:所以现行的做法是将每个用户的博客或网站整合到一个网站中,共享其相关…

定义 定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动更新.  Observer模式描述了如何建立这种关系.这一模式中的关键对象是目标(subject)和观察者(observer).一个目标可以有任意数目的依赖它的观察者.一旦目标的状态发生改变,所有的观察者都得到通知.这种交互也称为发布-订阅(publish-subscribe).目标是通知的发布者.故观察者模式又名 依赖(Dependents),发布-订阅(Publish-Subscribe)…

一.类自动载入 SPL函数 (standard php librarys) 类自动载入,尽管 __autoload() 函数也能自动加载类和接口,但更建议使用 spl_autoload_register('函数名') 函数. spl_autoload_register('函数名') 提供了一种更加灵活的方式来实现类的自动加载(同一个应用中,可以支持任意数量的加载器,比如第三方库中的).因此,不再建议使用 __autoload() 函数,在以后的版本中它可能被弃用. spl_autoload_re…

桥接模式是一个比较难理解的设计模式,设计和分析的时候也不容易把握,咱们听听“李建忠”老师是怎么来讲的.我们还是从演变的角度来说问题,一步一步的来把问题说清楚.先谈谈“抽象”和“实现”的关系. 抽象与实现 抽象不应该依赖于实现细节,实现细节应该依赖于抽象.这个东西很容易理解,抽象的东西是从众多的实例里面提取出来的精华,最原始,最稳定的东西,枝枝叶叶都已经去掉了. 就像建房子一样,我们一定要把地基打结实,如果地基天天改,上面的房子也很难建的起来,就算建起来也要拆了重新来建. 再者说,如果抽象B由于固…

从耦合关系谈起 耦合关系直接决定着软件面对变化时的行为 -模块与模块之间的紧耦合使得软件面对变化时,相关模块都要随之更改 -模块与模块之间的松耦合使得软件面对变化时,一些模块更容易被替换或者更改,但其他模块保持不变 抽象部分变化慢,细节(具体)部分变化快:高层部分变化慢,底层部分变化快. 当我们对于系统的认识无法梳理出上面的图时,最好不要一开始就用设计模式,设计模式其实是一个演绎的过程.当我们对软件认识不断深化时,慢慢就会知道哪些是主要的,哪些是次要的,就能梳理出一个抽象和具体的层次,再考虑用哪…

动机(Motivation) 在软件系统中,经常面临着“某些结构复杂的对象”的创建工作.由于需求的变化,这些对象经常面临着剧烈的变化,但他们却拥有比较稳定一致的接口. 如何应对这种变化?如何向“客户程序(使用这些对象的)”隔离出“这些易变对象”,从而使得“依赖这些易变对象的客户程序”不随着需求的改变而改变. 意图(Intent) 使用原型实例指定创建对象的种类,然后通过拷贝这些原型来创建新的对象.   ----<设计模式> GOF 结构(Structure)…

动机 (Motivation) 在软件系统中,经常面临着“某个对象”的创建工作; 由于需求的变化,这个对象经常面临着剧烈的变化,但是它却拥有比较稳定的接口. 如何应对这种变化?如何提供一种“封装机制”来隔离出“这个易变对象”的变化,从而保持系统中“其他依赖该对象的对象”不随着需求改变而改变 ? 意图 (Intent) 定义一个用于创建对象的接口,让子类决定实例化哪一个类.Factory Method 使得一个类的实例化延迟到子类.  ———<设计模式> GOF 结构(Structure)…

动机 (Motivation) 在软件系统中,有时候面临着“一个复杂对象”的创建工作,其通常由各个部分的子对象用一定的算法构成:由于需求的变化,这个复杂对象的各个部分经常面临着剧烈的变化,但是它们组合在一起的算法却相对稳定. 如何应对这种变化?如何提供一种“封装机制”来隔离出“复杂对象的各个部分”的变化,从而保持系统的“稳定构建算法”不随着需求改变而变化 ? 意图(Intent) 将一个复杂对象的构建与其表示分离,使得同样的构建过程可以创建不同的表示. ------<设计模式> GoF 结构 …

动机(Motivation) 在软件系统中经常面临着“一系列相互依赖的对象”的创建工作,同时,由于需求变化,往往存在更多系列对象的创建工作.如何应对这种变化?如何绕过常规对象的创建,提供一种“封装机制”来避免客户程序和这种“多系列具体对象的创建工作”的紧耦合? 意图(Intent) 提供一个接口,让该接口负责创建一系列“相关或者相互依赖的对象”,无需指定它们具体的类. ---<设计模式> GoF 结构 (Structure)…

一:模式分类 从目的来看: 创建型(Creational)模式:负责对象创建. 结构型(Structural)模式:处理类与对象间的组合. 行为型(Behavioral)模式:类与对象交互中的职责分配. 从范围来看: 类模式处理类与子类的静态关系. 对象模式处理对象间的动态关系. 二:Singleton (创建型模式) 单件 1.动机(Motivation) 软件系统中,经常有这样一些特殊的类,必须保证他们在系统中只存在一个实例,才能确保它们的逻辑正确性,以及良好的效率. 如何绕过常规的构造器,…

动机:在软件构建过程中 ,如果某一特定领域的问题比较复杂,类似的模式不断重复出现,如果使用普通的编程方式来实现将面临非常频繁的变化.在这种情况下,将特定领域的问题表达为某种语法规则的句子,然后构建一个解释器来解释这样的句子,从而达到解决问题的目的.意图:给定一个语言,定义它的文法的一种表示,并定义一种解释器,这个解释器使用该表示来解释语言中的句子. UML图解: 示例:接收中文形式的数字表示并能以罗马形式数字输出,应用解释器模式设计,如:四百七十一万六千四百五十二 =>4716452.代码如下…

到目前为止,我已经写完了面向对象完整的一个系列知识,前面基本属于理论,原理的理解,接下来,我们就用学到的知识来实战下吧. 看看理解原理和理论是否重要?例子从简单到复杂 一.单体(字面量)封装加减乘除 var Oper = { add : function( n1, n2 ){ return n1 + n2; }, sbb : function( n1, n2 ){ return n1 - n2; }, mul : function( n1, n2 ){ return n1 * n2; }, di…

在.Net框架中很多对象的方法中都会有Invoke方法,这种方法的设计实际是用了设计模式的命令模式, 模式图如下 其核心思路是将Client 向Receiver发送的命令行为进行抽象(ICommand),实例化(ConcreteCommand),以便对这些行为能够控制(记录,取消,恢复): 每个Command与Client是解耦的,即不依赖具体客户,调度者Invoker可以负责记录,控制客户执行了那些请求,与客户端存在单一的关联. 示例:计算器(Calculator)可以执行很多计算操作,客户(…

适配(转换)的概念无处不在 适配,即在不改变原有实现的基础上,将原先不兼容的接口转换为兼容的接口.生活中适配转换的例子太多了,也是设计模式里面比较容易理解的一个模式. 动机(Motivation) 在软件系统中,由于应用环境的变化,常常需要将“一些现存的对象”放在新的环境中应用,但是新环境要求的接口是这些现存对象所不满足的. 如何应对这种“迁移的变化”?如何既能利用现有对象的良好实现,同时又能满足新的应用环境所要求的接口? 意图(Intent) 将一个类的接口转换成客户希望的另一个接口.Adap…

   有一段时间没写东西了,今天继续把没写完的设计模式写完,今天这堂课是创建型设计模式的最后一堂课,原型设计模式,它同样也是解决了对象在创建的过程中的解耦合的情况,面对变化使代码更稳定,更准确的说是使创建对象的主业务逻辑更稳定.好了,我们继续.我们县讨论一下依赖关系.    依赖关系的倒置 抽象不应该依赖于实现细节,实现细节应该依赖于抽象. -抽象A直接依赖于实现细节b,实现细节b就类似我要吃米饭,上午可能要吃米饭,下午就可能要吃炸酱面,每个人习惯不同,这个是经常变化的.对于软件设计来说,我们可…

Builder模式的缘起 假设创建游戏中的一个房屋House设施,该房屋的构建由几个部分组成,且各个部分要富于变化. 如果使用最直观的设计方法,每一个房屋部分的变化,都将导致房屋构建的重新修正…… 动机(Motivation) 在软件系统中,有时候面临着“一个复杂对象”的创建工作,其通常由各个部分的子对象用一定的算法构成:由于需求的变化,这个复杂对象的各个部分经常面临着剧烈的变化,但是将它们组合在一起的算法却相对稳定. 如何应对这种变化?如何提供一种“封装机制”来隔离出“复杂对象的各个部分”的变…

//设计模式//单例模式//类的计划生育//让该类在外界无法造成对象//让外界可以造一个对象,做一个静态方法返回对象//在累里面可以通过静态变量控制返回对象只能有一个 //class Cat//{// public $name;// private function __construct()// {// }// static $temp;// static function new_ob(){// if (empty(self::$temp)){// self::$temp=new cat()…

1.单例模式 单例模式是一种常用的软件设计模式.在它的核心结构中只包含一个被称为单例的特殊类.通过单例模式可以保证系统中一个类只有一个实例.即一个类只有一个对象实例. 要实现每一个类只有一个实例,就需要对实例化进行限制. 单例模式实现要点: ① 构造函数私有化,不允许使用new关键字创建对象  ② 对外提供获取对象的方法.在方法中判断对象是否为空,如果为空则创建对象并返回,如果不为空则直接返回  ③ 实例对象的属性以及获取对象的方法必须是静态的  ④ 之后,创建对象只能使用我们提供的静态方法. …

要点: 1.如何使用观察者模式: 对应使用这个模式的用户(main)来说,subject和observer这两个基类是不被关系的,在调用者(main)中只是有concreteSubject和concreteObserver这两个具体目标和具体观察者来构建对象和程序. int _tmain(int argc, _TCHAR* argv []){ ConcreteSubject* CS = new ConcreteSubject(); ConcreteObserver* CO = new Concr…

策略模式的UML类图(VS2013 C++版本): 策略模式的重点:每个策略对象封装一个算法,有多少个算法就有多少个对象.策略模式的意图是封装算法.要从“抽象不仅面对状态(字段.属性)还面对行为(算法.函数)”这个概念来理解策略模式. 策略模式实现的关键: 1.将一组相关(名称.目的相关),但是具体实现又不同的算法抽象到一个接口里面(Compositor.Compose),子类SimpleCompositor和TeXCompositor去实现各自的Compose方法. 2.上下文类(Compos…

动机:在软件构建过程中,对于某一项任务,他常常有稳定的整体操作结构,但各个子步骤却有很多改变的需求,或者由于固有的原因(比如框架与应用之间的关系)而无法和任务的整体结构同时实现:如何在确定稳定操作结构的前提下,来灵活应对各种子步骤的变化或者晚期实现需求? 意图:定义一个操作中的算法的骨架,而将一些步骤延迟到子类中.TemplateMethod是的子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤. 适用性: 1.一次性实现一个算法的不变的部分,并将可变的行为留给子类来实现. 2.各子类中…

动机:有些系统组件的客户和组件中各种复杂的子系统有了过多的的耦合,随着外部客户程序  和个子系统的演化,这种过多的耦合面临很多变化的挑战:如何简化外部客户程序和系统的交互接口?  如何将外部客户程序的演化和内部子系统的变化之间的依赖相互解耦 意图:为子系统的一组接口提供一个一致的界面,Facade模式定义了了一个高层接口,这个接口使得这一子系统更加 容易使用  可适用性:1.当你要为一个复杂子系统提供一个简单接口时.子系统往往因为不断演化而变得越来越复杂.大多数模式使用时都会 产生更多更小的类.…

单例模式 单例,顾名思义单个实例. class Person: __instance = None def __init__(self): pass @staticmethod def getInstance(): if Person.__instance: return Person.__instance else: Person.__instance = Person() return Person.__instance obj1 = Person.getInstance() print(o…

首先提出一个很容易想到应用场景: 手机的生产过程:手机有非常多的子件(部件),成千上万,不同品牌的手机的生产过程都是复杂而有所区别的,相同品牌的手机在设计上也因客户需求多样化,大到型号,小到颜色,是否配置附件.假设手机的生产过程(这里用方法来代替)可以是几千个方法的叠加过程,每个方法都面临不同的变化,如果将手机的生产过程中的这些方法全部耦合在一个对象里实现,显然是不明智的. 教材书上对生成器模式的解释:生成器模式将复杂对象的构建过程和表示(实现)相分离,使得相同的构建过程可以创建不同的表示.如下…

场景:程序需要不断创建大量相似的细粒度对象,会造成严重的内存负载.我们可以选择享元模式解决该问题. 享元抽象:Flyweight 描述享元的抽象结构.它包含内蕴和外蕴部分(别被术语迷惑,这是一种比较深的描述,浅的来说,内蕴就是对象中不变的数据,外蕴反之,在编程时区分两者的区别就可以了,无需刻意在代码中表达这种术语的含义.) 享元:ConcreteFlyweight 可用用来共享的对象实例,我们将享元的按照共享性质分为内蕴(不因环境变化而变的部分),外蕴两部分.内蕴是享元的固有特性,不会变化.外蕴…

首先提出一个很容易想到应用场景: 手机的生产过程:手机有非常多的子件(部件),成千上万,不同品牌的手机的生产过程都是复杂而有所区别的,相同品牌的手机在设计上也因客户需求多样化,大到型号,小到颜色,是否配置附件.假设手机的生产过程(这里用方法来代替)可以是几千个方法的叠加过程,每个方法都面临不同的变化,如果将手机的生产过程中的这些方法全部耦合在一个对象里实现,显然是不明智的. 教材书上对生成器模式的解释:生成器模式将复杂对象的构建过程和表示(实现)相分离,使得相同的构建过程可以创建不同的表示.如下…