设计模式 | Ninokz

参考

https://refactoringguru.cn/

创建型

工厂模式

UML类图

产品（Product）将会对接口进行声明。对于所有由创建者及其子类构建的对象，这些接口都是通用的。

具体产品 （Concrete Products）是产品接口的不同实现。

创建者 （Creator）类声明返回产品对象的工厂方法。该方法的返回对象类型必须与产品接口相匹配。

你可以将工厂方法声明为抽象方法，强制要求每个子类以不同方式实现该方法。或者，你也可以在基础工厂方法中返回默认产品类型。

注意，尽管它的名字是创建者，但它最主要的职责并不是创建产品。一般来说，创建者类包含一些与产品相关的核心业务逻辑。工厂方法将这些逻辑处理从具体产品类中分离出来。打个比方，大型软件开发公司拥有程序员培训部门。但是，这些公司的主要工作还是编写代码，而非生产程序员。

具体创建者 （Concrete Creators）将会重写基础工厂方法，使其返回不同类型的产品。

注意，并不一定每次调用工厂方法都会创建新的实例。工厂方法也可以返回缓存、对象池或其他来源的已有对象。

Code

	interface IProduct
	{
		string DoStuff();
	}

	abstract class Creator 
	{
		public abstract IProduct Create();

		public virtual string SomeOperation()
		{
			return "Creator: The same creator's code has just worked with " + Create().DoStuff();
		}
	}

	class ConcreteCreatorA : Creator
	{
		public override IProduct Create()
		{
			return new ConcreteProductA();
		}
	}

	class ConcreteCreatorB : Creator
	{
		public override IProduct Create()
		{
			return new ConcreteProductB();
		}
	}


	class ConcreteProductA : IProduct
	{
		public string DoStuff()
		{
			return "ConcreteProductA";
		}
	}

	class ConcreteProductB : IProduct
	{
		public string DoStuff()
		{
			return "ConcreteProductB";
		}
	}

//IProduct product = new ConcreteCreatorA().Create();
//Console.WriteLine(product.DoStuff());

总结

工厂依赖产品接口，生产产品，具体工厂与具体产品分别继承工厂和实现产品接口

抽象工厂模式

UML类图

抽象产品 （Abstract Product）为构成系列产品的一组不同但相关的产品声明接口。

具体产品 （Concrete Product）是抽象产品的多种不同类型实现。所有变体（维多利亚/现代）都必须实现相应的抽象产品（椅子/沙发）。

抽象工厂 （Abstract Factory）接口声明了一组创建各种抽象产品的方法。

具体工厂 （Concrete Factory）实现抽象工厂的构建方法。每个具体工厂都对应特定产品变体，且仅创建此种产品变体。

尽管具体工厂会对具体产品进行初始化，其构建方法签名必须返回相应的抽象产品。这样，使用工厂类的客户端代码就不会与工厂创建的特定产品变体耦合。 客户端 （Client）只需通过抽象接口调用工厂和产品对象，就能与任何具体工厂/产品变体交互。

Code

// 抽象工厂接口声明了一组能返回不同抽象产品的方法。这些产品属于同一个系列
// 且在高层主题或概念上具有相关性。同系列的产品通常能相互搭配使用。系列产
// 品可有多个变体，但不同变体的产品不能搭配使用。	
	interface AbstractFactory
	{
		AbstractProductA CreateProductA();
		AbstractProductB CreateProductB();
	}

// 具体工厂可生成属于同一变体的系列产品。工厂会确保其创建的产品能相互搭配
// 使用。具体工厂方法签名会返回一个抽象产品，但在方法内部则会对具体产品进
// 行实例化
// 每个具体工厂中都会包含一个相应的产品变体。
	class ConcreteFactory1 : AbstractFactory
	{
		public AbstractProductA CreateProductA()
		{
			return new ProductA1();
		}

		public AbstractProductB CreateProductB()
		{
			return new ProductB1();
		}
	}

	class ConcreteFactory2 : AbstractFactory
	{
		public AbstractProductA CreateProductA()
		{
			return new ProductA2();
		}

		public AbstractProductB CreateProductB()
		{
			return new ProductB2();
		}
	}

	// 系列产品中的特定产品必须有一个基础接口。所有产品变体都必须实现这个接口
	interface AbstractProductA
	{
	}

	class ProductA1 : AbstractProductA
	{
	}

	class ProductA2 : AbstractProductA
	{

	}

	// 系列产品中的特定产品必须有一个基础接口。所有产品变体都必须实现这个接口
	interface AbstractProductB
	{
	}

	class ProductB1 : AbstractProductB
	{
	}

	class ProductB2 : AbstractProductB
	{
	}

	//AbstractProductA abstractProductA = new ConcreteFactory1().CreateProductA();
	//AbstractProductB abstractProductB = new ConcreteFactory1().CreateProductB();

