《大话设计模式》读书笔记

来源:互联网 发布:linux打包tar.gz 编辑:程序博客网 时间:2024/04/29 19:37

1.面向对象简介:利用面向对象编程,要达到可维护,可扩展,可复用和灵活性好的目的。通过面向对象的封装、继承、多态让程序能够尽量保持高内聚,低耦合的状态,使程序更加的灵活,容易修改,并且易于复用。界面逻辑和业务逻辑应该分离,分别封装,利用继承的特性把子类的功能分别继承父类,这样要增加新功能,就可以直接利用继承来添加,而不用修改原先定义好的类。


2.计算器设计---简单工厂模式:用单独的类来创造做这个创造实例的过程,这就是工厂,利用多态返回父类的方式实现了计算的结果,这样要改功能,直接在类里面改,要增加功能,直接增加子类就可以了。


3.商场打折---策略模式:面向对象的编程,并不是类越多越好,类的划分是为了封装,但分类的基础是抽象,具有相同属性和功能的对象的抽象的抽象集合才是类,策略模式定义了算法家族,分别封装起来,让它们之间可以互相替换,此模式让算法的变化,不会影响到使用算法的客户,利用封装变化点来灵活处理类的计算细节,封装变化点可以封装具体的算法或行为,策略模式是一种定义算法的方法,并且这些算法所要完成的都是相同的工作,只是实现的不同,它可以以相同的方式调用所有的算法,减少各种算法类与使用算法类之间的耦合,由于每个算法都有类,在软件测试的单元测试中可以单独测试,这样可以简化单元测试,当不同行为堆彻在一个类中,就很难避免使用条件语句来选择合适的行为,因此可以使用这些行为的类中消除条件语句。策略模型封装了变化,封装了算法,封装几乎任何类型的规则,只要在分析过程中听到需要在不同时间应用不同的业务规则,就可以考虑使用策略模式来处理这种变化的可能性。


4.拍摄 UFO ---单一职责原则:就一个类中,应该仅有引起它变化的原因,如果一个类中承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力,着找工耦合会导致脆弱的设计,设计会遭受到意想不到的破坏,所以在软件设计时,应该把那些职责互相分离,如果你能够多于一个动机去改变一个类,那么这个类就具有多于一个的职责,单一职责易维护、易扩展、易复用、灵活多样。


5.考研求职两不误---开放-封闭原则:软件实体(类、模块、函数等等)应该可以扩展,但是不可修改。它有两大特征:一是对于扩展是开放的,另一个是对于更改是封闭的。开放封闭原则面对需求的改变可以保持相对的稳定,从而使得系统可以在第一个版本以后不断的推出新的版本。当需求变化时,要创建抽象来隔离以后发生的同类变化,对程序的改动是通过增加新的代码,而不是更改现有的代码。


6.会修电脑不会修收音机---依赖倒转原则:抽象不应该依赖细节,细节不应该依赖于抽象,换句话说,就是针对接口编程,不要针对实现编程。里氏代换原则:子类型必须能够替换掉它们的父类型。一个软件实体如果使用的是一个父类的话,那么一定适用于它的子类,程序的行为没有发生变化。只有当子类可以替换掉父类,软件单位的功能不受影响时,父类才能真正被复用,而子类也能够在父类的基础上增加新的行为。子类型的可替换性才使得使用父类类型的模块在无需修改的情况下就可以扩展。


7.穿什么有这么重要---装饰模式:动态的给一个对象添加一些额外的职责,就增加功能来说,装饰模式比生成子类更为灵活。装饰模式利用对象进行包装,这样每个对象的实现就和如何使用这个对象分离开了,每个对象只关心自己的功能,不需要关心如何被添加到对象链当中。装饰模式是为已有功能动态的添加更多功能的一种方式,当系统需要新功能的时候,是向旧的类中添加新的代码,这些新加的代码通常装饰了原有类的核心职责或主要行为,它把每一个装饰的功能放在单独的类中,并让这个类包装它所要装饰的对象,因此,当需要执行特殊行为的时,客户代码就可以在运行时有选择地、按顺序地使用装饰功能包装对象了,即把类中的装饰功能从类中搬移去除,这样可以简化原有的类,而且有效地把类的核心职责和装饰功能区分开了,而且可以去除相关类中重复的装饰逻辑。


8.为别人做嫁衣---代理模式:为其他对象提供一种代理以控制对这个对象的访问。代理模式一般有四种应用:一、远程代理,也就是为一个对象在不同的地址空间提供局部代表,这样可以隐藏一个对象存在于不同地址空间的事实。 二、虚拟代理,是根据需要创建开销很大的对象。通过它来存放实例化需要很长时间的真实对象。三、安全代理,用来控制真实对象访问时的权限。四、智能指引,指当调用真实的对象时,代理处理另外一些事。


