Java中23种设计模式之静态工厂方法-CFANZ编程社区

初步接触设计模式，初步了解静态工厂方法，了解还不全面，我们先一步步了解一下。

一、背景介绍

工厂模式是设计模式的一种，设计模式是自程序开发逐渐就有的，提高开发效率的一种设计思路，先前的开发者们一直在用，只是后来在《Effective Java》中总结了下，就是现在的23种设计模式。
书中共有三个层面的内容：

一、把程序开发过程中在不同系统中多次使用过的成功设计的模式进行总结，用名称-问题-解决方案-实用效果这几个要素来描述；

二、提出了面向对象开发中“针对接口编程而不是针对实现编程”，“优先使用组合而不是继承”的总体设计思路；

三、就是基于上面的设计思路所形成的常用的设计模式，也就是现在流传最广的23种常见的设计模式；

当前说的设计模式是针对面向对象,而不是面向过程

二、知识剖析

1.工厂模式

工厂是为了实现对构造过程（创建过程）的封装。也是设计原则的体现。工厂模式是一种创建型的设计模式，主要思想就是替代new为我们创建对象，工厂可以选择创建对象的方法，对这个构造过程（创建方法）进行选择的逻辑就是工厂模式的逻辑。
这样也是为了给以后的系统带来更大的可扩展性，实现低耦合。

2.工厂模式大概有三种

简单工厂模式
工厂方法模式
抽象工厂模式

3.简单（静态）工厂模式

简单工厂模式是最初自然而然就有的设计思想，它只是把创建过程比较自然的封装了一下，又称为静态工厂模式，是直接根据条件决定创建的产品。

4.简单工厂模式由三部分组成：

工厂角色（工厂/工厂抽象类）：它创建具体产品，实现了对创建过程（构造过程）的封装。也是设计原则的体现。工厂类里面是创建对象的逻辑，也就是对这个构造过程进行封装
抽象产品角色（产品抽象/接口类）：工厂类所创建的产品的父类，或者说它们的共同接口
具体产品角色（产品实体类）：工厂类所创建的任何对象都是这个角色的实例

工厂模式和抽象工厂则是多了一个共同的工厂接口，所有实例工厂都是这个接口工厂的实现类

5.简单工厂模式的优点和缺点

优点：

封装了创建对象的过程，可以通过参数直接获取对象。把对象的创建和业务逻辑层分开，这样以后就避免了修改客户代码，如果要实现新产品直接修改工厂类，而不需要在原代码中修改，这样就降低了和客户代码修改的可能性，更加容易扩展。

缺点：

工厂类的职责比较大，如果修改需求或者需要添加新产品的话除了需要创建产品类，还要修改工厂类，而且如果工厂类出现问题的话所有的客户端（使用方）都会出现问题。
但是工厂模式完美的解决了这个问题，完全遵循了开闭原则，只需要添加新的工厂类实现抽象接口就可以了。

6.简单提一下面向过程

面向过程就是一种实际的思考方式，它关心的是某个事件，某个过程：比如起床-穿衣洗漱—吃饭-上班-工作-吃饭-下班-吃饭-睡觉这个过程。面向过程就是一步一步实现这些步骤，依照顺序，先有起床-然后穿衣-洗漱再接着继续实现后面的步骤。这就是大概的面向过程的开发思想。
如果用面向对象可能就是抽象出一个上班族的类，然后实现这几个方法，它也一样可以实现这几个步骤，但是它的灵活性更强大，可以直接实现它的方法而不需要在意前后做了什么

三、常见问题

1.设计模式

设计模式只是思路，并不能解决所有问题
不要强制使用，它是用来解决问题，而不是寻找问题
一定要在对的地方使用，不然只会适得其反

2.设计模式三大类：

1.创建型模式：专注于如何初始化对象，就是在创建对象的同时隐藏创建逻辑，避免去使用new直接实例化对象模式有工厂、单例、建造者、原型模式等等
2.结构型模式：结构型模式是针对类和对象的组合，思想是如何组合类和对象以获得更大/更好的结构模式有桥接、适配器、装饰、委托、享元、组合模式等等
3.行为型模式：关心的是对象之间的责任分配，它不仅仅指定结构，而且还概述了它们之间的消息传递的模式模式有命令、观察者、访问者、迭代器、中介者、策略模式等等

3.设计原则（不分先后）

一是开闭原则：

对扩展是开放的，对修改是关闭的。也就是只能添加，不能修改。比如：游戏/软件更新，只通过扩展修改，而不是更改原有的代码。

二是LoD（迪米特）法则：

一个对象尽可能对其它对象少了解，只关心自己。即尽可能少的与其它对象发生联系，尽量少依赖。或者说”只与直接的朋友通讯“。

三是依赖倒置（DIP）原则：

高层不应依赖低层模块，两者都应该依赖它们的抽象；抽象也不应该依赖细节，而是细节依赖抽象。
比如A依赖B，如果需求改了，需要修改A的依赖为C的话就必须修改A的代码。大多数情况下A属于高层模块，B和C属于低层模块。依赖倒置原则就是把A依赖的B和C都实现接口F，而让A通过接口F间接的依赖B或者C，这样就会降低修改A的情况

四是单一职责：

非常简单的概述：一个类只有一个职责，它只负责份内的事。在任何时候都应该遵循它，这是所有设计原则的基础。这个也算是所有原则的基本原则。

五是里氏替换原则：

通俗的来说就是子类可以扩展父类，但不能改变父类原有的方法。（因为修改很可能会造成整个继承体系的破坏，这也是继承的风险）

六是接口隔离原则：

客户端不应该依赖它不需要的接口，一个类的依赖应该建立在最小接口上
比如有一个接口I，它的实现类有两个：C和D,这时候A通过I去依赖C，B通过I依赖D.如果I对于A和B来说不是最小的接口（接口中还有其它方法），那么C和D这两个实现类就必须实现它们不需要实现的方法。比如A和B需要的都要在C里面有，这样C就会做额外的动作。这种情况就需要把I拆分为独立的几个更小的接口，然后把AC和BD都分离开来，让他们和自己需要的接口建立依赖。

七是合成复用原则（Composite Reuse Principle）:

尽量首先使用组合的方式，而不是使用继承。在面向对象设计中，如果直接继承基类，会破坏封装，因为继承将基类的实现细节暴露给子类；如果基类的实现发生改变，则子类的实现也不得不发生改变；从基类继承而来的实现是静态的，不可能在运行时发生改变，没有足够的灵活性。于是就提出了合成/聚合复用原则，也就是在实际开发设计中，尽量使用合成/聚合，不要使用类继承。