设计模式 简析

学习中，将会记录每种设计模式的应用和UML类图。

（1）  工厂模式

 

   提供创建对象的接口. 为所实例化的多个类定义一个公共接口，并由服务提供者而不是客户端代码，来确定要实例化上述类中的哪一个类。

     

工厂模式

工厂设计模式是面向对象编程中最常用的设计模式之一。它又被称为创建性模式，因为它被用来创建其他类。在应用程序预见不到自己要创建的对象类型时，就会使用工厂解决方案。在这些情况下，可以使用工厂模式作为创建对象的基础，不需要确切地了解将要创建哪些对象。

工厂 实际上是一组模式的名称，这组模式的目的是创建类。每个变体都指定一个不同的创建方法。这些模式变体是：

　　静态工厂（Static Factory）
　　工厂方法（Factory Method）
　　抽象工厂（Abstract Factory）

首先，我先一般性地查看一下工厂模式解决常见应用程序设计问题的方式。然后将演示工厂模式如何开始对 MIDP 2.0 中大量连接类型的连接进行处理。
基于工厂的解决方案

不管使用哪种变体，所有的工厂模式都是通过将应用程序从将要初始化的类中隔离出来进行启动，实现方法是插入一个 factory 类来做实际的创建工作。图 1 是工厂模式的结构图。可以看到，Client 是需要创建新实例的应用程序或类，Product 是需要创建的类；Factory 是实际创建产品的类。

图 1. 工厂设计模式的结构

图 2 是工厂模式使用方式的概述，其中的工厂可以创建两种产品。

 

下面是简单工厂模式的示意性UML图：

                

     如上图，简单工厂模式UML我画了两种，详细如下：

     ① 只有一个产品对象的简单工厂模式。 

     ② 带有一个抽象产品对象的简单工厂模式。

 

 

（2） 适配器模式

   Adapter（别名Wrapper）模式：将一个类的接口，转换成客户期望的另一个类的接口。适配器让原本接口不兼容的类可以合作无间。

  要点：

1． 适配器模式主要应用于“希望复用一些现存的类，但是接口又与复用环境要求不一致的情况”，在遗留代码复用、类库迁移等方面非常有用。

2． 适配器模式有对象适配器和类适配器两种形式的实现结构，但是类适配器采用“多继承”的实现方式，带来了不良的高耦合，所以一般不推荐使用。对象适配器采用“对象组合”的方式，更符合松耦合精神。

  实现：

类的适配器模式结构图（继承）

对象的适配器模式结构图（组合）

（对象适配器的代码实现）

Target：定义Client使用的与特定领域相关的接口

public interface Target {    void request();}

 

Adaptee：现在需要适配的已经存在的接口

public class Adaptee{    public void specificRequest(){}}

 

Adapter：对Adaptee 的接口与Target接口进行适配

public class Adapter implements Target{    public Adapter(Adaptee adaptee)    {        super();        this.adaptee = adaptee;    }    public void request()    {        adaptee.specificRequest();    }    private Adaptee adaptee;}

 

适用性：

1. 系统需要使用现有的类，而此类的接口不符合系统的需要。

2. 想要建立一个可以重复使用的类，用于与一些彼此之间没有太大关联的一些类，包括一些可能在将来引进的类一起工作。这些源类不一定有很复杂的接口。

3. （对对象适配器而言）在设计里，需要改变多个已有子类的接口，如果使用类的适配器模式，就要针对每一个子类做一个适配器，而这不太实际。

 

效果及优缺点：

对于类适配器：

1. 用一个具体的Adapter类对Adaptee和Taget进行匹配。结果是当我们想要匹配一个类以及所有它的子类时，类Adapter将不能胜任工作。

2. 使得Adapter可以override（重定义） Adaptee的部分行为，因为Adapter是Adaptee的一个子类。

对于对象适配器：

1. 允许一个Adapter与多个Adaptee，即Adaptee本身以及它的所有子类（如果有子类的话）同时工作。Adapter也可以一次给所有的Adaptee添加功能。

2. 使得override（重定义）Adaptee的行为比较困难。如果一定要override Adaptee的方法，就只好先做一个Adaptee的子类以override Adaptee的方法，然后再把这个子类当作真正的Adaptee源进行适配。

 

（3） 单实例模式