9.雷锋依然在人间---工厂方法模式:工厂方法模式实现时,客户端余姚决定实例化哪一个工厂来实现运算类,选择判断的问题还是存在的,也就是说,工厂方法把简单工厂的内部逻辑判断转移到了客户端代码来进行。你需要增加功能,本来是改工厂类的,而现在是修改客户端。


10.简历复印---原型模式:原型模式其实就是从一个对象再创建另外一个可定制的对象,而且不需要知道任何创建的细节。一般在初始化的信息不发生变化的情况下,克隆是最好的办法,这样既隐藏了对象创建的细节,又对性能是大大的提高。如果字段是值类型的,则对该字段执行逐位复制,如果字段是引用类型,则复制引用但不复制引用的对象,因此,原始对象及其复本引用同一对象。浅复制:被复制对象的所有变量都含有与原来的对象相同的值,而所有的对其他的对象的引用仍指向原来的对象。深复制:把引用对象的变量指向复制过的新对象,而不是原有的被引用的对象。


11.考题抄错会做也白搭---模板方法模式:如果我们用了继承,并且肯定这个继承的意义,就应该要成为子类的模板,所有重复都应该要上升到父类去,而不是让子类都去重复。当我们要完成在某一些细节层次一致的过程或一系列步骤,但其个别步骤在更详细的层次上的实现可能不同时,我们通常考虑用模板模式来处理。模板方法模式,定义一个操作中的算法的骨架,而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即重定义该算法的某些特定步骤。换而言之,模板方法模式是通过把不变的行为搬移到超类,去除子类中的重复代码来体现它的优势。


12.无熟人难办事---迪米特法则:如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用,如果其中一个类需要调用另一个类的某一个方法的话,可以通过第三者转发这个调用。松耦合有利于服用,不会对关系类造成波及。


13.牛市股票还会亏钱---外观模式:为子系统中的一组接口提供一个一致的界面,此模式定义了一个高层的接口,这个接口使得这一子系统更加容易使用。首先在设计的初级阶段,应该有意识的将不同的两个层分离,其次,在开发阶段,子系统往往因为不断的重构演化而变得越来越复杂,第三,在维护一个大型系统的时候,可能这个系统已经非常难以维护和扩展了。这时,你可以为新系统开发一个外观Facade类,来提供设计粗糙或高复杂度的遗留代码的简单的接口,让新系统与Facade对象交互,Facade与遗留代码交互所有复杂的工作。


14.好菜每回味不同---建造者模式:将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。它主要用于创建一些复杂的对象,这些对象内部构建间的建造顺序通常是稳定的,但对象内部的构建通常面临着复杂的变化。建造者模式的好处就是使得建造代码与代码分离,由于建造者隐藏了该产品是如何组装的,所以若需要改变一个产品的内部表示,只需要再定义一个具体的建造者就可以了。


15.老板回来,我不知道---观察者模式:观察者模式定义了一种一对多的依赖关系,让多个观察者对象同时监听某一主题对象。这个主题对象在状态发生变化时,会通知所有观察者对象,使它们能够自动更新自己。


16.就不能不换DB吗?---抽象工厂模式:定义了一个创建一系列相关或相互依赖的接口,而无需指定它们的具体类。用于交换产品系列,如ACCESS->SQL SERVER;产品的具体类名被具体工厂的实现分离。在一个应用中只需在初始化的时候出现一次,这就使得改变一个应用的具体工厂变得非常容易,它只需要改变具体工厂即可使用不同的产品配置。它让具体的创建实例过程与客户端分离,客户端是通过它们的抽象接口操纵实例,产品的具体类名也被具体的工厂的实现分离,不会出现在客户的代码中。  反射技术的格式是  Assembly.Load("程序集名称").CreateInstance("命名空间.类名称"),并且在程序的顶端写上using System.Reflection,从反射+抽象工厂模式的角度看,所有在用简单工厂的地方,都可以考虑用反射技术去除switch或if,解除分支判断带来的耦合。


无尽加班何时休---状态模式:当一个对象的行为取决于它的状态,并且它必须在运行时刻根据状态改变它的行为时,可考虑用到状态模式。状态模式主要解决的是当控制一个对象的状态转换的条件表达式国语复杂时的情况,把状态的判断逻辑转移到表示不同状态的一系列类当中,可以把复杂的判断逻辑简化。


