Extension设计

你在9楼的评论很有道理. 问题是,假设现在按照方案2来做,比如做一个AOP的实现, 我相信外观等等的因素都应该非常容易定下来. 事实上接口对于实现来说并没有起到什么规范作用. 或者这么说, 好像某某领导视察工作, 最后说了句"一定要加倍努力, 争取XXXX"之类的话. 那么接口的价值在什么地方体现呢? 第一种方案或许约束了以后的发挥, 但是这个接口可以看到一个明确的需求的体现, 而不再是泛泛而谈.

另外我恰恰认为这是关于framework的问题, 为什么会扯到设计模式呢? 我觉得设计模式的确在很多地方给我们带来了好处, 但是没有一个好的框架,即使小技巧再好, 对于一个公司来说可能获益也不会很明显.

一直有一种印象，楼主对于什么是设计模式似乎不是很理解。应用了interface就是framework而不是design model了？Gof的《设计模式》一书中因为使用C++做例子，而C++中只有class没有interface，所以会造成这种误解吧？换到java中实现时，里面多于50%的类可能都会变成interface。而如果换了《敏捷软件开发》这本书，大概就不会造成这种误解了吧。

既然楼主比较认同我在9楼说的，就继续这个思路往下说吧。很多时候，是否采用interface也是由需求决定的，或者时髦地说，由需求驱动的。我觉得，在多数引入interface的时候，我们要想一想，这个interface是否是必须的？我的想法是，如果你不能保证这个接口以后80%会被使用的话，那么这个interface的引用就是有问题的。我们的代码，应该是最快最简洁地完成手头的story。以后的需求变更，还是由新的story来保证比较好。

说到这里，你可能已经意识到了我能这样做是因为我使用了XP的开发模式。不错，其实我一再想强调的是：
1. 更改代码和设计实际上不是最time-costing的工作，我们不能怕代码以后会有改动，而要时刻做好改动的准备（XP所说的拥抱变化）。而这种保证并不是“过渡设计”带来的，而是比如：更好的测试，更好的代码风格，等等。
2. 对于多数人来说，适当的设计要好于过渡设计。我真的不明白为什么扩展性的问题不能“扯到”设计模式。不夸张的说，每一个设计模式，100%都和扩展性问题有关。
3. 框架是什么，我想楼主似乎也不太理解。它其实往往意味着更多的依赖。设计都是两面性的，当你引入更大自由度的同时，必然会引入与此相当的约束性。小的设计有小的约束，大的框架性的东西有大的约束。设计约束的内容种类繁杂，诸如，你使用何种平台？数据库？你的文件格式如何？你的扩展模块如何工作？代码格式如何？类的设计有何限制？你的性能要求是哪个数量级的？是否支持国际化？等等，等等。很多动辄说要引入一个“框架”的人，往往是些初学者。因为他们根本没有意识到这些约束的存在。他们谈论“框架”，往往只是因为一些诸如通用，远程，并发之类的大词，让他们觉得“爽”，而根本不是权衡利害之后的结论。
而做到“权衡利害”的一个基本前提就是：你的需求是什么？
相反，一个小的、适当的设计是比较容易找到的，即使对很多初学者。
建议初学者先学会了设计模式，超越了设计模式之后，再来考虑框架性的问题，不然你写出来的，只能是毫无价值的习作。

做了这么多年编程，感受是：能够真正体现“一个明确的需求”的合适的方法，目前只有Unit Test。
interface？很多interface并不能给你足够多的信息，还是需要通读源码才能获得自己想知道的东西，即使这接口是高手设计的。至于初学者设计的接口么，咳咳，我就不说了。

老兄的意思我已明白了. 就此打住, 这样争论不会有什么结果的. 不知道还有没有其他声音可以听到?

说句题外话, 不知道按照现在的行业水准, XP如何才能实现?

另外有个建议, 不要动则"不理解", 这或许不是讨论问题的态度.

其实未必。比如，我一再强调：明确你的需求。我希望的是，对明确的问题进行讨论。而你的答复一再回避这一点。你的AOP的例子和你的问题并不是一回事，不是么？


