设计模式解析一 工厂模式的不同

一. 前言

作为一个程序开发者,设计模式的学习总是不变的真理,也许在程序员职业生涯的前期学习设计模式还知识死记硬背,不知道如何应用的话,那在工作一段时间以后再回过头来学习,会发现前人的总结包含着无数的智慧。
用百科的话来说,设计模式是一套被反复使用、多数人知晓的、经过分类的、代码设计经验的总结。
一千个人有一千个哈姆雷特,每个人学习设计模式都会有自己的理解,接下来这个系列就是我对设计模式的理解,记录下来,也作为自己这段时间的学习总结。


二. 工厂模式

接下来的设计模式解析会进行一个分组的总结,把一些结构或者容易搞混的设计模式会合并在一起来进行分析,然后分析其中的不同。
java的是面向对象的编程,我们到处都在同对象打交道,自然少不了创建这样那样的对象,如何得到对象呢,比如这个代码:

Deserializer deserializer = new LocationInfoDeserializer();

有时候需要根据条件来获取不同的实现:

        //解码器
        Deserializer deserializer;
        if (UploadMsgType.LOCATION_INFO.equals(msgType)) {
            deserializer = new LocationInfoDeserializer();
        } else if (UploadMsgType.MEDIA_INFO.equals(msgType)) {
            deserializer = new MediaInfoDeserializer();
        }

这样的确是正确的,但这存在一些问题:

  • 如果实现类需要替换,我们需要去每一个new的地方去修改
  • 如果需要根据不同的条件来创建不同的实现,这种if判断代码可能充斥的到处都是

回忆一下,我们编写业务代码是不是总是先定义一个Serviceinterface,然后在定义一个ServiceImpl的实现,那么有没有想过为什么要这么做呢?
设计模式的思想告诉我们要做接口隔离,针对接口编程,而不是针对实现的编程,这样我们只要实现遵循了接口的规范,我们就可以任意的替换实现,而不必担心对上层应用造成影响。
Spring是一个伟大的框架,他为我们隐藏了很多复杂的细节,让我们的开发更加简单,实际上Spring框架中蕴含着丰富的设计模式,比如@Service注解,它为我们实现了工厂模式的过程,而隐藏了工厂模式的细节,但总有一些时候是需要我们自己去使用设计模式的,这时候思想的积累就尤为重要了。

1. 简单工厂模式

回到解码器这段代码,试想一下,如果这段代码揉进了业务代码里面会有多糟糕,这是一个解码器,需要根据不同的消息类型来得到解码器,消息类型增加的可能性太大了!
我们应该封装这部分,封装变化这是不变的真理:

public class SimpleDeserializerFactory {
    
    public static Deserializer produce(UploadMsgType msgType) {
        Deserializer deserializer = null;
        if (UploadMsgType.LOCATION_INFO.equals(msgType)) {
            deserializer = new LocationInfoDeserializer();
        } else if (UploadMsgType.MEDIA_INFO.equals(msgType)) {
            deserializer = new MediaInfoDeserializer();
        }
        return deserializer;
    }
    
}

所有需要解码器的地方只要调用这个方法就好,无论增加多少种消息类型,我们只需要在这里增加一段else if即可,没错这就是简单工厂模式,也许这都不能称之为一个设计模式,只是一种编码习惯。
下面看类图:

简单工厂模式

2. 工厂方法模式

上面的简单工厂让我们能够把获取解码器的部分进行了封装,但上面这是一个极简单的例子,每一个解码器的实例化都只是简单的进行一次new,但现实中总不是这样,对象和对象之间存在太多的依赖关系,一个对象需要依赖其他几个,甚至十几个对象,如果还像上面这样,那我们的代码会变成非常繁杂,大量的setnew:

public static Deserializer produce(UploadMsgType msgType) {
    if (UploadMsgType.LOCATION.equals(msgType)) {
        LocationInfoDeserializer locationInfoDeserializer = new LocationInfoDeserializer();
        LocationService locationService = new LocationService();
        locationInfoDeserializer.setLocationService(locationService);
        return locationInfoDeserializer;
    } else if (UploadMsgType.MEDIA.equals(msgType)) {
        MediaInfoDeserializer mediaInfoDeserializer = new MediaInfoDeserializer();
        MediaInfoService mediaInfoService = new MediaInfoService();
        mediaInfoDeserializer.setMediaInfoService(mediaInfoService);
        return mediaInfoDeserializer;
    }
    return null;
}

