面向对象的设计原则之一：针对接口编程，而不是针对实现编程
针对接口编程，而不是针对实现编程
在面向对象设计方法中有很多值得提倡的方法，这些方法可以为我们的设计带来很大的灵活性，可复用性。其中一个原则就是“针对接口编程，而不是针对实现编程”
这个原则带来的好处有以下几点：
Client不必知道其使用对象的具体所属类。
Client无需知道特定类，只需知道他们所期望的接口。
一个对象可以很容易地被（实现了相同接口的）的另一个对象所替换。
对象间的连接不必硬绑定（hardwire）到一个具体类的对象上，因此增加了灵活性。
松散藕合（loosens coupling）。
增加了重用的可能性。提高了（对象）组合的机率，因为被包含对象可以是任何实现了一个指定接口的类。
在实现上：
C++通过继承纯虚类来实现接口继承。
Java对接口继承具有单独的语言构造方式－Java接口。
但从辩证法的角度看，事物总有利有弊。“针对接口编程”有如上诸多好处，确不可避免的带来设计的复杂性。特别对于没有丰富经验的设计人员。
其中令我比较困惑的地方是：
要想针对接口编程，就必然要最大化接口类，使包括所有子类的方法，这样我们才能利用多态性用接口类来一致的操作子类。但这会带来以下几点不足。
违反面各对象的另一个原则，这个原则是：一个类只能定义那些对它的子类有意义的操作。
接口类包括了并不是对每一个子类都有意义的方法，使接口类臃肿，难以理解。
从父类继承的无用方法，如何处理。
举个例子来说。我们要实现这样一个功能模块。一个TreeView上有各种节点。我们对这样的一个Tree 的节点操作。比如复制，剪切，粘贴，重命名，查看属性、设置它的图标，添加到树节点上等等。每种节点的相同操作（比如复制）的实现是不同的。
你会怎么设计它：
在C＋+中我会这样做。
我会将每种结点实现成一个类。以实现各自的相关操作（比如复制，粘贴），这些类都继承至一个纯虚的父类，在这个父类中以虚方法的方式声名子类实现我的相关方法，这样做的好处是当你从Tree中取出一个节点时，你不必关心这个节点是什么类实现的，你只需要以纯虚的父类指针操作它就可以了，这样就实现了接口继承的所带来的优点。
但是，如果并不是每个节点都支持所有的方法，比如有些节点不允许复制，有些节点不允许重命名等，那么从父类继承的声名如何处理，实现成一个空方法么？还是不将这样的方法放到父类中？如果不放到父类中，就没办法以统一的方法操作所有的子类了！
请大家就这个问题畅所欲言。分不够我还可以加，虽然本人比较穷，但仍可倾囊相赠！
问题点数：0、回复次数：56Top
1 楼BirdGu（鲲鹏）回复于 2003-09-04 20:38:35 得分 0
code to interface的主要目的是为了将接口和实现分开。接口可以看成某种服务的抽象。code to interface使得这种服务的使用者只依赖接口，而不依赖实现。并且可以在服务的使用者“不知情”的情况下替换服务的实现。因此接口当中包含的是对服务的使用者有意义的方法。如果能结合“敏捷软件开发”中的DIP原则（The Dependency Inversion Principle）会更有助于你理解这个问题。
至于你举的例子，属于“部分实现某种服务”的情况。只要服务中某些接口的实现（提供）属于optional的，就会出现你描述的情况。此时需要某种机制，或是服务的使用者可以询问服务的提供者它提供哪些服务，不提供哪些服务；或是服务的提供者可以抛出异常，以表明自己不提供某种服务（或不支持某种操作）；或是服务的提供者什么也不做。具体采用哪种方式需要根据具体情况来决定。具体到Tree的例子，我认为可以在树节点的接口中增加“询问节点所支持的操作”的接口。这样树的使用者也许可以根据该接口的返回结果提供用户不同的操作选项。具体的节点类对于自己不支持的操作可以什么也不做。总之这属于code to interface比较复杂的应用情况，不能算它的缺点。Top
2 楼zengjd（一）回复于 2003-09-05 13:01:19 得分 0
TO BirdGu(鲲鹏)
首选感谢你精彩的回复！
如你所述，还有个问题使我困或，如果以的需要增加子类，并此子类仍然有其它子类所不支持的方法，那么为了客房端的透明性，我必然要在接口类中增加此方法的声名，如此以往，必然导致接口类的膨胀，直到难以理解，及维护！
不知道这种情况该怎么思考及解决！
再次感谢你精彩的回复！
Top
3 楼BirdGu（鲲鹏）回复于 2003-09-05 13:25:24 得分 0
接口定义了服务的提供者和使用者之间的一种“契约”。对你的问题，还是应该从服务使用者的角度来看。如果新方法的增加是对原有“契约”的必须的增强，那么应该在接口中增加这一新方法。这在实际软件开放中也是很常见的。
如果只是部分接口的实现者提供的额外功能，那么也可以考虑定义新的接口,该新接口可以是原有接口的扩展。
在实际应用中必然要均衡需要和代价来决定具体采用那种方法。
在理解code to interface概念时不能只考虑interface的实现者，还要多从interface使用者的角度考虑问题。Top
4 楼ozzzzzz（希望敏捷）回复于 2003-09-05 14:04:58 得分 0
楼主的问题在于没有考虑到其实一个具体的类可以实现多个不同的接口 另外要注意尽量使用组合对象而不是继承来解决你的问题
具体到你的问题 一个解决方法是不那些操作设为不同的接口 在不同的点多重实现不同的接口 也可以实现一些具体的操作类 他们实现不同的操作（ 其实这个观点有些像OPT的观点 世界是由一些对象和单独方法构成 ） 各个节点的操作也是一个对象 这个对象是那些操作的集合Top
5 楼gmc007（江西的佬表）回复于 2003-09-05 17:02:51 得分 0
学习Top
6 楼zengjd（一）回复于 2003-09-09 12:43:31 得分 0
TO ozzzzzz(希望敏捷)
你的想法很不错，不过能否再详细点！
谢谢！Top
7 楼runsoft（清风）回复于 2003-09-09 21:16:38 得分 0
都做接口，那不用实现了。Top
8 楼yangzhenhai（叉子）回复于 2003-09-12 09:44:26 得分 0
增加服务,针对于特定功能的服务.
另外就是对于对象的划分,一个类如果太大了,那当然是划分的不对,把它分分分,分到最小，好的设计就冒出来了.Top
9 楼libi（风自吟）回复于 2003-09-12 10:23:16 得分 0
如果你是一家公司的老总，公司员工超过1000，管理不过来，该怎么办。
你可以把员工分为多个部门，由部门经理去管，你只要管好部门经理就可以了。而如果一个部门下的员工太多，又可以分为多个科室，如此下去。
接口也可以如此分层分类进行管理嘛，不是说只能有一个接口。这并不是针对接口编程的弊端，而是问题本身的复杂所带来的麻烦，难道用别的方法你又能有简洁的解决办法吗。就算有一种非常高效的压缩算法，你非要它把一本书压缩到一个字节，那是不可能的，一本书的熵值远不止8比特嘛。
至于你所提到的例子，在《设计模式》中，正好有个“原型模式”和你的问题非常相像，只是书上关心的是产生新对象实例的方法（clone），而你关心的是判断是否支持该操作，不妨叫check方法，用check替换书上的clone就是你的问题的解。
这里的麻烦在于复制、粘贴等操作是针对所有节点的，而节点特定于应用，也就是说具体是哪个或者哪种类型的节点要到使用时才能确定，甚至可以是将来设计的新类型节点，这就使得由复制、粘贴等操作来实现check很困难。但是对于具体的节点，它能够做什么样的操作，那是可知的，所以由它来实现check是最合理的解决方法。这其实是职责分配的问题，把check的职责归于节点而不是操作，而接口使得我们这种职责分配方案得以实现，这不正是体现了针对接口编程的优点吗。Top
10 楼swinging（山不在高）回复于 2003-09-12 10:52:59 得分 0
引用：
其中令我比较困惑的地方是：
要想针对接口编程，就必然要最大化接口类，使包括所有子类的方法，这样我们才能
利用多态性用接口类来一致的操作子类。但这会带来以下几点不足。
这里是可以考虑重构的，比如是否这个接口可以被拆分。
我的感觉是，楼主过于关注接口，以致把所有的抽象都送入一个接口，
这样接口的膨胀给人的感觉几乎是必然的。
引用：
比如复制，剪切，粘贴，重命名，查看属性、设置它的图标，添加到树节点上等等。
每种节点的相同操作（比如复制）的实现是不同的。
你看，你把复制、剪切、重命名等等的所有操作全都囊括了，
其实从不同角度看这些操作，是可以不同的，比如查看属性、设置图标这些可以属于是节点，而对于复制、剪切、粘贴以及添加就可以重新考虑，比方说我们可以使用策略模式，将这些
操作进行封装，通过对不同的节点配置不同的策略来实现对该节点的不同操作，
另外，我们还可以试下这样，我们另外实现一个类层，比如接口是对不同树节点的操作构成，
通过扩展这个接口我们来支持不同节点的不同操作，这是个访问者（visitor）模式，每次
要请求不同操作的时候，我们实例化一个访问者传递给节点类，由节点类自己的实现决定调用哪个操作。
另外，还有添加节点删除节点等等操作，都是可以重新考虑的。
我是看到后粗略得想得，可能不是很完整和合适，
另外，我觉得举的这个例子和楼主的标题有点不太合适，^_^。Top
11 楼swinging（山不在高）回复于 2003-09-12 11:07:03 得分 0
另外，对于接口，
保持简洁是不错的选择，
复杂的接口对于实现是有不少弊端的。Top
12 楼lajikuai（辣鸡块）回复于 2003-09-12 21:41:57 得分 0
引用：libi(风自吟)
如果你是一家公司的老总，公司员工超过1000，管理不过来，该怎么办。
你可以把员工分为多个部门，由部门经理去管，你只要管好部门经理就可以了。
*******************
这个例子好！茅塞顿开！！！Top
13 楼ozzzzzz（希望敏捷）回复于 2003-09-16 13:17:13 得分 0
sorry 忽然就找不这个帖了
其实我在前面的解决方法过于复杂化 不是好办法
就你举的例子只要你设计一个类
节点
{
boolean 删除（return fasle)
boolean 添加（return fasle)
...................
...................
....................
................
}
然后让那些具体的点去继承就可以了 这个时候你只要具体实现那些你要实现的方法
当然如果你的问题足够复杂 我说到的前面的解决方法才会有使用的必要 而如何实现那个方法呢 我想如果你明白refactoring 那么你不断的对逐渐复杂的问题重构就自然会得到答案
其实我们所说的接口不是在说interface 也不是在说abstract 我说的那个类其实就是一个借口Top
14 楼dragongong（中国龙）回复于 2003-09-16 13:49:24 得分 0
面向接口编程，首先应该抛开如何实现接口，而是将重点放在客户方需要什么样的服务上。这些服务应该是原子的，或者说是同类型的。不同类型的服务，需要提供不同类型的接口。其次，才开始关注如何实现这些接口，有时候，一个类实现一个接口，更多时候，一个类实现多个接口。Top
15 楼berl88（牛人）回复于 2003-09-17 13:27:45 得分 0
多瞧瞧设计模式Top
16 楼LiwuxLiang（好好，学习。天天，向上。）回复于 2003-09-18 21:29:59 得分 0
keep learning...Top
17 楼LiwuxLiang（好好，学习。天天，向上。）回复于 2003-09-19 09:24:13 得分 0
这种思想很好，linux内核中的‘连接件’技术就有这种意思。
当有很多链表，且数据结构不同时，就在数据结构中嵌入‘连接件’，不再用原来的数据结构（宿主结构）串成链表，而是使用‘连接件’来串成链表。‘连接件’的结构固定，只有next和prev指针。链表操作函数只关心‘连接件’的数据结构，只需写一份代码。
当要处理宿主结构时，通过‘连接件’的地址和‘连接件’在宿主结构中的偏移量，计算宿主的地址。
这样，编写链表操作函数时，不用关心宿主的业务逻辑。只要宿主结构中定义了‘连接件’，代码就有效，宿主结构的其他内容可以更改。
这种可以很通用。甚至用在生活中、工作中。很是提高效率，避免自己关心不必要关心的东西。Top
18 楼arfayr（阿飞）回复于 2003-09-19 09:42:52 得分 0
“我会将每种结点实现成一个类。以实现各自的相关操作（比如复制，粘贴），这些类都继承至一个纯虚的父类，在这个父类中以虚方法的方式声名子类实现我的相关方法，这样做的好处是当你从Tree中取出一个节点时，你不必关心这个节点是什么类实现的，你只需要以纯虚的父类指针操作它就可以了，这样就实现了接口继承的所带来的优点。
但是，如果并不是每个节点都支持所有的方法，比如有些节点不允许复制，有些节点不允许重命名等，那么从父类继承的声名如何处理，实现成一个空方法么？还是不将这样的方法放到父类中？如果不放到父类中，就没办法以统一的方法操作所有的子类了！”
第一抽象所有节点都需要的方法，作为最基础的接口
第二根据一些具体操作的不同，定义一些特定的接口
第三具体的节点对象实现基本的接口和特定的接口
题外话：
就你的问题，我觉的更像是权限问题，如果一个节点不允许复制、命名，那么选中这个节点的时候就根本不会显示菜单，无需调用。
当然如果这个节点本身就的确不需要复制命名，比如为了分类，人为的在TreeView中添加节点，这些节点毫无意义的，那么他们实际上应该是另外一种对象，根本就不应该实现接口
首先分析你TreeView的节点到底有多少“类”节点对象，那些节点对象需要实现共同的接口，哪些不需要Top
19 楼arfayr（阿飞）回复于 2003-09-19 09:44:48 得分 0
另，你能把你的那个TreeView结构描述一下的话，大家更好讨论了Top
20 楼arfayr（阿飞）回复于 2003-09-19 09:47:19 得分 0
一种极端的说法，灵活的最终解决方法就是加上一“层”这样通过隔离层降低耦合，才会轻松的更改更换调整。类似于 LiwuxLiang(希望...) 说得linux内核中的‘连接件’Top
21 楼icesnowworld（哈哈）回复于 2003-09-19 09:50:53 得分 0
受益 受益Top
22 楼twinsant124（蚂蚁的天空）回复于 2003-09-19 10:06:12 得分 0
尽量使用组合对象而不是继承...
不要搞家族性的合作关系...
:)Top
23 楼JingGG（郭靖）回复于 2003-09-24 07:45:44 得分 0
其实这是一个自关联，或者说自包容的结构
tree节点类不是接口，而是抽象类
再有，子节点类完全没必要从父结点类中继承，两者可以公用一个类
原理可参见composition模式
而对于“每种节点的相同操作（比如复制）的实现是不同的。”的情况
楼主可以定义若干个子类，继承tree的节点类，以实现不同的复制功能
作为tree节点类，应该进行自包容，在具体添加子节点时，需根据需要添加实现了不同功能的tree节点子类，即可
至于那些父类定义了的，子类没法完成的操作，完全可以放心的在其子类中将其实现为空操作
这样就可不破坏父类的接口定义了Top
24 楼shihb（）回复于 2003-09-24 09:25:47 得分 0
对于楼主的问题，我提一下自己的看法。在OOPrinciple中不只是提到了Dependency Inversion Principle(依赖倒转原则),还有一个Interface Segregation Principle(接口分离原则)。不要想用一个接口实现所有的东西。推荐仔细阅读一下OOPrinciple。Top
25 楼Fusuli（傻强）回复于 2003-09-24 21:17:50 得分 0
1：面向接口编程的前提假设是实现接口的子类一定会有变化，否则就是过渡设计
2：用接口分离很方便啊你可以声明这样的借口
IRightClickAble();
IDeleteAble();
...
随便组合，要啥有啥Top
26 楼Fusuli（傻强）回复于 2003-09-25 00:30:33 得分 0
过度Top
27 楼Fusuli（傻强）回复于 2003-09-25 00:40:14 得分 0
例：
interface IDeleteable
{
public void Delete();
}
interface ICopyable
{
public void Copy();
}
那么支持删除和拷贝的节点就是
class item : IDeleteable,ICopyable
{
......
}Top
28 楼zengjd（一）回复于 2003-09-26 15:48:43 得分 0
这样做不是很好吧，有很多接口启不是很乱？Top
29 楼Fusuli（傻强）回复于 2003-09-26 23:06:01 得分 0
TO: zengjd(一)
但是有时候反而也会减少接口的数量啊，例如下面三个接口：
interface Iitem_Deleteable_Uncopyable()
{
Delete();
}
interface Iitem_Undeleteable_Copyable()
{
Copy();
}
interface Iitem_Deleteable_Copyable()
{
Copy();
Delete();
}
这三个接口你用上面提到的两个接口组合就可以得到，所以说接口分离的灵活性是很高的
当然任何设计都有个度，不能过度，根据实际情况自己把握吧
Top
30 楼eastz（barry）回复于 2003-09-28 12:48:49 得分 0
接口是一个事物的抽象，而抽象一个事物时的基本原则是：实现类是是一个抽象类的特殊类型，而不是角色扮演的关系。Top
31 楼BirdGu（鲲鹏）回复于 2003-09-28 15:41:15 得分 0
eastz:
为什么实现类和接口之间不是角色扮演的关系？
我认为用“角色扮演”来比喻类和接口之间的关系更恰当一些。Top
32 楼libi（风自吟）回复于 2003-09-29 14:51:13 得分 0
同意BirdGu(鲲鹏)
角色就是规定了一些职责，对象扮演角色就是承担这些职责，抽象到软件上就是类与接口的关系，用“角色扮演”来比喻类和接口之间的关系岂不是更贴切。
使用“扮演”这个词，就表示对象主动承担职责，并且可以扮演多个角色，承担多个职责。相对来说，职责是死的，对象是活的，我们可以随意分配职责给对象。这样理解岂不是很灵活。Top
33 楼w_rose（w_rose）回复于 2003-09-29 17:51:06 得分 0
针对接口编程也好，不针对实现编程，这是结构化的原则呀？
对象应该有稳定的接口，也就是说数据结构应该有稳定的意义不变的属性和操作接口，这是结构化的基本原则。
不要认为OO语言中其中有“对象”两个字，其任何一个基本特征就都是面向对象的。
结构化是面向对象的基本出发点。面向对象不是抛弃了结构化，而是说在对象继承时既保持原来结构化的接口，子类又能形式上修改父类的部分流程形成自己新的流程。它是扩展了结构化的僵化的形式，使它变得比较灵活。Top
34 楼w_rose（w_rose）回复于 2003-09-29 17:57:18 得分 0
不了解结构化的初衷，就会误解“不针对实现编程”。把结构化与非结构化的矛盾误解为面向对象与结构化的矛盾。面向对象的程序风格中，在很细节的地方，不需要面向对象的地方，应该满足结构化的规则，这竟然被说成“面向对象”的基本原则，真正的面向对象被庸俗的东西、低层的东西架空了。Top
35 楼w_rose（w_rose）回复于 2003-09-29 18:14:33 得分 0
没有“复制等几个”接口的对象与有那些操作的对象显然最好不在一类，而应该是后一个类继承前一个类，他们显然都可以执行前一类的操作，这是面向对象的基本特征。这不不是体现什么“面向接口编程”，而恰是是说这个所谓的“原则”太含糊了，需要继续刨根问底地分析它，修改它。
如果将一个所谓的“原则”细化和修改之后仍然能达到原来的好处，甚至更实用更精炼，那么就应该放弃原来的过于含糊、抽象的“原则”。Top
36 楼FlyNow（愛國者，拒絕日貨,誰敢管我，我是公務員）回复于 2003-09-29 22:17:21 得分 0
我覺得所舉的這個例子，不適合用繼承。
1、TreeView是一個類。比如复制，剪切，粘贴，重命名，查看属性、设置它的图标，添加到树节点上等等。每种节点的相同操作（比如复制）的实现是不同的。
2、每個節點是另外不同的類。
3、TreeView這個類產生動作：复制，剪切。。。等，由節點Node類去完成。
4、由此產生了接口問題，也就是针对接口编程。
同樣的動作，不同的實現者有不同的實現，這不一定要用虛函數這種強藕合的方式來實現，中間可加入一個調度層這也是一個類，由類TreeView把動作傳輸給操作層，然後操作層再調用。這樣我們只要規劃出類TreeView的動作接口：比如复制，剪切，粘贴，重命名，查看属性、设置它的图标，添加到树节点上等等。
有了類TreeView的動作接口，我們再做實現。我們知道，最終實現是由一個個Node對象完成的，可這一個個Node對象因為各自的特征，可能並不是繼承於一個共同的父，也可能不能抽象出共同的操作方法，使得很難用一種通用的方式去操縱這些對象。操作層也因此出現，操作層可以很好地處理例如權限，也能針對不同的對象做不同的操作調整。更大的好處是對象之問的藕合變得松散了，編程就容易了。另外：如果這些松散的對象有類似的操作性，可以讓擁有一個共同的子類（操縱接口）。
題外話：我認為編程開始，很難抽象出這麼一個接口出來，因為需求往往未能明確，編程者對對象了解也不夠深。這種情況我將其稱為面向未知問題的求解過程。這時，如果強求一個共同的合理的接口，往往不可得，其思路就不必在這裡卡死，這裡可以先存同而求異，把對象劃小（也就把問題細化了），然後把能解決的小問題先解決掉，未知的問題就會在腦中越來越清楚，最後把問題領域弄清。
Top
37 楼jlsg（又撑一年）回复于 2003-10-09 17:27:20 得分 0
学习,但是做接口太累了,但是弄完了就好爽Top
38 楼bigpig（理解万岁！）回复于 2003-10-10 13:01:33 得分 0
upTop
39 楼dsqf（风）回复于 2003-10-10 14:40:10 得分 0
学习Top
40 楼tj_dns（愉快的登山者）回复于 2003-10-10 18:03:03 得分 0
置顶讨论！Top
41 楼jjstar（北人）回复于 2003-10-10 20:27:51 得分 0
markTop
42 楼yunhi（）回复于 2003-10-11 01:02:45 得分 0
好帖，收藏Top
43 楼skybat（skybat）回复于 2003-10-13 20:47:34 得分 0
拜读zzzzzzzzzzzzzzzzzzzzzzzTop
44 楼w_rose（w_rose）回复于 2003-10-14 20:00:04 得分 0
哪一个类编成组件，它的属性和操作不是接口呢？所以说，“针对接口编成”失去了其现实的明确的含义。今天，随便使用一种比较常用的编程语言，它都直接向同语言的其它组件甚至跨语言的组件显示接口。如果讲求效率，而不是“盲目背书”，自然会理出“到底什么样的接口最有价值、用的最长久”的问题。Top
45 楼oiq（www.dpspace.com）回复于 2003-10-14 23:28:12 得分 0
upTop
46 楼ajoo（聪明的一猪）回复于 2003-10-20 01:05:49 得分 0
w_rose:
你的这个对接口的认识，似乎和c++的观念很象：类的声明就是接口。
可是，我感觉接口的意义在于：
定义规范，尊重规范，围绕规范。
需要一个功能，就定义一个接口，然后继续自己的工作。如何实现这个接口，有多少种可能的实现，都可以暂时被搁置或者让其他人来完成。
接口的特点：
1。可以先于，也往往先于实现存在。
2。接口是抽象的，它可以有任意数量的任意方式的实现。也就是说，接口和类是多对多的关系。接口可以对应0或者任意个类，类可以对应0或任意个接口。
这些，不是编译出来的类可以提供的。可以说，他们的概念完全不同。Top
47 楼babyjavalover（勇敢）回复于 2003-10-21 23:58:21 得分 0
请问个位高手学软件开发看哪本书好，我有一点面向对象的基础Top
48 楼azyue（沙漠之弧）回复于 2003-10-23 09:47:26 得分 0
总结一下啊：讲接口和单独说对象实现都是意义不大的。你说接口做的再好而实现一塌糊涂。如果没有接口又会思路混乱，难以管理。所以两者结合威力无比。好象前面的有的兄弟也提到的了。
例：up back to 楼主的：
你的接口不一定要扩张定义没一个子点。你可以定义实现中的父接点的实现方法功能就是指向子点的指针。呵呵，这是实现的魅力。
大自然是一分为二的同时也是相互关联制约的。把握度和量的关系其乐无穷。大家有空也可以翻翻哲学书籍。其实只要时常反过来想想许多问题会有璀璨的一面。
呵呵其实也是逆向思维的精髓。Top
49 楼imafool（中正仁和）回复于 2003-10-23 14:30:26 得分 0
每种方案的应用都应适度。Top
50 楼Iamfish（呆鱼）回复于 2003-10-28 12:09:12 得分 0
听课。Top
51 楼smilemac（子非魚）回复于 2003-10-29 01:20:36 得分 0
ajoo,
来这里普及基础知识来了:-)
"可是，我感觉接口的意义在于：定义规范，尊重规范，围绕规范。"
说的不错。Top
52 楼thur（大地精灵）回复于 2003-11-06 23:44:06 得分 0
这个论点不就是DP里面的嘛！Top
53 楼BloodyCold（明日帝国）回复于 2003-11-07 15:35:28 得分 0
让我想起了this->指针。
呵呵Top
54 楼Raptor（猛禽）回复于 2003-12-31 11:36:29 得分 0
强贴，留名Top
55 楼qiao_feng2002（飞天鹿）回复于 2003-12-31 15:12:11 得分 0
关注，呵呵Top
56 楼Chuanyan（Cappuccino）回复于 2003-12-31 21:20:26 得分 0
把一个接口“最大化”来使相关的类都可以通用，这本身就是设计者的水平问题。只有经常尝到N多的类不能在同一个接口下工作的郁闷之后，才能舒畅地针对接口来编程。Top
