Head First设计模式阅读笔记(三)

状态模式:
概念:允许对象在内部状态改变时改变它的行为,对象看起来好像修改了它的类。

定义一个状态的父类,限定了可以执行的操作,并实例化用于存储现在状态。子类通过继承关系,实现不同状态下,进行各种操作的逻辑。这样可以保证对修改封闭,对添加开放。 当加入一个新的状态的时候,只需要继承父类并实现相应操作,并修改主线程逻辑即可。

同策略模式大同小异,但是实现的意图不一样。 策略模式是为了类的多样化,操作的多样化;状态模式是为了状态转换的易于实现和添加。

状态模式

 

代理模式:
概念:为另一个对象提供一个替身或占位符以访问这个对象

现在看来,应该就是类似于webservice或者是云服务吧。为客户提供一个接口,告诉他可以实现的功能,然后客户就可以使用这个接口完成想要进行的操作。实际上,这个接口只是调用了一个远程的服务,将数据传递过去并将结果传递回来。

现在的很多像soap和hessian都可以很好的完成,另外还有python和ruby等脚本语言应该也比较方便的实现。

代理模式

 

复合模式:

概念:复合模式结合两个或以上的模式,组成一个解决方案,解决一再发生的一般性问题。

问题的引出:

一大堆Quackable —– 策略模式,继承

有一只鹅出现了,它希望自己像一个Quackable —– 适配器模式

然后,呱呱叫学家决定要计算呱呱叫声的次数 —– 工厂模式生成

但是呱呱叫学家担心他们忘了加上QuackCounter装饰者 —– 装饰者模式

又是鸭子,又是鹅,又是Quackable的……我们有管理上的困扰 —– 组合模式和迭代器模式

当任何呱呱声响起时,呱呱叫学家都希望能被告知 —– 观察者模式

实际上,就MVC框架就是很好的一个复合模式

 

其他的一些模式

桥接模式:不只改变你的实现,也改变你的抽象。

生成器模式:封装一个产品的构造过程,并允许步骤构造。

责任链模式:让一个以上的对象有机会能够处理某个请求。(处理流程)

蝇量模式:让某个类的一个实例能用来提供许多“虚拟实例”。(类似不同大小不同内容的注释文字)

解释器模式:为语言创建解释器。(编译原理的词法分析,语法分析)

中介者模式:集中相关对象之间复杂的沟通和控制方式。(卖房中介,可以应对不同房源,不同买房主,卖房主,有自己的营销策略)

备忘录模式:可以让对象返回之前的状态。(动态规划里面的备忘录方法)

原型模式:创建给定类的实例的过程很昂贵或很复杂时使用。

访问者模式:可以为一个对象的组合增加新的能力,且封装并不重要时使用。

Head First设计模式阅读笔记(二)

适配器模式:
概念:将一个类的接口,转换成客户期望的另一个接口。适配器让原本不兼容的类可以合作无间。
比如我们要将一个火鸡封装成一个鸭子,因为我们现在只有处理鸭子的机器方法。那么我们使用一个将火鸡转换成鸭子的适配器类,类中包含一个火鸡对象,当需要它鸣叫时,调用火鸡的鸣叫方法,需要飞时,调用火鸡的飞行方法。通俗理解就像插头转换器一样,所以叫适配器模式。

与装饰者模式(不改变接口,但加入方法)不同的是,适配器模式是直接将一个接口转成另一个接口。

适配器模式

外观模式:

概念:提供了一个统一的接口,用来访问子系统中的一群接口。外观定义了一个高层接口,让子系统更容易使用。

就是说把一些相关的类的操作集合在了一起,创建了一个流程的感觉。类似于功能的集合,比如按遥控器的家庭影院按钮,会关灯,开音响,下降幕布等一系列操作。

外观模式

模板方法模式:

概念:在一个方法中定义一个算法的骨架,而将一些步骤延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下,重新定义算法中的某些步骤。