这上面每个解码器都只有一个依赖,看起来还好,如果有十个呢?
未来随着业务的发展,将会出现改变,如果位置解码器出现改变,增加了依赖,我们将会修改这部分的代码,但面向对象的基本原则告诉我们一个类应当只有一个发生变化的原因。但上面的类出现了两个:

  • 位置解码器发生变化
  • 多媒体解码器发生变化

那么我们能不能更进一步,把上面的变化继续封装起来呢?
设计模式教我们要面向接口编程,那么我们能不能设计一个接口,接口返回解码器,然后设计不同的实现来返回不同的解码器呢?

public interface DeserializerFactory {

    Deserializer create();

}
public class LocationInfoDeserializerFactory implements DeserializerFactory {

    @Override
    public Deserializer create() {
        LocationInfoDeserializer deserializer = new LocationInfoDeserializer();
        LocationService service = new LocationService();
        deserializer.setLocationService(service);
        return deserializer;
    }

}
public class MediaInfoDeserializerFactory implements DeserializerFactory {
    @Override
    public Deserializer create() {
        MediaInfoDeserializer deserializer = new MediaInfoDeserializer();
        MediaInfoService service = new MediaInfoService();
        deserializer.setMediaInfoService(service);
        return deserializer;
    }

}

你看,现在变化的地方都被我们封装了起来,再回到刚才的方法,让我们对这个方法再进行一些改造:

public class SimpleDeserializerFactory {

    public static DeserializerFactory produce(UploadMsgType msgType) {
        DeserializerFactory factory = null;
        if (UploadMsgType.LOCATION.equals(msgType)) {
            factory = new LocationInfoDeserializerFactory();
        } else if (UploadMsgType.MEDIA.equals(msgType)) {
            factory = new MediaInfoDeserializerFactory();
        }
        return factory;
    }

    public static void main(String[] args) {
        UploadMsgType msgType = UploadMsgType.LOCATION;
        DeserializerFactory factory = SimpleDeserializerFactory.produce(msgType);
        Deserializer deserializer = factory.create();
    }
}

你看这一次,这个类又只剩下了一个改变的原因,那就是出现新增消息类型的时候。
这就是工厂方法模式,下面看类图:

工厂方法模式

定义

工厂方法模式定义了一个创建对象的接口,但由子类决定要实例化的类是哪一个,工厂方法让类把实例化推迟到子类。
这也是著名的依赖倒置原则,要依赖抽象,而不是依赖具体的实现类。

3. 抽象工厂模式

接下来,需求又来了,客户希望我们不仅仅能够进行解码,还希望我们能够对解码后的内容进行存储和一些特殊的处理,而不同的内容进行存储的方式也是不同的,所以我们抽象一下,可以知道,不论是位置还是多媒体数据我们都需要一个解码器,一个仓库服务还有一个处理器,这是他们的相同之处,不同的只是实现。
首先我们增加一个仓库服务的接口:

public interface StorageService {

   void save(Object o);

}

然后增加一个存储位置和存储多媒体的仓库服务实现:

public class MediaStorageService implements StorageService {

    @Override
    public void save(Object o) {
        System.out.println("save the media");
    }

}
public class LocationStorageService implements StorageService {

    @Override
    public void save(Object o) {
        System.out.println("save the location");
    }

}

接下来创建一个消息处理工厂的接口:

public interface MsgProcessFactory {

    Deserializer createDeserializer();

    StorageService createStorage();
}

针对不同的消息类型,创建不同的工厂实现:

public class MediaMsgProcessFactory implements MsgProcessFactory {
    @Override
    public Deserializer createDeserializer() {
        return new MediaInfoDeserializer();
    }

    @Override
    public StorageService createStorage() {
        return new MediaStorageService();
    }

}
public class LocationMsgProcessFactory implements MsgProcessFactory {

    @Override
    public Deserializer createDeserializer() {
        return new LocationInfoDeserializer();
    }

    @Override
    public StorageService createStorage() {
        return new LocationStorageService();
    }

}

