原文名：Building a Common Navigator Framework (CNF) Viewer Part III: Configuring Menus，作者：MICHAEL ELDER，出处：http://scribbledideas.blogspot.com/（本人从未能打开过，呵呵）。

先上Copyright

The opinions and ideas expressed herin are my own and do not represent the intent, opinion, or official statement of any company or organization.
All postings by me to this site are copyrighted (C) by Michael D. Elder, 2006 and made available under the terms of the Eclipse Public License 1.0 with the constraint that any reuse of the content must contain this copyright statement.

    在前面的文章中，我们通览了如何构件一个通用导航器架构视图，以及提供了一个基础扩展来展示属性文件。现在，我们将要学习如何为CNF配置菜单，以及如何为我们的视图添加操作来操作我们的内容。

概览

    这边有两个基本选择来为CNF视图增加操作：

    • 使用org.eclipse.ui.popupMenus作为objectContributions或viewerContributions来提供操作。...popupMenus扩展点能让你在整个Eclipse工作台上提供操作代理。CNF视图能被配置成接受这些操作代理（缺省情况下），或者忽略他们。在平台提供的Project Explorer视图中，对象或视图操作是被接受的（在第四部分中会详细介绍）。

    • 使用org.eclipse.ui.navigator.navigatorContent作为actionProviders来提供操作。有时候，客户需要更加有计划的控制下面这些内容：对于特定上下文环境中给定的菜单，要提供怎样的操作；基于当前的选择项，需要提供什么可重定向操作。

    CNF的操作提供者，只被CNF视图所接受。（将在第五部分给出详细信息）

配置菜单结构

    在第一部分，我们定义了示例<viewer />元素，弹出菜单被简要的提到了。

    回忆一下，这里有两种方法来配置弹出菜单。第一种可能就是简单的为org.eclipse.ui.navigator.viewer中<viewer />元素下的popupMenuId指定一个值，第二种可能就是采取一种更主动的方法来配置菜单支持的插入点。

    提示：popupMenuId和popupMenu元素同时被指定将导致错误。

    如果我们想要设置popupMenuId，将如同下面看到的一样：

    该标识符能被org.eclipse.ui.popupMenus的扩展者所使用，来为视图增加一个特定的viewerContributions；然而objectContributions不需要任何的标识符。

    当只有popupMenuId属性被指定，缺省的插入点（insertion points）集合会自动的配置到弹出菜单中。在org.eclipse.ui.navigator.viewer的schema参考中，列出了缺省配置。为方便起见，这里也列出了：

"group.new" separator="true"
"group.goto"
"group.open" separator="true"
"group.openWith"
"group.edit" separator="true"
"group.show" separator="true"
"group.reorganize"
"group.port"
"group.generate" separator="true"
"group.search" separator="true"
"group.build" separator="true"
"additions" separator="true"
"group.properties" separator="true"

    这些值能被org.eclipse.ui.popupMenus中的menubarPath属性元素所使用。

    当有计划的使用和搜索菜单项时，这些值也能被使用（参考org.eclipse.jface.action.IContributionManager，特别是insertAfter(),insertBefore(), 和appendToGroup()）。

    所有字符常量("group.*")都没定义在org.eclipse.ui.navigator.ICommonMenuConstants中，以便有计划的使用。

    作为替换，我们可以选择定义<viewer/>的子元素<popupMenu />，这里我们可以定义自己的插入点（insertion points）。（译者注：略过一个基本操作）。

    在我们的例子中，我们可以使用同Project Explorer一样的菜单配置。

        每个<insertionPoint />元素暗示这一个GroupMarker能通过IContributionMenu API被访问到。当separator属性被设置成true时，菜单将会展现一条水平线。Eclipse中的菜单有足够的智能，只显示必要的线，两条背靠背的线将只被显示成一条。

       让我们注意一下<popupMenu />下的allowsPlatformContributions="true"属性。缺省情况下，CNF接受..popupMenus提供的操作。若把该属性设置成false，将会限制菜单只接受操作提供者（Action Providers）。

    上面的例子并没有做什么神奇的事，在你自己的CNF视图中，你可以根据需要定义自己的插入点("group.example")。推荐的命名规约为"group.*"，除了additions group之外，上面的那些group都遵循了。

    对于扩展或操作CNF菜单插入点集合的一些评论。对于一个已经配置好的视图，是没有可能来声明性操作或扩展他的插入点集合的。有可能的是，通过Action Providers，来增加新的GroupMarkers 或Separators，但这里需要当心。在第五部分，我们将详细介绍这个是如何完成的，现在只是提醒一下，需要当心，并且当只有需要用到<actionProvider />中dependsOn属性时。该dependsOn的值指明为菜单提供额外插入点集合的Action Provider的标识符。永远不要programmatically（译者注：不知道该怎么翻）删除插入点，因为其它扩展可能会依赖与他们。如果你自己定义的视图不需要使用某个插入点，则在定义你自己的<popupMenu />元素时，不要定义他就好了。

