策略模式解析：
策略模式是一种定义一系列算法的方法，从概念上来看，所有这些算法完成的都是相同的工作，只是实现不同，
它可以以相同的方式调用所有的算法，减少了各种算法类与使用算法类之间的耦合
策略模式的策略层次为context定义了一系列的可重用的算法或行为，继承有助于析取出这些算法中的公共功能。
策略模式的另一个优点是简化了单元测试，因为每个算法都有自己的类，可以通过自己的接口单独测试
当不同的行为堆砌在一个类中时，就很难避免使用条件语句来选择合适的行为，将这些行为封装在一个个独立的
strategy类中可以在使用这些行为的类中消除条件语句
策略模式就是用来封装算法的，但在实践中，我们发现它可以用来封装几乎任何类型的规则，只要在分析过程中
听到需要在不同时间应用不同的业务规则，就可以考虑使用策略模式处理这种变化的可能性
在基本的策略模式中，选择所用具体实现的职责由客户端对象承担，并转给策略模式的context对象
单一职责原则：
就一个类而言，应该仅有一个引起它变化的原因
如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制
这个类完成其他的职责的能力，这种耦合设计会导致脆弱的设计，当变化发生时，设计会遭受意想不到的破坏
软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离
如果你想到多余一个的动机去改变一个类，那么这个类就具有多于一个的职责
开放-封闭原则：
软件实体（类，模块，函数等等）应该可以扩展，但是不可修改
无论模块式多么的封闭，都会存在一些无法对之封闭的变化，既然不可能完全封闭，
设计人员必须对于他设计的模块应该对哪种变化封闭做出选择，他必须先猜测出最可能发生的变化种类
然后构造抽象来隔离那些变化
等到变化发生时立即采取行动。在我们最初编写代码时，假设变化不会发生，当变化发生时，我们就创建抽象来
隔离以后发生的同类变化
面对需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码
我们希望的是在开发工作展开不久就知道可能发生的变化，查明可能发生的变化所等待的时间越长，要创建正确的
抽象就越困难
开放封闭原则是面向对象设计的核心所在，遵循这个原则可以带来面向对象技术所声称的巨大好处，就是可维护，可
扩展，可复用，灵活性好。开发人员应该仅对程序中呈现出频繁变化的那部分做出抽象，然而，对于应用程序中
的每个部分都刻意的进行抽象同样不是一个好主意，拒绝不成熟的抽象和抽象本身一样重要
依赖倒转原则：
抽象不依赖细节，细节应该依赖抽象，也就是要针对接口编程，不要对实现编程
在面向过程编程的时候高层模块式依赖低层模块的，而面向对象中，两者都应该依赖抽象
里氏代换原则：一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而且它察觉不出父类对象和
子类对象的区别，也就是说，在软件里面，把父类都替换成它的子类，程序行为没有变化
只有当子类可以替换掉父类，软件单位的功能不受到影响时，父类才能真正被复用，而子类也能够在父类的基础上增加
新的行为
正是由于子类型的可替换性才使得使用父类类型的模块在无需修改的情况下就扩展
依赖倒转其实可以说是面向对象设计的标志，用哪种语言来编写程序不重要，如果编写时考虑的都是如何
针对抽象编程，即程序中所有的依赖关系都是终止于抽象类或者接口，那就是面向对象的设计，反之那就是
过程化的设计了
装饰模式：
需要把所需的功能按正确的顺序串联起来进行控制
装饰模式，动态的给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更为灵活
Component是定义一个对象接口，可以给这些对象动态的添加职责，concreteComponent是定义了一个具体
的对象，也可以给这个对象添加一些职责。Decorator，装饰抽象类，继承了component，从外类来扩展
Component类的功能，但对于component来说，是无需知道decorator的存在的，至于concretedecorator就是具体
的装饰对象，起到给component添加职责的功能
装饰模式是为已有功能动态的添加更多功能的一种方式
当系统需要新功能的时候，是向旧的类中添加新的代码，这些新的代码通常装饰了原有类的核心职责或主要行为，
这增加了主类的复杂度，而新加入的东西仅仅是为了满足一些只在某种特定情况下才会执行的特殊行为的需要。
在这里装饰模式提供了一个非常好的解决方案，它把每个要装饰的功能放在单独的类中，并让这个类包装它所要装饰的
对象，因此当需要执行特殊行为时，客户代码就可以在运行时根据需要有选择的，按顺序的使用装饰功能包装对象了
装饰模式的优点是把类中的核心职责和装饰功能区分开了，而且可以去除相关类中重复的装饰逻辑
代理模式：
为其他对象提供一种代理以控制对这个对象的访问
subject类，定义了realsubject和proxy的公用接口，这样就在任何使用realsubject的地方都可以使用proxy
realsubject类定义proxy所代表的真实实体
proxy 类，保存一个引用使得代理可以访问实体，并提供一个与subject的接口相同的接口，这样代理就可以用来
替代实体
代理模式应用：1.是远程代理，也就是为一个对象在不同的地址空间提供局部代表，这样可以隐藏一个对象存在于
不同地址空间的事实（web service）
2．虚拟代理，根据需要创建开销很大的对象，通过它来存放实例化需要很长时间的真实对象(download)
3.安全代理，用来控制真是对象访问时的权限
4.智能指引，指当调用真实的对象时，代理处理另外一些事
工厂方法模式：
简单工厂模式的最大优点在于工厂类中包含了必要的逻辑判断，根据客户端的选择条件动态实例化相关的类，对于客户端来说
去除了与具体产品的依赖
工厂方法模式，定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类
工厂方法模式实现时，客户端需要决定实例化哪一个工厂来实现运算类，选择判断的问题还是存在的，也就是说，
工厂方法把简单工厂的内部逻辑判断移到了客户端代码来进行。想要加功能，本来是改工厂类的，而现在是修改客户端
原型模式：
原型模式，用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象
原型模式其实就是从一个对象再创建另外一个可定制的对象，而且不需要任何创建的细节
一般在初始化的信息不发生变化的情况下，克隆是最好的办法，这既隐藏了对象创建的细节，又对性能是大大的提高
浅复制是被复制对象的所有变量都含有与原来的对象相同的值，而所有的对其他对象的引用都仍然指向原来的对象
深复制把引用对象的变量指向复制过的新对象，而不是原有的被引用的对象
模板方法模式：
当我们要完成在某一细节层次一致的一个过程或一系列步骤，但其个别步骤在更详细的层次上的实现可能不同时，
我们通常考虑用模板方法来处理
模板方法模式，定义一个操作中的算法的骨架，而将一些步骤延迟到子类中，模板方法使得子类可以不改变
一个算法的结构即可重定义该算法的某些特定步骤
模板方法模式是通过把不变行为搬迁到超类，去除子类中的重复代码来体现它的优势
模板方法模式提供了一个很好的代码复用平台
当不变的和可变的行为在方法子类实现中混合在一起的时候，不变的行为就会在子类中重复出现，通过模板方法模式
把这些行为搬移到单一的地方，这样就帮助子类摆脱重复的不变行为的纠缠
迪米特法则（最少知识原则）：
如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的
某一个方法的话，可以通过第三者转发这个调用
在类的结构设计上，每一个类都应当尽量降低成员的访问权限
迪米特法则根本思想是强调了类之间的松耦合，类之间的耦合越弱，越有利于复用，一个处在弱耦合的类被修改，
不会对有关系的类造成波及
外观模式：
为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层次接口，这个接口时的这一子系统更加易用
首先在设计初期阶段，应该要有意识的将不同的两个层分离，层与层之间建立外观façade
其次，在开发阶段，子系统往往因为不断的重构演化而变得越来越复杂，增加外观façade可以提供一个简单的接口
减少它们之间的依赖
第三，在维护一个遗留的大型系统时，可能这个系统已经非常难以维护和扩展了，可以为新系统开发一个外观façade
类，来提供设计粗糙或高度复杂的遗留代码的比较清晰的接口，让新系统与façade对象交互，façade与遗留代码交互
所有复杂的工作
建造者模式：
将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示
如果我们用了建造者模式，那么用户就只需指定需要建造的类型就可以得到它们，而具体建造的细节不需知道
建造者模式是逐步建造产品的，所以建造者的builder类里的那些建造方法必须要足够普遍，以便为各种类型的具体建造者构造
由于建造者隐藏了该产品是如何组装的，所以若需改变一个产品的内部表示，只需要再定义一个具体的建造者就可以了
建造者模式是在创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时适用的模式
观察者模式：
观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生
变化时，会通知所有观察者对象
将一个系统分割成一系列相互协作的类有一个很不好的副作用，那就是需要维护相关对象之间的一致性，我们不希望
为了维持一致性而使各类紧密耦合，这样会给维护，扩展和重用都带来不便
观察者模式的使用场景：当一个对象的改变需要同时改变其他对象的时候，而且它不知道具体有多少对象有待改变时，
应该考虑使用观察者模式
一个抽象模型有两个方面，其中一方面依赖于另一方面，这时用观察者模式可以将这两者封装在独立的对象中使它们
各自独立的改变和复用
观察者模式所做的工作其实就是在解除耦合，让耦合的双方都依赖于抽象，而不是依赖于具体，从而使得各自的变化
都不会影响另一边的变化
抽象工厂模式：
更新中。。。