算法的骨架使用final定义,不可改变。可以延迟的步骤使用抽象方法abstract。比如可以定义制造咖啡,牛奶和茶的方法步骤,只是冲泡的内容不一样,添加的调料不一样,都需要烧开水和装杯(可能杯子也不一样)。

模板方法模式

迭代器模式:

概念:提供一种方法顺序访问一个聚合对象中的各个元素,而又不暴露其内部的表示。

比较好理解,就是比如有几种集合元素,数组,ArrayList,Hashmap,使用Iterator迭代获得全部元素。需要注意的是可以自己写一些Iterator方法,和compareTo方法,来完成比较。

迭代器模式

组合模式:

概念:允许你将对象组合成树形结构来表现“整体/部分”层次结构。组合能让客户以一致的方式处理个别对象以及对象组合。

就是借鉴的树的概念,一个结点,可以是父节点,也可以是子结点,迭代器会相同对待。他们共同继承自Component,可以将对象的集合以及个别的对象一视同仁。。复杂的是在迭代的过程中,要考虑到遍历的顺序,可以参考深搜和广搜。

组合模式

 

Head First设计模式

这是一本好书
上班第17天,今天发工资,哇咔咔
============================================
策略模式:
概念:定义了算法族,分别封装起来,让它们之间可以互相替换,此模式让算法的变化独立于使用算法的客户。
通俗来讲,就是有一个父类型,他有一些方法,子类型可以继承这些方法,但是这些方法在子类中的表现又不尽相同。
所以将父类型中的一些方法,也变成接口和类来处理,这样可以在构造子类的时候,选择对应的父类不同的方法来构造。

策略模式

观察者模式:
概念:定义了对象之间的一对多依赖,这样依赖,当一个对象改变状态时,它的所有依赖者都会收到通知并自动更新。
例子是天气预报,接收到新数据后对三个指示器进行更新。指示器继承自object并都有update方法。主题对象将不同的object加入到array,在获取数据后对全部object进行自动更新。

观察者模式

装饰者模式:
概念:动态地将责任附加到对象上。若要扩展功能,装饰者提供了比继承更有弹性的替代方案。
比如星巴兹咖啡的解决方案:先定义一个基类,有描述和花费两个方法,一般的咖啡直接继承该父类即可。如果需要加调料,使用继承自基类的装饰者类,用原始的对象构造新的对象,并添加额外的花费即可。

装饰者模式

工厂方法模式:
概念:定义了一个创建对象的接口,但由子类决定要实例化的类是哪一个。工厂方法让类把实例化推迟到子类。
在制作pizza的时候,使用pizza工厂类,来根据不同的type选择实例化不同的pizza style。这样可以保证在对之后的处理独立。
也就是把一串的if else移到专门的工厂类里面去,保证代码的稳定性。
包括:一般工厂模式,抽象工厂模式(可以有很多不同的工厂实现自同一个抽象工厂,比如pizza的原料也可以不同)

工厂模式

单件模式:
概念:确保一个类只有一个实例,并提供一个全局访问点
Singleton模式的实现基于两个要点:
  1)不直接用类的构造函数,而另外提供一个Public的静态方法来构造类的实例。通常这个方法取名为Instance。Public保证了它的全局可见性,静态方法保证了不会创建出多余的实例。
  2)将类的构造函数设为Private,即将构造函数”隐藏”起来,任何企图使用构造函数创建实例的方法都将报错。这样就阻止了开发人员绕过上面的Instance方法直接创建类的实例。
  通过以上两点就可以完全控制类的创建:无论有多少地方需要用到这个类,它们访问的都是类的唯一生成的那个实例。

命令模式:
概念:将“请求”封装成对象,以便使用不同的请求、队列或者日志来参数化其他对象。命令模式也支持可撤销的操作。
定义一个命令接口,具有execute方法,其他命令已此为基础。使用命令的对象包含一个command,通过set方法指定不同的命令并调用execute方法即可实现命令操作。

命令模式