一、UML类图，简单工厂基本类图

二、代码演示

/// <summary>
/// 产品抽象类
/// </summary>
public abstract class Product 
{
	public abstract void CreateProduct();
}
/// <summary>
/// 具体产品A
/// </summary>
public class ConcreteProductA:Product 
{
	public override void CreateProduct() 
	{
		//throw new NotImplementedException();
		Console.WriteLine("我是产品A");
	}
}
/// <summary>
/// 具体产品B
/// </summary>
public class ConcreteProductB:Product 
{
	public override void CreateProduct() 
	{
		//throw new NotImplementedException();
		Console.WriteLine("我是产品B");
	}
}
/// <summary>
/// 简单工厂
/// </summary>
public class SimpleProductFactory 
{
	public static Product CreateConcreteProduct(string productKey) 
	{
		Product product=null;
		switch (productKey) 
		{
			case "B":
			                product = new ConcreteProductB();
			break;
			case "A":
			                product = new ConcreteProductA();
			break;
		}
		return product;
	}
}
/// <summary>
/// 调用
/// </summary>
class Program 
{
	static void Main(string[] args) 
	{
		Product product = SimpleProductFactory.CreateConcreteProduct("B");
		product.CreateProduct();
		product = SimpleProductFactory.CreateConcreteProduct("A");
		product.CreateProduct();
		Console.Read();
	}
}

三、简单工厂的优缺点

• 优点：简单工厂模式能够根据外界给定的信息，决定究竟应该创建哪个具体类的对象。外界与具体类隔离开来，偶合性低。如同上面的例子，客户端根本就不知道具体是由谁来实现，也不知道具体是如何实现的，客户端只是通过工厂获取它需要的接口对象。
• 缺点：工厂类集中了所有实例的创建逻辑，没当有新产品添加时候必须要修改工厂。违反面向对象设计原则中的“开放封闭原则”。

四、应用场景
工厂类负责创建的对象比较少 ，客户只知道传入了工厂类的参数，对于始何创建对象（逻辑）不关心。

转载请注明：清风亦平凡 » C#实现简单工厂模式

二、开闭原则(Open-Closed Principle, 简称OCP)：一个软件实体应当对扩展开放，对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展。

三、里氏代换原则(Liskov Substitution Principle,简称 LSP)：所有引用基类（父类）的地方必须能透明地使用其子类的对象。

四、依赖倒转原则(Dependency Inversion  Principle,简称 DIP)：抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。

五、接口隔离原则(Interface  Segregation Principle, 简称ISP)：使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。

六、合成复用原则(Composite Reuse Principle, 简称 CRP)：尽量使用对象组合，而不是继承来达到复用的目的。

七、迪米特法则(Law of  Demeter, 简称 LoD)：一个软件实体应当尽可能少地与其他实体发生相互作用。

转载请注明：清风亦平凡 » 面向对象设计原则

设计模式是一套被反复使用的、多数人知晓的、经过分类编目的、代码设计经验的总结。通俗点讲就是设计过程中可以反复使用的、可以解决特定问题的设计方法。 使用设计模式是为了重用代码、让代码更容易被他人理解、保证代码可靠性。项目中合理地运用设计模式可以完美地解决很多问题，每种模式在现实中都有相应的原理来与之对应，每种模式都描述了一个在我们周围不断重复发生的问题，以及该问题的核心解决方案，这也是设计模式能被广泛应用的原因。

一、设计模式的分类。软件开发发展到现在已经有了很多的模式，其中经典的设计模式要属GoF提出的23种设计模式。这23种设计模式又可以分为三大类：

• 创建型模式：用来创建对象的模式，抽象了实例化的过程。所有的创建型模式都有两个特点：第一，他们都将系统使用具体类的信息封装起来；第二，他们隐藏了这些类的实例是如何被创建和组织的。对于这些对象外界只知道它们共同的接口，而不清楚其具体的实现细节。所以，创建型模式在创建什么，由谁来创建，以及何时创建等方面都为了软件设计者提供尽可能大的灵活性。
  • 单例模式（Singleton Pattern）:解决的是实体对象的个数问题，创建型的其他模式都是解决new所带来的耦合关系问题的。
  • 工厂方法模式(Factory Pattern)：在工厂方法中，工厂类成为了抽象类，实际的创建工作将由其具体的子类来完成。工厂方法的用意是定义一个创建产品对象的工厂接口，将实际的创建工作推迟到子类中去，此处描述的是“单个对象”的变化。
  • 抽象工厂模式 (Abstract Factory)：抽象工厂是所有工厂模式中最为抽象和最具有一般性的一种形态。抽象工厂可以向客户提供一个接口，使客户可以在不必指定产品具体类型的情况下，创建多个产品族中的产品对象，它描述的是“系列对象”的变化。
  • 生成器模式(Builder Pattern)：把构造对象实例的逻辑移到了类的外部，在这个类的外部定义了这个类的构造逻辑。它把一个复杂的对象的构造过程从对象的表示中分离出来。其直接效果是将一个复杂的对象简化为一个比较简单的目标对象 。它描述的是产品构造过程。
  • 原型模式(Prototype Pattern):它和工厂模式一样，同样对客户隐藏了对象创建工作，但是，与通过对一个类进行实例化来构造新对象不同的是，原型模式是通过拷贝一个现有的对象来生成新对象的。
