当看到new关键字的时候，就会想到具体，而业务代码中充斥着太多的new关键字，一旦有变化或扩展，就必须重对代码进行修改，通常这样修改过的代码更难以维护和更新，而且更容易犯错。
想想设计模式的SOLID原则
抽象不应该依赖细节；细节应该依赖抽象。针对接口编程，可以隔离以后系统可能发生的一大堆改变。为什么呢？通过多态，可以与任何新类实现该接口。
含义
- 当需要定义一个产品家族的产品时，产品众多，需要一个大的接口，来组合所有的产品。
-
new关键字有一定的副作用，虽然new关键字是java的基础部分，使用new不可避免，但是使用工厂模式可以把new对象的过程收集起来。 - 加入新的产品就必须要改变接口，这个将是一份庞大的工作。所以接口需要大一点
模式图
如果我们开发一个平台独立型的便携式软件。 这些平台可能是windows,linux,unix,也可能是数据库。如果我们不去按设计模式处理他们，将会看到到处都是#if #else的语句。创建对象的代码到处乱跑... 如果使用了工厂模式，则可以把创建对象的代码收集起来。
可以用制作汽车来对比。
模式图
案例
抽象工厂的目的是提供一个接口以便创建一个系列的相关对象，而无需指定精确的类。此模式可以在制造产业中找到相似的，一台器械不同的部分由不同的工厂来创建具体的东西。
创建CPU的产品家族
// class CPU
abstract class CPU {}
// class EmberCPU
class EmberCPU extends CPU {}
// class EnginolaCPU
class EnginolaCPU extends CPU {}
// class MMU
abstract class MMU {}
// class EmberMMU
class EmberMMU extends MMU {}
// class EnginolaMMU
class EnginolaMMU extends MMU {}
// class EmberFactory
class EmberToolkit extends AbstractFactory {
@Override
public CPU createCPU() {
return new EmberCPU();
}
@Override
public MMU createMMU() {
return new EmberMMU();
}
}
// class EnginolaFactory
class EnginolaToolkit extends AbstractFactory {
@Override
public CPU createCPU() {
return new EnginolaCPU();
}
@Override
public MMU createMMU() {
return new EnginolaMMU();
}
}
enum Architecture {
ENGINOLA, EMBER
}
abstract class AbstractFactory {
private static final EmberToolkit EMBER_TOOLKIT = new EmberToolkit();
private static final EnginolaToolkit ENGINOLA_TOOLKIT = new EnginolaToolkit();
// Returns a concrete factory object that is an instance of the
// concrete factory class appropriate for the given architecture.
static AbstractFactory getFactory(Architecture architecture) {
AbstractFactory factory = null;
switch (architecture) {
case ENGINOLA:
factory = ENGINOLA_TOOLKIT;
break;
case EMBER:
factory = EMBER_TOOLKIT;
break;
}
return factory;
}
public abstract CPU createCPU();
public abstract MMU createMMU();
}
public class Client {
public static void main(String[] args) {
AbstractFactory factory = AbstractFactory.getFactory(Architecture.EMBER);
CPU cpu = factory.createCPU();
}
}
案例二
image.png
public interface IButton {
void paint();
}
public interface IGUIFactory {
public IButton createButton();
}
public class WinFactory implements IGUIFactory {
@Override
public IButton createButton() {
return new WinButton();
}
}
public class OSXFactory implements IGUIFactory {
@Override
public IButton createButton() {
return new OSXButton();
}
}
public class WinButton implements IButton {
@Override
public void paint() {
System.out.println("WinButton");
}
}
public class OSXButton implements IButton {
@Override
public void paint() {
System.out.println("OSXButton");
}
}
public class Main {
public static void main(final String[] arguments) throws Exception {
IGUIFactory factory = null;
final String appearance = randomAppearance(); // Current operating system
if (appearance.equals("OSX")) {
factory = new OSXFactory();
} else if(appearance.equals("Windows")) {
factory = new WinFactory();
} else {
throw new Exception("No such operating system");
}
final IButton button = factory.createButton();
button.paint();
}
/**
* This is just for the sake of testing this program, and doesn't have to do
* with Abstract Factory pattern.
* @return
*/
public static String randomAppearance() {
final String[] appearanceArray = new String[3];
appearanceArray[0] = "OSX";
appearanceArray[1] = "Windows";
appearanceArray[2] = "error";
final java.util.Random random = new java.util.Random();
final int randomNumber = random.nextInt(3);
return appearanceArray[randomNumber];
}
}
最后
整理了一下抽象工厂方法的定义与通常显现的形式，想要探索其中更多的奥秘，还要亲自去实践。
