软件标准体系结构作业种模式.doc

Abstract Factory抽象工厂模式
抽象工厂是一个创建型模式，是为了处理实例化时所带来问题。
我们先来看看是什么问题，有时候我们会碰到这种情况，我们需要一系列对象。举个例子，有一系列BMW汽车零部件对象：轮子bmwwheel，油箱bmwoilbox，在一个管理函数中调用它们，代码以下
class BMWWheel
{
 public BMWWheel(){};
} 
class BMWOilbox
{
 public BMWOilbox(){};
}
public void Manage()
{
 BMWOilbox oilbox = new BMWOilbox();
 BMWWheel wheel = new BMWWheel();
}
假如现在需求变了，我们要用大众一汽BORA零件，不用BMW，那么我们除了要再加上对应零件对象外还要将Manage函数中对象更改为BORA零件对象。
那这时发觉new会带来了部分问题：实现依靠，不能应对具体实例化类型改变。
怎样处理这类问题呢？封装改变点。（没有改变就不需要封装）
工厂模式缘起：
1、改变点在“对象创建”，所以就封装“对象创建”
2、面向接口编程
简单工厂问题：
1、不能应对“不一样系列对象”改变。如：我们要在上面代码中加上其它对象就不能很好应对了
2、使用面向对象中国技术来封装改变点
动机：在软件系统中，常常面临着“一系列相互依靠对象”创建工作；同时，因为需求改变，往往存在更多系列对象创建工作。面对这种问题，我们想绕过常规对象创建方法，提供一个“封装机制”来避免用户程序和这种“多系列具体对象创建工作”紧耦合。
对于“紧耦合”，我原来是不喜爱这个词，不过今天明白了，不是程序紧耦合不好，而是面对频繁改变需求，紧耦合会使程序编写变得很吃力。假如面对一个不变需求，松耦合和紧耦合在代码编写上应该是没什么区分。
《设计模式》中解释这种模式意图是：提供一个接口，让该接口负责创建一系列“相关或相互依靠对象”，无需指定她们具体类。
下面我们来看看怎样使用抽象工厂模式完成对这种改变封装：
首先我们需求是BMW车轮和油箱，当然她们要继承各自基类，代码以下
 abstract class AbstractWheel
 {
  public AbstractWheel()
  {
   //Console.Write("Create a AbstractProduct");
  }
 }
 abstract class AbstractOilBox
 {
  public AbstractOilBox()
  {}
 }
 class BMWWheel:AbstractWheel
 {
  public BMWWheel()
  {
   Console.Write("Create a BMWwheel");
  }
 }
 class BMWOilBox:AbstractOilBox
 {
  public BMWOilBox()
  {
   Console.Write("Create a BMWOilBox");
  }
 }

 然后，我们在建立一个生产这些零件工厂，它继承自一个抽象工厂
 //抽象工厂
 abstract class AbstractFactory
 {
  abstract public AbstractWheel CreatWheel();
  abstract public AbstractOilBox CreatOilBox();
 }
 class BMWFactory:AbstractFactory
 {
  public override AbstractWheel CreatWheel()
  {
   return new BMWWheel();
  }
  public override AbstractOilBox CreatOilBox()
  {
     return new BMWOilBox();
  }
 }
 现在我们在Main函数中调用它们：
 static void Main(string[] args)
  {
   AbstractFactory factory = null;
   factory = new BMWFactory();
   factory.CreatWheel();
   Console.Write("\n");
   factory.CreatOilBox();
   Console.Write("\n");
   Console.Read();
  }
  显示结果：
          Create a BMWwheel
          Create a BMWOilBox
 现在我们想不用BMW零件，用BORA零件了，先写部分BORA零件类：
 class BORAWheel:AbstractWheel
 {
  public BORAWheel()
  {
   Console.Write("Create a BORAWheel");
  }
 }
 class BORAOilBox:AbstractOilBox
 {
  public BORAOilBox()
  {
   Console.Write("Create a BORAOilBox");
  }
 }
 然后我们再创建BORA零件工厂：
 class BORAFactory:AbstractFactory
 {
  public override AbstractWheel CreatWheel()
  {
   return new BORAWheel();
  }
  public override AbstractOilBox CreatOilBox()
  {
   return new BORAOilBox();
  }
 }
再来看看怎样在Main函数中修改使其调用BORA零件；我们只要在将Main中factory对象实例化为BORA工厂BORAFactory就能够了：
 static void Main(string[] args)
  {
   AbstractFactory factory = null;
   factory = new BORAFactory();
   factory.CreatWheel();
   Console.Write("\n");
   factory.CreatOilBox();
   Console.Write("\n");
   Console.Read();
  }

  结果以下：
          Create a BORAWheel
          Create a BORAOilBox
  Abstract Factory模式多个关键点：
