Eclipse 中的 Adapters

 学习设计模式有一段时间了，曾几何时认为Adapter是最简单的模式之一，学习了Eclipse中Adapter模式的应用才感觉自己一直停留在模式定义的低层次上，现在有些意识到：学习Adapter模式关键在于：整个框架如何支持Adapter模式。这篇文章使用java控制台程序模拟了Eclispe中属性页面显示自定义模型的逻辑交互，通过四种方式定义了一个简单的模型Person最后在PropertyView中显示，阐述Adapter模式如何彻底将自定义模型(Person)从Eclipse提供接口(IPropertySource)中解耦出来。

 

View中的某个元素(比如TableView的一行，或TreeView的一个节点)被选中后，Eclipse会将次元素对应的模型集合取出并试图转换为IPropertySource类型，如果成功就将其显示在PropertyView中，否则不与理会。具体的转换逻辑如下：

1. 判断当前对象是IPropertySource的实例，若是，万事OK；
2. 上步判断失败后，判断当前对象是不是IAdaptable的实例，若是，将其转换为IPropertySource类型的对象
3. 上两步都失败，从系统中注册的IAdapterFactory中寻求的机会。

//PropertyController.java public class PropertyController { public static void showProperty(Object source){ /** * first step: check whether the source is instance of IPropertySource */ if(source instanceof IPropertySource){ showProperty((IPropertySource)source); return; } /** * second step: check whether the class of source implements IAdaptable */ if(source instanceof IAdaptable){ IAdaptable adapter = (IAdaptable)source; IPropertySource propertySource = IPropertySource.class.cast(adapter.getAdapter(IPropertySource.class)); if(propertySource!=null){ showProperty(propertySource); return; } } /** * third step: get adapter from registered factories. */ showProperty(Platform.getAdapterManager().getAdapter(source, IPropertySource.class)); } private static void showProperty(IPropertySource source){ IPropertyDescriptor[] descriptors = source.getDescription(); String displayName=""; Object displayValue = null; System.out.println("**********property viewer*************"); for(IPropertyDescriptor desc : descriptors) { displayName = desc.getDisplayName(); displayValue = source.getPropertyValue(desc.getID()); if(displayName!=null&&displayValue!=null) System.out.println(String.format("%10s : %20s", displayName, displayValue.toString())); } } }

showProperty方法看似简单其实蕴藏测无穷的变换。

1. 函数签名：参数类型是Object，它是万物之源，这意味着理论上他可以处理任何对象，将按接口编程发挥到了极致。
2. 函数实现：函数体中根据具体业务逻辑转换成自己需要的类型，可以实现多个按接口编程的功效，当前方法中处理了三个类型的接口
   • IPropertySource : 第一步需要处理的类型
   • IAdaptable         : 第二步需要处理的类型
   • Object                : 第三步需要处理的类型
3. 这三步对传入对象的类型要求越来越低，第三种相当于没有要求。

下面根据转换逻辑构建相应的自定义模型Person

 

Person1直接实现IPerpertySource，是最直观的实现方式

//Pserson1.java class Person1 implements IPerson, IPropertySource{ String name; int age; public Person1(String name, int age){this.age=age; this.name=name;} @Override public IPropertyDescriptor[] getDescription() { // TODO Auto-generated method stub return new TextPropertyDescriptor[]{ new TextPropertyDescriptor("name", "NAME"), new TextPropertyDescriptor("age", "AGE")}; } @Override public Object getPropertyValue(Object id) { // TODO Auto-generated method stub if("name".equals(id)) return this.name; if("age".equals("age")) return this.age; return null; } @Override public int getAge() { // TODO Auto-generated method stub return this.age; } @Override public String getName() { // TODO Auto-generated method stub return this.name; } }

 

 启动PropertyView显示程序

 private static void showPerson1(){ System.out.println("Person1"); PropertyController.showProperty(new Person1("cauchy1", 11)); }

Person1的败点在于自定义模型中夹杂了IPropertySource的信息，即自定义模型(Person1)与已有接口(IPropertySource)有极高的耦合度，Eclipse如果将IPropertySource升级为IPropertySource2，那么Person1就需要改变。

 

解耦的过程通常是引入中间层的过程，先贴出中间层的类PersonResource

