简单工厂模式

最新推荐文章于 2024-09-23 17:11:27 发布

dexFeng

最新推荐文章于 2024-09-23 17:11:27 发布

阅读量167

点赞数

分类专栏：设计模式文章标签：设计模式

本文链接：https://blog.csdn.net/dexFeng/article/details/109310296

版权

设计模式专栏收录该内容

0 篇文章 0 订阅

订阅专栏

简单工厂

目的：主要是记录下个人觉得比较好的网址以及体会。

需要了解的UML类图的画法以及每种关系中的通常表示的类结构以及表示。
继承/接口比较明显；关联包含组合跟聚合（注意组合与聚合的区别，组合强于聚合，组合的部分无法单独存在，譬如公司与部门）。另外关联一般表现为A has B(B一般作为A的成员变量)，可以有自关联，单项关联，双向关联。依赖的关系较弱(一般在方法中体现，局部变量/方法返回值/方法形参)，需要避免双向依赖。

具体参考以下讲类图的：
https://blog.csdn.net/ibukikonoha/article/details/80643959
https://www.cnblogs.com/mabaoqing/p/10316120.html

学习设计模式比较好的网址：
https://www.jianshu.com/nb/7614011
此系列讲解的比较好，有空可以多看几遍。

以下内容仅仅就简单工厂模式的代码进行一个个人分析，网址：https://www.jianshu.com/p/819fbfb68b64

上面网址的类图 ![在这里插入图片描述](https://img-blog.csdnimg.cn/20201027144549462.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2RleEZlbmc=,size_16,color_FFFFFF,t_70#pic_center)

可以看到Drink/Coke/OrangeJuice/PlumJuice 是相关的产品类（产品类） Cousins是工厂类（工厂类，用于生产产品） XiaoGuang 作为客户端调用类。（客户端类）

public class XiaoGuang {
    public static void main(String[] args) {
        Drink drink = Cousins.create("可乐");
        drink.make();

//        Drink drinkCoke = new Coke();
//        drinkCoke.make();
    }
}

以上设计模式的主要好处：单一职责原则，面向接口编程。
客户端的调用只会与抽象产品以及工厂类产生关联，而不会关联到对应的细节。客户端需要指明我需要什么样的产品

坏处：不满足对修改关闭对扩展开放的原则。
假如现在需要增加一种新的饮料类型。则需要修改工厂类(也就是Cousins)。

那如何让其满足开闭原则呢？

public class XiaoGuang {
    public static void main(String[] args) {
//        Drink drink = Cousins.create("可乐");
//        drink.make();

        Drink drinkCoke = new Coke();
        drinkCoke.make();
    }
}

可以直接在客户端类调用对象的生产代码，这种方式足够简单，不需要Cousins类（工厂类）。满足了开闭原则，但是对外暴露了部分细节。
客户端依赖的类除了Drink还会依赖Coke,OrangeJuice,PlumJuice类，这种方式也很普遍，我们在使用集合类List的时候就经常这么用到。

那现在这2种方式的优劣就很明显了：
一种是用一个工厂类来处理对象的生产，客户端只需要跟工厂类打交道，但是新增产品就会涉及到修改工厂类
一种是不使用工厂类，客户端关联的类会增多，但是对修改关闭，对扩展开放。

每一个设计模式都不是万能的，都只能解决特定场景的某一个或者两个问题，或许引入进来之后还会违背其它的原则。譬如上面的例子。
而衡量代码结构设计的好坏，个人觉得非常重要的几点：

是否满足了单一职责原则（这个原则几乎所有的设计模式都会遵循，从这个原则的角度去看jdk/android 源码你会有不一样的体会），
客户端与类之间的耦合是否过多（最小知道原则），这个包括客户端与底层类之间的关联/依赖（关联跟依赖的耦合度是不一样的），是否过多的知道底层类细节(知道构造函数/与知道方法调用的耦合度也是不一样的，当然有些模式要区别对待，譬如责任链模式直接用客户端调用就不可避免的对外暴露内部方法，但如果外层再封装一个调用类就很好的对客户端屏蔽了细节，这种封装类的做法与外观模式很像)，
是否满足了开闭原则，开闭原则最大好处是提高软件的可维护性。而开闭原则是通过里氏替换原则+依赖倒置原则+面向接口原则（这3个原则在我个人的理解中感觉差不太多就是面向接口编程，但细节上有差异，比如依赖倒置强调方法的传值传参使用接口或者抽象类，接口隔离原则强调接口的粒度划分，里氏替换原则与策略模式必比较像，强调子类的扩展) 来共同实现的。

代码的结构依赖于模式的应用，而模式的应用又依赖于需求常见的精准把握。