总结

抽象工厂生产抽象产品，具体工厂继承抽象工厂，具体产品继承抽象产品

生成器模式

UML类图

生成器设计模式结构

生成器 （Builder）接口声明在所有类型生成器中通用的产品构造步骤。

具体生成器 （Concrete Builders）提供构造过程的不同实现。具体生成器也可以构造不遵循通用接口的产品。

产品（Products）是最终生成的对象。由不同生成器构造的产品无需属于同一类层次结构或接口。

主管（Director）类定义调用构造步骤的顺序，这样你就可以创建和复用特定的产品配置。

客户端 （Client）必须将某个生成器对象与主管类关联。一般情况下，你只需通过主管类构造函数的参数进行一次性关联即可。此后主管类就能使用生成器对象完成后续所有的构造任务。但在客户端将生成器对象传递给主管类制造方法时还有另一种方式。在这种情况下，你在使用主管类生产产品时每次都可以使用不同的生成器。

Code

	interface IBuilder
	{
		void reset();
		void step1();
		void step2();
		void step3();
	}


	class ConcreteA
	{

	}

	class ConcreteABuilder: IBuilder
	{
		private ConcreteA product;

		public ConcreteABuilder()
		{
			this.product = new ConcreteA();
		}

		public ConcreteA getResult()
		{
			return this.product;
		}

		public void reset()
		{
			this.product = new ConcreteA();
		}

		public void step1()
		{
			System.Console.WriteLine("ConcreteABuilder step1");
		}

		public void step2()
		{
			System.Console.WriteLine("ConcreteABuilder step2");
		}

		public void step3()
		{
			System.Console.WriteLine("ConcreteABuilder step3");
		}
	}

	class ConcreteB
	{

	}

	class ConcreteBBuilder: IBuilder
	{
		private ConcreteB product;

		public ConcreteBBuilder()
		{
			this.product = new ConcreteB();
		}

		public ConcreteB getResult()
		{
			return this.product;
		}

		public void reset()
		{
			this.product = new ConcreteB();
		}

		public void step1()
		{
			System.Console.WriteLine("ConcreteBBuilder step1");
		}

		public void step2()
		{
			System.Console.WriteLine("ConcreteBBuilder step2");
		}

		public void step3()
		{
			System.Console.WriteLine("ConcreteBBuilder step3");
		}
	}

	class Director
	{   
    // 主管可同由客户端代码传递给自身的任何生成器实例进行交互。客户端可通
    // 过这种方式改变最新组装完毕的产品的最终类型。主管可使用同样的生成步
    // 骤创建多个产品变体
		public void ConstructA(IBuilder abuilder)
		{
			abuilder.reset();
			abuilder.step1();
			abuilder.step2();
			abuilder.step3();
		}

		public void ConstructB(IBuilder bbuilder)
		{
			bbuilder.reset();
			bbuilder.step1();
			bbuilder.step2();
			bbuilder.step3();
		}
	}
//Director director = new Director();
//ConcreteABuilder abuilder = new ConcreteABuilder();
//ConcreteBBuilder bbuilder = new ConcreteBBuilder();
//director.ConstructA(abuilder);
//ConcreteA concreteA = abuilder.getResult();
//director.ConstructB(bbuilder);
//ConcreteB concreteB = bbuilder.getResult();

总结

具体Builder继承接口Builder，然后由Director使用

原型模式

UML类图

原型（Prototype）接口将对克隆方法进行声明。在绝大多数情况下，其中只会有一个名为 clone克隆的方法。

具体原型 （Concrete Prototype）类将实现克隆方法。除了将原始对象的数据复制到克隆体中之外，该方法有时还需处理克隆过程中的极端情况，例如克隆关联对象和梳理递归依赖等等。

客户端 （Client）可以复制实现了原型接口的任何对象。

Code

// 基础原型
interface IPrototype
{
	void SomeMethod();

	IPrototype Clone();
}

// 具体原型。克隆方法会创建一个新对象并将其传递给构造函数。直到构造函数运
// 行完成前，它都拥有指向新克隆对象的引用。因此，任何人都无法访问未完全生
// 成的克隆对象。这可以保持克隆结果的一致
class ConcreteInstance : IPrototype
{
	public void SomeMethod()
	{
		// Do something
	}

