源代码:https://github.com/telinx/thinkingWay
创建型模式五种:工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。
结构型模式七种:适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。
行为型模式十一种:策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。
创建型create:5
1.单例模式(singleton):公司小,公司只招一个网管,多了浪费公司支出
应用场合:
1.当类只能有一个实例而且客户可以从一个众所周知的访问点访问它时。
2.当这个唯一实例应该是通过子类化可扩展的,并且客户应该无需更改代码就能使用一个扩展的实例时。
2.工厂模式(factory):给客户发信息,可以需选择电子邮件 or 传真,两者都可以发送
应用场合:
1.需要在引用对象中才能决定实例化哪个被操作对象,同时这些被操作对象又复用相同操作逻辑的场合
3.抽象工厂模式:给客户发信息,可以需选择电子邮件 or 传真,两者都可以发送
应用场合:
1.一个系统要独立于它的产品的创建、组合和表示时。
2.一个系统要由多个产品系列中的一个来配置时。
3.当你强调一系列相关的产品对象的设计以便进行联合使用时。
4.当你提供一个产品类库,而只想显示他们的接口而不是实现时。
4.建造模式(builder):公司网管给公司组装电脑,买了一堆CPU、内存、硬盘...网管站在这堆器件中,网管只要组装起来就是台电脑
应用场合:
1.当创建复杂对象的算法应该独立于该对象的组成部分及他们的装配方式时
2.当构造过程必须允许被构造的对象有不同的表示时
5.原型模式(protoType): 实现clone, Java Native调用dll模块,内存开辟新的空间,分配地址创建对象
应用场合:
1.当一个系统应该独立于它的产品创建、构成和表示时。
2、当要实例化的类是在运行时刻指定时,例如通过动态装载。
3、为了避免创建一个与产品类层次平行的工厂类层次时。
4、当一个类的实例只能有几个不同状态组合中的一种时
结构型structure:7
6.适配器模式(adapter):手机充电器,交流电是220V,而充电器是输出220V电压,因此需要适配器转换,适配器将220转换成5V
应用场合:
1.你想使用一个已经存在的类,而它的接口不符合你的要求。
2.你想创建一个可以复用的类,该类可以与其他不相关的类或不可预见的类(即那些接口可能不一定兼容的类)协同工作。
3.(仅适用于对象adapter),你想使用一些已经存在的子类,但是不可能对每一个都进行子类化以匹配他们的接口。对象适配器可以适配它的父类接口
7.装饰模式(Decorator):MP3本只有播放音乐的功能,那把MP3集成在一个新的电路模块上,该模块除了播放歌曲可以闪光
装饰模式与代理模式区别:
装饰模式:被装饰的对象须传入装饰器中,要先知道被装饰的对象
代理模式:不需要知道被代理的对象,直接调用代理对象
应用场合:
1.比如java的System.IO各种输出就是通过装饰模式来实现的,还有一些日志类,动态的添加日志记录的功能,将耦合度降到最低
8.代理模式(Proxy):买一个产品不需要找到厂家,只需找到代理厂商就可以买到要的产品,实际厂家发货
应用场合:
1.远程代理:也就是为一个对象在不同的地址空间提供局部代表,这样可以影藏一个对象存在于不同地址空间的事实,比如.net里的webservice。
2.虚拟代理:根据需要将一个资源消耗很大的或者比较复杂的对象延迟到真正需要时才创建,比如延迟加载图片,优先加载文字
3.保护代理:控制对一个对象的访问权限,用于对象有权限设置的时候
4.智能引用:当调用真实对象时,代理处额外的事情来,提供额外的服务,如计算对象真实的引用次数,这样对象没有引用时可以自动释放它,通过代理访问一个对象时做一些额外的内务处理。
9.外观模式(Facade):开启电脑,点击开启,实际通电了CPU、内存、硬盘,这些使我们所看不到的
应用场合:
1.当你要为一个复杂子系统提供一个简单接口时。子系统往往因为不断演化而变得越来越复杂。大多数模式使用都会产生更 多更小的类。这使得子系统更具可重用性,也更容易对子系统进行定制,但这也给那些不需要定制子类的的用户带来一些 使用上的困难。Facade可以提供一个简单的缺省视图,这一视图对大多数用户来说已经足够,而那些需要更多的可定制 性的用户可以越过Facade层。
2.客户端程序与抽象类的实现部分存在着很大的依赖性。引入Facade将这个子系统与客户以及其他的子系统分离,可以提 高子系统的独立性和可移植性。
3.当你需要构建一个层次结构的子系统时,使用Facade模式定义子系统的每层的入口点。如果子系统之间是相互依赖的, 你可以让他们仅通过facade进行通讯,从而简化了他们之间的依赖关系。
10.桥接模式(Bridge):多功能螺丝刀,换到头就可以,使用者始终是拧这个把,这个把就是做了一个桥接,一个柄,多个刀头
桥接模式与装饰模式区别:
桥接模式:不为添加新的功能,供外接统一入口
装饰模式:在原来的基础添加新的功能
应用场合:
1.你不希望在抽象和它的实现部分有一个固定的绑定关系。例如这种情况可能是因为程序在运行时刻部分应用可以被选择或者切换。
2.类的抽象以及它的实现都可以通过生成子类的方法加以扩充。
3.对一个抽象的实现部分的修改应对客户不产生影响,即客户端的代码不必重新编译。
4.你想在多个对象之间共享实现,但是同时要求客户并不知道这一点
11.组合模式(Composite):在一个根节点,循环添加子节点
应用场合:
1.你想用部分-整体结构层次。
2.你希望用户忽略组合对象与单个对象的不同,用户将统一的使用组合结构中的所有对象
12.享元模式(Flyweight):共享篮球的篮球机器,最多只有10个,取走一个随之减少,返回去则增加,要目的是实现对象的共享,即共享池
应用场合:
1.一个应用程序使用了大量的对象。
2.完全由大量的对象,造成很大的存储开销。
3.对象的大多数状态都可变为外部状态。
4.如果删除对象的外部状态,那么可以用相对较少的共享对象取代很多组对象。
5.应用程序不依赖于对象标识,由于Flyweight对象可以被共享,对于概念上明显有别的对象,标识测试将返回真值。
行为型action:11
13、策略模式(strategy):假设每个计算器只能完成一种算法,加法是加法的,减法是减法,调用不同的计算器,做算法的操作,做类似的事情,却不同的细节
应用场合:
1.多个类只区别在表现行为不同,可以使用Strategy模式,在运行时动态选择具体要执行的行为。
2.需要在不同情况下使用不同的策略(算法),或者策略还可能在未来用其它方式来实现。
3.对客户隐藏具体策略(算法)的实现细节,彼此完全独立。
14、模板方法模式(Template Method):要写一个文档,得先找到模板,模板有的具备了所有的单元,但是有的单元不确切,那就照着模板写份新的模板即可,且补充那个不明确就够了
应用场合:
1.一次性实现一个算法的不变的部分,并将可变的行为留给子类来实现。
2.各子类中公共的行为应被提取出来并集中到一个公共类中以避免代码重复。
首先识别现有代码的不同之处,并且将不同之处分离为新的操作。
最后,用一个调用这些新的操作的模板方法来替换这些不同的代码。
3.控制子类的扩展
15、观察者模式(Observer):十字路口,总有人在观察是否可以行走,车观察交通灯是否绿灯,行人同样观察是否可以通行
应用场合:
1.当一个对象有两个方面,其中一个方面依赖于另一个方面。将二者封装在独立的对象中以使他们可以各自独立的改变和复用。
2.当一个对象的改变需要同时改变其他对象,而不知道具体有多少对象有待改变。
3.当一个对象必须通知其他对象,而又不能假定其他对象是谁。
16、迭代子模式(Iterator):顺序访问聚集中的对象,集合中常见,如果对集合类比较熟悉的话,理解本模式会十分轻松。这句话包含两层意思:一是需要遍历的对象,即聚集对象,二是迭代器对象,用于对聚集对象进行遍历访问
应用场合:
1.访问一个聚合对象的内容而无需暴露它的内部表示。
2.支持对聚合对象的多种遍历。
3.为遍历不同的聚合结构提供一个统一的接口(即,多态迭代)。
17、责任链模式(Chain of Responsibility):滤水器中含有多种过滤岩,一级净化,二级净化,三级净化,滤岩就是filter,滤水器就是chain
应用场合:
1.有多个的对象可以处理一个请求,哪个对象处理该请求运行时刻自动确定。
2.你想在不明确指定接受者的情况下,向多个对象中的一个提交请求。
3.处理一个请求的对象集合应被动态指定。
18、命令模式(Command):遥控器(controller)与电视(receiver),遥控器只要点击按钮发出命令(command)就可以让电视换台、调节音量等
应用场合:
1.抽象出待执行的动作以参数化某对象。
2.在不同的时刻指定、排列和执行请求。
3.支持取消操作。
4.支持修改日志,这样当系统崩溃时,这些修改可以被重做一遍。
5.用构建在原语操作上的高层操作构造一个系统。
19、备忘录模式(Memento):数据库备份机制,服务器1数据库A执行命令生成二进制文件(Memento),再将二进制传输给服务器2目录下即可灾备,恢复数据时将服务器2的二进制数据导入数据库即可
应用场合:
1.必须保存一个对象在某一时刻(部分)的状态,这样以后需要时它才能恢复到先前的状态。
2.如果用一个接口来让其他对象直接得到这个状态,将会暴露对象的实现细节并破坏对象的封装性。
20、状态模式(State):好比一个人,饿了就要吃,渴了就要喝,累了就要睡,不同的状态要做不同的事情
应用场合:
1.当一个对象的转换条件表达式过于复杂时,通常这个状态由一个或者多个枚举表示,通常有多个操作包含这一相同的的条件结构,state模式将一个条件分支放到一个类中,这使得你可以根据对象自身的情况将对象的状态作为对象,这一对象不依赖于其他对象而独立变化,把状态的判断逻辑放到表示不同状态的一系列类中。
2.一个对象的行为取决于它的状态,并且它必须在运行时根据状态立即改变行为。
21、访问者模式(Visitor):如一个不识字感冒的病人(visitor)去了医院看感冒科室的内科医生(subject),就问他是内科医生不
应用场合:
1.一个对象结构包含很多类对象,他们有不同的接口,而你想对这些对象实施一些依赖于其具体类的操作。
2.需要对一个对象中的对象进行很多不同的并且不相关的操作,而你想避免让这些操作‘污染’这些对象的类。
visitor使得你可以将相关的操作集中起来定义在一个类中。
当该对象结构被很多应用共享时,使用Visitor模式让每个应用包含需要用到的操作。
3.定义对象结构类很少改变,但经常需要在此结构上定义新的操作。
改变对象结构类需要重定义对所有访问者的接口,这可能需要很大的代价。
如果对象结构类经常改变,那么可能还是在这些类中定义这些操作较好。
22、中介者模式(Mediator):找个私人侦探公司(中介)去跟踪某人,侦探公司得先招线人,找好后让线人去拍照,拍完了给线人酬劳
应用场合:
1.一组对象以定义良好但是复杂的方式进行通信。产生的相互依赖关系结构混乱且难以理解。
2.一个对象引用很多其他对象并直接与这些对象通信,导致难以复用该对象。
3.想定制一个分部在多个类中的行为,而又不想生成太多的子类。
23、解释器模式(Interpreter):一团橡皮泥,先用个星型章印一下,再用个梅花型的印章印一下,就这样印下去,直到你想要的形状外表
一般应用在OOP开发中的编译器的开发中,不太会用到
应用场合:
当一个语言需要解释执行,并且你可以将该语句中的句子表示为一个抽象语法树时,可使用解释器模式。而当存在以下情况时该模式效果最好。
1.该文法简单对于复杂的文法,文法的类层次变得庞大而无法管理。
2.效率不是一个关键问题,最高效的解释器通常不是通过直接解析语法分析树实现的,而是首先将他们转换成另一种形式。
参考博客:
http://blog.csdn.net/doymm2008/article/details/13288067
http://www.cnblogs.com/pnljs/p/3169292.html