C#工厂模式

C#工厂模式
利用设计模式能够使我们的代码更灵活,更容易扩展,更容易维护。各种面向对象的程式设计语言都提供了基本相同的机制:比如类、继承、派生、多态等等。但是又有各自的特色,C# 中的反射机制便是个很重要的工具,好好地利用就能够在实际中发挥很大的作用。    我们来看一个例子:    我的程式中有需要一系列的对象,比如apple,orange…, 要想利用他们,我们就必须在程式中根据用户需要,然后一个个调用 new 操作符来生成他们,这样客户程式就要知道相应的类的信息,生成的代码显然不够灵活。我们能够在代码中不利用具体的类,而只是说明我们需要什么,然后就能够得到我们想要的对象吗?    哦,我们都看设计模式,听吧,很多人都在那里鼓吹他们是如何如何的棒,我们看看怎么样利用他们来解决问题。目标明确了,那我们看看哪个能够符合我们的需要。GoF的《设计模式》都看过吧,似懂非懂的看了一些,那我们看看能够不能够“凑”上去呢?J 嗯,我们的程式考虑的是对象怎么创建的,创建型模式应该符合需要吧。然后我们浏览一下各模式的“意图”部分。呵呵,第一个似乎就撞到彩了,抽象工厂,我们看看吧,“提供一个创建一系列相关或相互依赖对象的接口,而无需指定他们具体的类”,至少“无需指定他们具体的类”符合我们的需要。来看看他的结构吧:    我们的问题似乎用不到这么复杂吧,只有orange,apple等等(应该就是product了),他们显然是一类的,都是fruit,我们只要一个生产水果的工厂就能够,左边的继承层次不要,只有一个FruitFactroy看看行不,先别管他正统不正统,实用就行J    下面的一些东西显然是我们需要的:
Public interface IFruit { }
public class Orange:IFruit
{  
public Orange()  
{   
Console.WriteLine("An orange is got!");  
}
}

public class Apple:IFruit
{  
public Apple()  
{   
Console.WriteLine("An apple is got!");  
}
}
   我们的FruitFactory应该是怎么样呢?上面的结构图中他给的是CreateProductA,那好,我就MakeOrange,更有一个CreateProductB,俺MakeOrange还不行??

public class FruitFactory
{  
public Orange MakeOrange()  
{   
return new Orange();  
}  
public Apple MakeApple()  
{   
return new Apple();  
}
}

怎么使用这个工厂呢?我们来写下面的代码:
string FruitName = Console.ReadLine();
IFruit MyFruit = null;
FruitFactory MyFruitFactory = new FruitFactory();

switch (FruitName)
{  
case "Orange":   
MyFruit = MyFruitFactory.MakeOrange();   
break;  
case "Apple":   
MyFruit = MyFruitFactory.MakeApple();   
break;  
default:   
break;

}
   编译运行,然后在控制台输入想要的东西,呵呵,成功了。沉浸在幸福中的您得意忘形了吧。   但是等等,他似乎还不完美,我假如想要pear,我既要在客户代码中的switch中加入判断,又要在工厂方法中加入MakePear方法,似乎不怎么优雅。更好一点,在工厂中只提供一个方法,MakeFruit,然后传递进一个参数Name,代表我们想要的水果的名称,这样的话,似乎我们的客户代码中的那个switch就能够不要了,相反,在FruitFactory中似乎需要一个,还等什么呢?实现吧。

FruitFactory:
public class FruitFactory
{  
public IFruit MakeFruit(string Name)  
{   
switch (Name)   
{    
case "Orange":     
return new Orange();    
case "Apple":     
return new Apple();    
default:     
return null;   
}  
}
}
  
客户代码:
string FruitName = Console.ReadLine();
IFruit MyFruit;
FruitFactory MyFruitFactory = new FruitFactory();
MyFruit = MyFruitFactory.MakeFruit(FruitName);
   这样看起来好多了,至少我客户代码中不要再写那么一长串的判断代码了。    阿Q精神又在起作用,我们又沉浸在成功的喜悦中了。 嗯,代码似乎能够,应该没有什么改进了。但是似乎又有另外一个声音在说:    “除了一点……”    “嗯? 等等,什么?”    “FruitFactory也有switch啊,看起来也ugly啊!”    “哼,肯定是看《重构》或是《TDD》了,怎么需要那么苛刻!反正闲着也是闲着,看看能够改不?”    既然不要条件判断,传入的只有水果的名称,假如Name = “Apple”,要生成一个Apple的对象,我需要new Apple(),假如我能够这样多好: new MakeItToClass(Name),把字符串转换成一个类。C#中虽然没有上述语法,但是提供了相应的机制,那就是反射。其中一个重要的类就是System.Type类,他对于反射起着核心的作用。我们能够使用 Type 对象的方法、字段、属性和嵌套类来查找有关该类型的任何信息。    另外一个重要的类就是System.Activator,他包含特定的方法,用以在本地或从远程创建对象类型,或获取对现有远程对象的引用。    我们能够先利用Type类获取Name指定的类名的类的Type信息,然后能够根据这个信息利用Activator创建对象。还等什么呢?

public class FruitFactory
{  
public IFruit MakeFruit(string Name)  
{   
IFruit MyFruit = null;   
try   
{    
Type type = Type.GetType(Name,true);    
MyFruit = (IFruit)Activator.CreateInstance(type);   
}   
catch (TypeLoadException e)
{    
Console.WriteLine("I dont know this kind of fruit,exception caught - {0}" ,e.Message);
}    
return MyFruit;  
}
}

原文地址:https://www.cnblogs.com/guyuehuanhuan/p/1948119.html