首先，单例模式是对象的创建模式之一，此外还包括工厂模式。单例模式的三个特点：
1，该类只有一个实例
2，该类自行创建该实例(在该类内部创建自身的实例对象)
3，向整个系统公开这个实例接口

Java中大概是这个样子

1

2

3

4

5

6

7

8

9

10

11

12

13

class Singleton {

      

    //私有，静态的类自身实例

    privatestaticSingleton instance =newSingleton();

      

    //私有的构造子(构造器,构造函数,构造方法)

    privateSingleton(){}

      

    //公开，静态的工厂方法

    publicstaticSingleton getInstance() {

        returninstance;

    }

}

使用时

1

Singleton obj = Singleton.getInstance();

这个单例类在自身被加载时instance会被实例化，即便加载器是静态的。因此，对于资源密集，配置开销较大的单体更合理的做法是将实例化(new)推迟到使用它的时候。即惰性加载(Lazy loading)，它常用于那些必须加载大量数据的单体。修改下

?

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

class LazySingleton {

    //初始为null，暂不实例化

    privatestaticLazySingleton instance =null;

      

    //私有的构造子(构造器,构造函数,构造方法)

    privateLazySingleton(){}

      

    //公开，静态的工厂方法，需要使用时才去创建该单体

    publicstaticLazySingleton getInstance() {

        if( instance ==null) {

            instance =newLazySingleton();

        }

        returninstance;

    }   

}

使用方式同上。

 

（4） 外观模式

在这个程序中，我们首先要有一个顾客类，它是一个纯数据类，并无任何操作，示意代码：

//顾客类
public class Customer
{
    private string _name;

    public Customer(string name)
    {
        this._name = name;
    }

    public string Name
    {
        get { return _name; }
    }
}

下面这三个类均是子系统类，示意代码：

//银行子系统
public class Bank
{
    public bool HasSufficientSavings(Customer c, int amount)
    {
        Console.WriteLine("Check bank for " + c.Name);
        return true;
    }
}

//信用子系统
public class Credit
{
    public bool HasGoodCredit(Customer c)
    {
        Console.WriteLine("Check credit for " + c.Name);
        return true;
    }
}

//贷款子系统
public class Loan
{
    public bool HasNoBadLoans(Customer c)
    {
        Console.WriteLine("Check loans for " + c.Name);
        return true;
    }
}

 

来看客户程序的调用：

//客户程序
public class MainApp
{
    private const int _amount = 12000;

    public static void Main()
    {
        Bank bank = new Bank();
        Loan loan = new Loan();
        Credit credit = new Credit();

        Customer customer = new Customer("Ann McKinsey");

        bool eligible = true;

        if (!bank.HasSufficientSavings(customer, _amount))
        {
            eligible = false;
        }
        else if (!loan.HasNoBadLoans(customer))
        {
            eligible = false;
        }
        else if (!credit.HasGoodCredit(customer))
        {
            eligible = false;
        }

        Console.WriteLine("\n" + customer.Name + " has been " + (eligible ? "Approved" : "Rejected"));
        Console.ReadLine();
    }
}

 

  可以看到，在不用Façade模式的情况下，客户程序与三个子系统都发生了耦合，这种耦合使得客户程序依赖于子系统，当子系统变化时，客户程序也将面临很多变化的挑战。一个合情合理的设计就是为这些子系统创建一个统一的接口，这个接口简化了客户程序的判断操作。看一下引入Façade模式后的类结构图：

图4

门面类Mortage的实现如下：

//外观类
public class Mortgage
{
    private Bank bank = new Bank();
    private Loan loan = new Loan();
    private Credit credit = new Credit();

    public bool IsEligible(Customer cust, int amount)
    {
        Console.WriteLine("{0} applies for {1:C} loan\n",
          cust.Name, amount);

        bool eligible = true;

        if (!bank.HasSufficientSavings(cust, amount))
        {
            eligible = false;
        }
        else if (!loan.HasNoBadLoans(cust))
        {
            eligible = false;
        }
        else if (!credit.HasGoodCredit(cust))
        {
            eligible = false;
        }

        return eligible;
    }
}

顾客类和子系统类的实现仍然如下：