总结

    在这篇文章中，我们讨论了如何为CNF视图配置菜单，下面的文章将讨论如何使用org.eclipse.ui.popupMenus 和org.eclipse.ui.navigator.navigatorContent/actionProvider来增加菜单。

由windy444翻译，转载请注明

原文名：Building a Common Navigator Framework (CNF) Viewer Part II: Adding Content，作者：MICHAEL ELDER，出处：http://scribbledideas.blogspot.com/（本人从未能打开过，呵呵）。

先上Copyright

The opinions and ideas expressed herin are my own and do not represent the intent, opinion, or official statement of any company or organization.
All postings by me to this site are copyrighted (C) by Michael D. Elder, 2006 and made available under the terms of the Eclipse Public License 1.0 with the constraint that any reuse of the content must contain this copyright statement.

    在这篇文章中，我们将学习如何为我们上篇文章定义的例子增加一个简单的内容扩展。为避免陷于过度复杂的内容和标签提供者，我们将关注于一个简单的文件结构模型，简单文本文件*.properties。当完成时，我们的内容扩展将允许在Example viewer展开任意*.properties文件，并在下面正确排列出数据。

    首先，让我们看一下，内容扩展在plugin.xml中看起来是怎样的。（译者注：略过一些基本操作，plugin.xml如下：）

    该扩展用id "org.eclipse.ui.examples.navigator.propertiesContent"定义了一个内容扩展，显示的名称是"Properties File Contents"。该名称会出现在过滤器对话框的"Available Extensions"标签中。我们马上会去看一下内容和标签提供者的Java代码，但现在只是注意一下，两者都被指定了。只指定其中的一个是不行的。

    最后，我们设置一些属性，告诉框架，我们需要怎样的扩展：

   • activeByDefault  决定扩展是否在缺省配置中被激活（如：新工作空间）

   • icon  决定在用户界面引用该扩展时，显示什么图标

   • priority  有几种不同的用法。最主要的作用是指定视图中项的相对位置（视图中从上到下排列的分别是最高优先级（highest priority）项到最低优先级（lowest priority）项）。一般的说，“一般级”（"normal"）或“高级”（"high"）对于大多数的扩展来说，足够了，两者分别预示着与资源扩展混合在一起（优先级一样的话，则按字母顺序）或恰好放在工程下的资源之上。

   在每个<navigatorContent />元素内，我们能指定不同类别的扩展。但在扩展我们的例子之前，我们必须向架构定义，我们的扩展何时被调用。我们必须定义，什么时候视图中树的节点能够提供children，parents，或者标签和图标。我们用Eclipse 核心表达式来做这个工作。

   对于内容扩展，这里有两个重要的表达式：<triggerPoints /> 和<possibleChildren />。

   <triggerPoints />表达式指定树中哪种类型的节点对我们的扩展感兴趣。当架构找到了匹配<triggerPoints />的节点，我们的扩展会被调用，为该节点提供子元素。我们的扩展并不一定是唯一能有机会为该节点提供子元素的扩展，架构会聚集该节点下所有的子元素（译者注：可以是不同扩展提供的）。

     <possibleChildren />表达式指定我们的扩展能为树中哪种类型的节点提供标签或父节点（译者注：注意与triggerPoints 的不同）。若你的场景中必须在视图中支持link with editor, 或者 setSelection()，<possibleChildren />表达式必须是完整且正确的。

    一旦我们定义了一个扩展，我们必须把它绑定到想要关联的视图上。设定一个<viewerContentBinding />，来指定任何匹配include中模式的扩展，这些扩展对于在<viewerContentBinding />元素中指定的任何viewerId的视图是可见的。可以参考上一篇文章。

    既然我们已经设置好了扩展，现在可以来看一下真正处理事务的代码了。

    首先，我们需要一个模型。一个属性文件的结构是相当简单的，我们只要用一个模型对象PropertiesTreeData,就能够建模了。这个对象有三个域：name（属性的名称），value（属性的值），container（拥有属性模型的文件）。每一个模型元素，指示属性文件中的一条属性。

    在我们的例子中，模型只有当被内容提供者请求时，才被载入。内容提供者被框架用来决定树中每个元素的子元素，或者被用来指定给定元素的父元素（可能有多个）。

    我们的示例内容提供者实现了接口org.eclipse.jface.viewers.ITreeContentProvider，用来提供树形结构的信息。通用导航器架构也支持实现org.eclipse.jface.viewers.ITreePathContentProvider接口的内容提供者，但这个超出了本例的范围。

     PropertiesContentProvider也提供了我们的扩展需要的其它一些功能，比如监听资源变化和更新模型（以及视图）。在本文中不会涉及，读者可以到本文的源码中了解这个是如何工作的。

    现在，我们将关注ITreeContentProvider提供的视图集成方法。

    ITreeContentProvider必须实现getElements(Object input),getChildren(Object parent), hasChildren(Object element) 和 getParent(Object element)方法。

    getElements()方法被用来查询在视图根目录下有哪些元素。许多实现会直接调用getChildren()来处理，我们在这边也如此。

     getChildren()方法接受一个对象（我们这里是*.properties结尾的IFile，或者是由于在<triggerPoints />中描述而必须引入的PropertiesTreeData模型实例）。

    在接下来的实现中，我们检查接受的对象是否为org.eclipse.core.resources.IFile，并且是否以*.properties结尾。如果接受的对象满足这些要求，我们检查载入模型的缓存，当未缓存时，尝试载入模型。updateModel()方法将为每个属性创建一个PropertiesTreeData对象，并且在cachedModelMap中缓存所找到的模型。请读者在源码中查看updateModel()方法是如何实现的。

    hasChildren()方法被优化了，知道当传入的对象是以*.properties结尾的IFile，就返回true。另一种替换的方法，是在这边载入文件，作一些计算，但这样性能会受损。

    如果传入的对象是PropertiesTreeData模型元素，则返回false。因为我们的模型元素没有子元素。（属性没有子元素，但其它模型可能就会有了）。

    getParent()方法返回包含PropertiesTreeData项的IFile，若传入其它参数，返回null。通用导航器架构会继续询问其它扩展，直到一个非null的的父元素被找到或者已经遍历了所有扩展。回忆一下，如果元素匹配<possibleChildren />表达式，扩展会被要求为该元素提供父节点。

     最后，我们内容扩展的标签提供者，会告诉视图如何为我们的模型元素（PropertiesTreeData）来展现标签和图标。既然我们只关注这些元素，我们不必担心如何为其它元素来提供标签和图标。这些元素将由其它的扩展来展现标签和图标。

    PropertiesLabelProvider实现了org.eclipse.jface.viewers.ILabelProvider 和
