TOMMYHU

/**
* 观察者模式应用场景实例
*
* 免责声明:本文只是以哈票网举例，示例中并未涉及哈票网任何业务代码，全部原创，如有雷同，纯属巧合。
*
* 场景描述：
* 哈票以购票为核心业务(此模式不限于该业务)，但围绕购票会产生不同的其他逻辑，如：
* 1、购票后记录文本日志
* 2、购票后记录数据库日志
* 3、购票后发送短信
* 4、购票送抵扣卷、兑换卷、积分
* 5、其他各类活动等
*
* 传统解决方案:
* 在购票逻辑等类内部增加相关代码，完成各种逻辑。
*
* 存在问题：
* 1、一旦某个业务逻辑发生改变，如购票业务中增加其他业务逻辑，需要修改购票核心文件、甚至购票流程。
* 2、日积月累后，文件冗长，导致后续维护困难。
*
* 存在问题原因主要是程序的"紧密耦合"，使用观察模式将目前的业务逻辑优化成"松耦合"，达到易维护、易修改的目的，
* 同时也符合面向接口编程的思想。
*
* 观察者模式典型实现方式：
* 1、定义2个接口：观察者（通知）接口、被观察者（主题）接口
* 2、定义2个类，观察者对象实现观察者接口、主题类实现被观者接口
* 3、主题类注册自己需要通知的观察者
* 4、主题类某个业务逻辑发生时通知观察者对象，每个观察者执行自己的业务逻辑。
*
* 示例：如以下代码
*
*/
#===================定义观察者、被观察者接口============
/**
*
* 观察者接口(通知接口)
*
*/
interface ITicketObserver //观察者接口
{
    function onBuyTicketOver($sender, $args); //得到通知后调用的方法
}

/**
*
* 主题接口
*
*/
interface ITicketObservable //被观察对象接口
{
    function addObserver($observer); //提供注册观察者方法
}
#====================主题类实现========================
/**
*
* 主题类（购票）
*
*/
class HipiaoBuy implements ITicketObservable { //实现主题接口（被观察者）
    private $_observers = array (); //通知数组（观察者）
  

    public function buyTicket($ticket) //购票核心类，处理购票流程
{
       // TODO 购票逻辑
      

       //循环通知，调用其onBuyTicketOver实现不同业务逻辑
       foreach ( $this->_observers as $obs )
           $obs->onBuyTicketOver ( $this, $ticket ); //$this 可用来获取主题类句柄，在通知中使用
    }
  
    //添加通知
    public function addObserver($observer) //添加N个通知
{
       $this->_observers [] = $observer;
    }
}

#=========================定义多个通知====================
//短信日志通知
class HipiaoMSM implements ITicketObserver {
    public function onBuyTicketOver($sender, $ticket) {
       echo (date ( 'Y-m-d H:i:s' ) . " 短信日志记录：购票成功:$ticket
");
    }
}
//文本日志通知
class HipiaoTxt implements ITicketObserver {
    public function onBuyTicketOver($sender, $ticket) {
       echo (date ( 'Y-m-d H:i:s' ) . " 文本日志记录：购票成功:$ticket
");
    }
}
//抵扣卷赠送通知
class HipiaoDiKou implements ITicketObserver {
    public function onBuyTicketOver($sender, $ticket) {
       echo (date ( 'Y-m-d H:i:s' ) . " 赠送抵扣卷：购票成功:$ticket 赠送10元抵扣卷1张。
");
    }
}
#============================用户购票====================
$buy = new HipiaoBuy ();
$buy->addObserver ( new HipiaoMSM () ); //根据不同业务逻辑加入各种通知
$buy->addObserver ( new HipiaoTxt () );
$buy->addObserver ( new HipiaoDiKou () );
//购票
$buy->buyTicket ( "一排一号" );

?>

Christopher Alexander 说过：“每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动”。

