关于GP和OOP，我来重新开一个帖子

[gigix]

内容相信大家都知道，欢迎来继续讨论！

[gigix]

STL并非只是一些有用组件的集合。它还有鲜为人知而未被了解的一面：它是描述软件组件抽象需求条件的一个正规而有条理的阶层架构（formal hierarchy）。由于所有STL组件都是精确符合某些特定条件而写成，所以STL组件可以相互作用，可以扩充，而且你可以在增加新算法和新容器的同时，对于新旧代码之间的协同作用深具信心。

计算机科学的重要进步，许多是由于发掘了新的抽象性质而促成。一个被当代所有电脑语言支持的决定性抽象性质就是子程序subroutine（又名过程procedure或函数function，不同的语言使用不同的词汇）。C++支持另一种抽象性质：抽象数据类型（abstract data typing，ADT）。是的，在C++中，我们可以定义新的数据类型，以及该类型的基本操作行为。

代码与数据的结合形成了抽象数据类型，它必须透过一个具有明确定义的接口来操作。子程序是一种重要的抽象性质，因为一旦使用子程序，你就不需要仰赖（甚至不必知道）其实际作法；同样道理，你可以使用抽象数据类型——可以操作甚至产生新值——而不必在意数据的实际表现方式。唯一重要的是其接口。

C++也支持面向对象程序设计（OOP），此技术涉及与继承相关、由多态（polymorphic）数据类型所构成的阶层体系。面向对象程序设计（OOP）拥有比抽象数据类型（ADT）更多的间接性，因而达到更进一步的抽象性。某些情况下你可以取用（参考）某值并操作之，却不必指明其精确类型。你可以撰写单一函数，用以操作继承阶层体系中的不同类型。

泛型程序设计（Generic Programming）意味一种新的抽象性质。其中心抽象性比早期如子程序（subroutine）或类（class）或模块（module）的抽象性更难捉摸。它是数据类型的一组需求条件。这很难让人领悟，因为它并非与C++的某个性质联系在一起。C++（甚或任何当代电脑语言）并没有任何关键字可用来宣告一组抽象需求条件。

对于这种“一开始令人泄气的含糊情况”，泛型程序设计的回报是前所未有的弹性，以及不会损失效率的抽象性。泛型程序设计和面向对象程序设计不同，它并不要求你透过额外的间接层来呼叫函数；它让你撰写完全一般化并可重复运用的算法，其效率与“针对某特定数据类型而设计”的算法旗鼓相当。

泛型算法抽离（抽象化）于特定类型和特定数据结构之外，才得以接受尽可能一般化的参数类型。这意味一个泛型算法实际上具有两部分：（1）用来描述算法步骤的实际指令，（2）正确指定“其参数类型必须满足的之性质”的一组需求条件。

STL的创新在于认知这些类型条件可以被具体指明并加以系统化。也就是说，我们可以定义一组抽象概念（所谓concepts），只要某个类型满足某组条件，我们就说此类型符合某个concept。这些concept非常重要，因为算法对于其参数类型的大部分假设，都可以借由“符合某些concepts”以及“不同concepts之间的关系”来陈述。此外，这些concepts形成一个明确定义的阶层架构，这让人联想到传统面向对象程序设计中的继承（inheritance），只不过它是纯然的抽象。

这个concepts阶层架构是STL的一个概念性结构，也是STL最重要的部分。由于它，使得重复运用和交互操作变得可能。此一概念性结构作为软件组件的正规分类法也十分重要——即使没有具体代码。STL确实包含有具体的数据结构如pari和list，但要有效率的运用这些数据结构，你必须了解其所依据的概念结构。

定义抽象的concepts，并根据抽象的concepts来撰写算法与数据结构，是泛型程序设计的本质。

[gigix]

这篇是侯捷先生所译《泛型程序设计与STL》的前言部分中的一段，代表我的意见。请各位大虾继续发表高见！

[Last_Dodo]

gigix: I don't know enough of GP to comment about GP but I don't completely agree with you on "面向对象设计发展到一定程度之后，已经将算法抽象出来，具体类只负责数据". In general of OO class hierarchy, child classes not only add details of data but the operation (algorithm) details as well. Sometimes, the whole operator(algorithm) might be completely different.

[magicblue]

我再推一把
现在的东东都是越来越抽象，GP也是。OOP侧重于对象的建模，然后可以描述对象的行为（在系统分析时我们首先发现对象，在定义对象的行为并分类），但是行为的描述始终被限制在类这个范围内，我们可以在这个类的范围内使用所定义的行为，但不能超出类的范围。GP的行为描述超出了类的范围，因为它不是基于对象的基础，GP忽略了对象只描述纯的行为，那么在行为的适用性上我们便可以超出类的限制。我认为GP是不能脱离OOP的，世界是由物质组成的，所有的行动都是物质的表现，我们用GP描述纯的行为只是一种适合人的思维模式。
GP比OOP更抽象，但我认为它不是由OOP发展而来，也不是因为迫切的需要这种技术。至于GP能发挥多大威力我同意gigix的“OOP应该也可以通过某种契合点与GP相联系，从而使自身发挥更大的威力”

[gigix]

to do_do：你说的很对。不过，在某些面向对象的设计模式（比如Iterator模式和Composer模式）中，我的确感觉到了这种近似于GP的思维方式。所以我才有上面这种大胆的想象：面向对象发展到一定程度后，趋向于“将算法抽象出来，具体类只负责数据”。并在此基础上，诱发了GP的思维方式。

[Elminster]

GP 中新的抽象方式很难理解吗？我倒是不觉得。“它是数据类型的一组需求条件”，只要这个数据类型符合这些需求条件，我们就可以用同样的方法来处理。做个类比：我们都学过高等数学，我们只要知道某个函数符合某个特性，比如连续可导，那我们就可以在完全不知道这个函数具体的定义式是怎样的情况下来讨论这个函数，得出关于这个函数的某些结论。

“面向对象发展到一定程度后，趋向于‘将算法抽象出来，具体类只负责数据’”，确实如此，但并不是在所有的面向对象设计中都存在这一趋向，而且这一趋向本身是否定面向对象的思想的：“对象拥有属性和方法”是 OOP 的基石之一。

GP 也好，OOP 也好，都是为了能够更好的用程序来描述和解决面对的问题。GP 是在 OOP 之后发展起来的，并且借用了 OOP 中“对数据抽象”的想法，但它们是两种不同的思路，应该是个互相补充的关系，而不是谁代替谁的关系。

[Sword_Sharp]

讨~~厌~~，你学人家~~~~~~~~！

[magicblue]

GP算不算是一种思想，算不算是革命，还要时间去证实。理论的“证实”是没用的，不管它多么多么先进，如何如何好，最终想要被人们承认还要看看这种技术带来多大创造力。所以GP的拥护者做出东东来给我们看看：）

[gigix]

（这是我在刚才的一个小时中的一些想法，请指教）

我们的程序设计方法，始终是在追求松耦合，以此提高灵活性。

首先回顾一下OOP思想的发展过程：一开始，OO出自ADT（抽象数据类型），一个对象就是“something with methods”（语出《Design Patterns Explained》）。在这个阶段，我们为了确保“算法”和“数据”之间的松耦合，我们要求声明和实现在不同的文件中进行（C++）。然后，我们开始用“责任”的眼光来看待对象，对象是“something has responsibilities”。于是，我们的实现方式灵活多了：JAVA中不再要求声明和实现在不同的文件。这是因为我们知道，“算法”在抽象类中已经搞定了，具体类里面只有“数据”和被“算法”回调的一些细节方法。各位可以注意一些设计模式，应当可以发现：面向对象设计发展到一定程度之后，已经将算法抽象出来，具体类只负责数据；只有符合算法要求的类才能被用于该算法——这听起来是不是有点象GP？

看了侯先生译的那篇文章，我好象有了点想法了。GP的目的是进一步的追求松耦合：算法在一个系统中规定，数据在另一个系统中规定，两个系统的specification相通就可以协作。使用ADT，我们得到的是对象级的松耦合；使用OOP，我们得到的是类级别的松耦合；而使用GP，我们将得到系统级别的松耦合。

想到这里，我突然有种感觉：template是实现GP的一种手段，但似乎还不是全部手段，似乎还缺少一些很重要的东西。而换个角度，似乎用OOP的实现工具也可以来实现GP的思想，但又说不出细节——我的水平太低了。而且，我感觉STL（乃至其他的数据结构基本库）也只是GP的冰山一角而已。我感觉GP将在未来成为和“面向模式的程序设计”同样重要的设计方法——Design Patterns Explained的作者Shalloway说，相信你的直觉。

在前面，我曾经说过：我觉得面向对象的分析设计方法是最好最实用的。大家都知道我当然不是指“滥用继承”的方法。我是指合理运用面向对象策略的“面向模式”的方法，是结合了很多优秀思想之后的面向对象方法。同样，我有理由相信：作为一种强有力的方法、一种有生命力的思想，OOP应该也可以通过某种契合点与GP相联系，从而使自身发挥更大的威力。而我就一直在寻找这样的契合点——说这种话，明显是把OOP放在了GP之上，那没办法，我是OOP的爱好者呀。

[gigix]

结分

[gigix]

结分