0%

一、引言

在软件开发过程中,有些对象有时候会由于网络或其他的障碍,以至于不能够或者不能直接访问到这些对象,如果直接访问对象给系统带来不必要的复杂性,这时候可以在客户端和目标对象之间增加一层中间层,让代理对象代替目标对象,然后客户端只需要访问代理对象,由代理对象去帮我们去请求目标对象并返回结果给客户端,这样的一个解决思路就是今天要介绍的代理模式。

二、代理模式的详细介绍

代理模式按照使用目的可以分为以下几种:

  • 远程(Remote)代理:为一个位于不同的地址空间的对象提供一个局域代表对象。这个不同的地址空间可以是本电脑中,也可以在另一台电脑中。最典型的例子就是——客户端调用Web服务或WCF服务。
  • 虚拟(Virtual)代理:根据需要创建一个资源消耗较大的对象,使得对象只在需要时才会被真正创建。
  • Copy-on-Write代理:虚拟代理的一种,把复制(或者叫克隆)拖延到只有在客户端需要时,才真正采取行动。
  • 保护(Protect or Access)代理:控制一个对象的访问,可以给不同的用户提供不同级别的使用权限。
  • 防火墙(Firewall)代理:保护目标不让恶意用户接近。
  • 智能引用(Smart Reference)代理:当一个对象被引用时,提供一些额外的操作,比如将对此对象调用的次数记录下来等。
  • Cache代理:为某一个目标操作的结果提供临时的存储空间,以便多个客户端可以这些结果。

在哦上面所有种类的代理模式中,虚拟代理、远程代理、智能引用代理和保护代理较为常见的代理模式。下面让我们具体看看代理模式的具体定义。

2.1 定义

代理模式——就是给某一个对象提供一个代理,并由代理对象控制对原对象的引用。在一些情况下,一个客户不想或者不能直接引用一个对象,而代理对象可以在客户端和目标对象之间起到中介的作用。例如电脑桌面的快捷方式就是一个代理对象,快捷方式是它所引用的程序的一个代理

2.2 代理模式实现

看完代理模式的描述之后,下面以一个生活中的例子来解释下代理模式,在现实生活中,如果有同事出国或者朋友出国的情况下,我们经常会拖这位朋友帮忙带一些电子产品或化妆品等东西,这个场景中,出国的朋友就是一个代理,他(她)是他(她)朋友的一个代理,由于他朋友不能去国外买东西,他却可以,所以朋友们都托他帮忙带一些东西的。下面就以这个场景来实现下代理模式,具体代码如下:

复制代码

// 客户端调用
class Client
{ static void Main(string[] args)
{ // 创建一个代理对象并发出请求
Person proxy = new Friend();
proxy.BuyProduct();
Console.Read();
}
} // 抽象主题角色
public abstract class Person
{ public abstract void BuyProduct();
} //真实主题角色
public class RealBuyPerson : Person
{ public override void BuyProduct()
{
Console.WriteLine(“帮我买一个IPhone和一台苹果电脑”);
}
} // 代理角色
public class Friend:Person
{ // 引用真实主题实例
RealBuyPerson realSubject; public override void BuyProduct()
{
Console.WriteLine(“通过代理类访问真实实体对象的方法”); if (realSubject == null)
{
realSubject = new RealBuyPerson();
} this.PreBuyProduct(); // 调用真实主题方法
realSubject.BuyProduct(); this.PostBuyProduct();
} // 代理角色执行的一些操作
public void PreBuyProduct()
{ // 可能不知一个朋友叫这位朋友带东西,首先这位出国的朋友要对每一位朋友要带的东西列一个清单等
Console.WriteLine(“我怕弄糊涂了,需要列一张清单,张三:要带相机,李四:要带Iphone………..”);
} // 买完东西之后,代理角色需要针对每位朋友需要的对买来的东西进行分类
public void PostBuyProduct()
{
Console.WriteLine(“终于买完了,现在要对东西分一下,相机是张三的;Iphone是李四的……….”);
}
}

复制代码

在上面的代码中都有相应的注释,这里也不多解释了。

2.3 代理模式的类图结构

看完代理模式的实现之后,下面就以上面的例子来分析下代理模式的类图结构。具体的类图如下所示:

在上面类图中,代理模式所涉及的角色有三个:

抽象主题角色(Person):声明了真实主题和代理主题的公共接口,这样一来在使用真实主题的任何地方都可以使用代理主题。

