一直以为涉及到什么"模式"的都是很高深,很难理解的,其实只是我们心里害怕而已,只要去了解,也不过如此!
工厂模式:用一个小示例解释:
public abstract class Product //建一个抽象类,描述产品的
{
}
public class ConcreteProductA extends Product //产品A继承Product
{
}
public class ConcreteProductB extends Product //来个产品B
{
}
public class Creator //一个工厂按客户要求制造产品,由客户传入参数str
{
public static Product createProduct(String str)
{
if("A".equals(str))
{
return new ConcreteProductA();
}
else if("B".equals(str))
{
return new ConcreteProductB();
}
return null;
}
}
public class Client //客户调用工厂来生产符合自己要求的产品
{
public static void main(String[] args)
{
Product productA = Creator.createProduct("A");
System.out.println(productA.getClass().getName());
Product productB = Creator.createProduct("B");
System.out.println(productB.getClass().getName());
}
}
有人会问:为什么这么麻烦呢?为什么不直接 ConcreteProductA productA= new ConcreteProductA("A"); ConcreteProductB = new ConcreteProductB("B");
这样多省事,
如果创建ConcreteProductA 实例时所做的初始化工作不是像赋值这样简单的事,可能是很长一段代码,如果也写入构造函数中,那代码很难看了,
初始化工作中要做的工作很多,将很多工作装入一个构造方法中,有背于Java面向对象的原则,面向对象的封装(Encapsulation)和分派(Delegation)告诉我们,尽量将长的代码分派“切割”成每段,将每段再“封装”起来(减少段和段之间偶合联系性),这样,就会将风险分散,以后如果需要修改,只要更改每段,不会再发生牵一动百的事情。
在本例中我们将创建实例的工作与使用实例的工作分开了,让创建实例所需要的大量初始化工作从 ConcreteProductA 的构造函数中分离出去。
而且以后还会有产品C 产品D 等等.....这样就有更大的可扩展性和尽量少的修改量
|