//银行子系统
public class Bank
{
    public bool HasSufficientSavings(Customer c, int amount)
    {
        Console.WriteLine("Check bank for " + c.Name);
        return true;
    }
}

//信用证子系统
public class Credit
{
    public bool HasGoodCredit(Customer c)
    {
        Console.WriteLine("Check credit for " + c.Name);
        return true;
    }
}

//贷款子系统
public class Loan
{
    public bool HasNoBadLoans(Customer c)
    {
        Console.WriteLine("Check loans for " + c.Name);
        return true;
    }
}

//顾客类
public class Customer
{
    private string name;

    public Customer(string name)
    {
        this.name = name;
    }

    public string Name
    {
        get { return name; }
    }
}

 

而此时客户程序的实现：

//客户程序类
public class MainApp
{
    public static void Main()
    {
        //外观
        Mortgage mortgage = new Mortgage();

        Customer customer = new Customer("Ann McKinsey");
        bool eligable = mortgage.IsEligible(customer, 125000);

        Console.WriteLine("\n" + customer.Name +
            " has been " + (eligable ? "Approved" : "Rejected")); 
        Console.ReadLine();
    }
}

 

（5）桥接模式

概述:
在软件系统中，某些类型由于自身的逻辑，它具有两个或多个维度的变化，那么如何应对这种“多维度的变化”？如何利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化，而又不引入额外的复杂度？这就要使用Bridge模式。
意图:
　　　将抽象部分与实现部分分离，使它们都可以独立的变化。
                                                                    ——《设计模式》GOF
效果及实现要点：
1．Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的维度来变化。
2．所谓抽象和实现沿着各自维度的变化，即“子类化”它们，得到各个子类之后，便可以任意它们，从而获得不同路上的不同汽车。
3．Bridge模式有时候类似于多继承方案，但是多继承方案往往违背了类的单一职责原则（即一个类只有一个变化的原因），复用性比较差。Bridge模式是比多继承方案更好的解决方法。
4．Bridge模式的应用一般在“两个非常强的变化维度”，有时候即使有两个变化的维度，但是某个方向的变化维度并不剧烈——换言之两个变化不会导致纵横交错的结果，并不一定要使用Bridge模式。

适用性：
   在以下的情况下应当使用桥梁模式：
1．如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的联系。
2．设计要求实现化角色的任何改变不应当影响客户端，或者说实现化角色的改变对客户端是完全透明的。
3．一个构件有多于一个的抽象化角色和实现化角色，系统需要它们之间进行动态耦合。
4．虽然在系统中使用继承是没有问题的，但是由于抽象化角色和具体化角色需要独立变化，设计要求需要独立管理这两者。
总结：
      Bridge模式是一个非常有用的模式，也非常复杂，它很好的符合了开放-封闭原则和优先使用对象，而不是继承这两个面向对象原则。

桥接模式与装饰的区别:
装饰模式:
      这两个模式在一定程度上都是为了减少子类的数目，避免出现复杂的继承关系。但是它们解决的方法却各有不同，装饰模式把子类中比基类中多出来的部分放到单独的类里面，以适应新功能增加的需要，当我们把描述新功能的类封装到基类的对象里面时，就得到了所需要的子类对象，这些描述新功能的类通过组合可以实现很多的功能组合 .
桥接模式：
          桥接模式则把原来的基类的实现化细节抽象出来，在构造到一个实现化的结构中，然后再把原来的基类改造成一个抽象化的等级结构，这样就可以实现系统在多个维度上的独立变化 。

（6） 装饰模式

装饰者模式

Decorator模式（别名Wrapper）：动态将职责附加到对象上，若要扩展功能，装饰者提供了比继承更具弹性的代替方案。

 

意图：

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

 

设计原则：

1. 多用组合，少用继承。

利用继承设计子类的行为，是在编译时静态决定的，而且所有的子类都会继承到相同的行为。然而，如果能够利用组合的做法扩展对象的行为，就可以在运行时动态地进行扩展。

2. 类应设计的对扩展开放，对修改关闭。

 

要点：

1． 装饰者和被装饰对象有相同的超类型。

2． 可以用一个或多个装饰者包装一个对象。

3． 装饰者可以在所委托被装饰者的行为之前或之后，加上自己的行为，以达到特定的目的。

4． 对象可以在任何时候被装饰，所以可以在运行时动态的，不限量的用你喜欢的装饰者来装饰对象。