XP不能实现？至少我现在在用。javaeye上很多大拿都有这样的实践吧!我就跟他们学到不少。


我想这是楼主动怒的原因了。其实这也是我自勉的话。承认"不理解"没什么可耻的，至少我觉得自己还处于一个“半瓶醋”的状态。怕的是不理解而不自知。不过javaeye上的大拿们也只是达到了“理解”和“超越”设计模式的状态吧。有谁说自己已经很牛，能够独立设计一个通用“框架”的，能够创造“architecture”的，站出来让兄弟敬仰一下。我想他们大多也只处于探索和讨论阶段吧。

我明白了楼主的意思。其实楼主你把你的扩展点想像成接口或方法签名、将你的所谓贡献者想像成实现该接口的类或实现该方法的方法体，你的一二三四不就很容易理解了吗？你那样说太抽象了，有几个知道你自己的一套术语是什么意思。
这两套方案分别对应由上往下和由下往上的两种不同设计模式，一种是解析，一种是综合，一种是J2EE，一种是IoC，一种是类似于Eclipse平台的插件体系，一种是大杂烩应用程序，一种是Micro kernel操作系统，一种是monolithic操作系统。这些不同的对比分别对应于你所说的所谓方案A和方案B。别说的那么抽象，本来很简单的问题。
给你分析一下：


可翻译为：
接口不依赖于类的定义，也就是接口除了接口的声明（占位符）还应该有其本身方法的签名定义（外观定义）。换句话说，接口本身能够提供什么，它想要获得什么（都体现在方法的签名中，参数和返回值）。而具体接口方法的实现过程不注重，而由实现该接口的类提供。

翻译：
接口要根据实现的类定义，也就是现有了类的定义，才能有调用接口。（典型的由下往上上的设计方法，先有实现，再抽取接口）

翻译:
实现类要有方法签名的定义，其签名和类实现的接口方法定义一致。因为所有的实现类的方法签名都可以转化为方法参数和方法返回

翻译
实现类可以没有事先没有接口方法的签名定义，因为不同实现类开始要实现的接口很难确定。实现类的方法签名需要由其方法体定义所决定。（典型的自下往上的设计方法，先考虑怎么实现，再定义一个描述接口）

翻译：
同一个接口可以一次拥有多个实现类，通过组合实现类的逻辑可以实现另外一个实现类（代理机制）。

翻译：
每个类开始定义只能有一个，如果类的实现可以由其他多个组合实现（已经被实现了），那么需要另外一个类将这些类组合起来提供给最终的实现类。（Spring的POJO使用IoC机制进行组合不就是这样吗，由于只有一个实现类，接口和实现类就没必要分开了）

翻译：
这儿已经说明了所谓的扩展位置在程序中对应为一个接口。只是不明白你后面说的这些更换位置信息什么意思。

翻译：
这儿可能的意思是实现类不需要接口，其信息应该出现在实现类（扩展点的实现=贡献者=实现类）的签名中。由不同的代码调用。

这样不就很明白了吗，显然应该使用A方案。
总之实质上来说，你说的A、B两个方案就是设计模式的两个不同方向。
有时这种问题没有必要抽象的来想，找一个对应物进行想像最简单不过了。比所谓各种模式要容易理解多了。

16楼翻译的不错. 我说的太过术语化了.


更换位置的意思是, 由于扩展点很难说到底会在什么地方, 或许是一个Java类的Method, 或许是JSP中的一个Tag,或许是其他什么东西. 这些位置很难用一个通用的接口来定义清楚, 因此将位置接口从扩展点接口中剥离出去, 而扩展点中除了位置信息不能在接口中定义清楚之外, 其他都可以. 因此在解析的时候, 解析扩展点的适配器不需要更换, 只需要根据位置的实现来更换解析位置的接口就OK了.

除了这个之外, 我还有一个问题比较困扰, 就是外观. 外观到底能不能简单的定义为输入和输出的组合, 不知道老兄有什么见解, 还望赐教.

btw, 老兄的名号好熟悉, 经常出没于什么论坛?