如题,已经知道咱们今天要谈的是工厂。提到这个词,还和我小时候的梦想有关。小时候,总喜欢吃小动物饼干,小熊的小鹿的小马的小动物饼干陪伴了我大半个童年。要是有一天,我有个工厂,想吃多少就能制作多少 该有多好,就不用把它们种在地里等着来年发芽了。
今天有这个机会,我先生产饼干试一试~
制作一次饼干,自然要标明它的重量和成分。当然了,我还有各种形状的饼干。先做一些小熊和小鹿的让大伙尝尝。
//简单工厂
namespace 饼干
{
class Program
{
class 饼干//主人说要知道我的体重和成分,体重好害羞的说
{
public void 重量()
{Console.WriteLine("50克"); }
public void 成分()
{
Console.WriteLine("我由面粉和糖做成的");
}
}
class 小熊饼干:饼干 //根据“饼干” 又做了小鹿和小熊两个模型
{ }
class小鹿饼干 : 饼干
{ }
//简单工厂 通过主人在客户端输入的种类,简单工厂类来 逻辑判断实例哪种饼干
class SimpleFactroy
{
public static 饼干 制作饼干(string type)
{
饼干 result = null;
switch (type)
{ case "小熊饼干":
result = new 小熊饼干();
break;
case "小鹿饼干":
result = new 小鹿饼干();
break;
}
return result;
}
}
static void Main(string[]args)
{
//客户端代码,主人想生产哪种饼干,就可以在这里发送命令
饼干 A =SimpleFactroy.制作饼干("小熊饼干");
A.重量();
A.成分();
饼干 B =SimpleFactroy.制作饼干("小熊饼干");
B.重量();
B.成分();
饼干 C =SimpleFactroy.制作饼干("小鹿饼干");
C.重量();
C.成分();
}
}
}
简单工厂(详见链接)看起来也不错。可是刚写完,我的吃货舍友就来了。她们说,还想吃小兔子饼干。
更改过程如图(红色为更改)
我就要先去做一个小兔子的模型(即加功能类),然后再去修改工厂,在工厂中加一个‘case’判断过程。我们很明显的看出,这样不好,简单工厂类都要修改,这不把开放-封闭原则都破坏了?
于是,就有了下面的内容----工厂方法。
namespace 饼干
{
class Program
{
static void Main(string[] args)
{
//客户端代码
IFactory factory = new 小鹿饼干工厂();
饼干 binggan = factory.制作饼干();
binggan.重量();
binggan.成分();
}
class 饼干//来看看我的基本属性
{
public void 重量()
{ Console.WriteLine("50克"); }
public void 成分()
{
Console.WriteLine("我由面粉和糖做成的");
}
}
class 小熊饼干:饼干 //根据“饼干” 又做了小鹿和小熊两个模型
{ }
class 小鹿饼干 : 饼干
{ }
//饼干工厂
interface IFactory
{
饼干 制作饼干();
}
//小熊饼干工厂
class 小熊饼干工厂:IFactory
{
public 饼干 制作饼干()
{
return new 小熊饼干();
}
}
//小鹿饼干工厂
class 小鹿饼干工厂:IFactory
{
public 饼干 制作饼干()
{
return new 小鹿饼干();
}
}
}
}
那么还和上面一样,如果再添加一个小兔子饼干,是什么效果呢?我们用图来直观的看一下(采用的接口方法,故画成接口方便联系)。
理解了简单工厂的设计理念及实现方法再去理解相对复杂的工厂方法与抽象工厂有着水到渠成的效果。很明显我们从图中看出,工厂方法并不需要修改类,增加功能的时候,需要添加相应的类,并再客户端进行修改就可以了。
这样的好处是,遵循了开放-封闭的原则。体会两幅图的不同,我们便可以理解到两个设计模式的区别。但是,也存在缺点是,工厂方法人需要在客户端进行修改。怎么改进呢?系列博客,敬请关注。