今天一个同事给我一个设计，但我与他有不同的看法，具体问题是这样的：

他的设计
接口 TableStyle
类 DefaultTableStyle 实现了 TableStyle
接口 ModifyStyle
类 CTableStyle 实现了 TableStyle,ModifyStyle

在接口TableStyle中只声明多个get方法，在ModifyStyle接口中只声明多个set方法。

他给我的理由是这样设计用户只需要用接口进行操作，不用直接操作类。

我不同意，我觉得其实把 ModifyStyle接口和CTableStyle类可以合并在DefaultTableStyle中，也就是在DefaultTableStyle类中实现set方法，如同swing里的TreeModel接口和DefaultTreeModel类一样的关系。

用户如果不需要修改缺省设置可以直接用new出来的DefaultTableStyle或是修改它里面的各别属性。

我的理由是可以省掉ModifyStyle和CTableStyle，结构更清楚，明了。
因为用两个类两个接口做的事用一个接口一个类就可以实现了。而且swing中有很多地方都是这样做的。


但是他的观点是他的设计更OO，更对象。

天哪？！　难道用户只与接口打交道，不与类操作是更符合OO的规范？？

到底OO与接口是什么关系？在java中的接口在OO中如何体现？从字面上看他的设计的确有那么些道理。

我现在提出来，大家一起来讨论一下吧，参与者均有分。

我明白你的意思了。前面我可能没有完全了解你的系统。

作为我不可能从总体上了解你的系统，我想设计原则是这样的:
如果只有一些类用get，另一些类用set，没有或很少有类同时用get,或set，且set用的较少，你可以用你的设计。如果通过interface使用get,set很频繁那就可以考虑用两个接口。如果还有许多类需要同时调用get,set，那就可以考虑我的设计。如果用interface没有更多的好处（如多态），而这块又只是系统中很小的一块的话。就连interface也可以不要。毕竟没有必要仅仅为了封装get,set方法定义interface。一个系统可以有多种设计，各有各的好处，到底选哪个，这需要你综合考虑整个系统。看这块有多大，是不是设计的重点。而且有时候完全的OO，完全的面向实际，反而不好。你觉得呢？

补充一下：
你还可以看一下java　api，你可以发现里面只有大的interface例如Collection，没有unmodifiableCollection，而是用Collections.unmodifiableCollection()实现的。为什么这样实际呢，我想也是为了不但通用而且简化编程，是权衡过的。编程简化和对象封装有时候是矛盾的。就看你想要什么，而牺牲什么了。

接口是比类更为抽像是一个类型。
使用它的目的是抽取一组对象的共性，用它一进行对这组对象的共有方法的操作。
在OO中，要使用多继承时，C++能使用多个类继承一个父类来进行，但java不支持多个类的继承，只有用接口来实现。
如两个Bat的子类，一个ABat,一个BBat他们除了是bear（兽）的子类，但都能飞，有飞的特性,而FBird是Bird的一个子类，但它也有飞的特性，把这个特性抽出来益是
Class ABat extends bear implemnts CanFly;
Class BBat extends bear implemnts CanFly;
Class FBird extends Bird implemnts CanFly;
我认为，在java中，接口仅仅是因为不直接多继承的来解决多种抽象共性的一个手段，主要是为了使程序结构清晰。去掉了C++多继承过于复杂的问题。

各位大侠施主，你们好！

如果接口的名字也换了得话，确实都要改了。小衲是首先假设
接口的定义是比较稳定的，不会经常修改，因为接口不包括
具体实现，所以一般来说，相对稳定一些。但确实存在连
接口都要修改的情况。

我寺般若堂中有一部武林奇书，已经流传上千年了，非常薄没有几
页纸，小衲没有看过，据说内功不够的人看了，手少阳肺经会有
阻滞之感。。。峡车穴也会每日三次的隐隐跳动。。。


不过澄观大师看过这本书！看完之后，回来也不说话，闷头就
写程序！   据他说。。。书里面。。。全都是。。。接口！！！！！
一个类都没有！！！！！

咳咳咳咳咳咳。。。嘻嘻。。。

总的来说，你的同事的设计结构更灵活。
你的观点更实用。
希望能综合一下.

面向接口编程是面向对象的基本原则。但是，正确的接口从哪里来？不是从天上掉下来的，是从现实中的类中抽象出来的。所以不顾及实际的对象，硬抽象一些似是而非的接口，就是对于接口的滥用。往往是从类到接口，再从接口回到类，如此反复数次，才能够得到真正可复用的设计。在这个设计中，考虑到Style不是Table的主要职责，可以使用Decorate模式来实现Style，如果Decorate会生成大量的细小对象的话，也可以考虑结合Flyweight。