编辑词条简单工厂模式

 

简单工厂模式又可称为静态工厂模式.

上次我介绍的是facade模式,它简单而常用.
说它简单是因为它没有涉及到抽象类和接口,更谈不上多态;
说它常用是因为我们一直在用,分层的涉及是一个很好的应用.

简单工厂模式不在gof23种设计模式之中.
但是在小的项目中也会经常用.
如果对抽象类和接口不太理解的话,
简单工厂模式可以说是一个简单而实用的例子.
这也是把它放在第二种模式中的重要原因之一.

我还是喜欢从现实中找一些例子.
简单工厂就是小工厂,
我感觉应该这样理解"小":
1,工厂的规模小,生成的产品种类少;
比如我们把产品种类在1-5种我们就称它为简单工厂.
而产品大于5种就不太适合简单工厂了.(if-else用的太多)
2,只生成这几种产品,在很长一段时间内,不会在增加其它的产品.
工厂在很长一段时间内生产的产品不会改变.

还是找几个例子吧.
公交车公司的公交一卡通.
分月票卡(每月140次,办证时要照片)和那种按次刷的(没次8毛).
这就是可以用简单工厂.

雕牌洗衣粉厂生产的洗衣粉:超白,加酶,加酶加香,超白加香.

燕京啤酒厂:燕京啤酒

几乎所有的公司都会有几种产品,
以后在有公司找咱们做软件,
简单工厂模式也是比较好用上的,尽量给它用上.
简单工厂模式也是模式,反正这个程序是用上模式了.

有篇文章写的不错,也转一下吧
设计模式－简单工厂模式（SimpleFactory-C#)
《java与模式》上面那本书上的例子举的是园丁和果园的例子，
学习设计模式最好在生活中自己找个例子实践一下，
下面是我自己的一个例子，是讲快餐店的例子，快餐店提供很多食物，
比如面条，米饭，面包。
首先定义了一个Food接口，
然后这些食物都从它来继承，
定义了一个大厨他包办所有食物的制作工作，
这就是我所理解的简单工厂模式的概念，

下面是源代码：

using System;

namespace SimpleFactoryPattern
{
/// <summary>
/// 简单工厂模式示例
/// </summary>
class SimpleFactoryPattern
{
//定义Food接口
public interface Food
{
//烹饪
void Cook();
//卖出
void Sell();

}

//Noodle

public class Noodle:Food
{
public Noodle()
{
Console.WriteLine("/nThe Noodle is made..");
}
private int price;

//面条Noodle的Cook方法接口实现
public void Cook()
{
Console.WriteLine("/nNoodle is cooking...");
}

//面条Noodle的Sell方法接口实现
public void Sell()
{
Console.WriteLine("/nNoodle has been sold...");
}
public int Price
{
get{return this.price;}
set{price=value;}
}
}

//Rice
public class Rice:Food
{
public Rice()
{
Console.WriteLine("/nThe Rice is made ..");
}
private int price;
public void Cook()
{
Console.WriteLine("/nRice is cooking...");
}
public void Sell()
{
Console.WriteLine("/nRice has been sold...");
}
public int Price
{
get{return this.price;}
set{price=value;}
}
}

//Bread
public class Bread:Food
{
public Bread()
{
Console.WriteLine("/nThe Bread is made....");
}
private int price;
public void Cook()
{
Console.WriteLine("/nBread is cooking...");
}
public void Sell()
{
Console.WriteLine("/nBread has been sold...");
}
public int Price
{
get{return this.price;}
set{price=value;}
}
}

//定义大厨，他包办这个快餐店里的所有Food,包括面条，面包和米饭
class Chef
{
public static Food MakeFood(string foodName)
{
try
{
switch(foodName)
{
case "noodle": return new Noodle();
case "rice":return new Rice();
case "bread":return new Bread();
default:throw new BadFoodException("Bad food request!");
}
}
catch(BadFoodException e)
{
throw e;
}
}

}

//异常类，该餐馆没有的食品
class BadFoodException: System.Exception
{
public BadFoodException(string strMsg)
{
Console.WriteLine(strMsg);
}
}

/// <summary>
/// 应用程序的主入口点。
/// </summary>
[STAThread]
static void Main(string[] args)
{
Food food=Chef.MakeFood("bread");
food.Cook();
food.Sell();
Console.ReadLine();
}
}
}

最后,有的人可能会说.涉及模式根本无用武之地,其实确实如此.
最开始编程的人时候,没有几个用涉及模式的.
还是例说:
企业应用程序主要还是和数据库打交道.
比如我们网站的会员需要注册.
在数据库中有一个会员信息表.
随着业务的发展,我们还会有vip会员.
这时候我们是怎么做的呢?
在数据库会员信息表中加一个是否vip会员的字段.
这样会有什么缺点呢?
vip会员当然会有一些普通会员没有的属性,
这时候在数据库会员信息表中还会添加其它的一些字段.
但普通会员有的属性vip会员也可能没有.
而且在改数据库的时候,
可能会把数据库改错了,
原来已经测试无误的代码可能会产出新的bug.

如果用涉及模式来涉及,
可以在数据库中再添加一个vip会员信息表.
此表记录vip会员信息,与普通会员信息表不再有联系.
这样我们的简单工厂模式可以应用上了.
不管普通会员还是vip会员,都有用户名和密码

而其它的信息,普通会员普通会员有普通会员的属性

而vip会员有vip会员的属性.

这就是我从一个简单应用中提炼出来的设计模式.

可见用不用设计模式,用不用面向对象不全是我们程序员的事,
而是其它的一些因素引导着我们不去往这方面想.
在一些情况下,
比如数据库设计的不合理或原来的程序都是面向过程的,
而你用了设计模式也不见得比不用强.