18.在NBA我需要翻译---适配器模式:将一个类的接口转换成客户希望的另外一个借口,适配器模式使得原本由于有接口不兼容而不能一起工作的那些雷可以一起工作。当系统的数据和行为都正确,但接口不符时,我们应该考虑用适配器,目的是使控制范围之外的一个原有对象与某个接口匹配,适配器模式主要应用于希望复用一些现存的类,但是接口又与复用环境要求不一致的情况。


19.如果再回到从前---备忘录模式:在不破坏封装性的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态,这样就可以将以后的对象状态恢复到先前保存的状态。适用于功能比较复杂的,但需要记录或维护属性历史的类;或者需要保存的属性只是众多属性中的一小部分时Originator可以根据保存的Memo还原到前一状态。


20.分公司=一部门---组合模式:整体和部分可以被一致对待(如WORD中复制一个文字、一段文字、一篇文章都是一样的操作),将对象组合成树形结构以表示‘部分--整体’的层次结构,组合模式使得用户对单个对象和组合对象的使用具有一致性。当发现需求中是体现部分与整体层次的结构时,以及希望用户可以忽略组合对象与单个对象的不同,统一地使用组合结构中的所有对象时,就应该考虑组合模式。


21.想走?可以!先买票---迭代器:提供一种方法顺序访问一个聚合对象中的各个元素,而又不暴露对象的内部表示。当需要访问一个聚集对象,而且不管这些对象是什么都需要遍历的时候,就要考虑用迭代器模式,如果需要对聚集有多种方式遍历时,可以考虑用迭代器模式。迭代器模式就是分离了集合对象的遍历行为,抽象出一个迭代器来负责,这样既可以做到不暴露集合的内部结构,又可以让外部代码透明地访问集合内部的数据。


22.有些类也需要计划生育---单例模式:保证一个类仅有一个实例,并提供一个访问它的全局访问点。通常我们可以让一个全局变量使得一个对象被访问,但它不能防止你实例化多个对象。一个最好的办法就是,让类自身负责保存它的唯一实例,这个类可以保证没有其他实例可以被创建,并且它可以提供一个访问该实例的方法。


23。手机软件何时统一---桥接模式:将抽象部分与实现部分分离,使它们可以独立变化。这里说的意思不是让抽象基类与具体类分离,而是现实系统可能有多角度分类,每一种分类都有可能变化,那么把这种多角度分离出来让它们独立变化,减少它们之间的耦合性,即如果继承不能实现“开放-封闭原则”的话,就应该考虑用桥接模式。
24.烤羊肉串引来的思考---命令模式:
一、建立命令队列;二、可以将命令记入日志;三、接收请求的一方可以拒绝;四、添加一个新命令类不影响其它类;

命令模式把请求一个操作的对象与知道怎么操行一个操作的对象分开。


25.加薪非要老总批---职责链模式:使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系。将这个对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理为止。接收者和发送者都没有对方的明确信息,且链中的对象自己也并不知道链的结构,结果是职责链可简化对象的相互连接,它们仅需保持一个指向其后继者的引用,而不需要保持它所有的接收者的引用。


26.世界需要和平---中介者模式:用一个中介对象来封装一系列的对象交互,中介者使各对象不需要显示的相互引用,从而降低耦合;而且可以独立地改变它们之间的交互。


27.项目多页别傻做---享元模式:运用共享技术有效地支持大量细粒度的对象(对于C++来说就是共用一个内存块啦,对象指针指向同一个地方)。如果一个应用程序使用了大量的对象,而这些对象造成了很大的存储开销就应该考虑使用。还有就是对象的大多数状态可以外部状态,如果删除对象的外部状态,那么可以用较少的共享对象取代多组对象,此时可以考虑使用享元。


28.其实你不懂老板的心---解释器模式:通常当一个语言需要解释执行,并且你可以将该语言中的句子表示成为一个抽象的语法树时,可以使用解释器模式。如果一种特定类型的问题发生的频率足够高,那么可能就值得将该问题的各个实例表述为一个简单语言中的句子,这样就可以构建一个解释器,该解释器通过解释这些句子来解决该问题。解释器模式使用类来表示文法规则,可使用继承来改变或扩展该文法,这样就很容易地改变和扩展文法,也比较容易实现文法,因为定义抽象语法树中各个节点的类的实现大体相似,这些类都已与直接编写。


29男人和女人---访问者模式:用于数据结构稳定的系统。它把数据结构和作用于数据结构上的操作分离开,使得操作集合.优点:新增加操作很容易,因为增加新操作就相当于增加一个访问者,访问者模式将有关的行为集中到一个访问者对象中。缺点:使增加新的数据结构变得困难了。
原创粉丝点击