Java 设计模式之“工厂方法”之我见

    Java 设计模式中有一个叫做工厂方法的设计模式。那么什么叫工厂方法呢？

    【我们的烦恼】

    我们平时写程序的时候，经常会对同一个抽象类的子类或同一个接口的多个子实现进行选择，这时候我们就需要知道类的继承关系以及每个子类具体实现，每个子类的功能。例如：一个日志记录类Logger有两个子类FileLogger、ConsoleLogger。分别是面向文件和面向控制台的日志类。我们编写程序的时候会根据需要选择其中之一来对Logger的对象进行实例化。

    可能一：Logger log=new FileLogger()

    可能二：Logger log=new ConsoleLogger()

    我们除了清楚类的继承关系及每个类的应用范围歪，还需要判断当前的应用环境，例如到底是应该使用文件日志记录方式呢，还是控制台日志显示方式。

    【工厂方法】

     为了解决上面的烦恼，提出了工厂方法的模式。

     工厂方法就是为了解决对类的对象实例化时对子类的选择的烦恼。

     它是这样实现的，用一个属性文件（如logger.properties）来决定当前日志记录的环境选择。例如，我们可以将logger.properties的文件内容设置如下：

     Filelogging=on

     这表示，当前的日志记录到文件中。我们需要使用文件日志类来实例化Logger对象log。

    我们声明一个名为LoggerFactory的类，该类应该有一个名为getLogger（）的方法，它检查当前Filelogging的属性，然后调用不同的实现类实例化一个对象，并以Logger类型返回。

     这样，我们在使用的时候，只需要如此简单地就可以得到响应的日志记录类了。如下：

     Logger log=new LoggerFactory().getLogger();

    【我的看法】

     我觉得工厂方法并非如其所说的那么完美。虽然在直接使用的时候我们免去了判断当前环境的烦恼，但是我们却需要在属性文件里面进行属性的设置。虽然在使用时我们免去了对类继承关系的了解，但是在工厂类的设计的时候，了解类结构是免不了的。所以我认为：工厂方法使得使用傻瓜化，但是增加了工厂类设计的麻烦。不是吗？

    

呵呵，在具体设计时，对工厂模式的采用要依据具体设计，当你的程序结构庞大时，你的了解对设计的可靠度，我怀疑。这时工厂模式不是很好么？

言之有理，学习一下阁下的观点