四种设计模式详解
一、单例模式
1、单例模式的定义:
单例模式是设计模式中最简单的形式之一。这一模式的目的是使得类的一个对象成为系统中的唯一实例。要实现这一点,可以从客户端对其进行实例化开始。因此需要用一种只允许生成对象类的唯一实例的机制,“阻止”所有想要生成对象的访问。
2、单例模式实现方法:
- 第一种实现:
public class Singleton {
private static Singleton instance;
private Singleton (){}
public static Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
}
这种写法lazy loading很明显,但是致命的是在多线程不能正常工作。
- 第二种实现:
public class Singleton {
private static Singleton instance;
private Singleton (){}
public static synchronized Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
}
这种写法能够在多线程中很好的工作,而且看起来它也具备很好的lazy loading,但是,遗憾的是,效率很低,99%情况下不需要同步。
- 第三种实现:
public class Singleton {
private static Singleton instance = new Singleton();
private Singleton (){}
public static Singleton getInstance() {
return instance;
}
}
这种方式基于classloder机制避免了多线程的同步问题,不过,instance在类装载时就实例化。
- 第四种实现:
public class Singleton {
private volatile static Singleton singleton;
private Singleton (){}
public static Singleton getSingleton() {
if (singleton == null) {
synchronized (Singleton.class) {
if (singleton == null) {
singleton = new Singleton();
}
}
}
return singleton;
}
}
二、抽象工厂
1、抽象工厂定义
抽象工厂模式是所有形态的工厂模式中最为抽象和最具一般性的一种形态。
为了方便引进抽象工厂模式,引进一个新概念:产品族(Product Family)。所谓产品族,是指位于不同产品等级结构,功能相关联的产品组成的家族。如图:
图中一共有四个产品族,分布于三个不同的产品等级结构中。只要指明一个产品所处的产品族以及它所属的等级结构,就可以唯一的确定这个产品。
引进抽象工厂模式
所谓的抽象工厂是指一个工厂等级结构可以创建出分属于不同产品等级结构的一个产品族中的所有对象。如果用图来描述的话,如下图:
代码如下(示例):
import numpy as np
import pandas as pd
import matplotlib.pyplot as plt
import seaborn as sns
import warnings
warnings.filterwarnings('ignore')
import ssl
ssl._create_default_https_context = ssl._create_unverified_context
2、Abstract Factory模式的结构:
图中描述的东西用产品族描述如下:
抽象工厂(Abstract Factory)角色:担任这个角色的是工厂方法模式的核心,它是与应用系统商业逻辑无关的。
具体工厂(Concrete Factory)角色:这个角色直接在客户端的调用下创建产品的实例。这个角色含有选择合适的产品对象的逻辑,而这个逻辑是与应用系统的商业逻辑紧密相关的。
抽象产品(Abstract Product)角色:担任这个角色的类是工厂方法模式所创建的对象的父类,或它们共同拥有的接口。
具体产品(Concrete Product)角色:抽象工厂模式所创建的任何产品对象都是某一个具体产品类的实例。这是客户端最终需要的东西,其内部一定充满了应用系统的商业逻辑。
3、程序举例:
using System;
// "AbstractFactory"
abstract class AbstractFactory
{
// Methods
abstract public AbstractProductA CreateProductA();
abstract public AbstractProductB CreateProductB();
}
// "ConcreteFactory1"
class ConcreteFactory1 : AbstractFactory
{
// Methods
override public AbstractProductA CreateProductA()
{
return new ProductA1();
}
override public AbstractProductB CreateProductB()
{
return new ProductB1();
}
}
// "ConcreteFactory2"
class ConcreteFactory2 : AbstractFactory
{
// Methods
override public AbstractProductA CreateProductA()
{
return new ProductA2();
}
override public AbstractProductB CreateProductB()
{
return new ProductB2();
}
}
// "AbstractProductA"
abstract class AbstractProductA
{
}
// "AbstractProductB"
abstract class AbstractProductB
{
// Methods
abstract public void Interact( AbstractProductA a );
}
// "ProductA1"
class ProductA1 : AbstractProductA
{
}
// "ProductB1"
class ProductB1 : AbstractProductB
{
// Methods
override public void Interact( AbstractProductA a )
{
Console.WriteLine( this + " interacts with " + a );
}
}
// "ProductA2"
class ProductA2 : AbstractProductA
{
}
// "ProductB2"
class ProductB2 : AbstractProductB
{
// Methods
override public void Interact( AbstractProductA a )
{
Console.WriteLine( this + " interacts with " + a );
}
}
// "Client" - the interaction environment of the products
class Environment
{
// Fields
private AbstractProductA AbstractProductA;
private AbstractProductB AbstractProductB;
// Constructors
public Environment( AbstractFactory factory )
{
AbstractProductB = factory.CreateProductB();
AbstractProductA = factory.CreateProductA();
}
// Methods
public void Run()
{
AbstractProductB.Interact( AbstractProductA );
}
}
/**//// <summary>
/// ClientApp test environment
/// </summary>
class ClientApp
{
public static void Main(string[] args)
{
AbstractFactory factory1 = new ConcreteFactory1();
Environment e1 = new Environment( factory1 );
e1.Run();
AbstractFactory factory2 = new ConcreteFactory2();
Environment e2 = new Environment( factory2 );
e2.Run();
}
}
4、在什么情形下使用抽象工厂模式:
在以下情况下应当考虑使用抽象工厂模式:
一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节,这对于所有形态的工厂模式都是重要的。
这个系统有多于一个的产品族,而系统只消费其中某一产品族。
同属于同一个产品族的产品是在一起使用的,这一约束必须在系统的设计中体现出来。
系统提供一个产品类的库,所有的产品以同样的接口出现,从而使客户端不依赖于实现。
5、抽象工厂的起源
据说最早的应用是用来创建在不同操作系统的视窗环境下都能够运行的系统。比如在Windows与Unix系统下都有视窗环境的构件,在每一个操作系统中,都有一个视窗构件组成的构件家族。我们可以通过一个抽象角色给出功能描述,而由具体子类给出不同操作系统下的具体实现,如图:
可以发现上面产品类图有两个产品等级结构,分别是Button与Text;同时有两个产品族:Unix产品族与Windows产品族。
系统对产品对象的创建要求由一个工厂的等级结构满足。其中有两个具体工厂角色,即UnixFactory和WinFactory。UnixFactory对象负责创建Unix产品族中的产品,而WinFactory负责创建Windows产品族中的产品。
显然一个系统只能够在某一个操作系统的视窗环境下运行,而不能同时在不同的操作系统上运行。所以,系统实际上只能消费属于同一个产品族的产品。
在现代的应用中,抽象工厂模式的使用范围已经大大扩大了,不再要求系统只能消费某一个产品族了。
6、Abstract Factory模式在实际系统中的实现
// "AbstractFactory"
abstract class ControlFactory
{
// Methods
abstract public Button CreateButton();
abstract public Text CreateText();
}
// "ConcreteFactory1"
class WinFactory : ControlFactory
{
// Methods
override public Button CreateButton()
{ return new WinButton(); }
override public Text CreateText()
{ return new Wintext(); }
}
// "ConcreteFactory2"
class UnixFactory : ControlFactory
{
// Methods
override public Button CreateButton()
{ return new UnixButton(); }
override public Text CreateText()
{ return new UnixText(); }
}
// "AbstractProductA"
abstract class Button
{
}
// "AbstractProductB"
abstract class Text
{
}
// "ProductA1"
class WinButton : Button
{
}
// "ProductB1"
class WinText : Text
{
}
// "ProductA2"
class UnixButton : Button
{
}
// "ProductB2"
class UnixText : Text
{
}
// "Client"
class Form1
{
// Fields
private Button b1;
private Text t1;
// Constructors
public AnimalWorld( ControlFactory factory )
{
b1 = factory.CreateButton();
t1 = factory.CreateText();
}
}
class GameApp
{
public static void Main( string[] args )
{
ControlFactory Win= new WinFactory();
Form1 f1 = new Form1(Win );
ControlFactory Unix= new UnixFactory();
Form1 f2 = new Form1(Unix );
}
}
抽象工厂的另外一个例子:
7、"开放-封闭"原则
"开放-封闭"原则要求系统对扩展开放,对修改封闭。通过扩展达到增强其功能的目的。对于涉及到多个产品族与多个产品等级结构的系统,其功能增强包括两方面:
增加产品族:Abstract Factory很好的支持了"开放-封闭"原则。
增加新产品的等级结构:需要修改所有的工厂角色,没有很好支持"开放-封闭"原则。
综合起来,抽象工厂模式以一种倾斜的方式支持增加新的产品,它为新产品族的增加提供方便,而不能为新的产品等级结构的增加提供这样的方便。
三、观察者模式
1.观察者(Observer)模式定义:
观察者模式又叫做发布-订阅(Publish/Subscribe)模式、模型-视图(Model/View)模式、源-监听器(Source/Listener)模式或从属者(Dependents)模式。
观察者模式定义了一种一对多的依赖关系,让多个观察者对象同时监听某一个主题对象。这个主题对象在状态上发生变化时,会通知所有观察者对象,使它们能够自动更新自己。
一个软件系统常常要求在某一个对象的状态发生变化的时候,某些其它的对象做出相应的改变。做到这一点的设计方案有很多,但是为了使系统能够易于复用,应该选择低耦合度的设计方案。减少对象之间的耦合有利于系统的复用,但是同时设计师需要使这些低耦合度的对象之间能够维持行动的协调一致,保证高度的协作(Collaboration)。观察者模式是满足这一要求的各种设计方案中最重要的一种。
2.观察者模式的结构
观察者模式的类图如下:
可以看出,在这个观察者模式的实现里有下面这些角色:
抽象主题(Subject)角色:主题角色把所有对观察考对象的引用保存在一个聚集里,每个主题都可以有任何数量的观察者。抽象主题提供一个接口,可以增加和删除观察者对象,主题角色又叫做抽象被观察者(Observable)角色,一般用一个抽象类或者一个接口实现。
抽象观察者(Observer)角色:为所有的具体观察者定义一个接口,在得到主题的通知时更新自己。这个接口叫做更新接口。抽象观察者角色一般用一个抽象类或者一个接口实现。在这个示意性的实现中,更新接口只包含一个方法(即Update()方法),这个方法叫做更新方法。
具体主题(ConcreteSubject)角色:将有关状态存入具体现察者对象;在具体主题的内部状态改变时,给所有登记过的观察者发出通知。具体主题角色又叫做具体被观察者角色(Concrete Observable)。具体主题角色通常用一个具体子类实现。
具体观察者(ConcreteObserver)角色:存储与主题的状态自恰的状态。具体现察者角色实现抽象观察者角色所要求的更新接口,以便使本身的状态与主题的状态相协调。如果需要,具体现察者角色可以保存一个指向具体主题对象的引用。具体观察者角色通常用一个具体子类实现。
从具体主题角色指向抽象观察者角色的合成关系,代表具体主题对象可以有任意多个对抽象观察者对象的引用。之所以使用抽象观察者而不是具体观察者,意味着主题对象不需要知道引用了哪些ConcreteObserver类型,而只知道抽象Observer类型。这就使得具体主题对象可以动态地维护一系列的对观察者对象的引用,并在需要的时候调用每一个观察者共有的Update()方法。这种做法叫做"针对抽象编程"。
3、 观察者模式的示意性源代码
// "Subject"
abstract class Subject
{
// Fields
private ArrayList observers = new ArrayList();
// Methods
public void Attach( Observer observer )
{
observers.Add( observer );
}
public void Detach( Observer observer )
{
observers.Remove( observer );
}
public void Notify()
{
foreach( Observer o in observers )
o.Update();
}
}
// "ConcreteSubject"
class ConcreteSubject : Subject
{
// Fields
private string subjectState;
// Properties
public string SubjectState
{
get{ return subjectState; }
set{ subjectState = value; }
}
}
// "Observer"
abstract class Observer
{
// Methods
abstract public void Update();
}
// "ConcreteObserver"
class ConcreteObserver : Observer
{
// Fields
private string observerState;
private ConcreteSubject subject;
// Constructors
public ConcreteObserver( ConcreteSubject subject,
string name )
{
this.subject = subject;
this.name = name;
}
// Methods
override public void Update()
{
observerState = subject.SubjectState;
Console.WriteLine( "Observer {0}'s new state is {1}",
name, observerState );
}
// Properties
public ConcreteSubject Subject
{
get { return subject; }
set { subject = value; }
}
}
/**//// <summary>
/// Client test
/// </summary>
public class Client
{
public static void Main( string[] args )
{
// Configure Observer structure
ConcreteSubject s = new ConcreteSubject();
s.Attach( new ConcreteObserver( s, "1" ) );
s.Attach( new ConcreteObserver( s, "2" ) );
s.Attach( new ConcreteObserver( s, "3" ) );
// Change subject and notify observers
s.SubjectState = "ABC";
s.Notify();
}
}
4、 一个实际应用观察者模式的例子
//该例子演示了注册的投资者在股票市场发生变化时,可以自动得到通知。
// Observer pattern -- Real World example
using System;
using System.Collections;
// "Subject"
abstract class Stock
{
// Fields
protected string symbol;
protected double price;
private ArrayList investors = new ArrayList();
// Constructor
public Stock( string symbol, double price )
{
this.symbol = symbol;
this.price = price;
}
// Methods
public void Attach( Investor investor )
{
investors.Add( investor );
}
public void Detach( Investor investor )
{
investors.Remove( investor );
}
public void Notify()
{
foreach( Investor i in investors )
i.Update( this );
}
// Properties
public double Price
{
get{ return price; }
set
{
price = value;
Notify();
}
}
public string Symbol
{
get{ return symbol; }
set{ symbol = value; }
}
}
// "ConcreteSubject"
class IBM : Stock
{
// Constructor
public IBM( string symbol, double price )
: base( symbol, price ) {}
}
// "Observer"
interface IInvestor
{
// Methods
void Update( Stock stock );
}
// "ConcreteObserver"
class Investor : IInvestor
{
// Fields
private string name;
private string observerState;
private Stock stock;
// Constructors
public Investor( string name )
{
this.name = name;
}
// Methods
public void Update( Stock stock )
{
Console.WriteLine( "Notified investor {0} of {1}'s change to {2:C}",
name, stock.Symbol, stock.Price );
}
// Properties
public Stock Stock
{
get{ return stock; }
set{ stock = value; }
}
}
/**//// <summary>
/// ObserverApp test
/// </summary>
public class ObserverApp
{
public static void Main( string[] args )
{
// Create investors
Investor s = new Investor( "Sorros" );
Investor b = new Investor( "Berkshire" );
// Create IBM stock and attach investors
IBM ibm = new IBM( "IBM", 120.00 );
ibm.Attach( s );
ibm.Attach( b );
// Change price, which notifies investors
ibm.Price = 120.10;
ibm.Price = 121.00;
ibm.Price = 120.50;
ibm.Price = 120.75;
}
}
四、通用层次模式
这个模式出现在许多类图中。你经常发现一组对象集有自然的层次关系。例如机构图中经理及其下属的关系,或文件系统中的目录(也叫文件夹)、子目录和文件之间的关系。在这样一个层次中,每个对象可能没有或有多个对象位于他们上层(上级),并且没有或有多个对象在它们下层(下级)。但是某些对象不能有任何下级——例如机构图中的工作人员(与经理相对),或文件系统中的文件(与日录相对)。
安全通用层次模式类图
透明通用层次模式类图
透明模式的优点是所有的构件类都有相同的接口。在客户端看来,树叶类对象与合成类对象的区别起码在接口层次上消失了,客户端可以同等同的对待所有的对象。缺点是不够安全,因为树叶类对象和合成类对象在本质上是有区别的。树叶类对象不可能有管理子类对象,但如果写了这类方法在编译时期不会出错,而只会在运行时期才会出错。
安全模式的优点时安全,因为树叶类型的对象根本就没有管理子类对象的方法,因此,如果客户端对树叶类对象使用这些方法时,程序会在编译时期出错。缺点是不够透明,因为树叶类和合成类将具有不同的接口。
abstract class Component
{
public virtual void Operation();
}
class Composite : Component
{
private ArrayList children = new ArrayList();
public void Add( Component component )
{
children.Add( component );
}
public void Remove( Component component )
{
children.Remove( component );
}
}
class Leaf : Component
{
public void Operation()
{
}
}