5． 装饰模式中使用继承的关键是想达到装饰者和被装饰对象的类型匹配，而不是获得其行为。

6． 装饰者一般对组件的客户是透明的，除非客户程序依赖于组件的具体类型。在实际项目中可以根据需要为装饰者添加新的行为，做到“半透明”装饰者。

7． 适配器模式的用意是改变对象的接口而不一定改变对象的性能，而装饰模式的用意是保持接口并增加对象的职责。

 

实现：

适用性：

以下情况使用Decorator模式

1. 需要扩展一个类的功能，或给一个类添加附加职责。

2. 需要动态的给一个对象添加功能，这些功能可以再动态的撤销。

3. 需要增加由一些基本功能的排列组合而产生的非常大量的功能，从而使继承关系变的不现实。

4. 当不能采用生成子类的方法进行扩充时。一种情况是，可能有大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长。另一种情况可能是因为类定义被隐藏，或类定义不能用于生成子类。

 

优点：

1. Decorator模式与继承关系的目的都是要扩展对象的功能，但是Decorator可以提供比继承更多的灵活性。

2. 通过使用不同的具体装饰类以及这些装饰类的排列组合，设计师可以创造出很多不同行为的组合。

缺点：

1. 这种比继承更加灵活机动的特性，也同时意味着更加多的复杂性。

2. 装饰模式会导致设计中出现许多小类，如果过度使用，会使程序变得很复杂。

3. 装饰模式是针对抽象组件（Component）类型编程。但是，如果你要针对具体组件编程时，就应该重新思考你的应用架构，以及装饰者是否合适。当然也可以改变Component接口，增加新的公开的行为，实现“半透明”的装饰者模式。在实际项目中要做出最佳选择。

 

 

(7) 观察者模式

概述
　　在软件构建过程中，我们需要为某些对象建立一种“通知依赖关系” ——一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知。如果这样的依赖关系过于紧密，将使软件不能很好地抵御变化。使用面向对象技术，可以将这种依赖关系弱化，并形成一种稳定的依赖关系。从而实现软件体系结构的松耦合。
　　意图
　　定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时, 所有依赖于它的对象都得到通知并被自动更新。[GOF 《设计模式》]
　　结构图

图1 Observer模式结构图

生活中的例子
　　观察者定义了对象间一对多的关系，当一个对象的状态变化时，所有依赖它的对象都得到通知并且自动地更新。拍卖演示了这种模式。每个投标人都有一个标有数字的牌子用于出价。拍卖师开始拍卖时，他观察是否有牌子举起出价。每次接受一个新的出价都改变了拍卖的当前价格，并且广播给所有的投标人进行新的出价。

图2 使用拍卖例子的观察者模式

　　Observer模式解说
　　下面通过一个例子来说明Observer模式。监控某一个公司的股票价格变化，可以有多种方式，通知的对象可以是投资者，或者是发送到移动设备，还有电子邮件等。一开始我们先不考虑Observer模式，通过一步步地重构，最终重构为Observer模式。现在有这样两个类：Microsoft和Investor，如下图所示：

 

图3 UML静态图示例

效果及实现要点
　　1．使用面向对象的抽象，Observer模式使得我们可以独立地改变目标与观察者，从而使二者之间的依赖关系达到松耦合。
　　2．目标发送通知时，无需指定观察者，通知（可以携带通知信息作为参数）会自动传播。观察者自己决定是否需要订阅通知。目标对象对此一无所知。
　　3．在C#中的Event。委托充当了抽象的Observer接口，而提供事件的对象充当了目标对象，委托是比抽象Observer接口更为松耦合的设计。

　　适用性
　　1．当一个抽象模型有两个方面, 其中一个方面依赖于另一方面。将这二者封装在独立的对象中以使它们可以各自独立地改变和复用。
　　2．当对一个对象的改变需要同时改变其它对象, 而不知道具体有多少对象有待改变。
　　3．当一个对象必须通知其它对象，而它又不能假定其它对象是谁。换言之, 你不希望这些对象是紧密耦合的。

　　总结
　　通过Observer模式，把一对多对象之间的通知依赖关系的变得更为松散，大大地提高了程序的可维护性和可扩展性，也很好的符合了开放-封闭原则。