0%

工厂方法(FactoryMethod)模式的定义:定义一个创建产品对象的工厂接口,将产品对象的实际创建工作推迟到具体子工厂类当中。这满足创建型模式中所要求的“创建与使用相分离”的特点。

我们把被创建的对象称为“产品”,把创建产品的对象称为“工厂”。

如果要创建的产品不多,只要一个工厂类就可以完成,这种模式叫“简单工厂模式”,它不属于 GoF 的 23 种经典设计模式,它的缺点是增加新产品时会违背“开闭原则”(可以通过反射克服该缺点)

“工厂方法模式”是对简单工厂模式的进一步抽象化,其好处是可以使系统在不修改原来代码的情况下引进新的产品,即满足开闭原则。

工厂方法模式的主要优点有:

  • 用户只需要知道具体工厂的名称就可得到所要的产品,无须知道产品的具体创建过程(对创建过程复杂的对象很有作用)
  • 在系统增加新的产品时只需要添加具体产品类和对应的具体工厂类,无须对原工厂进行任何修改,满足开闭原则;

其缺点是:每增加一个产品就要增加一个具体产品类和一个对应的具体工厂类,这增加了系统的复杂度

工厂方法模式由抽象工厂、具体工厂、抽象产品和具体产品等4个要素构成。本节来分析其基本结构和实现方法。

模式的结构

工厂方法模式的主要角色如下:

  • 抽象工厂(Abstract Factory):提供了创建产品的接口,调用者通过它访问具体工厂的工厂方法 CreateProduct() 来创建产品。
  • 具体工厂(ConcreteFactory):主要是实现抽象工厂中的抽象方法,完成具体产品的创建
  • 抽象产品(Product):定义了产品的规范,描述了产品的主要特性和功能。
  • 具体产品(ConcreteProduct):实现了抽象产品角色所定义的接口,由具体工厂来创建,它同具体工厂之间一一对应。

抽象工厂、抽象产品可以是接口,也可以是抽象类。抽象产品的定义方式取决于产品对象的建模事物,抽象工厂的定义方式一般与抽象产品的定义方式保持一致。

