用一个简单的实例来实现简单工厂模式的应用。
有一个pizza商店生产不同种类的pizza,现在来模拟客户订购pizza的过程。
1.客户告诉pizza商店自己需要的pizza品种。
2.pizza的生产。
根据这个需求,可以进行具体的编写。
class Program
{
static void Main(string[] args)
{
client c = new client();
c.OrderPizza("奶酪");
Console.ReadKey();
}
}
// 工厂类
public class pizzaFactory
{
public static Pizza createPizza(string type)
{
Pizza pizza=null;
switch(type)
{
case "培根":pizza=new BaconPizza();break;
case "奶酪":pizza=new CheesePizza();break;
//。。。后期还可能添加更多的种类
default:break;
}
pizza.make();
return pizza;
}
}
// 客户类
public class client
{
public void OrderPizza(string type)
{
pizzaFactory.createPizza(type);
}
}
// pizza父类
public abstract class Pizza
{
public abstract void make();
}
// CheesePizza类
public class CheesePizza:Pizza
{
public override void make(){Console.WriteLine("生产出了cheesepizza");}
}
// BaconPizza类
public class BaconPizza:Pizza
{
public override void make(){Console.WriteLine("生产出了baconpizza");}
}
优点:
工厂类是整个模式的关键.包含了必要的逻辑判断,根据外界给定的信息,决定究竟应该创建哪个具体类的对象.通过使用工厂类,外界可以从直接创建具体产品对象的尴尬局面摆脱出来,仅仅需要负责“消费”对象就可以了。而不必管这些对象究竟如何创建及如何组织的.明确了各自的职责和权利,有利于整个 软件体系结构span style="font-family: arial, 宋体, sans-serif; font-size: 14px; line-height: 24px; ">的优化。 缺点: 由于工厂类集中了所有实例的创建逻辑,违反了 高内聚 责任分配原则,将全部创建逻辑集中到了一个工厂类中;它所能创建的类只能是事先考虑到的,如果需要添加新的类,则就需要改变工厂类了。 当系统中的具体产品类不断增多时候,可能会出现要求工厂类根据不同条件创建不同实例的需求.这种对条件的判断和对具体产品类型的判断交错在一起,很难避免模块功能的蔓延,对系统的维护和扩展非常不利;