Decorate Style

BlockDataSource = new BlockDateOrderFilter(

       new BlockDataSource(

              new SpecifyDateRangeEntryVODataSourceFilter(

                   new SpecifyUserEntryVODataSourceFilter(

                       new EntryVODataSource(SpringContext.getManagerFactory().getEntryManager()),

                       SpecifyUser

                   ),

                   new Today()

              )

       ),

       true

);

Strategy Style

       new EntryVODataSource(

              SpringContext.getManagerFactory().getEntryManager()

              new SpecifyUser(SpecifyUser),

              new Today(),

       ),

       true

);

从直觉上来说，上面显得更松，更易于测试。

问题在于对于FindAll这种Filter来说，N个Filter，复杂度就是N倍，我想这是一定不可以的

理性告诉我应该使用Strategy，但GOF上所举的Stream Decorate例子抑或JavaI/O一再用Decorate来对Stream Wrapper，复杂度同样也是N倍!

最后根据以下原则再次作出一个平衡

用一个Decorate你可以改变对象的外表，而Strategy使得你可以改变对象的内核。

BlockDataSource = new BlockDateOrderFilter(

       new BlockDataSource(

              new EntryVODataSource(

                     SpringContext.getManagerFactory().getEntryManager()

                     new SpecifyUser(SpecifyUser),

                     new Today(),

       ),

       true

);

这里的排序功能以Decorate出现，而其他的作为Strategy，没有增加任何复杂度，

换句话说在不增加复杂度的情况下更倾向于Decorate。

再次体会模式本无所谓模式，是一个代码演化的过程，思想演化的自然过程，领会对象意图，抓住基本概念，结合具体问题作出恰当的选择折中和平衡，这可能就是最大的挑战!Fighting..YO

庄 said,

这篇文章非常重要，列位看官，打起精神了！

1、为什么要OO，这是第一个问题，原本数据和程序是分离的，导致大量的问题，因此通过面向对象的方式，将数据和处理数据的程序，封装在一起，这就是面向 对象的基本动力。当然，这样的封装带来了很多麻烦的问题。（下一篇文章，我会讲讲，数据与程序各自继承，然后灵活封装的一些思路。）但是好处还是很多的。

2、封装，可以有一个很直观的理解，一个对象有了外部和内部，使用者只能看到一个对象的外部，而内部的数据和程序则是不可见的。我们可以打一个形象的比 喻，一个对象是一个“三维实体”，而它的接口，就是一个“二维的表面”。一个class，就完全的“具足”了三个概念“数据、程序、接口”。如果不是为了 开发大规模的程序，仅仅有class，就足够了。

3、共享->继承。继承的概念来自于共享，作为一个独立存在的对象，每个对象之间都是有差别的，如果没有继承的概念，那么就会需要写很多重 复的代码。而通过继承，我们可以做到：“A和B的共性的部分，我们抽取出来，先做一个基类。然后让A和B在继承之后各自扩展它。”

4、实例->abstract class。因为所有的class都只是模板，真正有意义的是class的实例，因此，多个对象的共性部分，也许并不够资格成为一个真正的对象的模板，因此，出现了abstract class的需要。

重申一遍：只有当多个对象所要继承的公共基类不能被实例化是，才需要abstract class。也就是说，如果这个公共基类可以被实例化，我们不该用abstract class，如果只有一个对象来扩展这个abstract class，那么这个abstract class也是多余的。

5、抽象类的形象比喻。抽象类其实应该称之为不完整类，从几何的比喻来说，它同样是三维的，同样有外部、内部的区别。唯一的不同是不能通过它得到一个实例。

6、二维表面->接口。interface与类、抽象类的最大的区别，它不是一个三维实体，它没有外部、内部之分。因此，千万不要将interface理解为抽象类的进一步抽象。作为一个二维表面，它的最大的作用不是实现多重继承。再重申一遍“java从来就没有提供过多重继承”。interface最大的作用，是提供对于一个类的多种可能的视角。

你将一个class的implements部分去掉，大多数类都照样可以编译，这个类的功能也同样没有减少，唯一的区别是：“按照那些接口来使用 这个类的用户会报错”。因此，相对于多重继承的“加法”，interface不是，也不可能给一个class带来新的实质内容，而只是提供了多重的视角。

7、因此，结论如下：
A、如果你定义的一个interface没有给一个class带来新的视角，那么这个interface就是浪费。
B、如果你想实现多态，那么你应该使用abstract class，而不应该使用interface。因为他们语义不同。哪怕是一个“纯抽象”的抽象类，也不能等于interface。
C、所有的语言元素都是因为需要而产生的，但是你总是可以误用他。

ajoo 反驳到,

引用: interface最大的作用，是提供对于一个类的多种可能的视角

我不认同这个说法。

你还是在围绕着你的"class implements interface"的视角说话。而这在interface的使用中属于次要地位。
为什么你不肯看看"declare requirements as interface and use interface directly"这样一个“即声明即用”的模式呢？


"implements SomeInterface"虽然是必要的，但是毕竟仍然是用来建立类和接口的关系的。也就是说，仍然是和实现细节相关的，模块内部的东西。
在另一篇帖子里我就曾经强调过，一个类implements一个接口还是同时implements两个接口，对于结构设计来说，并不重要，只不过是类内部的实现细节。

interface的作用在于把规范，协议这些东西作为first-class的类型使用。它唯一的作用就是帮你解耦。
把“类型”和“类”分开来看待。
interface的最大作用，不在于可以给“类”提供什么东西，而是在于可以让你忘掉“类”，忘掉实现，直接面对规范，协议。

简要地说：interface的重要性在于它本身的抽象性。而不在于"implements"这个keyword。
凡是谈到和“类”相关的任何东西，都不是最重要的。

另外，说“如果没有继承的概念，那么就会需要写很多重复的代码”，我也是不同意的。不用继承，用接口组合，也可以达到类似的功能的。而且更灵活。

引用: 只是声名一个interface，而没有一个（哪怕是一个MOCK）对象来实现它，你是不可能真正开始使用你的类的

这话没错是没错(当然,还得看你怎么定义"使用"这个词.没有实现类,我也可以写我的接口的使用类)

但是,有什么意义呢? 没有main(),你的所有的类都不可能最终运行,那么难道我们说什么设计都要扯到main()吗?

人不吃饭都得饿死,难道我们讨论编程的时候能说oo的主要方面在于吃饭?

“即声明即用”意义何在？
我上星期写了一个检测输入错误的模块. 我自己定义了接口StringMap来表示外界的输入(很可能从HttpServletRequest). 我完成了代码. 编译通过. 然后自己用HashMap来adapt出来一个StringMap来单元测试. 代码测试完成后. 交给别人, 别人只要把HttpServletRequest adapt成StringMap就成了.

我理解的老庄的意思,

第一层：接口是用来实现的。

对这个用法，我同意老庄的观点，它不是必要的。本来类就已经是实现了，为什么还多加个接口？脱裤子放屁嘛！

第二层：接口是用来给类来提供一个视图的。
这个方法，在我的总结，主要作用就是封装。你可以进一步把一些实现细节封装在类内部。然后给外部一个最小的视图。
我的静态工厂的目的就是这个。
但是，我仍然同意它不一定是必要的。我的经验是，如果一个类要做成public的，漏到package外面，就考虑让它实现一个接口，隐藏构造函数，然后用静态工厂公开语义入口。这种api式的设计方式可以保证包内部的实现变化最小程度地影响包外面广大的用户。
至于包内部的东西，就不见的有这个必要。毕竟这种设计是有额外代价的。

第三层：接口是用来给类提供多于一个得视图的。
我对这个不以为然。一个类有几个视图并不重要。用户看见的只是一个一个的视图，谁管它们是不是同一个类的视图？当用户看见的是视图，具体类对他们已经毫无意义了。

而我的看法：接口是用来让你忘掉类而直接面对规范和协议的。

 >> http://forum.javaeye.com/viewtopic.php?t=7776

 ...

ajoo said:

老庄：

我觉得可能是我的表达太过二义性了。造成你的理解和我说的意思不大对的上茬。

你看我最后回复的那篇了吗？你的思路始终还是在“实现者定义接口”这个基础上。

而我前面反驳你的论点，都是基于“使用者定义接口”这个前提。

一.所谓“接口是你自己定义的。反映你自己的需求。什么叫没有完成？”这句话说得不清楚，也难怪你不明白。

举个例子，我要实现一个功能A, 在实 现过程中，我发现我需要调用一个功能跟我自己正交的模块B。

此时，我第一步要作的就是，总结我对模块B的需求， 对吗？

怎么总结？ 通过接口。我自己定义出模块B要给我提供的接口IB以及相关的语义。

然后，把IB ioc进来，直接就用了。

这个IB是否一定对应"class B implements IB"？ 我不知道，我也不关心。

这里，我实现我自己的A的时候，可能已经有了接口IA，也可能没有。但是，无论如何我定义了接口IB。

二.关于单元测试，单独测试A,单独测试B, 联合测试A+B。都是少不了的。

不过，如果之间不是用接口耦合，你就只能联合测试了。我个人是认为单元测试是不可省略的。

我不希望A的作者有借口说我不能测试，因为B还没测完呢。

你的思路更象是造房子，地基打好之前别的都得等着，房子没造出来，屋内装修也是痴人说梦。 我的思路则象是计算机内部得各种插件。给每个插件定义好如何和别人联系的接口插槽，然后大家自己干自己的，互相之间不需要有其它依赖了。

三.你的例子还是围绕在实现功能A, 是否要先定义接口IA上。我对这个问题的回答是：不一定。看程序员自己了。

但是，我说得免费的情况是指“需求者定义接口”这种用法。也就是，实现功能A，发现需要功能B, 那么不要费神去找实现了B的类，直接就定义接口IB给自己用。工作量是不是最小？

忽然想起一个问题。不知道大家在写业务层，持久层，物理层的时候，是否让业务层直接依赖持久层的类，持久层直接依赖物理层的类？

这就是一种建造金字塔一样的方法。要测试业务层？必须等物理层写完了，并且测试好了，然后持久层写完了，测试好了，才能开始。

要是想从jdbc based向xml based的物理层迁移，整个金字塔就得重建。

相反，如果业务层依赖的仅仅是抽象的持久层的接口，持久层依赖的是物理层的接口。那么，迁移物理层，其它层并不需要动。

用“点菜”式的使用者定义接口的方式，业务层的接口是用户下的菜单。

持久层的接口是业务层实现者下的菜单。物理层的接口是由持久层实现者下的单。

实际上，如果面向接口，这个分层都不是绝对的。

对业务层的客户，我看见的是业务层的接口，你如果kiss，可以不搞那么多层，直接用jdbc实现业务层，并不影响我。

对持久层的客户（主要也就是业务层了），也是一样，我看见的就是接口，你的实现是通过调用间接的物理层还是直接用jaxp api写xml与我无干。要kiss就kiss好了。

这才体现出面向接口的好处。它给kiss提供了最大的可能。

嘿嘿，top down, bottom-up。

我前几天还在感慨fpl里面隐含着的bottom-up的思维方式和oo里面鼓励的top-down的区别，马上在oo里面看到这两个家伙又打起来了。

要我说，interface的一个好处是，它让你不用严格top-down，也不用彻底bottom-up。

用interface，你可以在问题的随便挑一个感兴趣的层次开始考虑。比如，我这人不懂业务逻辑，从top-down开始搞业务层比较麻烦。

我也不会jdbc，从物理层开始bottom-up也不可行。

没关系，用接口，我把两边都抽象起来，把问题拦腰一切，从中间开始着手做持久层。

你说这是top-down还是bottom-up呢？

这其实更符合人的思维方式的。

比如说，公司里，多数人都不会象总经理那样需要高瞻远瞩，运筹帷幄，但是也不是所有人都了解最基层的每个公司运营的细节。

但是，不妨碍每个人在自己的职责范围内给公司做出贡献。

公司可以换总经理，可以换底层的程序员，换了谁，公司都照样运行。为什么？就是因为这些上层啦，下层啦，都是按照一定的协议互相合作，并不是固定地依赖某个人。其实，所谓上层下层，主要是一种谁服从谁的行政关系（在oo里就是谁调用谁以及各个调用的语义），结构上只是各有分工，并不一定是严格的层次结构。

孔子说得好：只有分工不同，没有高低贵贱。

夫子真是大师啊。几万年前就把oo理论深入浅出地谆谆教导给了子孙。可惜我们这些不肖后代居然把淀积深厚的文化精华弃如敝履，反而去追捧浅薄的洋鬼子们的几孔之见。真是羞见夫子于地下呀。