1、假如没有应对“多系列对象构建”需求改变，则没有必需使用Abstract
Factory模式。
2、“系列对象”指是这项对象之间有相互依靠、或作用关系。
3、Abstract Factory模式关键在于应对“新系列”需求变动。缺点是难以应对“新对象”需求变动。这一点应该注意，就像前面说，假如我们现在要在加入其它系列类，代码改动会很大。
4、Abstract Factory模式常常和Factory Method模式共同组合来应对“对象创建”需求改变。
  组合模式（Composite Pattern）
概述
组合模式有时候又叫做部分-整体模式，它使我们树型结构问题中，模糊了简单元素和复杂元素概念，用户程序能够向处理简单元素一样来处理复杂元素,从而使得用户程序和复杂元素内部结构解耦。
意图
将对象组合成树形结构以表示“部分-整体”层次结构。Composite模式使得用户对单个对象和组合对象使用含有一致性。[GOF 《设计模式》]
结构图

图1 Composite模式结构图
生活中例子
组合模式将对象组合成树形结构以表示"部分-整体"层次结构。让用户一致地使用单个对象和组合对象。即使例子抽象部分，不过算术表示式确实是组合例子。算术表示式包含操作数、操作符和另一个操作数。操作数能够是数字，也能够是另一个表示式。这么，2+3和（2+3）+（4*6）全部是正当表示式。

图2 使用算术表示式例子Composite模式对象图
组合模式讲解
这里我们用绘图这个例子来说明Composite模式，经过部分基础图像元素（直线、圆等）和部分复合图像元素（由基础图像元素组合而成）构建复杂图形树。在设计中我们对每一个对象全部配置一个Draw()方法，在调用时，会显示相关图形。能够看到，这里复合图像元素它在充当对象同时，又是那些基础图像元素一个容器。先看一下基础类结构图：

图3
图中橙色区域表示是复合图像元素。示意性代码：
public abstract class Graphics
{
    protected string _name;

    public Graphics(string name)
    {
        this._name = name;
    }
    public abstract void Draw();
}

public class Picture : Graphics
{
    public Picture(string name)
        : base(name)
    { }
    public override void Draw()
    {
        //
    }

    public ArrayList GetChilds()
    { 
        //返回全部子对象
    }
}
而其它作为树枝构件，实现代码以下：
public class Line:Graphics
{
    public Line(string name)
        : base(name)
    { }

    public override void Draw()
    {
        Console.WriteLine("Draw a" + _name.ToString());
    }
}

public class Circle : Graphics
{
    public Circle(string name)
        : base(name)
    { }

    public override void Draw()
    {
        Console.WriteLine("Draw a" + _name.ToString());
    }
}

public class Rectangle : Graphics
{
    public Rectangle(string name)
        : base(name)
    { }

    public override void Draw()
    {
        Console.WriteLine("Draw a" + _name.ToString());
    }
}
现在我们要对该图像元素进行处理：在用户端程序中，需要判定返回对象具体类型到底是基础图像元素，还是复合图像元素。假如是复合图像元素，我们将要用递归去处理，然而这种处理结果却增加了用户端程序和复杂图像元素内部结构之间依靠，那么我们怎样去解耦这种关系呢？我们期望是用户程序能够像处理基础图像元素一样来处理复合图像元素，这就要引入Composite模式了，需要把对于子对象管理工作交给复合图像元素，为了进行子对象管理，它必需提供必需Add()，Remove()等方法，类结构图以下：

图4
示意性代码：
public abstract class Graphics
{
    protected string _name;

    public Graphics(string name)
    {
        this._name = name;
    }
    public abstract void Draw();
    public abstract void Add();
    public abstract void Remove();
}

public class Picture : Graphics
{
    protected ArrayList picList = new ArrayList();

    public Picture(string name)
        : base(name)
    { }
    public override void Draw()
    {
        Console.WriteLine("Draw a" + _name.ToString());

        foreach (Graphics g in picList)
        {
            g.Draw();
        }
    }

    public override void Add(Graphics g)
    {
        picList.Add(g);
    }
    public override void Remove(Graphics g)
    {
        picList.Remove(g);
    }
}

public class Line : Graphics
{
    public Line(string name)
        : base(name)
    { }

    public override void Draw()
    {
        Console.WriteLine("Draw a" + _name.ToString());
    }
    public override void Add(Graphics g)
    { }
    public override void Remove(Graphics g)
    { }
}

public class Circle : Graphics
{
    public Circle(string name)
        : base(name)
    { }

    public override void Draw()
    {
        Console.WriteLine("Draw a" + _name.ToString());
    }
    public override void Add(Graphics g)
    { }
    public override void Remove(Graphics g)
    { }
}

