Head First Design Patterns

    在更大的计划之前,先温习一下Design Pattern的功课。    看了《Head First Design Patterns》里讲Decorator的样章,发现JOLT大奖不是白拿的,叙事能力之强,表达之清晰,不是那些满腹经伦的老先生可以比的。而且整个Pattern的讲述过程循序渐进,真的可以保证--小白都能学会设计模式。    可惜就只有样章。Head First系列的电子书都不好找,只好还是翻出老先生们的书来看。    这次温习很快做完,其实GOF80%的模式,都是基于一个原则:

    优先使用对象组合,而不是类继承.

    初学OO的人,都习惯用现实世界去映射程序世界,继承是最自然的思路。GOF其实就是在扭转这个思路,让大家习惯使用组合,委托和程序对象。     组合机制只要根据两大原则,就可以变化出绝大部分的GOF模式.     1.任何耦合都可以通过增加一个中间层来解耦      代表模式有:   Facade , Mediator , Adapter  和 Factory/Abstract Factory , Proxy            2.通过组合来扩充对象特性,可以避免纯继承引起的类爆炸      代表模式有:  Bridge , Decorator , Chain of Response , Strategy/Command

     3.另外还有些独立的常用模式如Singleton , Visitor , Observe

     写给自己看的重放慢镜:    1.Facade : 为了减低一个系统和另一个系统的内部类之间的耦合性。建立对象A代理系统的主要功能

    2.Mediator:为了减低两个对象之间的耦合性。建立一个中间对象C,同时具有A和B的实例,并把C赋给A和B

    3.Adapter: 为了匹配不同的对象使用同一接口。建立对象B,代理A的方法并使其接口匹配。

    4.factory: 为了不依赖于具体对象而依赖于接口的创建对象。程序通过Factory获得对象。

    5.Proxy:   除了不依赖于具体对象,还能在过程中插入动作.程序通过Proxy调用对象的方法(AOP)

    6.Bridge:  如果对象特征向两个方向发展,Bridge能够避免两组对象特征的排列组合引起类爆炸。一组特征如大杯、中杯,一组特征如加奶、加糖。把其中一组特征抽象分离为接口2,把接口2的实例传入到主继承树中。

    7.Decorator: 通过包裹原对象,为原对象的动作添加新的动作。新类继承于原类,有原类同样的方法和原类的实体调用新类的方法时,会调用原类实体的原方法,再加上新类对其的扩展。

    8.COR:     通过安排职责链,让各对象根据情况添加自己的动作。每个对象都有下一个对象的指针,根据情况完成自己的操作后,把控制传给下一位。Apahce Jarkarta Commands有chains库。

    9.Strategy/Command: Template模式的对立物,把动作封装为对象进行组合。

    10.Observe: 通过一套机制,监控Observebal对象的状态变化。JDK实现了两套接口进行辅助。

    11.Visitor: 通过一套机制,让独立对象遍历组合里的所有对象,执行共同的动作。被访问对象有个accept(访问者)函数,在函数里面调用访问者.访问(this),不算很优雅的一个模式。

时间: 2024-10-30 00:45:37

Head First Design Patterns的相关文章

Design Patterns: Solidify Your C# Application Arch

Design Patterns: Solidify Your C# Application Architecture with Design Patterns中文版(下篇)    optimizer(翻译)   关键字     设计模式 singleton strategy decorator composite state   出处     http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmag01/html

Mobile UI Design Patterns: 10+ Sites for Inspiration

原文:http://sixrevisions.com/user-interface/mobile-ui-design-patterns-inspiration/ User interface design patterns are solutions to common design challenges, such as navigating around an app, listing data or providing feedback to users. Mobile apps and

《Design Patterns》学习总结

在时间比较空余的时候,又找到一本一直想看的书,就是这本名为<Design Patterns>(Gang of Four)的著作.本书通过类似Window Doc的程序,来揭开设计模式学习序幕,通过分析设计程序时遇到的困难,引出可以解决问题的设计模式,从而引导你更全面的掌握设计模式.案例程序的设计引出8个设计模式,案例程序设计完成后就是单独的23个经典设计模式,可以单个查阅,单个阅读. Abstract Factory模式 这个模式似乎离我比较远,因为本人还从未开发过在此模式讲解过程中介绍到的设

Comparing Two High-Performance I/O Design Patterns

Summary This article investigates and compares different design patterns of high performance TCP-based servers. In addition to existing approaches, it proposes a scalable single-codebase, multi-platform solution (with code examples) and describes its

C# Design Patterns (1) - Factory Method

Simple Factory Pattern (简单工厂模式) 特性: 把类的实例化工作,集中到一个「工厂类」去处理,亦即将 new instance 的工作,都交给一个「工厂」去处理,而不要分散写在各个类中.客户端程序,与创建实例 (对象) 的工作必须隔离,亦即「解耦」,客户端程序只要专注于自己的业务逻辑.适用于客户端程序在开发过程中,尚无法预知要创建的具体类型.产品具体的实现能和客户端隔离,便于事后抽换. Simple Factory Pattern (简单工厂模式).Factory Met

C# Design Patterns (4) - Proxy

本帖介绍 Proxy Pattern (代理模式). Proxy Pattern (代理模式) The Proxy Pattern provides a surrogate or placeholder for another object to control access to it...                                  - Design Patterns: Elements of Reusable Object-Oriented Software 在 Go

艾伟_转载:C# Design Patterns (4) - Proxy

本帖介绍 Proxy Pattern (代理模式). Proxy Pattern (代理模式) The Proxy Pattern provides a surrogate or placeholder for another object to control access to it...                                  - Design Patterns: Elements of Reusable Object-Oriented Software 在 Go

艾伟:C# Design Patterns (2) - Strategy

Strategy Pattern (策略模式) 所谓 Strategy Pattern 的精神,就是将策略 (算法) 封装为一个对象,易于相互替换,如同 USB 设备一样可即插即用:而不是将策略.具体的算法和行为,硬编码在某个类或客户程序中,导至事后的修改和扩展不易. 若有多种「策略」,就将这些个策略,和这些策略的算法.行为,封装在各个类中,并让这些类,去继承某个公用的抽象类或接口.接着在客户程序中,就可动态引用,且易于更换这些不同的「策略」,不会因为日后添加.修改了某一个「策略」,就得重新修改

艾伟:C# Design Patterns (3) - Decorator

Decorator Pattern (装饰模式) 装饰模式可「动态」地给一个对象添加一些额外的职责,提供有别于「继承」的另一种选择.就扩展功能而言,Decorator Pattern 透过 Aggregation (聚合) 的特殊应用,降低了类与类之间的耦合度,会比单独使用「继承」生成子类更为灵活. 一般用「继承」来设计子类的做法,会让程序变得较僵硬,其对象的行为,是在「编译」时期就已经「静态」决定的,而且所有的子类,都会继承到相同的行为:然而,若用「装饰模式」以及 UML 的 Aggregat