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

dq2004

象OOA/OOD这样可以贯穿软件开发全过程的方法或指导思想？

用了STL，写了几个模板类以解决某个特定问题就算泛型了？

大家来热烈地讨论一下吧！

OwnWaterloo

原帖由 dq2004 于 2009-12-7 09:41 发表
象OOA/OOD这样可以贯穿软件开发全过程的方法或指导思想？

用了STL，写了几个模板类以解决某个特定问题就算泛型了？

大家来热烈地讨论一下吧！

几个模板类，某个特定问题。

兄弟，讨论（甚至批评）某件事之前， 先去了解一下 ……

dq2004

我原帖的意思是通常情况下我们只是部分用到了泛型技术，
那么怎么才算是（或者如何正确地）应用泛型的开发方法？

我用词不当了？

OwnWaterloo

仅仅抽出2个出来举例：
1. lower_bound
解决的问题集合是： { (first,last,val) | first,last 属于forward,  val 可以比较，且[first,last)按此比较排序 }

2. vector
提供的是一个容器的集合。 对元素具体要求我也记不清了。


它们解决的是某个特定问题吗？

dq2004

看来我们没说到一块去，我说的“特定问题”是指业务上的（怪我没说清楚），就是说泛型是否可以像OO那样用于面向业务的分析和设计（当然也包括代码组织等较低层面）。

因为我感觉像《Essential C++》那样既然把泛型和面向过程、基于对象、面向对象放在一起讲（目录级别相同），是不是意味着泛型可以作为一种开发方法（论）或编程思想？

OwnWaterloo

"范型"（范型设计） 这个词太空泛， 我没找到一个准确的定义。 下面把"范型"， 换作"ducking type"， 不妨碍吧？
ducking type能更准确的描述stl的设计。

总的来说， ducking type是一种比interface更general 的抽象方式。
当interface演化到极端灵活的时候， 就形成了一种憋足的 ducking type。
ducking type无须付出任何代价， 就可以得到interface所能表现出的最灵活的形式。
而interface的灵活，会造成其他问题，比如interface的组合。

ducking type的劣势在于：
1. ducking type描述的契约不如interface那么明显。
2. ducking type现在还不是主流， 不被大多数人理解。

dq2004

你说的应该是静态多态这一特性，我基本同意你的观点，模板是比继承更通用的接口形式，而且避免了IS-A的强制语义要求。
从这个角度看，泛型技术是否主要集中于增强代码或对象组织的灵活性能力方面，从而有助于开闭原则的遵循？
也就是说，泛型基本上还是偏重于技术层面的辅助技术，而分析和设计还是可以照搬OO？

OwnWaterloo

不是静多态。 真的就是ducking type。
http://en.wikipedia.org/wiki/Duck_typing
C++只能实现编译时的ducking type， 也可能被称为静多态。


就像OO，本身一种思想。 o.function 只是该思想的一种语法形式。
ducking type也是一种思想， 与之对应的是interface。
stl使用了这种思想， template 只是实现这种思想的手段。 C++只能做到运行前。

OwnWaterloo

不是抠字眼。 这不是文学讨论， 没有统一的术语， 双方讨论的不是用一个东西， 就没有继续讨论下去的必要。

所以我说ducking type还不是主流。
如果在你脑海中，OO已经根深蒂固，那DT描述的确实可能就是一些在你看来不入流的东西。

如果一开始流行的不是OO、而是ducking type， OO可能永远流行不起来。

不管现实世界如何， ducking type才是更接近所需描述的问题， 而不是interface。
ducking type 只需要考虑 "完成这个功能，我需要那些其他功能"。
interface 除了要考虑上面的问题，还需要考虑 “如何将这些功能，拆分到各个interface之中 —— 即将那些功能打包称为一个interface”。
这个打包， 对interface来说， 是必须的。
问题本身不需要将解决问题的步骤打包到某个所谓的interface之中。 这就是interface本质上的毛病。

nicolas.shen

OO告诉我们它是一种“最接近现实世界”的建模方法 这种说法只具有时代意义，本质上oo没出现之前甚至高级语言没出现之前，asm甚至机器语言也是“最接近现实世界”的建模方法