Extension设计

最近在做Extension的设计， 有2种方案，不知道那种方案比较好。
需求是可以在某个地方定义一个扩展点， 可以是代码中（硬编码也算吧，AOP可能是以后使用的方式），UI， Workflow等等， 总之一切可以并需要扩展的地方。
扩展的含义有2个层面：
1。 这个地方是可以被扩展的。可以理解为Eclipse的ToolBar， 可以在上面扩展出一个按钮来，那么ToolBar可以被视为一个扩展点。
2。 扩展的实现是可以被动态替换的。比如规则中扩展，根据参数的不同调用不同的实现。

两种设计基本内容是一样的。转化为文本描述如下：
一个扩展点定义， 包含一个唯一标记和一个占位符。
一个贡献者定义， 包含一个唯一标记。
一个贡献者实现定义
扩展点和贡献者通过管理器进行连接（其实就是配置信息），贡献者可以在多个扩展点被使用。贡献者和贡献者实现同样通过管理器进行连接（同样也是配置信息），通过不同的绑定规则进行动态切换。

不同之处（方案A和方案B）：
1。A：扩展点不依赖贡献者， 也就是扩展点本身除了占位符以外应该有其本身的外观定义。换句话说就是扩展点本身能够提供什么，他想要获取什么。而中间过程不注重， 由贡献者提供。
   B：扩展点依赖贡献者，也就是扩展点的生命周期小于贡献者，必须先有贡献者才能有扩展点。
2。A：贡献者需要有外观定义，内容和扩展点的外观定义一致。因为所有贡献的外观都可以被转化为输入和输出。
   B：贡献者不需要有外观，因为不同类别的贡献者外观很难确定。贡献者的外观将被其实现所决定。
3。A：扩展点可以一次拥有多个贡献者，通过组合贡献者的逻辑实现一个更大的贡献。
   B：扩展点一次只能拥有一个贡献者，如果逻辑分散在多个贡献者中（已经被实现了），那么需要另一个贡献者先将这些贡献者包含以来提供给扩展点使用。
4。A：扩展的位置信息应该单独抽取一个接口来描述， 这样在不更改扩展点外观的前提下可以更换位置信息的描述方式。并且仅需要针对不同的位置信息编写适配器来解析其内容。
   B：位置信息不应当单独抽取，其信息应当出现在扩展点的实现当中。由不同的扩展点适配器来解释。
我比较倾向A方案， 原因是我觉得B方案中诸如位置，外观信息都没有在接口中进行定义， 而依赖于其实现和实现的适配器进行解释， 这样失去了接口的含义。虽然这样带来的好处是无限的扩展可能性， 但是在代码层面没有对设计做出任何解释，因此此接口的存在意义也就消失了。但是B方案的拥护者认为正是因为仅描述了一些名称信息，给以后的实现带来无限的扩展可能，而添加了诸如位置，外观这样的信息， 可能以后在扩展的时候会遇到不必要的障碍。
那么各位大侠认为呢？

如果觉得对这方面内容有兴趣， 可以到我的blog上留言。

莫非我说的不清楚?
还是大家对这个话题不是很感兴趣?
自己先顶下吧

莫非我说的不清楚?
还是大家对这个话题不是很感兴趣?
自己先顶下吧

问题问得太泛泛了。
1. 没有前提（语境）的方案原则很扯淡
2. 概念定义不清楚：
“两种设计基本内容是一样的。转化为文本描述如下：
一个扩展点定义， 包含一个唯一标记和一个占位符。
一个贡献者定义， 包含一个唯一标记。
一个贡献者实现定义
扩展点和贡献者通过管理器进行连接（其实就是配置信息），贡献者可以在多个扩展点被使用。贡献者和贡献者实现同样通过管理器进行连接（同样也是配置信息），通过不同的绑定规则进行动态切换。”
这里给出的实际是实现细节。看了之后我仍然不太明白你的“扩展点”和“贡献者”的语义是什么。比方说，有那些Use Case，需要实现哪些功能，二者如何作用？“管理器”“连接”和“绑定规则”仍然是一些未定义的词，用它们解释“扩展点”和“贡献者”——感觉你在说拉丁语。

