Builder接口重构

MeteorTL(http://www.meteortl.org)以前的(0.5.1以前)版本中的API接口为：
TemplateFactory 和 ContextFactory 用于创建 Template 和 Context 两个核心 Domain,
Factory 用于合并 TemplateFactory 和 ContextFactory 两个工厂,
Builder 用于创建 Factory,
Engine 实现 Builder，通过Builder接口一步步导航到其它接口，

然而一直感觉Builder接口很不顺眼，
因为它与core包中的其它接口内聚性不高，
它只是作为core包其它接口的使用者，而不是被core包其它接口使用，或继承于core包其它接口等更强一点的关联，并且不是核心Domain。
有几个版本试图将它移到engine包，但发现也并不妥善，
因为整体架构声明engine包用于实现core包所有接口，

仔细研究Builder的实现类Engine, 发现其持有一个不合理的Configuration状态，

public interface Builder {
	Factory buildFactory();
}

public class Engine implements Builder {

	private Configuration config;

	public Engine(Configuration config) {
		this.config = config;
	}

	public Factory buildFactory() {
		// 通过config信息创建一个Factory接口的实例并返回
	}

}

用户调用方式：

Factory Factory = new Engine(config).buildFactory();

问题在于config只在一次建造过程有效，Engine类持有它毫无意义，重构如下：

public interface Builder {
	Factory buildFactory(Configuration config);
}

public class Engine implements Builder {

	public Factory buildFactory(Configuration config) {
		// 通过config信息创建一个Factory接口的实例并返回
	}

}

用户调用方式：

Factory Factory = new Engine().buildFactory(config);

但这样Builder就会依赖于Configuration接口，
而按整体架构core包是不能依config包的，
所以只能把Builder移到engine包，
发现Engine实例的存在也没起任何作用，再重构为：

Factory Factory = Engine.buildFactory(config);

这样，Builder接口就应该删除，

在我试着删掉Builder接口后, 猛然发现Engine如果直接实现Factory会更合理，如：

public class Engine implements Factory {

	public Engine(Configuration config) {
		// 通过config信息建造自身
	}

	public Template getTemplate(String name, String encoding) {
		...
	}

	...

}

用户调用方式：

Factory Factory = new Engine(config);

总结：
当发现放在哪都不合理的类或接口，或许它本身就不应该存在。