大话设计模式

简单工厂模式

初学者的毛病：

1. 命名不规范；
2. 判断分支做无用功；
3. 溢出没有判断；

面向对象编程：

为了程序容易维护、容易扩展、又容易复用。

业务的封装

业务逻辑和页面逻辑分开，让它们耦合度下降，这样利于维护和扩展。

继承重写

策略模式

面向对象的编程，并不是类越多越好，类的划分是为了封装，但分类的基础是抽象，具有相同属性和功能的对象的抽象集合才是类。
策略模式：它定义了算法家族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化，不会影响到算法的客户。


策略模式的优点是简化了单元测试，因为每个算法都有自己的类，可以通过自己的接口单独测试。

开放-封闭原则OCP

对于扩展是开放的，对于更改是封闭的。
怎样的设计才能面对需求的改变却可以保持相对的稳定，从而使得系统可以在第一个版本以后不断推出新的版本呢？
面对需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码。

依赖倒转原则

A 高层模块不应该依赖底层模块。两个都应该依赖抽象(接口或抽象类）。
B 抽象不应该依赖细节。细节应该依赖抽象。（针对接口编程，不要对实现编程）

强内聚，松耦合
谁也不要依赖谁，除了约定的接口，大家都可以灵活自如。

依赖倒转原则其实可以说是面向对象设计的标志，用哪种语言来编写程序并不重要，如果编写时考虑的都是如何针对抽象编程而不是针对细节编程，即程序中所有的依赖关系都是终止于抽象类或者接口，那就是面向对象的设计，反之那就是过程化的设计了。

里氏代换原则

一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而且它察觉不出父类对象和子类对象的区别。也就是说，在软件里面，把父类都替换成它的子类，程序的行为没有变化。简单来说，子类型必须能够替换掉它们的父类型。
只有当子类可以替换掉父类，软件单位的功能不受到影响时，父类才能真正被复用，而子类也能够在父类的基础上增加新的行为。
正是有了里氏代换原则，才使得开放-封闭原则有了可能。正是由于子类型的可替换性才使得使用父类类型的模块在无需修改的情况下就可以扩展。

装饰模式

动态地给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更为灵活。

如果只有一个ConcreteComponent类而没有抽象的Component类，那么Decorator类可以是ConcreteComponent的一个子类。同理，如果只有一个ConcreteDecorator类，那么就没有必要建立一个单独的Decorator类，而可以把Deocorator和ConcreteDecorator的责任合并成一个类。

代理模式

为其他对象提供一种代理以控制对这个对象的访问。

应用

第一，远程代理，也就是为一个对象在不同的地址空间提供局部代表。这样可以隐藏一个对象存在于不用地址空间的事实。
第二，虚拟代理，是根据需要创建开销很大的对象。通过它来存放实例化需要很长时间的真实对象。eg:浏览器是用代理模式来优化下载。
第三，安全代理。
第四，智能指引。

工厂方法模式

简单工厂模式的最大优点在于工厂类中包含了必要的逻辑判断，根据客户端的选择条件动态实例化相关的类，对于客户端来说，去除了与具体产品的依赖。就像计算器，让客户端不用管该用哪个类的实例，只需要把“+”给工厂，工厂自动就给出了相应的实例，客户端只要去做运算就可以了，不同的实例会实现不同的算法。
问题是，如果再加一个功能，就得更改运算工厂类的方法里的case分支条件，违背了开放-封闭原则。
工厂模式：定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。

这样就不需要更改原有的工厂类了，只需要增加此功能的运算类和相应的工厂类。
但是客户端需要决定实例化哪一个工厂来实现运算类，还是会存在选择判断问题。也就是想要添加功能，本来是改工厂类的，而现在是修改客户端。
工厂方法模式还保持了封装对象创建过程的优点。降低了客户程序与产品对象的耦合。
反射可以解决避免分支判断的问题。

原型模式

用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。

原型模式其实就是从一个对象再创建另外一个可定制的对象，而且不需要知道任何创建的细节。

浅复制与深复制

浅复制：被复制对象的所有变量都含有与原来的对象相同的值，而所有的对其他对象的引用都仍然指向原来的对象。

深复制就是把要复制的对象所引用的对象都复制一遍。把引用对象的变量指向复制过的新对象，而不是原有的被引用的对象。

模板方法模式

定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
AbstractClass是抽象类，也就是一抽象模板，定义并实现了一个模板方法。
ConcreteClass实现父类所定义的一个或多个抽象方法，每一个AbstractClass都可以有任意多个ConcreteClass与之对应，而且每一个ConcreteClass都可以给出这些抽象方法的不同实现。

迪米特法则（最少知识原则）

如果两个类不必批次直接通信，那么这两个类就不应当发生直接的相互作用，如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。
根本思想是强调了类之间的松耦合。类之间的耦合越弱，越有利于复用，一个处在弱耦合的类被修改，不对对有关系的类造成波及。

外观模式

为子系统的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

使用外观模式的场景
首先，在设计初期阶段，应该要有意识的将不同的两个层分离，比如经典的三层架构，就需要考虑在数据访问层和业务逻辑层、业务逻辑层和表示层的层与层之间建立外观Facade，这样就可以为复杂的子系统提供一个简单的接口，使得耦合大大降低。
其次，在开发阶段，子系统往往因为不断的重构演化而变得越来越复杂，大多数的模式使用时也都会产生很多很小的类，这给外部调用它们的用户程序带来了使用上的困难，增加外观Facade可以提供一个简单的接口，减少它们之间的依赖。
第三，在维护一个遗留的大型系统时，可能这个系统已经非常难以维护和扩展了。可以给新系统开发一个外观Facade类，来提供设计粗糙或高度复杂的遗留代码的比较清晰简单的接口，让新系统与Facade对象交互，Facade与遗留代码交互所有复杂的工作。

建造者模式

将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示意图时，可以应用于一个设计模式——“建造者模式”，又叫生成器模式。

建造者模式解析

应用场景：主要用于创建一些复杂的对象，这些对象内部构建间的建造顺序通常是稳定的，但对象内部的构建通常面临着复杂的变化。
好处：使得建造代码与表示代码分离，由于建造者隐藏了该产品是如何组装的，所以若需要改变一个产品的内部表示，只需要再定义一个具体的建造者就可以了。 iikiik

观察者模式

观察者模式又叫发布-订阅模式。
它定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题的对象。这个主题对象在状态发生变化时，会通知所有的观察者对象，使它们能够自动更新自己。
观察者模式的动机：将一个系统分割成一系列相互协作的类有一个很不好的副作用，那就是需要维护相关对象间的一致性。我们不希望为了维持一致性而使各类紧密耦合，这样会给维护、扩展和重用都带来不便。
应用场景：第一，当一个对象的改变需要同时改变其他对象时，而且它不知道具体有多少对象有待改变时，应该考虑使用观察者模式。第二，当一个抽象模型有两个方面，其中一方面依赖于另一个方面，这时用观察者模式可以将这两者封装在独立的对象中使它们各自独立的改变和复用。
总结：观察者模式所做的工作其实就是在解除耦合。让耦合的双方都依赖于抽象，而不是依赖于具体。从而使得各自的变化都不会影响另一边的变化。

事件委托

Java 利用反射实现C#的委托