我们还需要一个消息处理器,来整合这些消息处理的过程:

public interface MsgProcess {

    void process(byte[] bytes);

}

针对不同消息的不同处理过程:

public class MediaMsgProcess implements MsgProcess {

    private MsgProcessFactory msgProcessFactory;

    public MediaMsgProcess(MsgProcessFactory msgProcessFactory) {
        this.msgProcessFactory = msgProcessFactory;
    }

    @Override
    public void process(byte[] bytes) {
        Deserializer deserializer = msgProcessFactory.createDeserializer();
        Object o = deserializer.decode(bytes);
        StorageService storageService = msgProcessFactory.createStorage();
        storageService.save(o);
        // TODO 其他针对多媒体的业务逻辑
    }

}
public class LocationMsgProcess implements MsgProcess {

    private MsgProcessFactory msgProcessFactory;

    public LocationMsgProcess(MsgProcessFactory msgProcessFactory) {
        this.msgProcessFactory = msgProcessFactory;
    }

    @Override
    public void process(byte[] bytes) {
        Deserializer deserializer = msgProcessFactory.createDeserializer();
        Object o = deserializer.decode(bytes);
        StorageService storageService = msgProcessFactory.createStorage();
        storageService.save(o);
        // TODO 其他针对位置的业务逻辑
    }

}

然后让我们运行他:

public static void main(String[] args) {
        byte[] bytes = new byte[1024];
        MsgProcessFactory factory = new LocationMsgProcessFactory();
        MsgProcess process = new LocationMsgProcess(factory);
        process.process(bytes);

        factory = new MediaMsgProcessFactory();
        process = new MediaMsgProcess(factory);
        process.process(bytes);

    }

输出:

save the location
save the media
定义

抽象工厂模式的重点在于提供一个接口,用于创建相关或依赖对象的家族,而不需要明确具体的实现。
在这里,我们的解码器和仓库服务就是相关的对象家族,因为多媒体的解码器应该和多媒体仓库服务一起使用,如果用错了就会出现致命的后果。而无论什么消息需要处理的时候都需要一个解码器和一个仓库服务,所以这才是抽象,实际应用中,抽象自然没有这么简单,是需要仔细思考的。

抽象工厂模式和工厂方法模式的不同

为什么抽象工厂模式和工厂方法模式相比只是在一个工厂接口里多了几个方法却被称为抽象的原因,在我理解,抽象描述的就是抽象出对不同的业务逻辑处理中相同的部分,如果用肉包子来举例,我们可以试着抽象,制作一个鲜肉包子、酱肉包子、牛肉包子的做法是不同的,但是他们相同的地方在哪呢?

  • 都需要面粉
  • 都需要肉(尽管肉可能是不同的)
  • 都需要调料(调料可能也是不同的)

这就是抽象。
抽象工厂模式的类图就不给了,大家试着自己画一下吧。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 214,717评论 6 496
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,501评论 3 389
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 160,311评论 0 350
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,417评论 1 288
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,500评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,538评论 1 293
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,557评论 3 414
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,310评论 0 270
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,759评论 1 307
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,065评论 2 330
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,233评论 1 343
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,909评论 5 338
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,548评论 3 322
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,172评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,420评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,103评论 2 365
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,098评论 2 352

推荐阅读更多精彩内容

  • 链接:https://github.com/WiKi123/DesignPattern作者: WiKi123(gi...
    树懒啊树懒阅读 3,495评论 0 2
  • Swift1> Swift和OC的区别1.1> Swift没有地址/指针的概念1.2> 泛型1.3> 类型严谨 对...
    cosWriter阅读 11,094评论 1 32
  • 本文首发于个人博客:Lam's Blog - 谈谈23种设计模式在Android源码及项目中的应用,文章由Mark...
    格子林ll阅读 4,640评论 1 105
  • 一生所爱始终只有你一人而已,你是一缕缕春风,吹得我满心欢喜;你是冬日里温暖的阳光,明媚而灿烂;你是我清澈透...
    王子懿阅读 269评论 0 1
  • 一声问候,随着新年的喜庆悄然送达 一份深情,伴着友谊的甜蜜悠然发酵 一种情谊,听着欢快的颂歌吟唱恒久 一道祝福,顺...
    微笑nice阅读 192评论 0 1