简介
工厂方法模式
是针对的一种产品,抽象工厂模式
是针对一系列产品的解决方案- 提供一个创建一系列相关或者相互依赖的接口,而无需指定他们的具体类
- 通常包含
抽象工厂
工厂基类,其接口子类必须实现具体工厂
工厂子类,在这里创建产品多个抽象产品
父指针指向的对象每个抽象产品对应的具体产品
子类指针指向的对象
背景
- 使用者清楚的知道哪个产品对应哪个工厂,然后他只需要去实例化这个工厂就可以。
- 比如collection 中的迭代器 ,你使用迭代器之前你就该知道你的collection是什么类别,当然你就知道该调什么工厂去实现
- 只是需要一种产品,而不想知道也不需要知道究竟是哪个工厂为生产的,即最终选用哪个具体工厂的决定权在生产者一方,它们根据当前系统的情况来实例化一个具体的工厂返回给使用者,而这个决策过程这对于使用者来说是透明的。(来自百度百科,目前我也不懂。。)
一言以蔽之
有了抽象工厂以后,每个产品的生产就都交给其子类(具体)实现了,遵循了抽象封闭原则
//抽象产品
class CellPhone
{
};
class EarPhone
{
};
class XiaoMiCellPhone : public CellPhone
{
public:
};
class MeizuCellPhone : public MeizuCellPhone
{
};
class XiaoMiEarPhone : public EarPhone
{
};
class MeizuEarPhone : EarPhone
{
};
//抽象工厂
class Factory
{
public:
virtual CellPhone createCellPhone() = 0 ;
virtual EarPhone createEarPhone() = 0 ;
};
//具体工厂
class XiaoMiFactory : public Factory
{
public:
CellPhone createCellPhone()
{
return new XiaoMiCellPhone ;
}
EarPhone createEarPhone()
{
return new XiaoMiEarPhone() ;
}
};
class MeizuFactory : public Factory
{
public:
CellPhone &createCellPhone()
{
return new MeizuCellPhone ;
}
EarPhone &createEarPhone()
{
return new MeizuEarPhone() ;
}
};
//客户端
Factory *factory = new XiaoMiFactory ; // 换Meizu只需要改这里
CellPhone *cell = &(factory->createCellPhone());
review
- 如果这个程序给我做的话,我能想到把Animal给抽象出来,也就是之前所说的简单工厂模式,这里是把创建Animal的工厂也给抽象了,这样就克服了简单工厂违背的“开放-封闭原则”
- 因此也解决了简单工厂里超大的switch的问题,本身简单工厂里的switch就处理了多个产品,所以耦合很重,现在再也不用担心会把这个switch撑爆啦!
advantage
- 当引进新的产品时,不需要修改具体工厂方法
- 降低了客户程序与产品间的耦合
- 当客户端更换对象时,不需要做大的改动(前提是已经有这个对象的工厂了)
disadvantage
- 每增加一类产品,就需要增加相应的产品工厂,增加了开发量
使用场合
见背景里面的描述,当然希望下次能把这两个分开叙述
Tips
- 下一章更新抽象工厂模式 PS: 这里不是已经有了抽象工厂吗,怎么还有一个抽象工厂模式?