public class Rectangle : Graphics
{
    public Rectangle(string name)
        : base(name)
    { }

    public override void Draw()
    {
        Console.WriteLine("Draw a" + _name.ToString());
    }
    public override void Add(Graphics g)
    { }
    public override void Remove(Graphics g)
    { }
}
这么引入Composite模式后，用户端程序不再依靠于复合图像元素内部实现了。然而，我们程序中仍然存在着问题，因为Line，Rectangle，Circle已经没有了子对象，它是一个基础图像元素，所以Add()，Remove()方法对于它来说没有任何意义，而且把这种错误不会在编译时候报错，把错误放在了运行期，我们期望能够捕捉到这类错误，并加以处理，稍微改善一下我们程序：
public class Line : Graphics
{
    public Line(string name)
        : base(name)
    { }

    public override void Draw()
    {
        Console.WriteLine("Draw a" + _name.ToString());
    }
    public override void Add(Graphics g)
    { 
        //抛出一个我们自定义异常
    }
    public override void Remove(Graphics g)
    {
        //抛出一个我们自定义异常
    }
}
这么改善以后，我们能够捕捉可能出现错误，做深入处理。上面这种实现方法属于透明式Composite模式，假如我们想要更安全一个做法，就需要把管理子对象方法申明在树枝构件Picture类里面，这么假如叶子节点Line，Rectangle，Circle使用这些方法时，在编译期就会犯错，看一下类结构图：

图5
示意性代码：
public abstract class Graphics
{
    protected string _name;

    public Graphics(string name)
    {
        this._name = name;
    }
    public abstract void Draw();
}

public class Picture : Graphics
{
    protected ArrayList picList = new ArrayList();

    public Picture(string name)
        : base(name)
    { }
    public override void Draw()
    {
        Console.WriteLine("Draw a" + _name.ToString());

        foreach (Graphics g in picList)
        {
            g.Draw();
        }
    }

    public void Add(Graphics g)
    {
        picList.Add(g);
    }
    public void Remove(Graphics g)
    {
        picList.Remove(g);
    }
}

public class Line : Graphics
{
    public Line(string name)
        : base(name)
    { }

    public override void Draw()
    {
        Console.WriteLine("Draw a" + _name.ToString());
    }
}

public class Circle : Graphics
{
    public Circle(string name)
        : base(name)
    { }

    public override void Draw()
    {
        Console.WriteLine("Draw a" + _name.ToString());
    }
}

public class Rectangle : Graphics
{
    public Rectangle(string name)
        : base(name)
    { }

    public override void Draw()
    {
        Console.WriteLine("Draw a" + _name.ToString());
    }
}
这种方法属于安全式Composite模式，在这种方法下，即使避免了前面所讨论错误，不过它也使得叶子节点和树枝构件含有不一样接口。这种方法和透明式Composite各有优劣，具体使用哪一个，需要依据问题实际情况而定。经过Composite模式，用户程序在调用Draw()时候不用再去判定复杂图像元素中子对象到底是基础图像元素，还是复杂图像元素，看一下简单用户端调用：
public class App
{
    public static void Main()
    {
        Picture root = new Picture("Root");

        root.Add(new Line("Line"));
        root.Add(new Circle("Circle"));

        Rectangle r = new Rectangle("Rectangle");
        root.Add(r);

        root.Draw();
    }
}
效果及实现关键点
1．Composite模式采取树形结构来实现普遍存在对象容器，从而将“一对多”关系转化“一对一”关系，使得用户代码能够一致地处理对象和对象容器，无需关心处理是单个对象，还是组合对象容器。
2．将“用户代码和复杂对象容器结构”解耦是Composite模式关键思想，解耦以后，用户代码将和纯粹抽象接口——而非对象容器复内部实现结构——发生依靠关系，从而更能“应对改变”。
3．Composite模式中，是将“Add和Remove等和对象容器相关方法”定义在“表示抽象对象Component类”中，还是将其定义在“表示对象容器Composite类”中，是一个关乎“透明性”和“安全性”两难问题，需要仔细权衡。这里有可能违后面向对象“单一职责标准”，不过对于这种特殊结构，这又是必需付出代价。ASP.NET控件实现在这方面为我们提供了一个很好示范。
4．Composite模式在具体实现中，能够让父对象中子对象反向追溯；假如父对象有频繁遍历需求，可使用缓存技巧来改善效率。
适用性
以下情况下适用Composite模式：
1．你想表示对象部分-整体层次结构
2．你期望用户忽略组合对象和单个对象不一样，用户将统一地使用组合结构中全部对象。
总结
组合模式解耦了用户程序和复杂元素内部结构，从而使用户程序能够向处理简单元素一样来处理复杂元素。