decajes的专栏

把《大话设计模式》完全地看完了，确实很通俗易懂。但是书上得来终觉浅，还是好好把书中的代码实现一遍吧。        简单工厂模式，在书中的定义就是用一个单独的类来做这个创造实例的过程。即把各个不同对象的创建代码封装成一个类。个人感觉这个方式确实很不错，因为每一个类对象就可以在其需要的时候灵活地创建，而且实现方法还可以在各自类中定义，容易修改而不互相影响。下面就按照书本上的例子，用C++来实现一

外观模式，看完之后就觉得好像我们生活中的客服，譬如我们中国移动的10086，客户如果想了解某个手机服务，可以直接通过客服访问移动提供的服务信息，而不用直接与各个业务平台直接接触。也就是说，当我们的客户程序需要与子系统交互的时候，我们可以通过一个facade类来调用各个子系统的功能，让客户端程序直接与这个facade类交互，这样不但解除了客户程序与子系统的耦合，而且还有利于屏蔽子系统之间的复杂操作。

原型模式就是从一个对象再创建另一个可定制的对象，而且不需要知道任何创建的细节。书中的定义为：原型模式(Prototype)，用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。        个人理解为定义一个抽象接口Prototype，然后在其中定义一个纯虚函数Clone。再定义一个创建原型的类concretePrototype来定义属性并实现Clone方法，克隆自身并返回新的对

所谓代理，就是把自己的事情交给别人去做，也就是间接实现自己的目的。书本上对于代理模式（proxy）的定义为：为其他对象提供一种代理以控制对这个对象的访问。其实这个模式挺好理解的，就是相当于在一个类里面实现另一个类的方法，它们的功能是一样的，所以我们可以抽象出一个接口，让本类和代理类都继承它，然后在本类里实现接口里的方法，在代理类的方法里调用本类的方法，然后通过代理类来实现本类的功能。

看书看到这个模型的时候，马上想到了之前学到的简单工厂模式，然后看了一下例子，觉得假如同样对于计算器来说的话，貌似简单工厂模式灵活一点，因为工厂类里包含了相关的逻辑判断。起码对于客户端而言，可以动态地选择条件来实例化相关的类。而工厂模式，貌似虽然使添加方法更加灵活，但是判断要实例化相关类的时候，却要在客户端里写判断逻辑。         工厂方法模式(Factory Method)在书中的定义为

今天学习了那个装饰模式，顾名思义就是，保持原来的基本不变，然后要什么就添加什么。就好比一个人穿衣服，这个人没有变胖或者变瘦，也没有变高或变矮，就是单纯地 添加衣服裤袜，就会觉得这个人看上去不同了。在书本上的定义是：装饰模式（Decorator），动态地给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更加灵活。        下面就是对书本中代码的实践，主要是通过 Decorat

开闭原则（Open Close Principle）定义：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。问题由来：在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。解决方案：当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来

迪米特法则（Law Of Demeter）定义：一个对象应该对其他对象保持最少的了解。问题由来：类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。解决方案：尽量降低类与类之间的耦合。         自从我们接触编程开始，就知道了软件编程的总的原则：低耦合，高内聚。无论是面向过程编程还是面向对象编程，只有使各个模块之间的耦合尽量的低，才能提高代码的复用

接口隔离原则（Interface Segregation Principle）定义：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。问题由来：类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必须去实现他们不需要的方法。解决方案：将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关

里氏替换原则（Liskov Substitution Principle）肯定有不少人跟我刚看到这项原则的时候一样，对这个原则的名字充满疑惑。其实原因就是这项原则最早是在1988年，由麻省理工学院的一位姓里的女士（Barbara Liskov）提出来的。定义1：如果对每一个类型为 T1的对象 o1，都有类型为 T2的对象o2，使得以 T1定义的所有程序 P在所有的对象 o1 都代换

单一职责原则（Single Responsibility Principle）定义：不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。问题由来：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。解决方案：遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责

依赖倒置原则（Dependence Inversion Principle）定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。

策略模式在书中的定义是：它定义了算法家族，分别封转起来，让它们之间可以互相替换，此模式让算法的变化不会影响到使用算法的客户。       创建对象的话让简单工厂模式实现，刚开始总感觉策略模式可有可无，因为按照工厂选择的对象，再调用该对象的方法去实现多态就足够了，为什么还要写一个类来管理具体的方法呢？先实践一下代码，再回头想想吧！！！！ 主要实现的类   #include "stdafx

模板方法模式个人理解就是对继承的合理使用。也就是说当子类中出现许多重复和特有的代码段时，我们应该把重复的代码上升到父类中。然后子类就通过继承来获得重复的功能，而在子类中重写或者添加自身特有的方法。就好像我们把模板拿过来，然后就添加自己的内容。        模板方法模式在书中的定义为：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义改算法