烟花中的模式设想

           过年过节放鞭炮，烟花是中国的传统风俗。不仅可以烘托节日的气氛，而且还可以让我们看到美丽的烟火，相信大家不会忘记奥运会开闭幕上的精彩无比的烟火表演，让世界过目不忘，堪称锦上添花。

          

       今晚坐在车上，望着车外美丽的烟火，突然将这绚丽多瑙的烟火和工作中的设计模式联系起来。下面简单的用设计模式“点燃”下烟火，仅供大家娱乐。

      

       综观整个放烟火过程，主要参与者与角色有：放烟火者 烟火筒 烟火

        

       Command 模式 -- 只管点燃

            整个烟花提供给放烟火者的入口只有一条导火线，至于其中是放哪个烟花，烟花的燃 烧方式，烟花的形状，这些繁琐的事情，统统不用管~~，内部已经井然有序，整装待发，只要放烟火者轻轻的点燃，下面就尽情的享受吧！！

 

       Chain of Responsibility(职责链) -- 一个接一个点燃

            漂亮的烟花总是先后出现多种美丽的形状，让你眼花缭乱，其实有谁想过，为什么烟花的形状是一个接一个，而没有出现同时或者错位呢？里面肯定有一条无形的绳索，按先后顺序进行排列。

       Composite(组合) -- 各种烟火的组装

            这种模式多出现在比较大的烟火中，一组形状的烟花假如有A,B,C,D四种，其中D下面又有 D1,D2,D3三种形状， D1下面又有D11,D12……，这种情况下，设想下烟火怎么去决定燃放这些呢？是不是 烟火燃放A B C，到D时 由D再调用 D1,D2,D3, D1发现自己下面还有子烟火，再用D1的方式调用D11,D12。这就是典型的COMPOSITE 模式。

       Bridge（桥梁） -- 组装

            我们在把目光放在烟火的外观上，烟火由外面的烟火筒和一个炮组成，烟火筒有大有小，十个的、12个、8个装的，炮也有多种多样的，小型，中等、大型的。在安装的时候根据实际情况需要再决定从这两种类型中挑选，两个class搞定：）

    

       Strategy(策略) -- 随机安装

             我们又把目光再次放到了安装上，在现有的烟火筒上，随机的选择烟火的样式，烟火是固定的，变的只是它的类型（子类），这不就是我们说的策略吗？在固定的模式下，根据实际的需要选择具体的功能类载入，这就是策略。

        Proxy(代理) -- 给用户提供

             一筒几十个的烟火，如果堆在一起，然后由你决定是先点燃哪个，怎么放置这些比较安全，也不会影响到其他烟火？是间隔多久？放的期间火柴没有了怎么办？ 晕啊，细想起来还很多，我的天，那样放太麻烦了。不用担心，聪明的商家，早就替你做好了这些，你不用关心那些繁琐的事情。那些事情统统交给外面的烟火筒吧，由她和烟火交互，我们只要去关心访问这个烟火筒代理（proxy），使用她提供我们的简单的接口（导火索），一切就是这么简单。

        Facade(外观) -- 提供统一外观接口

            呵呵，最后一个想到的有点牵强，烟火筒是不是又可以算是一个外观模式呢？它提供了简单而又单一的功能---点燃。太统一了：）

      以上就是个人的一点想法，请大家随意拍砖啊~~~

singleton (单例) --- 点烟火的香
   点烟火的时候从香炉里取得一支香,去点燃摆放好的烟火, 在点烟火的过程中,我们用的始终是刚才从香炉里拿的那支香.,点完后再把香放回香炉.

不过,现在城里人基本上都不会在过节的时候点香了

确实是这样的，香烟也可以~~

过年的喜庆也想这个。。真不知说啥好。。哈哈。。

这里还可以有lazy-init和first-init的问题~

建议lz把类图贴上来

我以前尝试过发图，但是javaeye显示不出来 就放弃了。。。

由贴可见IT同胞们精神压力有多大， 连放个鞭炮都能联系到设计模式。

老提设计模式有意思吗？

仅仅A调用B，我估计要是想那有很多设计模式思想在里面了。

模式应该是驱动出来的，除了经验上的处理，比如，命令模式一般都会在整个系统开发开始时使用上