interface CellPhone
{
void show();
}
class Android implements CellPhone
{
public void show()
{
System.out.println("Android show");
}
}
class Iphone implements CellPhone
{
public void show()
{
System.out.println("Iphone show");
}
}
public class FactoryDemo
{
public static void main(String[] argv)
{
CellPhone c = new Android();
c.show();
}
}
先看代码,如上所示,类FactoryDemo 调用类Android中的方法show,假如有一天 想用Iphone代替Android,并且Android 在项目中大量使用了,如何更改,咋办!
会非常难以维护,我们应该这样想,类FactoryDemo只是调用Android类的show方法,不关心类Android如何实现的. 我们可以在Android中实现一个接口,用以new实现类Android,然后构建一个工厂类Factory,调用这个接口,然后类Factory用以FactoryDemo调用. 因为我们只是用Factory类中的方法,可以不用对象,所以把Factory中getInstance方法定义成static 类型.
class Factory
{
public static CellPhone getInstance()
{
return new Android();
}
}
public class FactoryDemo
{
public static void main(String[] argv)
{
CellPhone c = new Android();
c = Factory.getInstance();
c.show();
}
}
所以要想用Iphone类替换Android类就可以在Factory中更改一行 new Android()就可以了.
优点
工厂类是整个模式的关键。包含了必要的逻辑判断,根据外界给定的信息,决定究竟应该创建哪个具体类的对象。通过使用工厂类,外界可以从直接创建具体产品对象的尴尬局面摆脱出来,仅仅需要负责“消费”对象就可以了。而不必管这些对象究竟如何创建及如何组织的。明确了各自的职责和权利,有利于整个软件体系结构的优化。
缺点
由于工厂类集中了所有实例的创建逻辑,违反了高内聚责任分配原则,将全部创建逻辑集中到了一个工厂类中;它所能创建的类只能是事先考虑到的,如果需要添加新的类,则就需要改变工厂类了。
当系统中的具体产品类不断增多时候,可能会出现要求工厂类根据不同条件创建不同实例的需求.这种对条件的判断和对具体产品类型的判断交错在一起,很难避免模块功能的蔓延,对系统的维护和扩展非常不利;
这些缺点在工厂方法模式中得到了一定的克服。
使用场景
工厂类负责创建的对象比较少;
客户只知道传入工厂类的参数,对于如何创建对象(逻辑)不关心;
由于简单工厂很容易违反高内聚责任分配原则,因此一般只在很简单的情况下应用。
http://blog.csdn.net/huang_xw/article/details/7669141