简单工厂模式的介绍
说到简单工厂,自然的第一个疑问当然就是什么是简单工厂模式了?
在现实生活中工厂是负责生产产品的,同样在设计模式中,简单工厂模式
我们也可以理解为负责生产对象的一个类, 我们平常编程中,当使用
”new”关键字创建一个对象时,此时该类就依赖与这个对象,也就是
他们之间的耦合度高,当需求变化时,我们就不得不去修改此类的源码,
此时我们可以运用面向对象(OO)的很重要的原则去解决这一的问题,
该原则就是——封装改变,既然要封装改变,自然也就要找到改变的代码,
然后把改变的代码用类来封装,这样的一种思路也就是我们简单工厂模式的实现方式了。
优点与缺点
看完简单工厂模式的实现之后,你和你的小伙伴们肯定会有这样的疑惑(因为我学习的时候也有)——这样我们只是把变化移到了工厂类中罢了,好像没有变化的问题,因为如果客户想吃其他菜时,此时我们还是需要修改工厂类中的方法(也就是多加case语句,没应用简单工厂模式之前,修改的是客户类)。我首先要说:你和你的小伙伴很对,这个就是简单工厂模式的缺点所在(这个缺点后面介绍的工厂方法可以很好地解决),然而,简单工厂模式与之前的实现也有它的优点:
简单工厂模式解决了客户端直接依赖于具体对象的问题,客户端可以消除直接创建对象的责任,而仅仅是消费产品。简单工厂模式实现了对责任的分割。
简单工厂模式也起到了代码复用的作用,因为之前的实现(自己做饭的情况)中,换了一个人同样要去在自己的类中实现做菜的方法,然后有了简单工厂之后,去餐馆吃饭的所有人都不用那么麻烦了,只需要负责消费就可以了。此时简单工厂的烧菜方法就让所有客户共用了。(同时这点也是简单工厂方法的缺点——因为工厂类集中了所有产品创建逻辑,一旦不能正常工作,整个系统都会受到影响,也没什么不好理解的,就如事物都有两面性一样道理)
虽然上面已经介绍了简单工厂模式的缺点,下面还是总结下简单工厂模式的缺点:
工厂类集中了所有产品创建逻辑,一旦不能正常工作,整个系统都会受到影响(通俗地意思就是:一旦餐馆没饭或者关门了,很多不愿意做饭的人就没饭吃了)
系统扩展困难,一旦添加新产品就不得不修改工厂逻辑,这样就会造成工厂逻辑过于复杂。
了解了简单工厂模式之后的优缺点之后,我们之后就可以知道简单工厂的应用场景了:
当工厂类负责创建的对象比较少时可以考虑使用简单工厂模式()
客户如果只知道传入工厂类的参数,对于如何创建对象的逻辑不关心时可以考虑使用简单工厂模式
示例:
[C#] 纯文本查看 复制代码 namespace _016
{
//抽象类(菜)
public abstract class Food
{
//抽象方法,输出点了的菜
//抽象方法接下来会被重写,直接调用抽象方法就可以
public abstract void Print();//抽象方法没有方法体
}
//打印土豆丝 类
//重写抽象方法
public class tds : Food
{
public override void Print()
{
Console.WriteLine("来份土豆丝");
}
}
//打印西红柿 类
//抽血抽象方法
public class xhs : Food
{
public override void Print()
{
Console.WriteLine("来份西红柿");
}
}
//工厂类 厨师
public class cs
{
public static Food CreateFood(string t)
{
Food food = null;
if (t.Equals("土豆丝"))
{
food = new tds();
}
else if (t.Equals("西红柿"))
{
food = new xhs();
}
return food;
}
}
class Program
{
static void Main(string[] args)
{
Food food1 = cs.CreateFood("土豆丝");
food1.Print();
Food food2 = cs.CreateFood("西红柿");
food2.Print();
//手动输入土豆丝或是西红柿
try
{
Food food3 = cs.CreateFood(Console.ReadLine());
food3.Print();
}
catch { }
Console.ReadKey();
}
}
}
|
|