一般情况下,产品对象是对现实世界中的事物进行建模,使用抽象类定义抽象产品更合理。特殊情况下,产品对象对功能组件、功能实现建模或产品对象已有父对象(C#中对象只能有一个父类)时则使用接口定义抽象产品。

其结构图如图所示(使用抽象类):

模式的实现

根据上图写出的该模式的代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70

class Program
{
static void Main(string[] args)
{

Product product1 = new ConcreteFactory1().CreateProduct();
product1.ShowInfo();
Product product2 = new ConcreteFactory2().CreateProduct();
product2.ShowInfo();
Console.ReadKey();
}
}





public abstract class Product
{
public abstract void ShowInfo();
}



public class ConcreteProduct1 : Product
{
public override void ShowInfo()
{
Console.WriteLine("产品类型为Product1");
}
}



public class ConcreteProduct2 : Product
{
public override void ShowInfo()
{
Console.WriteLine("产品类型为Product2");
}
}




public abstract class AbstractFactory
{
public abstract Product CreateProduct();
}



public class ConcreteFactory1 : AbstractFactory
{
public override Product CreateProduct()
{
return new ConcreteProduct1();
}
}



public class ConcreteFactory2 : AbstractFactory
{
public override Product CreateProduct()
{
return new ConcreteProduct2();
}
}

运行结果:

1
2
产品类型为Product1
产品类型为Product2

上述代码,添加新类型的产品,需要新增新产品类和新产品工厂类,工厂父类AbstractFactory不需要修改,这样对于已有的工厂不会产生任何潜在的改动影响——便于扩展。
这种方式和直接new ConcreteProduct1()、new ConcreteProduct2()有点像,只不过由每一种Product自己的工厂类复杂new操作,主要原因如下:

  • new一个Product出来,可能有很多字段都需要赋值,还要运行一些初始化方法。如果这些赋值、方法在客户client类里面写,那么其他所有客户都要写这些代码,代码重复。如果这些赋值、方法写在产品类的构造函数里面,要干的事情特别多,几十行上百行的代码,全放构造函数里面,有点违背设计原则,在构造函数做太复杂的操作,当出错时发现错误有时会很困难。构造函数应该尽量简单,一眼望穿,最好能保证永不出现构造失败的情况。
  • 如果ConcreteProduct1多了一个子类ConcreteProduct1Child,现在生产产品时返回这个类的对象,那么所有客户端的new ConcreteProduct1,都要换成new ConcreteProduct1Child,而如果做成工厂模式,直接在返回ConcreteProduct1的代码哪里更改一下返回ConcreteProduct1Child类的对象就可以了,反正返回的都是Product1(抽象父类)——方便维护
  • 如果所有的产品类,在返回对象之前,又要添加新的逻辑了,那么需要一个个类的找,修改,如果全集中在工厂类中,直接在工厂类中修改即可,避免遗漏,还是——方便维护

如果返回一个实例要做很多事情,不好直接写在构造函数里面,可以写在具体的工厂类里面,而且如果工厂父类要添加新的逻辑,所有工厂同时享有。所以工厂模式主要是有代码重用,分割职责解耦,便于维护的特点。

工厂方法模式通常适用于以下场景:

  • 客户只知道创建产品的工厂名,而不知道具体的产品名。如 TCL 电视工厂、海信电视工厂等。
  • 创建对象的任务由多个具体子工厂中的某一个完成,而抽象工厂只提供创建产品的接口。
  • 客户不关心创建产品的细节,只关心产品的品牌。

当需要生成的产品不多且不会增加,一个具体工厂类就可以完成任务时,可删除抽象工厂类。这时工厂方法模式将退化到简单工厂模式,其结构图如图所示:

在上面的实现代码上增加简单工厂方法的实现,代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

public class SimpleFactory
{
public static Product CreateProduct(string name)
{
Product product = null;
if (name == "ConcreteProduct1")
{
product = new ConcreteProduct1();
}
else if (name == "ConcreteProduct2")
{
product = new ConcreteProduct2();
}
return product;
}
}


public class ReflectionSimpleFactory
{

public static Product CreateProduct(string name)
{

Assembly ass = Assembly.GetCallingAssembly();

AssemblyName assName = new AssemblyName(ass.FullName);

Type t = ass.GetType(assName.Name+"."+name);

Product o = (Product)Activator.CreateInstance(t);
return o;
}
}

C#工厂模式——简单工厂、工厂方法、反射+简单工厂、抽象工厂——CSDN

在软件开发过程中有时需要创建一个复杂的对象,这个复杂对象通常由多个子部件按一定的步骤组合而成(如计算机、角色模型),只有建造者模式可以很好地描述该类产品的创建

建造者(Builder)模式的定义:指将一个复杂对象的构造与它的表示分离,使同样的构建过程可以创建不同的表示,这样的设计模式被称为建造者模式。

它是将一个复杂的对象分解为多个简单的对象,然后一步一步构建而成。它将变与不变相分离,即产品的组成部分是不变的,但每一部分是可以灵活选择的。

该模式的主要优点如下:

  • 各个具体的建造者相互独立,有利于系统的扩展。
  • 客户端不必知道产品内部组成的细节,便于控制细节风险。

其缺点如下:

  • 产品的组成部分必须相同,这限制了其使用范围。
  • 如果产品的内部变化复杂,该模式会增加很多的建造者类

建造者(Builder)模式和工厂模式的关注点不同:建造者模式注重零部件的组装过程,而工厂方法模式更注重零部件的创建过程,但两者可以结合使用

建造者(Builder)模式由产品、抽象建造者、具体建造者、指挥者等 4 个要素构成

模式的结构

建造者(Builder)模式的主要角色如下:

  • 产品角色(Product):它是包含多个组成部件的复杂对象,由具体建造者来创建其各个零部件
  • 抽象建造者(Builder):它是一个包含创建产品各个子部件的抽象方法的接口,通常还包含一个返回复杂产品的方法**GetResult()**。
  • 具体建造者(Concrete Builder)实现Builder接口,完成复杂产品的各个部件的具体创建方法。
  • 指挥者(Director):它调用建造者对象中的部件构造与装配方法完成复杂对象的创建,在指挥者中不涉及具体产品的信息

其简单结构图如图所示(来自GOF):

其详细结构图如图所示(Part部分可以定义任意个):

1
2
3
4
5
6
7
8
可以代入下面的情景理解:
将访问类看做买房子的客户
将产品看做房子
将指挥者看做建筑商
将抽象建造者看做建房的通用流程
将具体建造者1看做户型1的施工队
将具体建造者2看做户型2的施工队
客户买房子,建筑商会根据客户需求安排对应户型的施工队键房。

模式的实现

上图给出了建造者(Builder)模式的主要结构,其相关类的代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86

public class Product
{
private String partA;
private String partB;
private String partC;
public void SetPartA(String partA)
{
this.partA=partA;
}
public void SetPartB(String partB)
{
this.partB=partB;
}
public void SetPartC(String partC)
{
this.partC=partC;
}
public void Show()
{

}
}


public abstract class Builder
{

protected Product product=new Product();
public abstract void BuildPartA();
public abstract void BuildPartB();
public abstract void BuildPartC();

public Product GetResult()
{
return product;
}
}


public class ConcreteBuilder1 : Builder
{
public void BuildPartA()
{
product.SetPartA("建造 PartA");
}
public void BuildPartB()
{
product.SetPartA("建造 PartB");
}
public void BuildPartC()
{
product.SetPartA("建造 PartC");
}
}


public class Director
{
private Builder builder;
public Director(Builder builder)
{
this.builder=builder;
}

public Product Construct()
{
builder.BuildPartA();
builder.BuildPartB();
builder.BuildPartC();
return builder.GetResult();
}
}


class Program
{
static void Main(string[] args)
{
Builder builder=new ConcreteBuilder1();
Director director=new Director(builder);
Product product=director.Construct();
product.Show();
Console.ReadKey();
}
}

建造者(Builder)模式创建的是复杂对象,其产品的各个部分经常面临着剧烈的变化,但将它们组合在一起的算法却相对稳定,所以它通常在以下场合使用:

  • 创建的对象较复杂,由多个部件构成,各部件面临着复杂的变化,但构件间的建造顺序是稳定的
  • 创建复杂对象的算法独立于该对象的组成部分以及它们的装配方式,即产品的构建过程和最终的表示是独立的

建造者(Builder)模式在应用过程中可以根据需要改变,如果创建的产品种类只有一种,只需要一个具体建造者,这时可以省略掉抽象建造者,甚至可以省略掉指挥者角色

前面介绍的工厂方法模式中考虑的是一类产品的生产,如畜牧场只养动物、电视机厂只生产电视机、计算机软件学院只培养计算机软件专业的学生等。

同种类称为同等级,也就是说:工厂方法模式只考虑生产同等级的产品,但是在现实生活中许多工厂是综合型的工厂,能生产多等级(种类) 的产品,如农场里既养动物又种植物,电器厂既生产电视机又生产洗衣机或空调,大学既有软件专业又有生物专业等。

抽象工厂模式将考虑多等级产品的生产,将同一个具体工厂所生产的位于不同等级的一组产品称为一个产品族,下图所示的是海尔工厂和 TCL 工厂所生产的电视机与空调对应的关系图:

抽象工厂(AbstractFactory)模式的定义:是一种为访问类提供一个创建一组相关或相互依赖对象的接口,且访问类无须指定所要产品的具体类就能得到同族的不同等级的产品的模式结构

抽象工厂模式是工厂方法模式的升级版本,工厂方法模式只生产一个等级的产品,而抽象工厂模式可生产多个等级的产品

使用抽象工厂模式一般要满足以下条件:

  • 系统中有多个产品族,每个具体工厂创建同一族但属于不同等级结构的产品
  • 系统一次只可能消费其中某一族产品,即同族的产品一起使用

抽象工厂模式除了具有工厂方法模式的优点外,其他主要优点如下:

  • 可以在工厂类的内部对产品族中相关联的多等级产品共同管理,而不必专门引入多个新的类来进行管理。
  • 当增加一个新的产品族时不需要修改原代码,满足开闭原则。

其缺点是:当产品族中需要增加一个新的产品时,所有的工厂类都需要进行修改

抽象工厂模式同工厂方法模式一样,也是由抽象工厂、具体工厂、抽象产品和具体产品等 4 个要素构成,但抽象工厂中方法个数不同,抽象产品的个数也不同

模式的结构

抽象工厂模式的主要角色如下:

  • 抽象工厂(Abstract Factory):提供了创建产品的接口,它包含多个创建产品的方法CreateProduct(),可以创建多个不同等级的产品
  • 具体工厂(Concrete Factory):主要是实现抽象工厂中的多个抽象方法,完成具体产品的创建。
  • 抽象产品(Product):定义了产品的规范,描述了产品的主要特性和功能,抽象工厂模式有多个抽象产品
  • 具体产品(ConcreteProduct):实现了抽象产品角色所定义的接口,由具体工厂来创建,它同具体工厂之间是多对一的关系

注:抽象工厂、抽象产品的定义推荐使用抽象类,GOF中也是使用的抽象类。

抽象工厂模式的简化结构图如图所示(来自GOF):

抽象工厂模式的详细结构图如图所示(1、2代表产品族,如海尔、TCL等;A、B代表产品等级,如电视机、空调等):

模式的实现

参考工厂方法的代码实现,增加多个具体工厂、多个抽象产品,部分代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22



public abstract class AbstractFactory
{
public abstract ProductA CreatProduct();
public abstract ProductB CreatProduct();
}



public class ConcreteFactoryA1 : AbstractFactory
{
public override ProductA CreatProduct()
{
return new ConcreteProductA1();
}
public override ProductB CreatProduct()
{
return new ConcreteProductB1();
}
}

抽象工厂模式最早的应用是用于创建属于不同操作系统的视窗构件。如 java 的 AWT 中的 Button 和 Text 等构件在 Windows 和 UNIX 中的本地实现是不同的。

抽象工厂模式通常适用于以下场景:

  • 当需要创建的对象是一系列相互关联或相互依赖的产品族时,如电器工厂中的电视机、洗衣机、空调等。
  • 系统中有多个产品族,但每次只使用其中的某一族产品。如有人只喜欢穿某一个品牌的衣服和鞋。
  • 系统中提供了产品的类库,且所有产品的接口相同,客户端不依赖产品实例的创建细节和内部结构。

抽象工厂模式的扩展有一定的“开闭原则”倾斜性:

  • 当增加一个新的产品族时只需增加一个新的具体工厂,不需要修改原代码,满足开闭原则。
  • 当产品族中需要增加一个新种类的产品时,则所有的工厂类都需要进行修改,不满足开闭原则。

另一方面,当系统中只存在一个等级结构的产品时,抽象工厂模式将退化到工厂方法模式

C#工厂模式——简单工厂、工厂方法、反射+简单工厂、抽象工厂——CSDN

一、引言

最近在设计模式的一些内容,主要的参考书籍是《Head First 设计模式》,同时在学习过程中也查看了很多博客园中关于设计模式的一些文章的,在这里记录下我的一些学习笔记,一是为了帮助我更深入地理解设计模式,二同时可以给一些初学设计模式的朋友一些参考。首先我介绍的是设计模式中比较简单的一个模式——单例模式(因为这里只牵涉到一个类)

二、单例模式的介绍

说到单例模式,大家第一反应应该就是——什么是单例模式?,从“单例”字面意思上理解为——一个类只有一个实例,所以单例模式也就是保证一个类只有一个实例的一种实现方法罢了(设计模式其实就是帮助我们解决实际开发过程中的方法, 该方法是为了降低对象之间的耦合度,然而解决方法有很多种,所以前人就总结了一些常用的解决方法为书籍,从而把这本书就称为设计模式),下面给出单例模式的一个官方定义:确保一个类只有一个实例,并提供一个全局访问点。为了帮助大家更好地理解单例模式,大家可以结合下面的类图来进行理解,以及后面也会剖析单例模式的实现思路:

三、为什么会有单例模式

看完单例模式的介绍,自然大家都会有这样一个疑问——为什么要有单例模式的?它在什么情况下使用的?从单例模式的定义中我们可以看出——单例模式的使用自然是当我们的系统中某个对象只需要一个实例的情况,例如:操作系统中只能有一个任务管理器,操作文件时,同一时间内只允许一个实例对其操作等,既然现实生活中有这样的应用场景,自然在软件设计领域必须有这样的解决方案了(因为软件设计也是现实生活中的抽象),所以也就有了单例模式了。

四、剖析单例模式的实现思路

了解完了一些关于单例模式的基本概念之后,下面就为大家剖析单例模式的实现思路的,因为在我自己学习单例模式的时候,咋一看单例模式的实现代码确实很简单,也很容易看懂,但是我还是觉得它很陌生(这个可能是看的少的,或者自己在写代码中也用的少的缘故),而且心里总会这样一个疑问——为什么前人会这样去实现单例模式的呢?他们是如何思考的呢?后面经过自己的琢磨也就慢慢理清楚单例模式的实现思路了,并且此时也不再觉得单例模式陌生了,下面就分享我的一个剖析过程的:

我们从单例模式的概念(确保一个类只有一个实例,并提供一个访问它的全局访问点)入手,可以把概念进行拆分为两部分:(1)确保一个类只有一个实例;(2)提供一个访问它的全局访问点;下面通过采用两人对话的方式来帮助大家更快掌握分析思路:

菜鸟:怎样确保一个类只有一个实例了?

老鸟:那就让我帮你分析下,你创建类的实例会想到用什么方式来创建的呢?

新手:用new关键字啊,只要new下就创建了该类的一个实例了,之后就可以使用该类的一些属性和实例方法了

老鸟:那你想过为什么可以使用new关键字来创建类的实例吗?

菜鸟:这个还有条件的吗?………, 哦,我想起来了,如果类定义私有的构造函数就不能在外界通过new创建实例了(注:有些初学者就会问,有时候我并没有在类中定义构造函数为什么也可以使用new来创建对象,那是因为编译器在背后做了手脚了,当编译器看到我们类中没有定义构造函数,此时编译器会帮我们生成一个公有的无参构造函数)

老鸟:不错,回答的很对,这样你的疑惑就得到解答了啊

菜鸟:那我要在哪里创建类的实例了?

老鸟:你傻啊,当然是在类里面创建了(注:这样定义私有构造函数就是上面的一个思考过程的,要创建实例,自然就要有一个变量来保存该实例把,所以就有了私有变量的声明,但是实现中是定义静态私有变量,朋友们有没有想过——这里为什么定义为静态的呢?对于这个疑问的解释为:每个线程都有自己的线程栈,定义为静态主要是为了在多线程确保类有一个实例

菜鸟:哦,现在完全明白了,但是我还有另一个疑问——现在类实例创建在类内部,那外界如何获得该的一个实例来使用它了?

老鸟:这个,你可以定义一个公有方法或者属性来把该类的实例公开出去了(注:这样就有了公有方法的定义了,该方法就是提供方法问类的全局访问点)

通过上面的分析,相信大家也就很容易写出单例模式的实现代码了,下面就看看具体的实现代码(看完之后你会惊讶道:真是这样的!):

复制代码

///


/// 单例模式的实现 ///

public class Singleton
{ // 定义一个静态变量来保存类的实例
private static Singleton uniqueInstance; // 定义私有构造函数,使外界不能创建该类实例
private Singleton()
{
} ///
/// 定义公有方法提供一个全局访问点,同时你也可以定义公有属性来提供全局访问点 ///

///
public static Singleton GetInstance()
{ // 如果类的实例不存在则创建,否则直接返回
if (uniqueInstance == null)
{
uniqueInstance = new Singleton();
} return uniqueInstance;
}
}

复制代码

 上面的单例模式的实现在单线程下确实是完美的,然而在多线程的情况下会得到多个Singleton实例,因为在两个线程同时运行GetInstance方法时,此时两个线程判断(uniqueInstance ==null)这个条件时都返回真,此时两个线程就都会创建Singleton的实例,这样就违背了我们单例模式初衷了,既然上面的实现会运行多个线程执行,那我们对于多线程的解决方案自然就是使GetInstance方法在同一时间只运行一个线程运行就好了,也就是我们线程同步的问题了(对于线程同步大家也可以参考我线程同步的文章),具体的解决多线程的代码如下:

复制代码

///


/// 单例模式的实现 ///

public class Singleton
{ // 定义一个静态变量来保存类的实例
private static Singleton uniqueInstance; // 定义一个标识确保线程同步
private static readonly object locker = new object(); // 定义私有构造函数,使外界不能创建该类实例
private Singleton()
{
} ///
/// 定义公有方法提供一个全局访问点,同时你也可以定义公有属性来提供全局访问点 ///

///
public static Singleton GetInstance()
{ // 当第一个线程运行到这里时,此时会对locker对象 “加锁”, // 当第二个线程运行该方法时,首先检测到locker对象为”加锁”状态,该线程就会挂起等待第一个线程解锁 // lock语句运行完之后(即线程运行完之后)会对该对象”解锁”
lock (locker)
{ // 如果类的实例不存在则创建,否则直接返回
if (uniqueInstance == null)
{
uniqueInstance = new Singleton();
}
} return uniqueInstance;
}
}

复制代码

上面这种解决方案确实可以解决多线程的问题,但是上面代码对于每个线程都会对线程辅助对象locker加锁之后再判断实例是否存在,对于这个操作完全没有必要的,因为当第一个线程创建了该类的实例之后,后面的线程此时只需要直接判断(uniqueInstance==null)为假,此时完全没必要对线程辅助对象加锁之后再去判断,所以上面的实现方式增加了额外的开销,损失了性能,为了改进上面实现方式的缺陷,我们只需要在lock语句前面加一句(uniqueInstance==null)的判断就可以避免锁所增加的额外开销,这种实现方式我们就叫它 “双重锁定”,下面具体看看实现代码的:

复制代码

///


/// 单例模式的实现 ///

public class Singleton
{ // 定义一个静态变量来保存类的实例
private static Singleton uniqueInstance; // 定义一个标识确保线程同步
private static readonly object locker = new object(); // 定义私有构造函数,使外界不能创建该类实例
private Singleton()
{
} ///
/// 定义公有方法提供一个全局访问点,同时你也可以定义公有属性来提供全局访问点 ///

///
public static Singleton GetInstance()
{ // 当第一个线程运行到这里时,此时会对locker对象 “加锁”, // 当第二个线程运行该方法时,首先检测到locker对象为”加锁”状态,该线程就会挂起等待第一个线程解锁 // lock语句运行完之后(即线程运行完之后)会对该对象”解锁” // 双重锁定只需要一句判断就可以了
if (uniqueInstance == null)
{ lock (locker)
{ // 如果类的实例不存在则创建,否则直接返回
if (uniqueInstance == null)
{
uniqueInstance = new Singleton();
}
}
} return uniqueInstance;
}
}

复制代码

五、C#中实现了单例模式的类

 理解完了单例模式之后,菜鸟又接着问了:.NET FrameWork类库中有没有单例模式的实现呢?

经过查看,.NET类库中确实存在单例模式的实现类,不过该类不是公开的,下面就具体看看该类的一个实现的(该类具体存在于System.dll程序集,命名空间为System,大家可以用反射工具Reflector去查看源码的):

复制代码

// 该类不是一个公开类 // 但是该类的实现应用了单例模式
internal sealed class SR
{ private static SR loader; internal SR()
{
} // 主要是因为该类不是公有,所以这个全部访问点也定义为私有的了 // 但是思想还是用到了单例模式的思想的
private static SR GetLoader()
{ if (loader == null)
{
SR sr = new SR();
Interlocked.CompareExchange(ref loader, sr, null);
} return loader;
} // 这个公有方法中调用了GetLoader方法的
public static object GetObject(string name)
{
SR loader = GetLoader(); if (loader == null)
{ return null;
} return loader.resources.GetObject(name, Culture);
}
}

复制代码

六、总结

到这里,设计模式的单例模式就介绍完了,希望通过本文章大家可以对单例模式有一个更深的理解,并且希望之前没接触过单例模式或觉得单例模式陌生的朋友看完之后会惊叹:原来如此!

一、引言

在上一专题中介绍了工厂方法模式,工厂方法模式是为了克服简单工厂模式的缺点而设计出来的,简单工厂模式的工厂类随着产品类的增加需要增加额外的代码),而工厂方法模式每个具体工厂类只完成单个实例的创建,所以它具有很好的可扩展性。但是在现实生活中,一个工厂只创建单个产品这样的例子很少,因为现在的工厂都多元化了,一个工厂创建一系列的产品,如果我们要设计这样的系统时,工厂方法模式显然在这里不适用,然后抽象工厂模式却可以很好地解决一系列产品创建的问题,这是本专题所要介绍的内容。

二、抽象工厂详细介绍

这里首先以一个生活中抽象工厂的例子来实现一个抽象工厂,然后再给出抽象工厂的定义和UML图来帮助大家更好地掌握抽象工厂模式,同时大家在理解的时候,可以对照抽象工厂生活中例子的实现和它的定义来加深抽象工厂的UML图理解。

2.1 抽象工厂的具体实现

下面就以生活中 “绝味” 连锁店的例子来实现一个抽象工厂模式。例如,绝味鸭脖想在江西南昌和上海开分店,但是由于当地人的口味不一样,在南昌的所有绝味的东西会做的辣一点,而上海不喜欢吃辣的,所以上海的所有绝味的东西都不会做的像南昌的那样辣,然而这点不同导致南昌绝味工厂和上海的绝味工厂生成所有绝味的产品都不同,也就是某个具体工厂需要负责一系列产品(指的是绝味所有食物)的创建工作,下面就具体看看如何使用抽象工厂模式来实现这种情况。

复制代码

1 ///


2 /// 下面以绝味鸭脖连锁店为例子演示下抽象工厂模式 3 /// 因为每个地方的喜欢的口味不一样,有些地方喜欢辣点的,有些地方喜欢吃不辣点 4 /// 客户端调用 5 ///

6 class Client 7 {
8 static void Main(string[] args)
9 {
10 // 南昌工厂制作南昌的鸭脖和鸭架
11 AbstractFactory nanChangFactory = new NanChangFactory(); 12 YaBo nanChangYabo = nanChangFactory.CreateYaBo(); 13 nanChangYabo.Print();
14 YaJia nanChangYajia= nanChangFactory.CreateYaJia(); 15 nanChangYajia.Print();
16
17 // 上海工厂制作上海的鸭脖和鸭架
18 AbstractFactory shangHaiFactory = new ShangHaiFactory(); 19 shangHaiFactory.CreateYaBo().Print();
20 shangHaiFactory.CreateYaJia().Print();
21
22 Console.Read();
23 }
24 }
25
26 ///
27 /// 抽象工厂类,提供创建两个不同地方的鸭架和鸭脖的接口 28 ///

29 public abstract class AbstractFactory 30 {
31 // 抽象工厂提供创建一系列产品的接口,这里作为例子,只给出了绝味中鸭脖和鸭架的创建接口
32 public abstract YaBo CreateYaBo(); 33 public abstract YaJia CreateYaJia(); 34 }
35
36 ///
37 /// 南昌绝味工厂负责制作南昌的鸭脖和鸭架 38 ///

39 public class NanChangFactory : AbstractFactory 40 {
41 // 制作南昌鸭脖
42 public override YaBo CreateYaBo() 43 {
44 return new NanChangYaBo(); 45 }
46 // 制作南昌鸭架
47 public override YaJia CreateYaJia() 48 {
49 return new NanChangYaJia(); 50 }
51 }
52
53 ///
54 /// 上海绝味工厂负责制作上海的鸭脖和鸭架 55 ///

56 public class ShangHaiFactory : AbstractFactory 57 {
58 // 制作上海鸭脖
59 public override YaBo CreateYaBo() 60 {
61 return new ShangHaiYaBo(); 62 }
63 // 制作上海鸭架
64 public override YaJia CreateYaJia() 65 {
66 return new ShangHaiYaJia(); 67 }
68 }
69
70 ///
71 /// 鸭脖抽象类,供每个地方的鸭脖类继承 72 ///

73 public abstract class YaBo 74 {
75 ///
76 /// 打印方法,用于输出信息 77 ///

78 public abstract void Print(); 79 }
80
81 ///
82 /// 鸭架抽象类,供每个地方的鸭架类继承 83 ///

84 public abstract class YaJia 85 {
86 ///
87 /// 打印方法,用于输出信息 88 ///

89 public abstract void Print(); 90 }
91
92 ///
93 /// 南昌的鸭脖类,因为江西人喜欢吃辣的,所以南昌的鸭脖稍微会比上海做的辣 94 ///

95 public class NanChangYaBo : YaBo 96 {
97 public override void Print() 98 {
99 Console.WriteLine(“南昌的鸭脖”); 100 } 101 } 102
103 ///
104 /// 上海的鸭脖没有南昌的鸭脖做的辣 105 ///

106 public class ShangHaiYaBo : YaBo 107 { 108 public override void Print() 109 { 110 Console.WriteLine(“上海的鸭脖”); 111 } 112 } 113
114 ///
115 /// 南昌的鸭架 116 ///

117 public class NanChangYaJia : YaJia 118 { 119 public override void Print() 120 { 121 Console.WriteLine(“南昌的鸭架子”); 122 } 123 } 124
125 ///
126 /// 上海的鸭架 127 ///

128 public class ShangHaiYaJia : YaJia 129 { 130 public override void Print() 131 { 132 Console.WriteLine(“上海的鸭架子”); 133 } 134 }

复制代码

2.2 抽象工厂模式的定义和类图

上面代码中都有详细的注释,这里就不再解释上面的代码了,下面就具体看看抽象工厂模式的定义吧(理解定义可以参考上面的实现来加深理解):

抽象工厂模式:提供一个创建产品的接口来负责创建相关或依赖的对象,而不具体明确指定具体类

抽象工厂允许客户使用抽象的接口来创建一组相关产品,而不需要知道或关心实际生产出的具体产品是什么。这样客户就可以从具体产品中被解耦。下面通过抽象工模式的类图来了解各个类中之间的关系:

2.3 抽象工厂应对需求变更

看完上面抽象工厂的实现之后,如果 “绝味”公司又想在湖南开一家分店怎么办呢? 因为湖南人喜欢吃麻辣的,下面就具体看看应用了抽象工厂模式的系统是如何应对这种需求的。

复制代码

///


/// 如果绝味又想开一家湖南的分店时,因为湖南喜欢吃麻的 /// 所以这是有需要有一家湖南的工厂专门制作 ///

public class HuNanFactory : AbstractFactory
{ // 制作湖南鸭脖
public override YaBo CreateYaBo()
{ return new HuNanYaBo();
} // 制作湖南鸭架
public override YaJia CreateYaJia()
{ return new HuNanYajia();
}
} ///
/// 湖南的鸭脖 ///

public class HuNanYaBo : YaBo
{ public override void Print()
{
Console.WriteLine(“湖南的鸭脖”);
}
} ///
/// 湖南的鸭架 ///

public class HuNanYajia : YaJia
{ public override void Print()
{
Console.WriteLine(“湖南的鸭架子”);
}
}

复制代码

此时,只需要添加三个类:一个是湖南具体工厂类,负责创建湖南口味的鸭脖和鸭架,另外两个类是具有湖南口味的鸭脖类和鸭架类。从上面代码看出,抽象工厂对于系列产品的变化支持 “开放——封闭”原则(指的是要求系统对扩展开放,对修改封闭),扩展起来非常简便,但是,抽象工厂对于添加新产品这种情况就不支持”开放——封闭 “原则,这也是抽象工厂的缺点所在,这点会在第四部分详细介绍。

三、抽象工厂的分析

抽象工厂模式将具体产品的创建延迟到具体工厂的子类中,这样将对象的创建封装起来,可以减少客户端与具体产品类之间的依赖,从而使系统耦合度低,这样更有利于后期的维护和扩展,这真是抽象工厂模式的优点所在,然后抽象模式同时也存在不足的地方。下面就具体看下抽象工厂的缺点(缺点其实在前面的介绍中以已经涉及了):

抽象工厂模式很难支持新种类产品的变化。这是因为抽象工厂接口中已经确定了可以被创建的产品集合,如果需要添加新产品,此时就必须去修改抽象工厂的接口,这样就涉及到抽象工厂类的以及所有子类的改变,这样也就违背了“开发——封闭”原则。

知道了抽象工厂的优缺点之后,也就能很好地把握什么情况下考虑使用抽象工厂模式了,下面就具体看看使用抽象工厂模式的系统应该符合那几个前提:

  • 一个系统不要求依赖产品类实例如何被创建、组合和表达的表达,这点也是所有工厂模式应用的前提。
  • 这个系统有多个系列产品,而系统中只消费其中某一系列产品
  • 系统要求提供一个产品类的库,所有产品以同样的接口出现,客户端不需要依赖具体实现。

四、.NET中抽象工厂模式实现

抽象工厂模式在实际中的应用也是相当频繁的,然而在我们.NET类库中也存在应用抽象工厂模式的类,这个类就是System.Data.Common.DbProviderFactory,这个类位于System.Data.dll程序集中,该类扮演抽象工厂模式中抽象工厂的角色,我们可以用reflector反编译工具查看该类的实现:

复制代码

/// 扮演抽象工厂的角色
/// 创建连接数据库时所需要的对象集合,
/// 这个对象集合包括有 DbConnection对象(这个是抽象产品类,如绝味例子中的YaBo类)、DbCommand类、DbDataAdapter类,针对不同的具体工厂都需要实现该抽象类中方法,public abstract class DbProviderFactory
{ // 提供了创建具体产品的接口方法
protected DbProviderFactory(); public virtual DbCommand CreateCommand(); public virtual DbCommandBuilder CreateCommandBuilder(); public virtual DbConnection CreateConnection(); public virtual DbConnectionStringBuilder CreateConnectionStringBuilder(); public virtual DbDataAdapter CreateDataAdapter(); public virtual DbDataSourceEnumerator CreateDataSourceEnumerator(); public virtual DbParameter CreateParameter(); public virtual CodeAccessPermission CreatePermission(PermissionState state);
}

复制代码

DbProviderFactory类是一个抽象工厂类,该类提供了创建数据库连接时所需要的对象集合的接口,实际创建的工作在其子类工厂中进行,微软使用的是SQL Server数据库,因此提供了连接SQL Server数据的具体工厂实现,具体代码可以用反编译工具查看,具体代码如下:

复制代码

/// 扮演着具体工厂的角色,用来创建连接SQL Server数据所需要的对象
public sealed class SqlClientFactory : DbProviderFactory, IServiceProvider
{ // Fields
public static readonly SqlClientFactory Instance = new SqlClientFactory(); // 构造函数
private SqlClientFactory()
{
} // 重写抽象工厂中的方法
public override DbCommand CreateCommand()
{ // 创建具体产品
return new SqlCommand();
} public override DbCommandBuilder CreateCommandBuilder()
{ return new SqlCommandBuilder();
} public override DbConnection CreateConnection()
{ return new SqlConnection();
} public override DbConnectionStringBuilder CreateConnectionStringBuilder()
{ return new SqlConnectionStringBuilder();
} public override DbDataAdapter CreateDataAdapter()
{ return new SqlDataAdapter();
} public override DbDataSourceEnumerator CreateDataSourceEnumerator()
{ return SqlDataSourceEnumerator.Instance;
} public override DbParameter CreateParameter()
{ return new SqlParameter();
} public override CodeAccessPermission CreatePermission(PermissionState state)
{ return new SqlClientPermission(state);
}
}

复制代码

因为微软只给出了连接SQL Server的具体工厂的实现,我们也可以自定义连接Oracle、MySql的具体工厂的实现。

五、总结

到这里,抽象工厂模式的介绍就结束,在下一专题就将为大家介绍建造模式。

程序源码:抽象工厂模式实现

在面向对象程序设计过程中,有时会面临要创建大量相同或相似对象实例的问题。创建那么多的对象将会耗费很多的系统资源,它是系统性能提高的一个瓶颈。例如,围棋和五子棋中的黑白棋子,图像中的坐标点或颜色,局域网中的路由器、交换机和集线器,教室里的桌子和凳子等。这些对象有很多相似的地方,如果能把它们相同的部分提取出来共享,则能节省大量的系统资源,这就是享元模式的产生背景。

享元(Flyweight)模式的定义:运用共享技术来有效地支持大量细粒度对象的复用。它通过共享已经存在的对象来大幅度减少需要创建的对象数量、避免大量相似类的开销,从而提高系统资源的利用率。

享元模式的主要优点是:相同对象只要保存一份,这降低了系统中对象的数量,从而降低了系统中细粒度对象给内存带来的压力。

其主要缺点是:

  • 为了使对象可以共享,需要将一些不能共享的状态外部化,这将增加程序的复杂性。
  • 读取享元模式的外部状态会使得运行时间稍微变长。

享元模式中存在以下两种状态:

  • 内部状态,即不会随着环境的改变而改变的可共享部分。
  • 外部状态,指随环境改变而改变的不可以共享的部分。享元模式的实现要领就是区分应用中的这两种状态,并将外部状态外部化。

模式的结构#

享元模式的主要角色有如下:

  • 抽象享元角色(Flyweight):是所有的具体享元类的基类,为具体享元规范需要实现的公共接口,非享元的外部状态以参数的形式通过方法传入。
  • 具体享元(Concrete Flyweight)角色:实现抽象享元角色中所规定的接口。
  • 非享元(Unsharable Flyweight)角色:是不可以共享的外部状态,它以参数的形式注入具体享元的相关方法中
  • 享元工厂(Flyweight Factory)角色:负责创建和管理享元角色。当客户对象请求一个享元对象时,享元工厂检査系统中是否存在符合要求的享元对象,如果存在则提供给客户;如果不存在的话,则创建一个新的享元对象。

下图是享元模式的结构图。图中的 UnsharedConcreteFlyweight 是非享元角色,里面包含了非共享的外部状态信息 info;而 Flyweight 是抽象享元角色,里面包含了享元方法 operation(UnsharedConcreteFlyweight state),非享元的外部状态以参数的形式通过该方法传入;ConcreteFlyweight 是具体享元角色,包含了关键字 key,它实现了抽象享元接口;FlyweightFactory 是享元工厂角色,它逝关键字 key 来管理具体享元;客户角色通过享元工厂获取具体享元,并访问具体享元的相关方法。

模式的实现#

享元模式的实现代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
class Program
{
static void Main(string[] args)
{
FlyweightFactory factory=new FlyweightFactory();
IFlyweight f01=factory.GetFlyweight("a");
IFlyweight f02=factory.GetFlyweight("a");
IFlyweight f03=factory.GetFlyweight("a");
IFlyweight f11=factory.GetFlyweight("b");
IFlyweight f12=factory.GetFlyweight("b");
f01.Operation(new UnsharedConcreteFlyweight("第1次调用a。"));
f02.Operation(new UnsharedConcreteFlyweight("第2次调用a。"));
f03.Operation(new UnsharedConcreteFlyweight("第3次调用a。"));
f11.Operation(new UnsharedConcreteFlyweight("第1次调用b。"));
f12.Operation(new UnsharedConcreteFlyweight("第2次调用b。"));
Console.ReadLine();
}
}


public class UnsharedConcreteFlyweight
{
private String info;
public UnsharedConcreteFlyweight(String info)
{
this.info=info;
}
public String GetInfo()
{
return info;
}
public void SetInfo(String info)
{
this.info=info;
}
}


public interface IFlyweight
{
void Operation(UnsharedConcreteFlyweight state);
}


public class ConcreteFlyweight : IFlyweight
{
private String key;
public ConcreteFlyweight(String key)
{
this.key=key;
Console.WriteLine("具体享元"+key+"被创建!");
}
public void Operation(UnsharedConcreteFlyweight outState)
{
Console.WriteLine("具体享元"+key+"被调用,");
Console.WriteLine("非享元信息是:" + outState.GetInfo());
}
}


public class FlyweightFactory
{
private Dictionary<String, IFlyweight> flyweights = new Dictionary<String, IFlyweight>();
public IFlyweight GetFlyweight(String key)
{
IFlyweight flyweight;
flyweights.TryGetValue(key,out flyweight);
if(flyweight!=null)
{
Console.WriteLine("具体享元" + key + "已经存在,被成功获取!");
}
else
{
flyweight=new ConcreteFlyweight(key);
flyweights.Add(key, flyweight);
}
return flyweight;
}
}

程序运行结果如下:

1
2
3
4
5
6
7
8
9
10
具体享元a被创建!
具体享元a已经存在,被成功获取!
具体享元a已经存在,被成功获取!
具体享元b被创建!
具体享元b已经存在,被成功获取!
具体享元a被调用,非享元信息是:第1次调用a。
具体享元a被调用,非享元信息是:第2次调用a。
具体享元a被调用,非享元信息是:第3次调用a。
具体享元b被调用,非享元信息是:第1次调用b。
具体享元b被调用,非享元信息是:第2次调用b。

享元模式是通过减少内存中对象的数量来节省内存空间的,所以以下几种情形适合采用享元模式:

  • 系统中存在大量相同或相似的对象,这些对象耗费大量的内存资源。
  • 大部分的对象可以按照内部状态进行分组,且可将不同部分外部化,这样每一个组只需保存一个内部状态。
  • 由于享元模式需要额外维护一个保存享元的数据结构,所以应当在有足够多的享元实例时才值得使用享元模式

在前面介绍的享元模式中,其结构图通常包含可以共享的部分和不可以共享的部分。在实际使用过程中,有时候会稍加改变,即存在两种特殊的享元模式:单纯享元模式和复合享元模式,下面分别对它们进行简单介绍。

  • 单纯享元模式:这种享元模式中的所有的具体享元类都是可以共享的,不存在非共享的具体享元类,其结构图如图所示:

  • 复合享元模式:这种享元模式中的有些享元对象是由一些单纯享元对象组合而成的,它们就是复合享元对象。虽然复合享元对象本身不能共享,但它们可以分解成单纯享元对象再被共享,其结构图如图所示:

在有些情况下,一个客户不能或者不想直接访问另一个对象,这时需要找一个中介帮忙完成某项任务,这个中介就是代理对象。

由于某些原因需要给某对象提供一个代理以控制对该对象的访问。这时,访问对象不适合或者不能直接引用目标对象,代理对象作为访问对象和目标对象之间的中介

主要优点有:

  • 代理模式在客户端与目标对象之间起到一个中介作用和保护目标对象的作用
  • 代理对象可以扩展目标对象的功能
  • 代理模式能将客户端与目标对象分离,在一定程度上降低了系统的耦合度

主要缺点有:

  • 在客户端和目标对象之间增加一个代理对象,会造成请求处理速度变慢
  • 增加了系统的复杂度

代理模式的结构比较简单,主要是通过定义一个继承抽象主题的代理来包含真实主题,从而实现对真实主题的访问。

模式的结构#

代理模式的主要角色如下:

  • 抽象主题(Subject)类:通过接口或抽象类(推荐使用接口)声明真实主题和代理对象实现的业务方法
  • 真实主题(Real Subject)类:实现了抽象主题中的具体业务,是代理对象所代表的真实对象,是最终要引用的对象
  • 代理(Proxy)类:提供了与真实主题相同的接口,其内部含有对真实主题的引用,它可以访问、控制或扩展真实主题的功能

其结构图如图所示:

模式的实现#

代理模式的实现代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

class Program
{
static void Main(string[] args)
{

Proxy proxy=new Proxy();
proxy.Request();
Console.ReadKey();
}
}


public interface ISubject
{
void Request();
}


public class RealSubject :ISubject
{
public void Request()
{
Console.WriteLine("访问真实主题方法...");
}
}


public class Proxy : ISubject
{
private RealSubject realSubject;
public void Request()
{
if (realSubject==null)
{
realSubject=new RealSubject();
}
PreRequest();
realSubject.Request();
PostRequest();
}
public void PreRequest()
{
Console.WriteLine("访问真实主题之前的预处理。");
}
public void PostRequest()
{
Console.WriteLine("访问真实主题之后的后续处理。");
}
}

程序运行的结果如下:

1
2
3
访问真实主题之前的预处理。
访问真实主题方法...
访问真实主题之后的后续处理。

前面分析了代理模式的结构与特点,现在来分析以下的应用场景:

  • 远程代理(Remote Proxy):这种方式通常是为了隐藏目标对象存在于不同地址空间的事实,方便客户端访问。
    例如,用户访问网盘的虚拟硬盘时实际访问的是网盘空间。
  • 虚拟代理(Virtual Proxy):这种方式通常用于要创建的目标对象开销很大时。
    例如,下载一幅很大的图像需要很长时间,这时可以先用小比例的虚拟代理替换真实的对象,消除用户对服务器慢的感觉。
  • 保护代理(Protection Proxy):这种方式通常用于控制不同种类客户对真实对象的访问权限。
  • 智能指引(Smart Reference):主要用于调用目标对象时,代理附加一些额外的处理功能。

智能指引的典型用途包括:

  • 增加计算真实对象的引用次数的功能,这样当该对象没有被引用时,就可以自动释放它;
  • 当第一次引用一个持久对象时,将它装入内存。
  • 在访问一个实际对象前,检查是否已经锁定了它,以确保其他对象不能改变它。

在前面介绍的代理模式中,代理类中包含了对真实主题的引用,这种方式存在两个缺点:

  • 真实主题与代理主题一一对应,增加真实主题也要增加代理
  • 设计代理以前真实主题必须事先存在,不太灵活。

采用动态代理模式可以解决以上问题(如 SpringAOP),C#中可以使用RealProxy实现动态代理,有两种方法:
第一种:只使用RealProxy,不能代理带out参数的方法(可能是我没找到),代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
class Program
{
static void Main(string[] args)
{
Console.WriteLine("***\r\n Begin program - logging with decorator\r\n");
IRepository<Customer> customerRepository =RepositoryFactory.Create<Customer>();
var customer = new Customer()
{
Id = 1,
Name = "Customer 1",
Address = "Address 1"
};
customerRepository.Add(customer);
customerRepository.Update(customer);
customerRepository.Delete(customer);
Console.WriteLine("\r\nEnd program - logging with decorator\r\n***");
Console.ReadLine();
}
}

public class Customer
{
public int Id { get; set; }
public string Name { get; set; }
public string Address { get; set; }
}


public interface IRepository<T>
{
void Add(T entity);
void Delete(T entity);
void Update(T entity);
IEnumerable<T> GetAll();
T GetById(int id);
}


public class Repository<T> : IRepository<T>
{
public void Add(T entity)
{
Console.WriteLine("Adding {0}", entity);
}
public void Delete(T entity)
{
Console.WriteLine("Deleting {0}", entity);
}
public void Update(T entity)
{
Console.WriteLine("Updating {0}", entity);
}
public IEnumerable<T> GetAll()
{
Console.WriteLine("Getting entities");
return null;
}
public T GetById(int id)
{
Console.WriteLine("Getting entity {0}", id);
return default(T);
}
}


class DynamicProxy<T> : RealProxy
{
private readonly T _decorated;
public DynamicProxy(T decorated) : base(typeof(T))
{
_decorated = decorated;
}
private void Log(string msg, object arg = null)
{
Console.ForegroundColor = ConsoleColor.Red;
Console.WriteLine(msg, arg);
Console.ResetColor();
}
public override IMessage Invoke(IMessage msg)
{
var methodCall = msg as IMethodCallMessage;
var methodInfo = methodCall.MethodBase as MethodInfo;
Log("In Dynamic Proxy - Before executing '{0}'",methodCall.MethodName);
try
{
var result = methodInfo.Invoke(_decorated, methodCall.InArgs);
Log("In Dynamic Proxy - After executing '{0}' ",methodCall.MethodName);
return new ReturnMessage(result, null, 0,methodCall.LogicalCallContext, methodCall);
}
catch (Exception e)
{
Log(string.Format("In Dynamic Proxy- Exception {0} executing '{1}'", e),methodCall.MethodName);
return new ReturnMessage(e, methodCall);
}
}
}


public class RepositoryFactory
{
public static IRepository<T> Create<T>()
{
var repository = new Repository<T>();
var dynamicProxy = new DynamicProxy<IRepository<T>>(repository);
return dynamicProxy.GetTransparentProxy() as IRepository<T>;
}
}

第二种:使用RealProxy、MarshalByRefObject,可以代理带out参数的方法,代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

public class Program
{
static void Main(string[] args)
{

Proxy<ISubject> proxy = new Proxy<ISubject>(new RealSubject());
ISubject subject = (ISubject)proxy.GetTransparentProxy();
int arg = 0;
subject.Request(out arg);
Console.WriteLine(arg);
Console.ReadKey();
}
}

public class Proxy<T> : RealProxy where T: class
{
MarshalByRefObject myMarshalByRefObject;
public Proxy(MarshalByRefObject realT) : base(typeof(T))
{
myMarshalByRefObject = realT;
}
public override IMessage Invoke(IMessage myMessage)
{
IMethodCallMessage myCallMessage = (IMethodCallMessage)myMessage;
Console.WriteLine("动态代理方法中:执行前");
IMethodReturnMessage myIMethodReturnMessage = RemotingServices.ExecuteMessage(myMarshalByRefObject, myCallMessage);
Console.WriteLine("动态代理方法中:执行后");
return myIMethodReturnMessage;
}
}


public interface ISubject
{
void Request(out int arg);
}


public class RealSubject : MarshalByRefObject,ISubject
{
public void Request(out int arg)
{
arg = 1;
Console.WriteLine("访问真实主题方法...");
}
}

C#中动态代理与泛型函数——CSDN
面向方面的编程-使用 RealProxy 类进行面向方面的编程——MSDN

在现实生活中,常常存在办事较复杂的例子,如办房产证或注册一家公司,有时要同多个部门联系,这时要是有一个综合部门能解决一切手续问题就好了。

软件设计也是这样,当一个系统的功能越来越强,子系统会越来越多,客户对系统的访问也变得越来越复杂。这时如果系统内部发生改变,客户端也要跟着改变,这违背了“开闭原则”,也违背了“迪米特法则”,所以有必要为多个子系统提供一个统一的接口,从而降低系统的耦合度,这就是外观模式的目标。

客户去当地房产局办理房产证过户要遇到的相关部门:

外观(Facade)模式的定义:是一种通过为多个复杂的子系统提供一个一致的接口,而使这些子系统更加容易被访问的模式。该模式对外有一个统一接口,外部应用程序不用关心内部子系统的具体的细节,这样会大大降低应用程序的复杂度,提高了程序的可维护性。

外观(Facade)模式是“迪米特法则”的典型应用,它有以下主要优点:

  • 降低了子系统与客户端之间的耦合度,使得子系统的变化不会影响调用它的客户类。
  • 对客户屏蔽了子系统组件,减少了客户处理的对象数目,并使得子系统使用起来更加容易。
  • 降低了大型软件系统中的编译依赖性,简化了系统在不同平台之间的移植过程,因为编译一个子系统不会影响其他的子系统,也不会影响外观对象。

外观(Facade)模式的主要缺点如下:

  • 不能很好地限制客户使用子系统类。
  • 增加新的子系统可能需要修改外观类或客户端的源代码,违背了“开闭原则”。

外观(Facade)模式的结构比较简单,主要是定义了一个高层接口。它包含了对各个子系统的引用,客户端可以通过它访问各个子系统的功能。

模式的结构#

外观(Facade)模式包含以下主要角色:

  • 外观(Facade)角色:为多个子系统对外提供一个共同的接口。
  • 子系统(Sub System)角色:实现系统的部分功能,客户可以通过外观角色访问它。
  • 客户(Client)角色:通过一个外观角色访问各个子系统的功能。

其结构图如图所示:

模式的实现#

外观模式的实现代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
class Program
{
static void Main(string[] args)
{
Facade f = new Facade();
f.method();
Console.ReadLine();
}
}


public class Facade
{
private SubSystem01 obj1=new SubSystem01();
private SubSystem02 obj2=new SubSystem02();
private SubSystem03 obj3=new SubSystem03();
public void method()
{
obj1.Method1();
obj2.Method2();
obj3.Method3();
}
}

public class SubSystem01
{
public void Method1()
{
Console.WriteLine("子系统01的Method1()被调用!");
}
}


public class SubSystem02
{
public void Method2()
{
Console.WriteLine("子系统02的Method2()被调用!");
}
}


public class SubSystem03
{
public void Method3()
{
Console.WriteLine("子系统03的Method3()被调用!");
}
}

程序运行结果如下:

1
2
3
子系统01的Method1()被调用!
子系统02的Method2()被调用!
子系统03的Method3()被调用!

通常在以下情况下可以考虑使用外观模式:

  • 对分层结构系统构建时,使用外观模式定义子系统中每层的入口点可以简化子系统之间的依赖关系。
  • 当一个复杂系统的子系统很多时,外观模式可以为系统设计一个简单的接口供外界访问。
  • 当客户端与多个子系统之间存在很大的联系时,引入外观模式可将它们分离,从而提高子系统的独立性和可移植性。

在外观模式中,当增加或移除子系统时需要修改外观类,这违背了“开闭原则”。如果引入抽象外观类(或接口),则在一定程度上解决了该问题,其结构图如图所示:

在现实生活中,存在很多“部分-整体”的关系,例如,大学中的部门与学院、总公司中的部门与分公司、学习用品中的书与书包、生活用品中的衣月艮与衣柜以及厨房中的锅碗瓢盆等。
在软件开发中也是这样,例如,文件系统中的文件与文件夹、窗体程序中的简单控件与容器控件等。对这些简单对象与复合对象的处理,如果用组合模式来实现会很方便。

组合(Composite)模式的定义:有时又叫作部分-整体模式,它是一种将对象组合成树状的层次结构的模式,用来表示“部分-整体”的关系,使用户对单个对象和组合对象具有一致的访问性。

组合模式的主要优点有:

  • 组合模式使得客户端代码可以一致地处理单个对象和组合对象,无须关心自己处理的是单个对象,还是组合对象,这简化了客户端代码
  • 更容易在组合体内加入新的对象,客户端不会因为加入了新的对象而更改源代码,满足“开闭原则”

其主要缺点是:

  • 设计较复杂,客户端需要花更多时间理清类之间的层次关系;
  • 不容易限制容器中的构件;
  • 不容易用继承的方法来增加构件的新功能;

模式的结构#

组合模式包含以下主要角色:

  • 抽象构件(Component)角色:它的主要作用是为树叶构件和树枝构件声明公共接口,并实现它们的默认行为。在透明式的组合模式中抽象构件还声明访问和管理子类的接口;在安全式的组合模式中不声明访问和管理子类的接口,管理工作由树枝构件完成。
  • 树叶构件(Leaf)角色:是组合中的叶节点对象,它没有子节点,用于实现抽象构件角色中 声明的公共接口。
  • 树枝构件(Composite)角色:是组合中的分支节点对象,它有子节点。它实现了抽象构件角色中声明的接口,它的主要作用是存储和管理子部件,通常包含 Add()、Remove()、GetChild() 等方法

组合模式分为透明式的组合模式和安全式的组合模式

  • 透明方式:在该方式中,由于抽象构件声明了所有子类中的全部方法,所以客户端无须区别树叶对象和树枝对象,对客户端来说是透明的。但其缺点是:树叶构件本来没有 Add()、Remove() 及 GetChild() 方法,却要实现它们(空实现或抛异常),这样会带来一些安全性问题。其结构图如图所示:

  • 安全方式:在该方式中,将管理子构件的方法移到树枝构件中,抽象构件和树叶构件没有对子对象的管理方法,这样就避免了上一种方式的安全性问题,但由于叶子和分支有不同的接口,客户端在调用时要知道树叶对象和树枝对象的存在,所以失去了透明性。其结构图如图所示:

模式的实现#

假如要访问集合 c0={leaf1,{leaf2,leaf3}} 中的元素,其对应的树状图如图所示:

下面给出透明式的组合模式的实现代码,安全式的组合模式与之类似:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
class Program
{
static void Main(string[] args)
{
IComponent c0=new Composite();
IComponent c1=new Composite();
IComponent leaf1=new Leaf("1");
IComponent leaf2=new Leaf("2");
IComponent leaf3=new Leaf("3");
c0.Add(leaf1);
c0.Add(c1);
c1.Add(leaf2);
c1.Add(leaf3);
c0.Operation();
Console.Read();
}
}


public interface IComponent
{
void Add(IComponent c);
void Remove(IComponent c);
IComponent GetChild(int i);
void Operation();
}


public class Leaf : IComponent
{
private String name;
public Leaf(String name)
{
this.name=name;
}
public void Add(IComponent c){ }
public void Remove(IComponent c){ }
public IComponent GetChild(int i)
{
return null;
}
public void Operation()
{
Console.WriteLine("树叶"+name+":被访问!");
}
}


public class Composite : IComponent
{
private List<IComponent> children=new List<IComponent>();
public void Add(IComponent c)
{
children.Add(c);
}
public void Remove(IComponent c)
{
children.Remove(c);
}
public IComponent GetChild(int i)
{
return children[i];
}
public void Operation()
{
foreach (var obj in children)
{
obj.Operation();
}
}
}

程序运行结果如下:

1
2
3
树叶1:被访问!
树叶2:被访问!
树叶3:被访问!

前面分析了组合模式的结构与特点,下面分析它适用的以下应用场景:

  • 在需要表示一个对象整体与部分的层次结构的场合。
  • 要求对用户隐藏组合对象与单个对象的不同,用户可以用统一的接口使用组合结构中的所有对象的场合。

如果对前面介绍的组合模式中的树叶节点和树枝节点进行抽象,也就是说树叶节点和树枝节点还有子节点,这时组合模式就扩展成复杂的组合模式了,如 Java AWT/Swing 中的简单组件 JTextComponent 有子类 JTextField、JTextArea,容器组件 Container 也有子类 Window、Panel。复杂的组合模式的结构图如图所示:

在现实生活中,常常需要对现有产品增加新的功能或美化其外观,如房子装修、相片加相框等。
在软件开发过程中,有时想用一些现存的组件。这些组件可能只是完成了一些核心功能。但在不改变其结构的情况下,可以动态地扩展其功能。所有这些都可以釆用装饰模式来实现。

装饰(Decorator)模式的定义:指在不改变现有对象结构的情况下,动态地给该对象增加一些职责(即增加其额外功能)的模式,它属于对象结构型模式

装饰(Decorator)模式的主要优点有:

  • 采用装饰模式扩展对象的功能比采用继承方式更加灵活
  • 可以设计出多个不同的具体装饰类,创造出多个不同行为的组合

其主要缺点是:装饰模式增加了许多子类,如果过度使用会使程序变得很复杂

通常情况下,扩展一个类的功能会使用继承方式来实现。但继承具有静态特征,耦合度高,并且随着扩展功能的增多,子类会很膨胀。如果使用组合关系来创建一个包装对象(即装饰对象)来包裹真实对象,并在保持真实对象的类结构不变的前提下,为其提供额外的功能,这就是装饰模式的目标。

模式的结构

装饰模式主要包含以下角色:

  • 抽象构件(Component)角色:定义一个抽象接口以规范准备接收附加责任的对象。
  • 具体构件(Concrete Component)角色:实现抽象构件,通过装饰角色为其添加一些职责。
  • 抽象装饰(Decorator)角色:继承抽象构件,并包含具体构件的实例,可以通过其子类扩展具体构件的功能。
  • 具体装饰(ConcreteDecorator)角色:实现抽象装饰的相关方法,并给具体构件对象添加附加的责任。

装饰模式的结构图如图所示:

模式的实现#

装饰模式的实现代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
class Program
{
static void Main(string[] args)
{
IComponent p=new ConcreteComponent();
p.Operation();
Console.WriteLine("---------------------------------");
IComponent d=new ConcreteDecoratorA(p);
d.Operation();
Console.ReadLine();
}
}


public interface IComponent
{
void Operation();
}


public class ConcreteComponent : IComponent
{
public ConcreteComponent()
{
Console.WriteLine("创建具体构件角色");
}
public void Operation()
{
Console.WriteLine("调用具体构件角色的方法Operation()");
}
}


public abstract class Decorator : IComponent
{
private IComponent component;
public Decorator(IComponent component)
{
this.component=component;
}
public virtual void Operation()
{
component.Operation();
}
}


public class ConcreteDecoratorA : Decorator
{
public ConcreteDecoratorA(IComponent component)
: base(component)
{

}
public override void Operation()
{
base.Operation();
AddedFunction();
}
public void AddedFunction()
{
Console.WriteLine("为具体构件角色增加额外的功能AddedFunction()");
}
}

程序运行结果如下:

1
2
3
4
5
创建具体构件角色
调用具体构件角色的方法Operation()
---------------------------------
调用具体构件角色的方法Operation()
为具体构件角色增加额外的功能AddedFunction()

装饰模式通常在以下几种情况使用:

  • 当需要给一个现有类添加附加职责,而又不能采用生成子类的方法进行扩充时。例如,该类被隐藏或者该类是终极类或者采用继承方式会产生大量的子类。
  • 当需要通过对现有的一组基本功能进行排列组合而产生非常多的功能时,采用继承关系很难实现,而采用装饰模式却很好实现。
  • 当对象的功能要求可以动态地添加,也可以再动态地撤销时。

Java的java.io包和.NET的Stream类都使用了该模式。我不会就它们的实现谈论很多细节。.NET中,Stream是一个抽象类,提供了基本的行为(如Component),从抽象类Stream继承来的类FileStream,MemoryStream是ConcreteCompents,类BufferedStream,CryptoStream等是ConcreteDecorators。你能清楚地认识到它们同样忽略了Decorator

装饰模式所包含的 4 个角色不是任何时候都要存在的,在有些应用环境下模式是可以简化的,如以下两种情况:

  • 如果只有一个具体构件而没有抽象构件时,可以让抽象装饰继承具体构件,其结构图如图所示:

  • 如果只有一个具体装饰时,可以将抽象装饰和具体装饰合并,其结构图如图所示: