泛型究竟算不算一种开发方法？

dq2004

你的意思是不是说面向接口是OOP的核心原则，而接口必须面临的打包问题带来了技术上的或额外的限制，同时duck-typing是解决这一问题的良方？

统一的术语是一方面，我也没有对duck-typing提出不同的解释，因为我对这个概念并不熟悉，不知道把它理解为泛型的一种扩展或是同一思维方式下的不同方面是否准确。所以到目前为止，我提的是泛型，你提到了duck-typing，应该算是同一问题的不同层面吧，讨论的大方向是一致的。希望你能进一步从较完整的应用角度谈一谈duck-typing对软件开发的指导意义，毕竟像你说的DT还不是主流，可能坛子里很多人对这一概念都不是很熟悉（至少包括我：）。

另一方面，讨论的主题才是更重要的东西。我发这个帖子的目的其实是想讨论一下OO之外的开发方法，尤其是在C++语言框架内。倒不是说OO观念对我来说根深蒂固，相反，我一直对OO持有怀疑态度，所以一开始对泛型编程抱有很大希望。但是用过一段时间之后发现除了在技术层面的使用，还找不到把它有效地应用于业务层面的途径或完整的方案。所以希望在这个帖子里听听大家的意见。

我之所以认为泛型是一个突破口，一方面在C++里这是目前唯一有希望的较成熟的OO之外的技术支撑，另一方面受一本书的启发：《产生式编程——方法、工具与应用》，它讲到了领域工程、特征建模、泛型编程和元程序设计等完整的开发方法，并且大量提及了泛型技术。不过产生式编程的简称虽然和泛型一样都是GP，但它是Generative而不是Generic，百度上说它是“一种软件工程泛型”。

总之，只要是OO之外的开发方法的讨论都欢迎。只有一个大前提，就是最好基于现有的C++技术，人工智能或者自动化编程这样“远大”的理想还是另开帖子讨论吧，除非你有成熟的解决方案：）

dq2004

原帖由 nicolas.shen 于 2009-12-7 21:15 发表
OO告诉我们它是一种“最接近现实世界”的建模方法 这种说法只具有时代意义，本质上oo没出现之前甚至高级语言没出现之前，asm甚至机器语言也是“最接近现实世界”的建模方法

说的好，很精辟！

那么我们的问题就变成了：在目前的时代阶段（后OO时代），有没有能扛起“最接近现实世界”大旗的新的开发方法？

BTW：要是在几年前，有人质疑OO的权威，绝对会被斥责为“你根本不懂OO”。其实就算是现在，你如果到Javaeye的论坛里吼一嗓子“打倒OO！”也会惨遭围观的（稍有夸张，实际上在那里对OO也已经有不少人开始反思了）。

OwnWaterloo

看来我得解释一下ducking type。

class C1 :  ## 一个只有g1 的类
        def g1( self ) : pass

class C2 :  ## 一个只有g2 的类
        def g2( self ) : pass

class C3 :  ## 有g1和g2的类
        def g1( self ) : pass
        def g2( self ) : pass

def f1( o ) :  ## 依赖o 有 g1
        return object.g1()

def f2( o ) : ## 依赖o 有g2
        return object.g2()

def f3( o ) : ## 依赖o 有g1和g2
        return o.g1() + o.g2()

python的语法我可能写错， 大致就这个意思。

C1 o1
f1( o1 )  ok
f2( o1 )  missing g2
f3( o1 )  missing g2

C2 o2;
f1( o2 )  mssing g1
f2( o2 )  ok
f3( o2 )  missing g1

C3 o3
f1( o3 )  ok
f2( o3 )  ok
f3( o3 )  ok

C1、C2、C3之间没有，也不需要任何继承关系。
它们和f1、f2、f3的交互是直接通过g1、g2、g3的。

C++ template可以在编译时实现上面的思想。STL也是采用的这种思想。


而基于interface的设计， 就必须将g1,g2,g3打包到适当的interface之中。
interface成败都在这个打包的过程。

struct I1 {
      virtual int g1();
};

