不一样的工厂模式(设计模式六)
前言
介绍工厂模式,展示工厂模式的演化。
正文
看下工厂模式是如何演化的。
public interface ISplitter
{
void Splite();
}
class BinarySplitter : ISplitter
{
public void Splite()
{
throw new NotImplementedException();
}
}
class TxtSplitter : ISplitter
{
public void Splite()
{
throw new NotImplementedException();
}
}
class VideoSplitter : ISplitter
{
public void Splite()
{
throw new NotImplementedException();
}
}
假如有上面这些东西,分别是字节切割、文本切割、声音切割。
然后有一个类调用:
public class Application
{
public void doSomeThing()
{
ISplitter splitter = new TxtSplitter();
}
}
那么问题来了,这样写好不好?
答案是不好,因为违反了依赖倒置原则。
依赖倒置原则(Dependence Inversion Principle)是程序要依赖于抽象接口,不要依赖于具体实现。简单的说就是要求对抽象进行编程,不要对实现进行编程,这样就降低了客户与实现模块间的耦合。
new TxtSplitter() 依赖了具体的实现了,所以不符合。
那么既然不能依赖具体的类,那么如何获取到TxtSplitter 对象呢?
既然不能依赖于类,那么可以用方法返回。
class SplitterFactory
{
public static ISplitter CreateSplitter()
{
return new BinarySplitter();
}
}
好吧。
然后:
ISplitter splitter = SplitterFactory.CreateSplitter();
看这一行:ISplitter splitter = SplitterFactory.CreateSplitter();
splitter 是接口没有依赖具体的实现,BinaryFactory.CreateSplitter()也没有直接依赖具体的实现。
SplitterFactory.CreateSplitter()怎么能说没有直接依赖具体的实现呢?这个怎么看呢?要从当前类Application来看,从Application来看,显示创建一个SplitterFactory.CreateSplitter()
Application是不知道到底SplitterFactory.CreateSplitter() 创建了什么,只有SplitterFactory知道。所以在Application没有直接依赖具体实现。
但是问题就是application 没有直接具体依赖,但是却有间接具体依赖。
虽然在Application中解决了,但是在SplitterFactory还是有依赖BinarySplitter,这样就形成了间接依赖。
就是这样的。
这样又一个什么坏处呢?现在不用去修改Application 的代码了,因为抽象的,但是如果现在和Application 模型相同的,然后需要用到TxtSplitter。
那么模型就是这样的。
也就是说SplitterFactory的不稳定性导致了,导致了Application 复用性不行,增加了耦合。
那么可以这样:
public abstract class SplitterFactory
{
public abstract ISplitter CreateSplitter();
}
现在就不依赖任何东西了。
那么这样具体的工厂就要具体去实现。
class BinarySplitterFactory : SplitterFactory
{
public override ISplitter CreateSplitter()
{
return new BinarySplitter();
}
}
class TxtSplitterFactory : SplitterFactory
{
public override ISplitter CreateSplitter()
{
return new TxtSplitter();
}
}
class VideoSplitterFactory : SplitterFactory
{
public override ISplitter CreateSplitter()
{
return new VideoSplitter();
}
}
然后Application 这样写:
public class Application
{
SplitterFactory factory;
public Application(SplitterFactory factory)
{
this.factory = factory;
}
public void doSomeThing()
{
ISplitter splitter = factory.CreateSplitter();
}
}
这样子,下图就形成了稳定的。
干了这么多其实就是为了Application的稳定性。
概念图
工厂模式,定义一个用于创建对象的接口,让子类决定实例化哪一个类。Factory Method使得一个类的实例化延迟到子类。
Factory Methor 模式用于隔离对象的使用者和具体类型之间耦合关系。通过面向对象的手法,将所要创建的具体对象工作延迟到子类,从而实现一种扩展,较好的解决了这种紧耦合关系。缺点在于创建方法和参数相同,方法倒是好事,参数倒是一个硬要求。
相关文章
- 设计模式之工厂模式_单例模式和工厂模式
- java工厂模式实例(设计模式)「建议收藏」
- 抽象工厂设计模式例题_什么是抽象工厂模式
- C#设计模式——(结构型-外观设计模式)
- JS设计模式之工厂模式
- 【设计模式 09】建造者模式(生成器)
- 详解设计模式:中介者模式
- 设计模式之工厂模式-抽象工厂模式
- Java设计模式之建造者模式
- Java设计模式之状态模式
- 设计模式 | 结构型 | 组合模式
- 面向对象设计模式--单例模式详解+实际应用(Java)
- Go 语言实现创建型设计模式 - 工厂模式
- 设计模式系列整理-01-工厂模式
- 抽象工厂模式 创建型 设计模式(四)详解程序员
- 工厂方法模式 创建型 设计模式(三)详解程序员
- java设计模式之单例模式详解架构师
- 设计模式之职责链模式(行为型)详解架构师
- 设计模式:简单工厂模式详解架构师
- 设计模式之简单工厂模式详解大数据
- PHP设计模式_注册树模式详解编程语言
- Oracle数据库开启归档模式(oracle开归档)
- php设计模式之工厂模式
- php设计模式Command(命令模式)
- php设计模式Factory(工厂模式)
- java设计模式之装饰模式详细介绍
- android设计模式之单例模式详解
- C#设计模式之单例模式实例讲解