• 结构型模式：此模式讨论的是类和对象的结构，它采用继承机制来组合接口或者实现，或者通过组合一些对象，来实现新的功能。这些结构模式在某些方面具有很大的相似性，但侧重点都有所不同。
  • 适配器模式(Adapter Pattern)：通过类的继承或者对象的组合，让不兼容的接口变得兼容。用于已有接口的转换。
  • 桥接模式(Bridge Pattern)：通过将抽象和实现分离，让它们可以分别独立的变化，它强调的是系统沿着多个方向变化。
  • 装饰者模式(Decorator Pattern)：采用对象组合而非继承的方式，实现了在运行时动态 扩展对象功能的能力，它强调的是扩展接口。
  • 组合模式(Composite Pattern)：模糊了单元元素和复杂元素的概念，它强调的是一种类层次的结构。
  • 外观模式(Facade  Pattern)：将复杂系统的内部子系统与客户程序之间的依赖解耦，它侧重于简化接口，更多的是一种架构模式
  • 享元模式(Flyweight Pattern)：解决的是由于大量的细粒度对象所造成的内存开销问题，它是外观模式（Facade Pattern）恰好相反，它所关注的重点是细小的对象。
  • 代理模式(Proxy Pattern)：为其他对象提供一种代理以控制这个对象的访问，它注重于增加间接层来简化的复杂问题。
• 行为型模式：负责处理对象之间的信息交互和职责分配。
  • 职责链模式（Chain Of  Responsibility Pattern）：允许多个类处理同一请求，而不必了解彼此的功能。它在类之间提供一个松散耦合。类之间唯一的联系是相互之间的传递请求。请求在类之间传递，直到一个类处理它为止。当一个对象向多个对象发送相同的信息时，就需要一种策略来确定是哪个对象对所发送的信息进行处理，而这样的处理对象只能有一个。
  • 命令模式 （Command Pattern）：把申请特定操作的请求封装到一个对象中，并给对象一个众所周知的接口。命令模式允许系统使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。每一个命令都是一个操作，请求的一方发出请求要求执行一个操作。接收的一方收到请求，并执行操作。命令模式允许请求方和接收方独立起来，这使得请求方不必知道接收方的接口，更不必清楚请求是怎么接收，以及操作是否被执行、何时被执行或者是怎么执行的。
  • 解释器模式(Interpreter Pattern)：定义语言的文法，并且建立一个解释器来解释该语言中的句子。
  • 迭代器模式(Iterator Pattern)：提供一种方式可以连续的访问几个对象的所有元素而不必关注内在的描述方式。
  • 中介者模式（Mediator Pattern）：用一个中介对象来封装一系列的对象交互。中介者使各个对象不需要显示地相互引用，从而达到松散耦合的目的，而且它可以独立地改变他们之间的交互。简单来说，就是将原来两个直接引用或者依赖的对象拆开，在中间加入一个“中介”对象，使得两方的对象分别和“中介”对象引用或者依赖。
  • 备忘录模式（Memento Pattern ）：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可以将该对象恢复到原来的保存的状态。
  • 观察者模式（Observer Pattern）：定义了一种把改动通知给多个对象的方式。
  • 状态模式（State Pattern）：允许一个对象在其内部状态改变时修改它的行为。
  • 策略模式（Strategy Pattern）：将算法封装到类中。它定义了一系列的算法，并将每一个算法封装起来，而且使他们还可以相互替换。策略模式让算法独立于使用它的客户而变化。
  • 模板方法模式（Template Method Pattern）：提供算法的一个抽象定义。在一个方法里定义算法的骨架，将一些步骤延迟到其子类上。
  • 访问者模式（Visitor Pattern）：在不改变类的前提下，为一个类添加多种操作。

转载请注明：清风亦平凡 » 设计模式简介