	public IPrototype Clone()
	{
		return new ConcreteInstance();
	}
}

class PrototypeManager
{
	private List<IPrototype> prototypes = new();

	public void AddPrototype(IPrototype prototype)
	{
		prototypes.Add(prototype);
	}

	public IPrototype GetPrototype(int index)
	{
		return prototypes[index].Clone();
	}
}

总结

具体原型继承原型接口，再由其他一个类聚合

单例模式

UML类图

单例（Singleton）类声明了一个名为 getInstance获取实例的静态方法来返回其所属类的一个相同实例。

单例的构造函数必须对客户端（Client）代码隐藏。调用 获取实例方法必须是获取单例对象的唯一方式。

Code

class Singleton
{
	private static Singleton instance;
	private static readonly object lockObject = new object();

	private Singleton() { }

	public static Singleton Instance
	{
		get
		{
			if (instance == null)
			{
				lock (lockObject)
				{
					if (instance == null)
					{
						instance = new Singleton();
					}
				}
			}
			return instance;
		}
	
	}
}

总结

单例需要注意多线程问题，屏蔽拷贝和构造，留出静态获取实例

结构型

适配器

UML类图

客户端 （Client）是包含当前程序业务逻辑的类。

客户端接口 （Client Interface）描述了其他类与客户端代码合作时必须遵循的协议。

服务（Service）中有一些功能类（通常来自第三方或遗留系统）。客户端与其接口不兼容，因此无法直接调用其功能。

适配器 （Adapter）是一个可以同时与客户端和服务交互的类：它在实现客户端接口的同时封装了服务对象。适配器接受客户端通过适配器接口发起的调用，并将其转换为适用于被封装服务对象的调用。

客户端代码只需通过接口与适配器交互即可，无需与具体的适配器类耦合。因此，你可以向程序中添加新类型的适配器而无需修改已有代码。这在服务类的接口被更改或替换时很有用：你无需修改客户端代码就可以创建新的适配器类。

Code

	// Target 定义客户端代码使用的特定于域的接口。
    public interface ITarget
    {
        string GetRequest();
    }

    // Adaptee 包含一些有用的行为，但它的接口是与现有客户端代码不兼容。
	// 被适应者需要一些在客户端代码可以使用它之前进行调整
    class Adaptee
    {
        public string GetSpecificRequest()
        {
            return "Specific request.";
        }
    }

    // 适配器使被适应者的界面与目标的接口兼容接口。
    class Adapter : ITarget
    {
        private readonly Adaptee _adaptee;

        public Adapter(Adaptee adaptee)
        {
            this._adaptee = adaptee;
        }

        public string GetRequest()
        {
            return $"This is '{this._adaptee.GetSpecificRequest()}'";
        }
    }

daptee adaptee = new Adaptee();
ITarget target = new Adapter(adaptee);
Console.WriteLine(target.GetRequest());

总结

桥接

UML类图

抽象部分 （Abstraction）提供高层控制逻辑，依赖于完成底层实际工作的实现对象。

实现部分 （Implementation）为所有具体实现声明通用接口。抽象部分仅能通过在这里声明的方法与实现对象交互。

抽象部分可以列出和实现部分一样的方法，但是抽象部分通常声明一些复杂行为，这些行为依赖于多种由实现部分声明的原语操作。

具体实现 （Concrete Implementations）中包括特定于平台的代码。

精确抽象 （Refined Abstraction）提供控制逻辑的变体。与其父类一样，它们通过通用实现接口与不同的实现进行交互。

通常情况下， 客户端 （Client）仅关心如何与抽象部分合作。但是，客户端需要将抽象对象与一个实现对象连接起来。

Code

	class Abstraction
	{
		protected IImplementation _implementation;

		public Abstraction(IImplementation implementation)
		{
			_implementation = implementation;
		}

		public virtual void Operation1()
		{
			_implementation.Method1();
		}

		public virtual void Operation2()
		{
			_implementation.Method1();
			_implementation.Method2();
		}
	}

	class ExtendedAbstraction : Abstraction
	{
		public ExtendedAbstraction(IImplementation implementation) : base(implementation)
		{
		}

		public override void Operation1()
		{
			_implementation.Method2();
		}
	}

	interface IImplementation
	{
		void Method1();

		void Method2();	
	}

	class ConcreteImplementationA : IImplementation
	{
		public void Method1()
		{
            Console.WriteLine("A Method1");
        }

		public void Method2()
		{
			Console.WriteLine("A Method2");
		}
	}

	class ConcreteImplementationB : IImplementation
	{
		public void Method1()
		{
			Console.WriteLine("B Method1");
		}

		public void Method2()
		{
			Console.WriteLine("B Method2	");
		}
	}