代理主题角色(Friend):代理主题角色内部含有对真实主题的引用,从而可以操作真实主题对象;代理主题角色负责在需要的时候创建真实主题对象;代理角色通常在将客户端调用传递到真实主题之前或之后,都要执行一些其他的操作,而不是单纯地将调用传递给真实主题对象。例如这里的PreBuyProduct和PostBuyProduct方法就是代理主题角色所执行的其他操作。

真实主题角色(RealBuyPerson):定义了代理角色所代表的真是对象。

附:在实际开发过程中,我们在客户端添加服务引用的时候,在客户程序中会添加一些额外的类,在客户端生成的类扮演着代理主题角色,我们客户端也是直接调用这些代理角色来访问远程服务提供的操作。这个是远程代理的一个典型例子。

三、代理模式的优缺点

全面分析完代理模式之后,让我们看看这个模式的优缺点:

优点:

  1. 代理模式能够将调用用于真正被调用的对象隔离,在一定程度上降低了系统的耦合度;
  2. 代理对象在客户端和目标对象之间起到一个中介的作用,这样可以起到对目标对象的保护。代理对象可以在对目标对象发出请求之前进行一个额外的操作,例如权限检查等。

缺点:

  1.  由于在客户端和真实主题之间增加了一个代理对象,所以会造成请求的处理速度变慢
  2. 实现代理类也需要额外的工作,从而增加了系统的实现复杂度。

五、总结

到这里,代理模式的介绍就结束了,代理模式提供了对目标对象访问的代理。并且到这里,结构型模式的介绍也结束了,结构型模式包括:适配器模式桥接模式装饰者模式组合模式外观模式享元模式和代理模式,下面开始介绍行为型模式的第一个模式:模板方法模式。

  本专题所有源码:设计模式之代理模式源码

单例(Singleton)模式的定义:指一个类只有一个实例,且该类能自行创建这个实例的一种模式
例如,Windows 中只能打开一个任务管理器,这样可以避免因打开多个任务管理器窗口而造成内存资源的浪费,或出现各个窗口显示内容的不一致等错误。

单例模式有 3 个特点:

  • 单例类只有一个实例对象
  • 该单例对象必须由单例类自行创建
  • 单例类对外提供一个访问该单例的全局访问点

单例模式是设计模式中最简单的模式之一。通常,普通类的构造函数是公有的,外部类可以通过“new 构造函数()”来生成多个实例。但是,如果将类的构造函数设为私有的,外部类就无法调用该构造函数,也就无法生成多个实例。这时该类自身必须定义一个静态私有实例,并向外提供一个静态的公有函数用于创建或获取该静态私有实例。

单例模式的结构

单例模式的主要角色如下:

  • 单例类(Singleton):包含一个实例且能自行创建这个实例的类。
  • 访问类(Client):使用单例的类。

单例模式的实现

Singleton 模式通常有两种实现形式:懒汉式单例、饿汉式单例。

第 1 种:懒汉式单例

该模式的特点是类加载时没有生成单例,只有当第一次调用 Getlnstance 方法时才去创建这个单例。代码如下:

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 Singleton
{

private static Singleton instance;


private static readonly object locker = new object();


private Singleton(){ }





public static Singleton GetInstance()
{

if (instance == null)
{
lock (locker)
{

if (instance == null)
{
instance = new Singleton();
}
}
}
return instance;
}
}

第 2 种:饿汉式单例

该模式的特点是类一旦加载就创建一个单例,保证在调用 GetInstance 方法之前单例已经存在了。代码如下:

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



public class Singleton
{

private static Singleton instance=new Singleton();


private Singleton() { }





public static Singleton GetInstance()
{
return instance;
}
}

前面分析了单例模式的结构与特点,以下是它通常适用的场景的特点:

  • 在应用场景中,某类只要求生成一个对象的时候,如一个班中的班长、每个人的身份证号等。
  • 当对象需要被共享的场合。由于单例模式只允许创建一个对象,共享该对象可以节省内存,并加快对象访问速度。如 Web 中的配置对象、数据库的连接池等。
  • 当某类需要频繁实例化,而创建的对象又频繁被销毁的时候,如多线程的线程池、网络连接池等。

单例模式可扩展为多例(Multition)模式,这种模式可生成多个实例并保存在 List 中,客户需要时可随机获取,其结构图如图所示:

多例模式可分为以下两种:

  • 有上限多例模式:多例类的实例数目有上限,并把实例的上限当做逻辑的一部分创造到了多例类的内部,这种多例模式叫做有上限多例模式。
  • 无上限多例模式:多例类的实例数目并不需要有上限,实例数目并没有上限的多例模式就叫做无上限多例模式。

