在前一篇文章一个示例让你明白适配器模式中,详细介绍了适配器模式,本文以实际项目中遇到的问题来演示适配器模式的实际应用。
项目中使用的原有接口
原来的项目中使用到了一个类ESPMenu,该类的代码很简单:
public class ESPMenu {
private String id;
private String caption;
private String normalIcon;
private String selectedIcon;
private String viewType;
private String icon
private String content;
public String getId() {
return id;
}
public String getCaption() {
return caption;
}
public String getNormalIcon() {
return normalIcon;
}
public String getViewType() {
return viewType;
}
public String getSelectedIcon() {
return selectedIcon;
}
public String getIcon() {
return icon;
}
public String getContent() {
return content;
}
}
从上面的代码可见,这是一个普通的实体类。 在项目中一个ESPMenu对象代表一个菜单项。这里的菜单是从后台中的XML中配置的。一个菜单项对应对应一个XML中的一个标签
<node id="my_task" caption="任务" selectedIcon="myTask.png" normalIcon="myTask_n.png"/>
这个标签和上面的ESPMenu对象表达的是相同的意思,都是表示一个菜单项,包括菜单的id,菜单显示的标题,显示的背景图片等信息。
目前,项目原有接口指的就是这个类了。这里要做一个说明:并不是只有实现一个interface才叫接口, 这里所说的接口是广义上的接口概念,能被外界访问到的部分都可以称作接口。 比如ESPMenu中有一个公共方法getIcon(), 这个方法就可以称作接口的一部分,因为它能被外界访问。
需求的变更
<node id="xinwen" caption="新闻" normalIcon="/images/icons/mobile/myHome.png" viewType="webView" url="3g.sina.com.cn"/>
那么我就得在上面的ESPMenu中增加一个url字段。这是不可行的,因为增加一个字段没什么大不了, 但是每次扩展都要增加字段,这就毫无扩展性可言。所以后台提供了实现方式,用一个叫做StubObject的对象表示每个菜单项。这个对象是面向抽象的,使用基本的键值存储来描述菜单中的各个属性,不会有具体的字段名字。比如要获得菜单的标题,只需要调用getObject("caption"), 要获取url字段,只需调用getObject("url"), 使用一个getObject方法获取所有信息,只要传入对应的参数。
public Object getObject(Object Key) {
参数是Object类型的,返回值也是Object类型的,能适应所有的需求。
使用适配器模式应对需求变更
public interface ESPMenu {
public String getId();
public String getCaption();
public String getNormalIcon();
public String getViewType() ;
public String getSelectedIcon() ;
public String getIcon() ;
public String getContent() ;
public Object getObject(Object key);
}
/*package*/class ESPMenuImpl implements ESPMenu{
private StubObject stubObj;
public ESPMenuImpl(StubObject stubObj) {
this.stubObj = stubObj;
}
@Override
public String getId() {
return (String) stubObj.getObject("id");
}
@Override
public String getCaption() {
return (String)stubObj.getObject("caption"));
}
@Override
public String getNormalIcon() {
return (String)stubObj.getObject("normalIcon"));
}
@Override
public String getViewType() {
return (String) stubObj.getObject("viewType");
}
@Override
public String getSelectedIcon() {
return (String) stubObj.getObject("selectedIcon");
}
@Override
public String getIcon() {
return (String) stubObj.getObject("icon");
}
@Override
public String getContent() {
return (String) stubObj.getObject("content");
}
@Override
public Object getObject(Object key) {
return stubObj.getObject(key, "");
}
}
这个实现类在成员变量位置组合了一个StubObject对象, 也就是我们要使用的新接口。 并且将对就接口的调用, 都委托到对 StubObject对象的调用。每个获取菜单属性的方法接口都没有改变,只是将调用都分发到StubObject对象的getObject方法,并且传入对应的key。
总结
设计上的事就是这样,想到了, 就能比较优雅的解决问题,想不到的话, 就只能使用到处修改代码的方法比较笨拙的应对问题,还容易将项目弄的混乱。现在我比较庆幸当初学习了设计模式,而没有听其他人的“建议”, 很多人都说“我们做的项目中用不到设计模式,学这个没用”。关于学习这个问题在我的另一篇博客 我为什么要学习Linux?中提到过。设计模式是个好东西,以后我肯定还会进一步的学习,并且在项目中多实践,提升自己的设计能力。
其实设计模式并不难,难的是真正领悟他的精妙,并且能灵活的运用于日常项目的开发。