Abstraction abstraction;
abstraction = new Abstraction(new ConcreteImplementationA());
abstraction.Operation2();

abstraction = new ExtendedAbstraction(new ConcreteImplementationB());
abstraction.Operation2();

总结

组合

UML类图

组件（Component）接口描述了树中简单项目和复杂项目所共有的操作。

叶节点 （Leaf）是树的基本结构，它不包含子项目。

一般情况下，叶节点最终会完成大部分的实际工作，因为它们无法将工作指派给其他部分。

容器（Container）——又名 “组合（Composite）”——是包含叶节点或其他容器等子项目的单位。容器不知道其子项目所属的具体类，它只通过通用的组件接口与其子项目交互。

容器接收到请求后会将工作分配给自己的子项目，处理中间结果，然后将最终结果返回给客户端。

客户端 （Client）通过组件接口与所有项目交互。因此，客户端能以相同方式与树状结构中的简单或复杂项目交互。

Code

interface Component
{
	void execute();
}

class Leaf : Component
{
	private readonly int num = 0;

	public Leaf(int n)
	{
		num = n;
	}

	public void execute()
	{
		System.Console.WriteLine("Leaf");
	}
}

class Composite : Component
{
	private List<Component> children = new List<Component>();

	public void add(Component component)
	{
		children.Add(component);
	}

	public void remove(Component component)
	{
		children.Remove(component);
	}

	public void execute()
	{
		System.Console.WriteLine("Composite");
		foreach (Component component in children)
		{
			component.execute();
		}
	}
}

总结

装饰

UML类图

部件（Component）声明封装器和被封装对象的公用接口。

具体部件 （Concrete Component）类是被封装对象所属的类。它定义了基础行为，但装饰类可以改变这些行为。

基础装饰 （Base Decorator）类拥有一个指向被封装对象的引用成员变量。该变量的类型应当被声明为通用部件接口，这样它就可以引用具体的部件和装饰。装饰基类会将所有操作委派给被封装的对象。

具体装饰类 （Concrete Decorators）定义了可动态添加到部件的额外行为。具体装饰类会重写装饰基类的方法，并在调用父类方法之前或之后进行额外的行为。

客户端 （Client）可以使用多层装饰来封装部件，只要它能使用通用接口与所有对象互动即可。

Code

	interface IComponent
	{
		void execute();
	}

	class ConcreteComponent : IComponent
	{
		public virtual void execute()
		{
			System.Console.WriteLine("ConcreteComponent");
		}
	}

	class BaseDecorator : IComponent
	{
		protected IComponent component;

		public BaseDecorator(IComponent component)
		{
			this.component = component;
		}

		public void SetComponent(IComponent component)
		{
			this.component = component;
		}

		public virtual void execute()
		{
			component.execute();
		}
	}

	class ConcreteDecoratorA : BaseDecorator
	{
		public ConcreteDecoratorA(IComponent component) : base(component)
		{
		}

		public override void execute()
		{
			base.execute();
			System.Console.WriteLine("ConcreteDecoratorA");
		}
	}


	var simple = new ConcreteComponent();
	simple.execute();
	ConcreteDecoratorA decorator1 = new ConcreteDecoratorA(simple);
	decorator1.execute();

//ConcreteComponent
//Decorating...
//ConcreteComponent
//ConcreteDecoratorA
//ConcreteDecoratorB

外观

UML类图

外观（Facade）提供了一种访问特定子系统功能的便捷方式，其了解如何重定向客户端请求，知晓如何操作一切活动部件。

创建附加外观 （Additional Facade）类可以避免多种不相关的功能污染单一外观，使其变成又一个复杂结构。客户端和其他外观都可使用附加外观。

复杂子系统 （Complex Subsystem）由数十个不同对象构成。如果要用这些对象完成有意义的工作，你必须深入了解子系统的实现细节，比如按照正确顺序初始化对象和为其提供正确格式的数据。

子系统类不会意识到外观的存在，它们在系统内运作并且相互之间可直接进行交互。

客户端 （Client）使用外观代替对子系统对象的直接调用。

Code

class Subsystem1
{
	public void Operation1()
	{
		System.Console.WriteLine("Subsystem1: Ready!");
	}

	public void OperationN()
	{
		System.Console.WriteLine("Subsystem1: Go!");
	}
}

class Subsystem2
{
	public void Operation1()
	{
		System.Console.WriteLine("Subsystem2: Get ready!");
	}