       这几天分析一个我接手的系统，是一个典型的分布式系统。其中有特色的技术就是采用了webservice，
webservice从字面上分解就是web service----一个提供web服务的系统，可以通过web方式访问这些服务。
而从现实中，webservice可以说是一套标准：分布式，跨平台，跨语言等; 标准实现采用SOAP协议，SOAP
协议是基于流行的XML表达的，具有一个套封envlope, envlope里包含一个必须的body和一个可选的head;
就是在这个body里，我们声明了访问的方法、方法的参数或返回值。
        webservice实现, C++系统上采用开源的gSoap，而java采用apache的Axis。这两个框架都提供工具来
生成C++代码或Java代码，不管是gSoap或者Axis，他们生成的最终代码，客户端只需要调用简单的对象就
可以访问服务器，而服务器生成一样的接口，开发者实现这些接口就行，中间的通讯过程全部由框架解决了。
         其实这种技术架构并不新颖，早期的CORBA和DCOM, 后来java的RMI, 这些基本上都是RPC技术，大同
小异而已。而它们的背后设计模式，可以说就是23种模式之一的代理模式Proxy。简言之就是，一个客户不想
或者不能直接引用一个对象（接口），而代理对象（接口）可以在客户端和目标对象之间起到中介作用。
        按目的划分代理模式有8种：
        1、远程代理：为位于不同的地址空间的对象提供一个局域代表对象
        2、虚拟代理：根据需要创建一个资源消耗较大的对象，使得此对象只在需要时才会被真正创建
        3、Copy-on-Write代理：把复制拖延到只有在客户需要时才真正采取行动
        4、保护代理：控制对象的访问，提供使用权限检查
        5、Cache代理：为某个目标操作的结果提供临时的存储空间，以便多客户共享
        6、防火墙代理：保护目标，防止恶意用户
        7、同步化代理：能同时访问对象而没有冲突
        8、智能引用代理：提供一些额外操作，如访问次数统计
        显然RPC方式属于第1种远程代理模式。
        可以看出，在面对一种技术时，我们从它的定义、实现、引入目的、类似相关技术、背后理论基础来
细细分析，就比较容易掌握了。

1.单例模式（Singleton模式）
概念：单例模式的意思就是只有一个实例。单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。这个类称为单例类。
应用：
一些资源管理器常常设计成单例模式。
需要管理的软件内部资源也包括譬如负责记录网站来访人数的部件，记录软件系统内部事件、出错信息的部件，或是对系统的表现进行检查的部件等。这些部件都必须集中管理，不可政出多头。 　
　这些资源管理器构件必须只有一个实例，这是其一；它们必须自行初始化，这是其二；允许整个系统访问自己这是其三。因此，它们都满足单例模式的条件，是单例模式的应用。
参考：i.简单实用
http://www.cnblogs.com/procoder/archive/2010/02/25/Singleton-NET.html
ii.深入详细
http://www.cnblogs.com/BoyXiao/archive/2010/05/07/1729376.html
2.观察者模式
概念：Observer：定义对象间的一种一对多的依赖关系,以便当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并自动刷新。

通俗的理解：

---

msdn中关于依赖注入的描述：http://msdn.microsoft.com/zh-cn/magazine/cc163739(en-us).aspx#contents（下面是译文）
今天比以往更加注重对现有组件的重用和把异构组件联结成一种粘合框架。但是这种联结很快就成了一项让人畏缩的任务，因为这个时候程序的尺寸和复杂度都在增加，依赖性也是。减少这种依赖性扩展的一个方法就是使用依赖注入（Dependency Injection），它允许你把对象注入一个类，这胜于依赖这个类来建立自己的对象。

设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。
百度百科：http://baike.baidu.com/view/66964.htm
　　可复用面向对象软件系统现在一般划分为两大类：应用程序工具箱和框架(Framework)，我们平时开发的具体软件都是应用程序，Java的API属于工具箱；而框架是构成一类特定软件可复用设计的一组相互协作的类，EJB（EnterpriseJavaBeans）是Java应用于企业计算的框架。
　　框架通常定义了应用体系的整体结构类和对象的关系等等设计参数，以便于具体应用实现者能集中精力于应用本身的特定细节。框架主要记录软件应用中共同的设计决策，框架强调设计复用，因此框架设计中必然要使用设计模式。
　　另外，设计模式有助于对框架结构的理解，成熟的框架通常使用了多种设计模式,如果你熟悉这些设计模式，毫无疑问，你将迅速掌握框架的结构，我们一般开发者如果突然接触EJBJ2EE等框架，会觉得特别难学，难掌握，那么转而先掌握设计模式，无疑是给了你剖析EJB或J2EE系统的一把利器。
基于C#的23种设计模式http://wenku.baidu.com/view/29c5d41fb7360b4c2e3f6435.html

---

一个23设计模式的搞笑解释
1、FACTORY —追MM少不了请吃饭了，麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西，虽然口味有所不同，但不管你带MM去麦当劳或肯德基，只管向服务员说“来四个鸡翅”就行了。麦当劳和肯德基就是生产鸡翅的Factory

工厂模式：客户类和工厂类分开。消费者任何时候需要某种产品，只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时，工厂类也要做相应的修改。如：如何创建及如何向客户端提供。

2、BUILDER  — MM最爱听的就是“我爱你”这句话了，见到不同地方的MM,要能够用她们的方言跟她说这句话哦，我有一个多种语言翻译机，上面每种语言都有一个按键，见到 MM我只要按对应的键，它就能够用相应的语言说出“我爱你”这句话了，国外的MM也可以轻松搞掂，这就是我的“我爱你”builder。（这一定比美军在伊拉克用的翻译机好卖）

创建型：

1. 单件模式(Singleton Pattern)

2. 抽象工厂（Abstract Factory）

3. 建造者模式(Builder)

4. 工厂方法模式（Factory Method)

5. 原型模式(Prototype)

      

       结构型：

6. 适配器模式（Adapter Pattern)

7. 桥接模式（Bridge Pattern)

8. 装饰模式(Decorator Pattern)

9. 组合模式(Composite Pattern)

10. 外观模式（Facade Pattern)

11. 享元模式(Flyweight Pattern)

12. 代理模式(Proxy Pattern)

行为型

13. 模板方法(Template Method)

14. 命令模式(Command Pattern)

15. 迭代器模式(Iterator Pattern)

16. 观察者模式(Observer Pattern）

17. 解释器模式(Interpreter Pattern)

18. 中介者模式(Mediator Pattern)

19. 职责链模式(Chain of Responsibility Pattern)

20. 备忘录模式(Memento Pattern)

21. 策略模式(Strategy Pattern)

22. 访问者模式(Visitor Pattern)

23. 状态模式(State Pattern)