//PersonResource.java class PersonResource implements IPropertySource{ private IPerson person = null; public PersonResource(IPerson person){ this.person=person; } @Override public IPropertyDescriptor[] getDescription() { // TODO Auto-generated method stub return new TextPropertyDescriptor[]{ new TextPropertyDescriptor("name", "NAME"), new TextPropertyDescriptor("age", "AGE")}; } @Override public Object getPropertyValue(Object id) { // TODO Auto-generated method stub if("name".equals(id)) return person.getName(); if("age".equals("age")) return person.getAge(); return null; } }

Person2:通过实现IAdaptable，将耦合转给了中间层。

//Person2.java public class Person2 implements IPerson, IAdaptable { private String name; private int age; public void setName(String name) { this.name = name; } public String getName() { return name; } public void setAge(int age) { this.age = age; } public int getAge() { return age; } public Person2(String name, int age){ this.name=name; this.age=age; } @Override public Object getAdapter(Class<?> adapter) { // TODO Auto-generated method stub /** Person decouple to IPropertyResource, but couple to PersonResource **/ if(adapter==IPropertySource.class) return new PersonResource(this); return null; } }

虽然降低了Person2与IPropertySource的耦合度，却增加了与IAdaptable以及PersonResource的耦合。

1.IAdaptable是一个表示占位符的接口，基本上不发生变化，因此与IAdaptable的耦合暂且可以接受。与

2.PersonResource的构造函数签名发生变化还是会导致Person2改变。

 

Person3:与PersonResource解耦。

仅仅创建实例的过程由工厂代替，其实将Person与工厂耦合在了一起，解耦一个又来一个，Eclipse的方案是想将需要转换的模型(Person3)与它对应的工厂注册在一个HashMap中，对于Person3需要放在getAdapter中区查询相应的工厂，然后再由工厂创建对象即可。getAdapter方法中不会出现具体工厂信息。

public class Person3 implements IPerson, IAdaptable { private String name; private int age; public void setName(String name) { this.name = name; } public String getName() { return name; } public void setAge(int age) { this.age = age; } public int getAge() { return age; } public Person3(String name, int age){ this.name=name; this.age=age; } @Override public Object getAdapter(Class<?> adapter) { // TODO Auto-generated method stub //decouple Person with PersonResource //In order to use this decoupled way, //we need to register AdaptableFactory return Platform.getAdapterManager().getAdapter(this, adapter); } } class PersonPropertiesSourceAdapterFactory implements IAdapterFactory{ @Override public Object getAdapter(Object adaptableObject, Class<?> adapterType) { // TODO Auto-generated method stub if(adapterType==IPropertySource.class) return new PersonResource((IPerson)adaptableObject); return null; } }

 

 

启动Person3的显示程序

private static void showPerson3(){ PersonPropertiesSourceAdapterFactory factory = new PersonPropertiesSourceAdapterFactory(); Platform.getAdapterManager().registerAdapters(factory, Person3.class); System.out.println("Person3"); PropertyController.showProperty(new Person3("cauchy3", 33)); Platform.getAdapterManager().unRegisterAdapters(Person3.class); }

 

至此，Person3只与Adaptable接口具有耦合度。对于Person3来说它不知道自己将要转换成什么类型，这种实现方式已经具备了通用性，因为Person3完全不知道自己要用于显示在PropertyView中。要想达到别的目的，只需要实现相应IAdapterFacotory即可。 细心的你可能已经发现Person3的getAdapter方法的实现与前文介绍的转换逻辑的第三步一个模样，这正是Eclipse牛逼的地方，他将工厂创建的过程放在了转换逻辑中（这种方式在Eclipse中使用很多，我用getAdapterManager进行搜索，出来一大堆），这样一来Person就彻底干净了，于是Person4出现了

Person4: 耦合彻底消失

public class Person4 implements IPerson { private String name; private int age; public void setName(String name) { this.name = name; } public String getName() { return name; } public void setAge(int age) { this.age = age; } public int getAge() { return age; } public Person4(String name, int age){ this.name=name; this.age=age; } }

 

IPerson是为了让PersonResource统一的方式包Person2,Person3,Person4。

启动Person4的显示

private static void showPerson4(){ PersonPropertiesSourceAdapterFactory factory = new PersonPropertiesSourceAdapterFactory(); Platform.getAdapterManager().registerAdapters(factory, Person4.class); System.out.println("Person4"); PropertyController.showProperty(new Person4("cauchy4", 44)); Platform.getAdapterManager().unRegisterAdapters(Person4.class); }

与启动Person3的如出一辙。