举个例子.
我要造个汽车, 首先我确定了车要有轮子, 于是我留下了装轮子得位置, 这个可以认为是扩展点.
其次轮子不是我自己生产得, 轮子有自己得生产商, 好比贡献者.
但是轮子具体生产厂商也不是我得轮子供应商. 比如我买了米其林得轮子, 其实是中国的某个小厂生产的. 那么具体到轮子以后可以认为是一个实现了.但是由于这些小厂的生产能力不一样, 所以质量也有些差别, 那么我的轮子供应商在考虑到我的要求以后决定给我不同的车型提供不同小厂生产的轮子, 这就是根据参数决定不同的实现. 不知道这么说是不是更容易理解一些?

问题是不是轮子这么简单, 引擎也是同样的原理. 也就是不单是代码的问题, UI, 工作流等等都会产生同样的需求. 如果仅仅是代码, 我也不会写这么大段的文字, 随便用个模式就搞定了. 所以这是一个high level的问题.

另外不知道你说的语境是指什么, 抱歉我对UML没有什么特别的兴趣, 如果只是指前提, 那么前提是做一个容易维护和扩展的系统, 没有什么特指.

语境就是：你讨论这个问题的前提条件。我想Use case并不是一个UML特有的概念，也并不是只能用UML来描述。它说明的是你的需求，你“到底”想做什么。
问题是你的问题不仅仅是"high level"这么简单，而是过于"general"了，通用到超越了设计的界限。它可以简单描述为：如何实现软件的可扩展性？
这下问题就复杂了。比如，UI和工作流解决扩展性的方式就不同。即使不同的UI框架，解决扩展性的方式也有所不同。c和c++不同，c++和java也不同。同样是工作流，解决不同领域问题时，其需求有所不同，对扩展性的要求也不同。
另外一个问题是，你的“可扩展性”定义是什么呢？多大的扩展性是你所需要的呢？如果有了一些实际项目的经验，你就会发现，扩展性的要求是由市场需求决定的。而我相信：设计过程中缺失的需求总是客观存在的，只是你不知道/没有发现/或者没有表述出来而已。抱歉我不是你们的市场总监，所以没法回答你的“可扩展性”的问题。

人对上帝说，我想要一个太阳，上帝就创造了太阳；
人对上帝说，我想要一个月亮，上帝就创造了月亮；
人对上帝说，我想成为上帝，上帝笑了，带来了无穷的灾难。

万能的程序是不存在的。同样，无条件的扩展也是不可能的。

参考一下eclipse的point extension

当然无限的扩展性毫无疑问是不存在的, 如果存在的话我相信也论不到我来讨论这个问题, 大师们早就应该有想法了.
问题就在于我们开发时候通常会碰到这样那样的问题, 虽然语言不同, 也非常有可能是异构系统. 但是最终他们会通过同一种方式来进行描述. 就像Method永远是参数和返回(或许有其他我不知道的). 我认为虽然很多问题的表象不尽相同, 但其本质是一致的. 如同用TagLib输出一段HTML和调用一个method求取一个结果其本质没有什么不同, 虽然看上去几乎没有什么共同点.
我的本意也并没有局限在某个系统或者某种语言上, 只是想讨论一下这样的2种思路的优缺点.

6楼的理解我个人认为是一个做项目或者做产品的态度, 没有明确的需求自然无从入手, 或者入手也将会是灾难, 这样的问题我们都不是第一次, 也不会是最后一次遇到.

比较赞同7楼的意见, eclipse的extension point做的的确很好, 理论上可以无限扩展, 不过他的设计我没有搞的很明白, 7楼如果有时间和兴趣可以指点一下吗?

其实你的评论一定程度表明了你的需求：我所说的缺失的部分。
两种类型的扩展我认为难分优劣。如果简单粗暴地评论的话，1更类似作项目的态度——我知道我要什么，不要什么，只在需要的地方引入扩展就可以了。如果以后有需求变化的话，再加一个story进行设计的改进。2更类似产品化的态度——我要面对更多的User，他们各自有着差异很大的需求。

这个扯得比较远了。一直觉得楼主是在讨论设计模式层面的东西，而不是eclipse式的framework甚至是architecture设计的问题。这种设计，一般水平的程序员还是不要模仿为好。因为：1. 水平。设计架构遇到的很多问题我想多数人可能还想不清楚；2. 需求。其实多数情况我们需要的只是一点小技巧，用不上这种层面的技术。孔子说，不要用大炮打蚊子。

其实技术不是越大越好，大在更多选择的同时，往往也意味着更多的约束（这还没有讨论到随着指数增长的工作量）。

咳，这些问题，还是把《设计模式》和《敏捷软件开发》两本书读通了再来讨论吧。