	public void OperationZ()
	{
		System.Console.WriteLine("Subsystem2: Fire!");
	}
}

class Facade
{
	private Subsystem1 _subsystem1;
	private Subsystem2 _subsystem2;

	public Facade(Subsystem1 subsystem1, Subsystem2 subsystem2)
	{
		this._subsystem1 = subsystem1;
		this._subsystem2 = subsystem2;
	}

	public void Operation()
	{
		System.Console.WriteLine("Facade initializes subsystems:");
		_subsystem1.Operation1();
		_subsystem2.Operation1();
		System.Console.WriteLine("Facade orders subsystems to perform the action:");
		_subsystem1.OperationN();
		_subsystem2.OperationZ();
	}
}

Facade facade = new Facade(new Subsystem1(), new Subsystem2());
facade.Operation();

享元模式

对象的常量数据通常被称为内在状态，其位于对象中，其他对象只能读取但不能修改其数值。而对象的其他状态常常能被其他对象 “从外部” 改变，因此被称为外在状态。享元模式建议不在对象中存储外在状态，而是将其传递给依赖于它的一个特殊方法。程序只在对象中保存内在状态，以方便在不同情景下重用。

UML

享元模式只是一种优化。在应用该模式之前，你要确定程序中存在与大量类似对象同时占用内存相关的内存消耗问题，并且确保该问题无法使用其他更好的方式来解决。

享元（Flyweight）类包含原始对象中部分能在多个对象中共享的状态。同一享元对象可在许多不同情景中使用。享元中存储的状态被称为 “内在状态”。传递给享元方法的状态被称为 “外在状态”。

情景（Context）类包含原始对象中各不相同的外在状态。情景与享元对象组合在一起就能表示原始对象的全部状态。

通常情况下，原始对象的行为会保留在享元类中。因此调用享元方法必须提供部分外在状态作为参数。但你也可将行为移动到情景类中，然后将连入的享元作为单纯的数据对象。

客户端 （Client）负责计算或存储享元的外在状态。在客户端看来，享元是一种可在运行时进行配置的模板对象，具体的配置方式为向其方法中传入一些情景数据参数。

享元工厂 （Flyweight Factory）会对已有享元的缓存池进行管理。有了工厂后，客户端就无需直接创建享元，它们只需调用工厂并向其传递目标享元的一些内在状态即可。工厂会根据参数在之前已创建的享元中进行查找，如果找到满足条件的享元就将其返回；如果没有找到就根据参数新建享元。

Code

class FlyweightFactory
{
	private readonly Dictionary<string, Flyweight> flyweights = new Dictionary<string, Flyweight>();

	public Flyweight GetFlyweight(string key)
	{
		if (!flyweights.ContainsKey(key))
		{
			flyweights[key] = new Flyweight();
		}

		return flyweights[key];
	}
}

class Flyweight
{
	public virtual void Operation()
	{
           Console.WriteLine("Flyweight Operation");
       }
}

class Context
{
	public Flyweight repeatingState { get; set; }
	public string uniqueState { get; set; }

	public Context(Flyweight repeatingState,string uniqueState)
	{
		this.repeatingState = repeatingState;
		this.uniqueState = uniqueState;
	}

	public void Operation()
	{
           Console.WriteLine("Some Operations");
       }
}


FlyweightFactory factory = new FlyweightFactory();
Flyweight flyweight = factory.GetFlyweight("key");
Context context = new Context(flyweight, "uniqueState");
context.Operation();

代理

UML类图

服务接口 （Service Interface）声明了服务接口。代理必须遵循该接口才能伪装成服务对象。

服务（Service）类提供了一些实用的业务逻辑。

代理（Proxy）类包含一个指向服务对象的引用成员变量。代理完成其任务（例如延迟初始化、记录日志、访问控制和缓存等）后会将请求传递给服务对象。

通常情况下，代理会对其服务对象的整个生命周期进行管理。

客户端 （Client）能通过同一接口与服务或代理进行交互，所以你可在一切需要服务对象的代码中使用代理。

Code


interface ServiceInterface
{
	void Operationn();
}

class Service : ServiceInterface
{
	public void Operationn()
	{
		// Do something
	}
}

class ServiceProxy : ServiceInterface
{
	private ServiceInterface _service;

	public ServiceProxy(ServiceInterface service)
	{
		_service = service;
	}

	public void Operationn()
	{
		// Do something before
		_service.Operationn();
		// Do something after
	}
}

Service service = new Service();
ServiceProxy serviceProxy = new ServiceProxy(service);
serviceProxy.Operationn();

行为