org.eclipse.ui.navigator.IDescriptionProvider接口。

    ILabelProvider是JFace中提供标签和图标的缺省接口要求。

    IDescriptionProvider是特定用于通用导航器架构的，用于在Eclipse窗口左下角的状态栏显示文本。

    ILabelProvider要求的方法是getText() 和 getImage()。我们将让模型标签显示"name= value"的字符串。对于图标，我们使用平台提供的一个共享图标。

    标签提供者在下面两种情况下会被访问到：1.自己的扩展定义的元素。2.所有匹配<possibleChildren />的元素。如果图标或标签返回了null，框架会基于<possibleChildren />和视图bindings，继续查找其它扩展（来显示标签和图标）。如果你的扩展希望由其它人来定义标签和图标，则要返回null。

    就这些了，最终的视图Example View在属性文件下列出了属性。

由windy444翻译，转载请注明

原文名：Building a Common Navigator Framework (CNF) Viewer Part I: Defining the View Part ，作者：MICHAEL ELDER，出处：http://scribbledideas.blogspot.com/（本人从未能打开过，呵呵）。

先上Copyright

The opinions and ideas expressed herin are my own and do not represent the intent, opinion, or official statement of any company or organization.
All postings by me to this site are copyrighted (C) by Michael D. Elder, 2006 and made available under the terms of the Eclipse Public License 1.0 with the constraint that any reuse of the content must contain this copyright statement.

    关于扩展点和API的特定文档，可以在Eclipse的平台帮助（(Help > Help Content）中找到，Platform Plug-in Developer's Guide >Reference > API Reference | Extension Points Reference，涉及的扩展点有org.eclipse.ui.navigator.viewer，org.eclipse.ui.navigator.navigatorContent。相关的API包为org.eclipse.ui.navigator。若你想知道这篇文章中提到的东西的更多细节，这些东西可以作为参考。

    好了，哪里开始呢？首先，我们将对包含该视图的插件作一些配置，把org.eclipse.ui.navigator添加到依赖（dependencies）中。然后，我们用org.eclipse.ui.views扩展点来定义一个view part，并把org.eclipse.ui.navigator.CommonNavigator类作为view part的实现类。这个类将为我们的视图提供一些基础功能。然后，我们定义org.eclipse.ui.navigator.viewer扩展点，把视图配置成通用导航器（Common Navigator）。最后，能够通过定义org.eclipse.ui.navigator.navigatorContent扩展点以及绑定(org.eclipse.ui.navigator.viewer/viewerContentBinding)来关联扩展点和视图。

   你不仅可以通过org.eclipse.ui.navigator.CommonNavigator，把该架构用于导航器，你可以通过org.eclipse.ui.navigator.INavigatorContentService把该架构用于从对话框到编辑器的任何地方，或者定义你自己的视图和view part。但在这里，我们将只关注于基本功能。

基本设置

   通用导航器架构是Eclipse 3.2的一个新特性，因此，你至少需要安装Eclipse 3.2。（译者注：下面一些是开发过插件的人都知道的事情，此处略过）

定义View Part

   当要定义一个具有通用导航器功能的视图，你必须定义一个实际的view part，这个是你视图的容器。

   （译者注：略去一段无关紧要的，插件开发初学者可以去参考基本view的开发，定义完成后的plugin文件如下：）

 定义视图配置

      一旦定义好了view part，我们将通过org.eclipse.ui.navigator.viewer对我们的视图作一些配置扩展，这些扩展将告诉架构一些基础的东西，例如，通用导航器的view part是哪个，弹出菜单的结构是怎样的，是否要定义object contributions，以及一些会影响视图缺省行为的属性。

    （译者注：略过定义plugin.xml文件过程，后面会附上该文件）

     对于弹出菜单的一些评论。通用导航器架构提供两种方式让视图来定制菜单。第一种方式是通过指定org.eclipse.ui.navigator.viewer扩展点下viewer的popupMenuId，来接受缺省的分隔符，以及菜单的group mark id。缺省值被记录在org.eclipse.ui.navigator.viewer扩展点下，为了方便，被列在了下面。

"group.new" separator="true"
"group.goto"
"group.open" separator="true"
"group.openWith"
"group.edit" separator="true"
"group.show" separator="true"
"group.reorganize"
"group.port"
"group.generate" separator="true"
"group.search" separator="true"
"group.build" separator="true"
"additions" separator="true"
"group.properties" separator="true"

    另一种方式，你可以选择不去指定popupMenuId，作为替换，你可以指定<popupmenu />作为<viewer />元素的子元素。在这里，你可以定义自己的分隔符以及group mark id（能够由后面的用户来增加菜单）。如果你期望绑定平台(Resource, Java^tm)提供内容扩展的内容（content）或者操作（Action），推荐您使用缺省分组（上面列出的）。

    对于选项（option）的一些评论。<viewer />元素下的< options />元素能够允许指定基于字符串的name=value对。这里有一些选项被基础架构所使用（在org.eclipse.ui.navigator.viewer扩展点文档的例子部分有记录），但你自己的视图或扩展点也可以使用这种机制来提供额外的扩展。请参考org.eclipse.ui.navigator.INavigatorViewerDescriptor中读取<viewer />元素中属性的API。你能通过通用导航器视图的org.eclipse.ui.navigator.INavigatorContentService得到视图描述符。

   定义viewerId后的plugin文件：

     定义好视图后，我们需要添加内容扩展，并绑定到视图上。我将在下一篇文章中给出一些更具体的信息。作为示例，我们简单的把缺省的资源内容（由org.eclipse.ui.navigator.resources插件定义）绑定到视图上。

    （译者注：略过一些基本操作，定义完后的plugin文件如下：）

    你现在可以启动工作台了（Run... > New Eclipse Application），这时能看到我们的视图。但我们还未给视图绑定操作，所以，你仍然要通过在资源导航器或包浏览器中创建工程，才能在我们的视图中出现工程。后面，我们会增加资源操作和过滤器，但现在，让我们看看该视图拥有的缺省行为。目前有折叠所有按钮（Collapse All），Link with Editor按钮，过滤器（Filters）按钮（以及一个"Available Filters"标签），和一个扩展标签（"Available Content"）。

    要绑定资源过滤器，我们需要在</includes>元素下增加另一个contentExtension元素，指定"org.eclipse.ui.navigator.resources.filters.*"为标识符。这将会选取org.eclipse.ui.navigator.resources定义的所有的过滤器。当然，你可以参考org.eclipse.ui.navigator.resources的plugin文件，选取你自己想要的过滤器的标示符。

    再一次选择Run...，确认在过滤器对话框中出现了一些资源过滤器。

    接下来，我们将绑定默认的资源操作。要绑定操作，需要在我们扩展点的根下面，增加一个viewerActionBinding元素。（译者注：略过一些操作，定义完后的plugin文件如下：）

     现在，启动工作台后，在默认的空视图中（在视图中右键空的地方），你将看到New, Import, Export, 和 Refresh操作。当你选中视图中的一个元素时，出现的菜单类似与资源导航器中的。

（译者注：再次略过一段操作，不影响对文章的理解）

定义过滤器

    今天我们将做的最后一件事，是用Eclipse核心表达式（Core Expressions）为我们的视图定义一个过滤器。核心表达式架构的文档在org.eclipse.core.expressions插件中。我们将用org.eclipse.core.resources定义的属性测试者（property testers）来测试特定的工程性质（Nature），然后隐藏所有没有该性质的工程。

（译者注：略过一些操作，定义完后的plugin文件如下：）

    你也可以在扩展点中设置activeByDefault属性，来决定该过滤器是否在缺省配置中被激活。

    最后，我们需要为我们的视图定义contentExtension，来作为viewerContentBinding的一部分。确保使用了我们新建的过滤器的id，或者一个通用的样式（如："org.eclipse.ui.examples.navigator.filters.*"）来绑定所有我们未来定义的匹配样式的过滤器。最后的plug.xml如下：

    现在，最后一次启动工作台。创建一个新的简单工程和Java工程，当“Hide non-Java Projects”被激活时，简单工程会被隐藏。

（译者注：第一部分终于翻译完了）

雨过陌上独踱，不见虹之颜色。
归来床前数点，零落月光之宴。

——雨后坝上寻虹不见而归有感。

Extension Object同Visitor、Decorator等模式差不多，都是在不改变类层次机构的前提下向系统添加功能，被称为扩展对象模式。

在了解扩展对象模式之前需要了解一下相关的一条OOD原则，就是单一职责原则（Single Responsibility Principle，SRP）。

就一个类而言，应该仅有一个引起他变化的原因。

大致的意思就是要把职责分配到不同的对象当中去。如果我们把每一个职责的变化看成是变化的一个轴线，当需求变化时，该变化会反映为类的职责的变化。 如果一个类承担了多余一个的职责，那么引起他变化的原因就多余一个轴线，也就是把这些职责耦合到了一起。在某种程度上，这种耦合会导致Fragile Design，当变化发生时，设计会遭受到意向不到的破坏。

在具体讨论之前，先来看一个设计问题。

我们要开始设计一个RSS Reader，一般使用一棵树来呈现对于Feed的管理和组织结构，类似于Bloglines、GreatNews那样的。构建这棵树的过程中，我们可以使用Composite模式来设计相应的类层次结构，例如，基本接口我们可以采用

public interface IChannelNode {

public String getTitle();

public String getId();

... ...

}

然后构建Composite的子类（用来容纳目录等组织结构）和具体类，例如

public class CompositeChannelNode implements IChannelNode {

public void addChild(IChannelNode node);

... ...

}

public class FeedChannelNode implements IChannelNode {

... ...

}

上述这些类结构完全可以用来描述这棵树的层次结构了，而且我们可以使用Eclipse中的TreeViewer来显示。Eclipse中的 TreeViewer是基于Structured Model的，所以，几乎使用很少的代码，就可以完成显示这个树的功能，这也是Eclipse对于这种基于Structured Model封装的比较好的结果。不过简单的使用UI会比较单调，所以，就需要对于UI部分进行润色，那么在这个类层次中不可避免的要加入UI部分的代码， 这就不符合SRP的要求了。另外，假如我们还要完成对于这棵树的persistent，那么序列化的代码又会污染这个单纯的模型了。这里我们就可以使用扩 展对象模式了，把这些变化另外wrap起来。

对Extension的抽象封装

这个是Uncle Bob提过的一种优雅的实现机制，是基于对于Extension的抽象封装，然后在本身模型（上面的Channel组织模型）注册这些 Extension，在运行时可以方便的得到合适的扩展来执行相应功能。例如我们来定义一个Extension的注册和使用机制，然后在 IChannelNode中将请求delegate给这套机制，当然也可以把这个直接集成到IChannelNode的代码中，下面用Part和 PartExtension来完成这部分功能（代码不是完整的）。

public abstract class Part  {

public void addExtension(String extensionType, PartExtension extension) { ... ... }

public PartExtension getExtension(String extensionType) { ... ... }

}

public interface PartExtension {

}

可以简单的使用一个HashMap来完成extension的注册和获取。其实这部分的代码就把扩展这部分不变的内容封装起来，而对于可能存在的变 化完全可以利用增加新的类来完成，也就满足了开放封闭原则（OCP）。比如我们说到的persistent部分，建立相应的persistent扩展就可 以了。

public class PersistentPart extends Part {

public PersistentPart() {

addExtension("CSVFormat", new CSVPersistentPartExtension());

// 注册其他format的存储方式

}

}

public interface PersistentExtension extends PartExtension {

public void doPersistent(IChannelNode node);

}

public class CSVPersistentPartExtension implements PersistentExtension {

public void doPersistent(IChannelNode node) {

// save node.getTitle();

// save node.getId();

......

}

}

变化的部分就是用什么方式来存储信息了，比如我们不使用CVS来存储而改用XML存储，那么只需要生成相应的XMLPersistentPartExtension，并把他注册到PersistentPart就可以了。
看了这个，当时我觉得搞得真是很麻烦，很复杂，而且可读性很差啊，呵呵。不过本身Extension Object的实现就是特别复杂的，慢慢实践，我想会越来越掌握这种方法的。

我投入精力更大的是下面要说的一种同Adapter结合起来的扩展方法，并使用这种方法实现了UI部分的分离，感觉确实方便很多，不过开始理解起来也是比较头疼。

使用Adapter模式来扩展

这里要说的是Eclipse平台底层最为核心的IAdaptable，Erich Gamma一手打造，我先后看了好久才体会到这种设计的魅力。这次扩展我们拿UI来说事。Eclipse中显示一个Tree很容易，有了 Structured Model之后，打造好相应的TreeContentProvider和LabelContentProvider就基本完成了。但是对于一个效果复杂的 显示在Provider中的代码就会显的很臃肿，主要也是在LabelContentProvider中，而原有模型的逻辑也会增加很多基于UI部分的代 码，比如Channel不同状态下要显示什么样的图片，使用什么样的字体，什么样的前景背景色等等。所以，比较好的办法就是分离出一套并行的类层次， IChannelNodeUI，而且如果在扩展过程中我们能够把IChannelNode适配到IChannelNodeUI，并交给 LabelContentProvider就好办了，所有的UI代码就搞到IChannelNodeUI这套东西里面去了。
现在介绍的扩展方式就是依据Adapter为基础的，所以，现在先把Adapter这部分搞定

public interface IChannelNodeUI {

public Image getImage();

public Font getFont();

... ...

}

public class ChannelNodeUIAdapter implements IChannelNodeUI {

private IChannelNode node_;

public ChannelNodeUIAdapter(IChannelNode node) { ... ... }



public Image getImage() {

if (node_.isLoading())

// return loading image;

... ...

}

......

}

接下来也就是对这些扩展的管理，比如我们还有对于IPersistent的适配，那么如何更好的来管理这些扩展呢。比较容易想到的还是注册然后获取这样的方法，可是这些适配器和适配关系如何管理呢？
看一下，Erich大牛的IAdaptable

org.eclipse.core.runtime/IAdaptable

public interface IAdaptable {

public Object getAdapter(Class adapter);

}

如果IChannelNode从IAdaptable继承过来，那么我们就可以在LabelContentProvider中这样写到（都没有进行check啊）：

    public Image getImage(Object element) {

IChannelNode node = (IChannelNode)element;

IChannelNodeUI uiNode = (IChannelNodeUI)node.getAdapter(IChannelNodeUI.class);

return uiNode.getImage();

}

那么就需要我们对于IChannelNode中的getAdapter来实现，比如我们在ChannelNode中：

    public Object getAdapter(Class adapter) {

if(adapter == IChannelNodeUI.class)

return new ChannelNodeUIAdapter(this);

return null;

}

这样的问题就是不好维护，所以，Erich大牛还提供了对应的IAdapterFactory和IAdapterManager，当然AdapterManager是Platform中提供的对于框架部分的封装，不需要我们干什么了。
我们也就需要生成一个AdapterFactory，然后把他注册给Platform的AdapterManager就可以了：

    IAdapterManager manager = Platform.getAdapterManager();

IAdapterFactory uiFactory = new ChannelNodeUIFactory();

manager.registerAdapters(uiFactory, IChannelNode.class);

那么如何使用呢，Eclipse的Platform里提供了一个PlatformObject的类，继承他直接就具有了Adaptable的能力， 并自动把getAdapter的请求转交给Platform了，缺陷就是会影响你的继承体系，毕竟Java无法多元继承，所以，如果你不是继承自 PlatformObject的话，自己转交一下，

    Platform.getAdapterManager().getAdapter(this, IChannelNodeUI.class);

这种扩展对象模式就是基于这样的Adapter模式，由IAdaptable、IAdapterFactory和IAdapterManager完成了对框架的封装，从而给Eclipse带来了巨大的灵活性。

参考数目：《敏捷软件开发》、《Contributing to Eclipse》