原型(Prototype)模式的定义如下:用一个已经创建的实例作为原型,通过复制该原型对象来创建一个和原型相同或相似的新对象。
在这里,原型实例指定了要创建的对象的种类。用这种方式创建对象非常高效,根本无须知道对象创建的细节。
例如,Windows 操作系统的安装通常较耗时,如果复制就快了很多。在生活中复制的例子非常多,这里不一一列举了。

由于 C# 提供了 ICloneable 接口,用 C# 实现原型模式很简单。

模式的结构

原型模式包含以下主要角色:

  • 原型(Prototype):声明一个克隆自身的接口,该角色一般有抽象类(Prototype)、接口(ICloneable)两种实现方式(GOF使用的是抽象类,在C#中个人推荐使用接口)。
  • 具体原型类(ConcretePrototype):实现原型(抽象类或接口)的 Clone() 方法,它是可被复制的对象。
  • 访问类(Client):使用具体原型类中的 Clone() 方法来复制新的对象。

使用接口作为Prototype时,其结构图如图所示(后面全部是接口方式的原型模式实现):

使用抽象类作为Prototype时,其结构图如图所示(来自GOF):

模式的实现

C# 中已经定义了 ICloneable 接口,具体原型类只要实现 ICloneable 接口就可实现对象的克隆(Object有 MemberwiseClone() 方法默认浅克隆),克隆是浅克隆还是深克隆取决于具体原型类 Clone() 的实现。其代码如下:

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

public interface ICloneable
{
Object Clone();
}


public abstract class Prototype
{
public abstract Object Clone();
}


public class ConcretePrototype : ICloneable
{
private int id;
public int Id
{
get { return id; }
}
public ConcretePrototype(int id)
{
this.id = id;
}
public Object Clone()
{
return new ConcretePrototype(id);
}







}


class Program
{
static void Main(string[] args)
{
ConcretePrototype cp1 = new ConcretePrototype(1);
ConcretePrototype cp2 = (ConcretePrototype)cp1.Clone();
Console.WriteLine("cp1的Id为:{0}",cp1.Id);
Console.WriteLine("cp2的Id为:{0}", cp2.Id);
Console.ReadKey();
}
}

运行结果:

1
2
cp1的Id为:1
cp2的Id为:1

原型模式通常适用于以下场景:

  • 对象之间相同或相似,即只是个别的几个属性不同的时候。
  • 对象的创建过程比较麻烦,但复制比较简单的时候。

原型模式可扩展为带原型管理器的原型模式,它在原型模式的基础上增加了一个原型管理器 PrototypeManager 类。该类用 Dictionary(或HashMap) 保存多个复制的原型,Client 类可以通过管理器的 Get(String id) 方法从中获取复制的原型。其结构如图所示:

工厂方法(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

https://www.cnblogs.com/PatrickLiu/p/8250985.html
https://www.cnblogs.com/zhili/p/SingletonPatterm.html

单例模式(Singleton):保证一个类只有一个实例,并提供一个访问它的全局访问点

应用场景:一个无状态的类使用单例模式节省内存资源。

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

/// <summary>
/// 单例模式的实现
/// </summary>
public class Singleton
{
// 定义一个静态变量来保存类的实例
private static Singleton uniqueInstance;

// 定义私有构造函数,使外界不能创建该类实例
private Singleton()
{
}

/// <summary>
/// 定义公有方法提供一个全局访问点,同时你也可以定义公有属性来提供全局访问点
/// </summary>
/// <returns></returns>
public static Singleton GetInstance()
{
// 如果类的实例不存在则创建,否则直接返回
if (uniqueInstance == null)
{
uniqueInstance = new Singleton();
}
return uniqueInstance;
}
}

私有的实例构造器是屏蔽外界的调用,上面的单例模式的实现在单线程下确实是完美的,也很好的满足了我们单线程环境的需求。

单线程单例模式的几个要点:

1.Singleton模式中的实例构造器可以设置为protected以允许子类派生。
2.Singleton模式一般不要支持ICloneable接口,因为这可能会导致多个对象实例,与Singleton模式的初衷违背。
3.Singleton模式一般不要支持序列化,因为这也有可能导致多个对象实例,同样与Singleton模式的初衷违背。
4.Singletom模式只考虑到了对象创建的工作,没有考虑对象销毁的工作。为什么这样做呢,因为Net平台是支持垃圾回收的,所以我们一般没有必要对其进行销毁处理。
5.不能应对多线程环境:在多线程环境下,使用Singleton模式仍然有可能得到Singleton类的多个实例对象