关于模式的原则:DIP(依赖倒转原则)、OCP(开闭原则)
简单工厂模式及实例
http://www.cnblogs.com/zzj-46000452/archive/2006/09/16/506286.html
解读设计模式----简单工厂模式(SimpleFactory Pattern),你要什么我就给你什么
策略模式和简单工厂模式的区别:
策略(Strategy)模式在结构上与工厂模式类似,唯一的区别是工厂模式实例化一个产品的操作是在服务端来做的 ,换句话说客户端传达给服务端的只是某种标识,服务端根据该标识实例化一个对象。而策略模式的客户端传达给服务端的是一个实例,服务端只是将该实例拿过去在服务端的环境里执行该实例的方法。
单一职责原则、开放-关闭原则 ,需要在平时的程序说些当中,注意到这两个职责的使用方法。
装饰模式:
http://www.cnblogs.com/god_bless_you/archive/2010/06/10/1755212.html
装饰模式的使用例子:
http://wenku.baidu.com/view/7eec6b896529647d272852ef.html
要点:
1.装饰者和被装饰对象有相同的超类型。
2.可以用一个或多个装饰者包装一个对象。
3.装饰者可以在所委托被装饰者的行为之前或之后,加上自己的行为,以达到特定的目的。
4.对象可以在任何时候被装饰,所以可以在运行时动态的,不限量的用你喜欢的装饰者来装饰对象。
5.装饰模式中使用继承的关键是想达到装饰者和被装饰对象的类型匹配,而不是获得其行为。
6.装饰者一般对组件的客户是透明的,除非客户程序依赖于组件的具体类型。在实际项目中可以根据需要为装饰者添加新的行为,做到“半透明”装饰者。
7.适配器模式的用意是改变对象的接口而不一定改变对象的性能,而装饰模式的用意是保持接口并增加对象的职责。
1.工厂模式
通过建立相关“产品”的单独的“工厂”,这样遵循了了关闭-修改的原则,可以创建一类相关的“产品”对象
2.原型模式
通过一个已经创建的对象,来创建新的对象。
3.模板方法模式
父类创建的方法,通过子类来实现,这样可以避免过多重复的代码
4.外观模式
类似于API,通过将低粒度的操作,整合为高粒度的操作,方便使用者调用,这样就可以减少代码阅读性的难度
5.迪斯特拉法则
两个类如果不直接对话的话,则不能直接关联,需要通过创建一个抽象类来进行操作,这样可以避免程序结构的混乱。例子是:IT部门(下属有很多的员工,分别完成某一些的服务),其他部门需要服务的时候,不需要具体的知道IT部门的具体人,就可以通过IT部门建立的接口,来获得服务。
建造者模式,这个模式比较陌生,暂时没有想到如何在实际的项目中运用,只是简单的通过书中的案例进行了实现
定义
将一个复杂对象的构造与它的表示分离,使同样的构建过程可以创建不同的表示,这样的设计模式被称为建造者模式。
实用范围
1.当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时。
2.当构造过程必须允许被构造的对象有不同表示时。
角色
在这样的设计模式中,有以下几个角色:
1,builder:为创建一个产品对象的各个部件指定抽象接口。
2,ConcreteBuilder:实现Builder的接口以构造和装配该产品的各个部件,定义并明确它所创建的表示,并提供一个检索产品的接口。
3,Director:构造一个使用Builder接口的对象。
4,Product:表示被构造的复杂对象。ConcreteBuilder创建该产品的内部表示并定义它的装配过程,包含定义组成部件的类,包括将这些部件装配成最终产品的接口。
1.观察者模式,自己的理解就是减少项目的代码复杂,高内聚的情况。通过迪米斯特拉法则,建立一个依赖于抽象的模式,建立观察者和被观察着的实际类,来处理不同的类型,并且完善出一个良好的模式,用于通知其他相关需要处理
类。
1.抽象工厂模式:用于创建不同抽象属性的产品
2.反射模式
JAVA反射机制定义:JAVA反射机制是在运行状态中,对于任意一个类,都能够知道这个类的所有属性和方法;对于任意一个对象,都能够调用它的任意一个方法和属性;这种动态获取的信息以及动态调用对象的方法的功能称为java语言的反射机制。
提供了以下功能:
在运行时判断任意一个对象所属的类;
在运行时构造任意一个类的对象;
在运行时判断任意一个类所具有的成员变量和方法;
在运行时调用任意一个对象的方法;生成动态代理。
1.状态模式:自己理解(通过状态模式,可以判断摸一个物体的状态,并且依据它的状态进行相应的操作)
状态模式(State Pattern)是设计模式的一种,属于行为模式。
定义(源于Design Pattern):当一个对象的内在状态改变时允许改变其行为,这个对象看起来像是改变了其类。
状态模式主要解决的是当控制一个对象状态的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同 状态的一系列类中,可以把复杂的判断逻辑简化。
意图:允许一个对象在其内部状态改变时改变它的行为
适用场景:
1.一个对象的行为取决于它的状态,并且它必须在运行时刻根据状态改变它的行为。
2.一个操作中含有庞大的多分支结构,并且这些分支决定于对象的状态。
1,适配器模式:自己的理解就是:在编程的过程中,没有思考到特别的例子,所以需要对系统进行重构,但是不想改变系统程序的全部结构,就创建一个接口用目标的系统代码,(在计算机编程中,适配器模式(有时候也称包装样式或者包装)将一个类的接口适配成用户所期待的。一个适配允许通常因为接口不兼容而不能在一起工作的类工作在一起,做法是将类自己的接口包裹在一个已存在的类中。)
2.Adapter模式的定义:把一个类的接口变换成客户端所期待的另外一种接口,使得原本由于接口不兼容而不能再一起工作的那些类可以一起工作。(实例:2,5和3.5的耳机)
3.备忘录模式,用于保存每一个对象的值,方便用户回到进度或者恢复操作。
4.组合模式:用于处理相似的结构
1,迭代器模式:用于提供一个排序的方法(可以有很多种),来对内部的对象进行排序的模式
迭代器(Iterator)模式,又叫做游标(Cursor)模式。GOF给出的定义为:提供一种方法访问一个容器(container)对象中各个元素,而又不需暴露该对象的内部细节。
从定义可见,迭代器模式是为容器而生。很明显,对容器对象的访问必然涉及到遍历算法。你可以一股脑的将遍历方法塞到容器对象中去;或者根本不去提供什么遍历算法,让使用容器的人自己去实现去吧。这两种情况好像都能够解决问题。
然而在前一种情况,容器承受了过多的功能,它不仅要负责自己“容器”内的元素维护(添加、删除等等),而且还要提供遍历自身的接口;而且由于遍历状态保存的问题,不能对同一个容器对象同时进行多个遍历。第二种方式倒是省事,却又将容器的内部细节暴露无遗。
而迭代器模式的出现,很好的解决了上面两种情况的弊端。先来看下迭代器模式的真面目吧。
迭代器模式由以下角色组成:
1) 迭代器角色(Iterator):迭代器角色负责定义访问和遍历元素的接口。
2) 具体迭代器角色(Concrete Iterator):具体迭代器角色要实现迭代器接口,并要记录遍历中的当前位置。
3) 容器角色(Container):容器角色负责提供创建具体迭代器角色的接口。
4) 具体容器角色(Concrete Container):具体容器角色实现创建具体迭代器角色的接口——这个具体迭代器角色于该容器的结构相关。
适用情况
由上面的讲述,我们可以看出迭代器模式给容器的应用带来以下好处:
1) 支持以不同的方式遍历一个容器角色。根据实现方式的不同,效果上会有差别。
2) 简化了容器的接口。但是在java Collection中为了提高可扩展性,容器还是提供了遍历的接口。
3) 对同一个容器对象,可以同时进行多个遍历。因为遍历状态是保存在每一个迭代器对象中的。
由此也能得出迭代器模式的适用范围:
1) 访问一个容器对象的内容而无需暴露它的内部表示。
2) 支持对容器对象的多种遍历。
3) 为遍历不同的容器结构提供一个统一的接口(多态迭代)。
单列模式:一个类仅仅有他一个实例,而且提供一个方法,可以全局的访问他。
1,迭代器模式:用于提供一个排序的方法(可以有很多种),来对内部的对象进行排序的模式
迭代器(Iterator)模式,又叫做游标(Cursor)模式。GOF给出的定义为:提供一种方法访问一个容器(container)对象中各个元素,而又不需暴露该对象的内部细节。
从定义可见,迭代器模式是为容器而生。很明显,对容器对象的访问必然涉及到遍历算法。你可以一股脑的将遍历方法塞到容器对象中去;或者根本不去提供什么遍历算法,让使用容器的人自己去实现去吧。这两种情况好像都能够解决问题。
然而在前一种情况,容器承受了过多的功能,它不仅要负责自己“容器”内的元素维护(添加、删除等等),而且还要提供遍历自身的接口;而且由于遍历状态保存的问题,不能对同一个容器对象同时进行多个遍历。第二种方式倒是省事,却又将容器的内部细节暴露无遗。
而迭代器模式的出现,很好的解决了上面两种情况的弊端。先来看下迭代器模式的真面目吧。
迭代器模式由以下角色组成:
1) 迭代器角色(Iterator):迭代器角色负责定义访问和遍历元素的接口。
2) 具体迭代器角色(Concrete Iterator):具体迭代器角色要实现迭代器接口,并要记录遍历中的当前位置。
3) 容器角色(Container):容器角色负责提供创建具体迭代器角色的接口。
4) 具体容器角色(Concrete Container):具体容器角色实现创建具体迭代器角色的接口——这个具体迭代器角色于该容器的结构相关。
适用情况
由上面的讲述,我们可以看出迭代器模式给容器的应用带来以下好处:
1) 支持以不同的方式遍历一个容器角色。根据实现方式的不同,效果上会有差别。
2) 简化了容器的接口。但是在java Collection中为了提高可扩展性,容器还是提供了遍历的接口。
3) 对同一个容器对象,可以同时进行多个遍历。因为遍历状态是保存在每一个迭代器对象中的。
由此也能得出迭代器模式的适用范围:
1) 访问一个容器对象的内容而无需暴露它的内部表示。
2) 支持对容器对象的多种遍历。
3) 为遍历不同的容器结构提供一个统一的接口(多态迭代)。
1,桥接模式:在于突出聚集和合成的关系。类似于有手机的硬件、软件之分的时候,可以通过是用桥接模式,可以很好的处理硬件和软件的使用问题,而需要注意的是当我们写面向对象的程序的时候,需要判断继承的关系是不是(IS-A)的关系,如果不是就尽量不要是用继承的关系,可以考虑是用聚集和组成关系。
1.命令模式:
通过服务类和实际操作类,把使用着和完成着,通过服务类进行分离:通过客户调用服务类,服务类在调用操作类,通过操作类来完成相关的操作。
作用:支持回滚的命令(撤销和恢复)
代码理解上面:方便编程的理解,把客户和具体的实现类进行分离
1,职责链模式:
通过职责的分化(分给每一个相关的职责人),这样可以简化一个判断的总过程和处理过程
2,但是需要注意的是:需要在使用之前定义好职责的范围和相关的处理内容。
1,中介者模式:通过中介者这个集合全部会员的统一,来进行处理多个对象之间的要求,处理协调全局的事务,缺点是不方便维护,因为中介者模式是一个整体的类,所以一个国家有变化对主类会有较大的影响。
1,享元模式
享元模式(英语:Flyweight Pattern)是一种软件设计模式。它使用共享物件,用来尽可能减少内存使用量以及分享资讯给尽可能多的相似物件;它适合用于当大量物件只是重复因而导致无法令人接受的使用大量内存。通常物件中的部分状态是可以分享。常见做法是把它们放在外部数据结构,当需要使用时再将它们传递给享元。
2,解释器模式
Interpreter模式也叫解释器模式,是由GoF提出的23种设计模式中的一种。Interpreter是行为模式之一,它是一种特殊的设计模式,它建立一个解释器,对于特定的计算机程序设计语言,用来解释预先定义的文法。
3,访问模式
访问者模式:表示一个作用于某对象结构中的各元素的操作。它可以使你在不改变各元素的类的前提下定义作用于这些元素的新操作。
访问者模式适用于数据结构相对稳定而基于该数据结构的操作需要经常扩展的系统。因为该模式的优点就是增加新的操作很容易。