一个接口设计模式的探讨

我在设计一个UI时，采用了模版引擎实现，为了隔绝和各模版引擎实现的依赖性，我对模版引擎进行了包装，抽象出一层接口层：

Template

从上面的问题看来，Template，Context，Engine之间是紧耦合的，应该被封装在一起，那么

现在一个折衷的做法就是，取消Template接口，

修改TemplateEngine 接口，去除根据Template进行绑定的方法。

只能通过模版名称进行绑定。

同时也要去除Context接口，转而采用Map。

public interface class TemplateEngine{    
   
 public void mergeTemplate(String templateName, Map context,    
   Writer pWriter) throws MergeException;       
   
}   

这样所有的实现都紧密地放在TemplateEngine里面，但是同样也是有问题的，有些情况下外层还是需要Template和Context的。

同时，对于OO分析，只从抽象概念来考虑的话Template，Context，Engine都是很自然的模型，他们的这些行为也是很自然的。可是，因为语言实现上的一些困扰，不得以，把他们揉在一起，是因为我抽象分析的有问题，还是语言本身并不完全贴近实际意义上的OO分析？

大家给点建议

1. Context definition is more like a hashmap, in my experience, this is very harmful when this appears in an interface. The reason is that at runtime, any key/value pair could be there and thus it breaks your encapsulation. With large set of data, this kind of runtime interface pencentration makes debug very hard. Take a closer look to see whether you can further isolate the uncertainty, e.g., to a variable in a method in the interface.

2. A common way to avoid the checking on the VelocityContext is to use a double-dispatcher(or visitor), make your template a visitor of the context.

应该将Teamplate和Context都隐藏，只暴露TemplateEngine作为通用接口，所有传入参都用JDK中已有的常规类，
如：

public interface TemplateEngine {   
  
    public void mergeTemplate(String templateName, Map model, Writer out) throws MergeTemplateException;   
  
}

然后，每种模板引擎都实现：

public interface VelocityTemplateEngine {
	public void mergeTemplate(String templateName, Map model, Writer out) throws MergeTemplateException {
		VelocityContext...
		VelocityTemplte...
	}
}

public interface CommonTemplateEngine {
	public void mergeTemplate(String templateName, Map model, Writer out) throws MergeTemplateException {
		org.commontemplate.core.Context...
		org.commontemplate.core.Templte...
	}
}

晕没看到你自己的回复已经这样改了，还不能删除，当我没说，呵呵，

这样是不是也不太好啊，

难道Context对于外层，真的就只是个Map？

即然要通用，你就只能取最小交集。