struct I2 {
        virtual int g2();
};

int f1(I1* o) { return o->g1(); }
int f2(I2* o) { return o->g2(); }

如果我需要一个f3， 同时依赖2个方法，怎么办？


1. 运行时查询
int f3(I1* o) {
      return dynamic_cast<o2&(*o).g2() + o->g1();
}
将静态类型语言，当作动态类型语言使用


2. 将多个interface打包
struct I3 : I1, I2 {};
int f3(I3* o) { return o->g1() + o->g2(); }

这问题小，所以interface的组合最多3个。你想象一下，g的数量继续扩大，I会怎么设计？
这就是interface的问题所在。
所谓的架构 …… 很多时候就是在解决如何从所有可能的interface组合中，出那么几个"合理"的interface。
interface包含的方法多了么， 会引入不必要的依赖，影响实现。
比如f1， 也可以用f1(I3*) ， 但只实现了g1的类本来可以和f1交互的，现在不行了。
所以，java、.net中都出现了一些极端的interface设计： ICloneable { object Clone() }, IDisposeable { void Dispos() }
interface包含的方法少了么， f不能被实现。 走的就是上面2条路， 运行时查询，或者将interface继续打包。

假设有4个行为：
I_1;
I_2;
I_3;
I_4;

I_1_2;
I_2_3;
I_3_4;
I_4_1;

I_1_2_3;
I_2_3_4;
I_3_4_1;
I_4_1_2;

I_1_2_3_4;

才4个function，就会搞出这么多interfaces。全要吗
OO设计的时候，是不是绞尽脑汁在考虑如何从中排除一些？  滑稽！

而DT， 就是直接依赖你所需要的。 根本无须考虑interface这个间接的打包过程。

OwnWaterloo

原帖由 dq2004 于 2009-12-8 09:40 发表
我之所以认为泛型是一个突破口，一方面在C++里这是目前唯一有希望的较成熟的OO之外的技术支撑，另一方面受一本书的启发：《产生式编程——方法、工具与应用》，它讲到了领域工程、特征建模、泛型编程和元程序设计等完整的开发方法，并且大量提及了泛型技术。不过产生式编程的简称虽然和泛型一样都是GP，但它是Generative而不是Generic，百度上说它是“一种软件工程泛型”。

所以我说术语要统一。 这书我没看过。 你说的Generative我完全不明白是什么意思。

原帖由 dq2004 于 2009-12-8 09:40 发表
另一方面，讨论的主题才是更重要的东西。我发这个帖子的目的其实是想讨论一下OO之外的开发方法，尤其是在C++语言框架内。倒不是说OO观念对我来说根深蒂固，相反，我一直对OO持有怀疑态度，所以一开始对泛型编程抱有很大希望。但是用过一段时间之后发现除了在技术层面的使用，还找不到把它有效地应用于业务层面的途径或完整的方案。所以希望在这个帖子里听听大家的意见。

原帖由 dq2004 于 2009-12-8 09:40 发表
总之，只要是OO之外的开发方法的讨论都欢迎。只有一个大前提，就是最好基于现有的C++技术，人工智能或者自动化编程这样“远大”的理想还是另开帖子讨论吧，除非你有成熟的解决方案：）

C++语言内， STL就是一个成功的范例。
虽然没有人工智能那么远大， 但也还不成熟。

技术上面说，DT的缺点就是契约是隐式的。 python中，不符合规范就异常， c++中，不符合规范就导致所谓的天书般的编译错误。
更多是非技术上的， 比如该思想目前还非主流。

struct ILightable {
        virtual void light();
};
这算显示指定f与ILightable的契约了？ 某个light 背地里其实是打烂某个灯泡，你依然不能从接口上看出来。

DT无非就是少这么一点"文档式的代码"。 oh， ILightable,一看就知道， 可以light。 或者说，需要light。 但light看什么还是得去看文档。
为DT少的这点东西看2眼文档会死吗？ STL 5个iterator concepts， 5个html页面， 10分钟就看完， STL algorithm就理解一半。 很痛苦吗？
主观不愿意接受而已。懒惰而已。 尤其是在已经有了另一种抽象方式之后。



至于应用。
它目前没用， 不等于它本身就无用， 并将一直无用下去。 有这么多死扣"OO口号"不放的家伙， 毙了他们咋嘀？
国人嘛，就这个风气，大多数人喜欢跟风喊喊口号；即使自己完全不理解口号的含义。 反正大家都在喊，我喊2嗓子又何妨？
不是何妨，你还必须得跟着喊，否则就非主流。喊了才显得牛逼，喊了才显得霸气。

46年去日本建个核电站， 你觉得会不会被抽死？ 等石油用完了，号召大家禁止核电站，你觉得会不会被抽死？
眼光要长远。

OwnWaterloo

原帖由 dq2004 于 2009-12-8 09:41 发表
BTW：要是在几年前，有人质疑OO的权威，绝对会被斥责为“你根本不懂OO”。其实就算是现在，你如果到Javaeye的论坛里吼一嗓子“打倒OO！”也会惨遭围观的（稍有夸张，实际上在那里对OO也已经有不少人开始反思了）。

OO有tm什么值得被称为权威的？
那些斥责"你根本不懂OO"的家伙，有多少人又真的懂OO？ 30%有吗？

（某些）java程序员顽固不化是有事实依据的， 看看他们对java6、java7的态度就知道了 ： 我只是想当一个代码工， 我年纪大了， 别让我学那么多东西！

OwnWaterloo

上面关于OO有些过激 …… OO可行，但不值得迷信，更谈不上权威。
OO能权威，也是数量众多的口号家捧出来的而已。

rrrrrrrr8

我觉得,泛型就代码模板,没什么高深的.
就像更高级的宏一样,甚至你可完全不用鸟它,自已来另一套,就像QT的mo一样.

dq2004

呵呵，感谢OwnWaterloo的仔细讲解。看来我们至少有一点是一致的，就是对OO的不满

至于产生式编程名称里的Generative在这里不是什么至关重要的概念。在02年到04年的几年时间里，我想做一个平台类的框架（那几年“平台”满天飞：），当时就深刻感受到了OO的不足，又苦于没有替代的方案，就到处找资料，什么专家系统、语义网络、自动推理机、自然语言理解、甚至数学和物理都翻了翻。当时按“GP”关键字搜索泛型相关资料时就扯出了产生式编程的概念，还买了那本书来，反正只要是沾一点边儿的资料都想拿来汲取灵感了。

说来惭愧，那个平台项目最后失败了，并且直到今天我还是不知道该怎么实现它（或者我应该对最初这一想法感到惭愧？）。

从技术上来看，这几年JAVA世界里的框架、工具层出不穷，表面上看形势一片大好，OO分析和设计的讨论如火如荼，我却认为这恰恰是声称“一切都是对象”的JAVA在OO方法上的后继无力——因为真理永远只有一个——同质框架越多越说明没有哪一个是“贴近真理”的。

在C++世界里，接触到boost的时候让我眼前一亮，我几乎认定泛型或者说模板技术就是OO的继任者了，但是冷静下来又发现还是有很多困惑的地方，至少它还缺少业务分析和设计方面的完整理论，现阶段只能说在实现方面大有可为。

在C/C++论坛里，绝大多数时候我们都是在讨论具体的技术问题，很希望象我一样在开发方法层面存在困惑或某些想法的朋友能够就此展开一些讨论，互相激发一些灵感。

欢迎更多的朋友参与进来。

OwnWaterloo

我觉得，接口就像函数指针的模板，没什么高深的。
就像更高级的函数指针结构体一样，你甚至可以完全不鸟它，自己另来一套，就像glib的gobject一样，或者OIOIC一样

dq2004

泛型或者模板在技术上确实没什么高深的，主要还是背后的非传统思想。
任何新技术的出现都有这样的问题，你敢在第一次接触STL的时候就说：
“切，这算什么新东西，我早就这么想了，只是还没有发表而已”么？
所以这还是应了那句话——没有做不到的，只有想不到的。