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

deargodzw

在客户的眼里，看到的只有结果

dq2004

上周的C++技术大会哪位去听了？看演讲简介有讲泛型的，还有与OO结合的，但是具体内容可能还没整理出来，暂时看不到。
今天无意间在云风的BLOG上看到了他对Lippman演讲的笔记，题目是大规模可伸缩性软件开发，结论居然是C++不适合做这个！

各位有没有用C++开发的大规模应用系统的可复用和可扩展性方面的优秀经验分享的？

附：第二届C++大会演讲简介 和 云风的Lippman演讲笔记

dq2004

原帖由 deargodzw 于 2009-12-9 14:47 发表
在客户的眼里，看到的只有结果

话是不错，但程序员不能只为客户活着，也得为自己着想啊。
如果能以少量的脑细胞和时间换取客户的认可，何乐而不为？
只是在达到这一目标之前，要先付出巨大的努力……

_unistd_

我们不需要泛型，泛形只能用来显摆和意淫，，无法解决发杂问题！

lygxy

太高深了，不懂

dq2004

原帖由 _unistd_ 于 2009-12-9 16:03 发表
我们不需要泛型，泛形只能用来显摆和意淫，，无法解决发杂问题！

泛型不行的话，C++里还有什么样的技术有这样的潜力呢？
或者说语言只是工具，关键还得靠程序员脑子里的设计？

要不咱们退一步，不说泛型，就说OO，在各位的日常工作中OO的分析设计对软件的复用和扩展起到了多大作用？
是不是大多数人利用C++实现的是基于对象而不是面向对象的开发方法呢？或者有对象的框架，但内容还是面向过程的？

star_in_sky

看你是如何定义“开发方法”了。

如果你把它定义为：解决软件工程问题的通用方法。那应该不算了。

如果简单点定义为：解决软件工程开发中某类问题的方法，那就是了。

个人从实际使用的角度来看：
1. 泛型更多的使用在了算法类的问题中。它把数据类型和具体算法剥离。使算法适用于多种数据类型。而不需要为每个类型
  重复定义类似的算法。这样可以保证算法的稳定性。
   
2. 为程序带来了强类型：在使用泛型中必须显示指定类型，这对程序在编译器排错、运行期类型安全奠定了良好的基础。

3. C++中STL可以说是泛型颠峰之作了，至此之后，泛型才得到工程界的广泛关注。(Java1.5之后也引入了泛型支持)。

个人感觉我们对于OO编程过于崇拜了，导致了我们在很多时候不自觉的就要把某种编程方法、思想硬和OO比较、硬要用OO思想去套用。以前看过Unix编程艺术一书，节中有关编程的一些基本原则提出了一些观点；但是我只是模模糊糊觉得有些道理，不过从日后的实际的工作中确确实实感受到了这些观点的真知灼见。

每种开发方法都有一定的适用范围。OO也有它适用的方法，并不是所有的领域OO都适用的。

其实，我现在回过头来看以往的编程道路发现：常常被我们忽略的东西才是真正有价值的东西。

就目前的计算机硬件体系而言，某位先知多年前提出的一个公式：
程序 ＝ 算法 ＋ 数据结构
才是真正我们需要的。

欢迎继续交流啊

everlasting_188

云风的博客上这二点写的很好：
1>从 java 开始学习编程，对程序员来说是有很大代价的，以前用 pascal 开始学习程序也有很大代价。大约是说，失去了对某些本质的理解。形成的对程序世界的世界观会有问题。
2>c++ 更像是 BS 大牛个人的作品，他一个人构架了 C++ 的大部分东西。但是我们未来需要新的语言来解决问题的话，应该参考量子力学的发展过程，大家一起来构架。C++ 呢，说这个最后可能会被我们带进坟墓。不是 C++ 不好，是因为细节太多，没人全搞的明白。结果每个人写出来的程序都不一样。指定规范很难。最后会有很多人不愿意学。

我认为：如果你用的技术会带来阻碍你理解世界，他不是一个好的技术。如果你用的技术阻碍你改变这个世界，他也不是一个好技术。java用的话，也只是在他专长的领域做；c++做的好，无所不能，关键大家都遵守规范(如：华为化在代码评审上和写上的时间差不多，而且将规范制定的相对好一些)。拿着技术炫耀的，最终也只能发展成为个工具，因为先天理解世界的能力不够（包括：无法很好的理解事物，无法让别人认同你的思想，想想穷其一个人，能写多大的程序，当然也可能有天才的存在），只能拿细节来炫耀。

老外整天讲：top-down，和bottom-up。首先是设计的问题，然后才是语言的问题，设计上需要什么功能，选择语言看是否满足。当然如果没有更好的语言，也只能选择他了。没有必要鼓吹什么，要解决现实的问题。

[ 本帖最后由 everlasting_188 于 2009-12-10 10:05 编辑 ]

hellioncu

做开发不要太教条化，在合适的地方用合适的方法，融会贯通

dq2004

说到对世界的理解，大家想想在生活中碰到现实问题的时候，有多少人会按软件开发的思路解决的？当然生活问题太复杂，还是举一个开发的例子，比如在做需求调研的时候，尤其是针对一个陌生的业务领域，除了用户给的文档资料，在与客户沟通过程中，经常是想到哪说到哪，能记多少先记多少的。也就是说，零散的、不完整的、平面化的思维可能才是更接近现实世界的。

再举一个生活的小例子：家里的东西经常会在想用它的时候找不到，有时候就会想怎么存放这些东西才容易找。如果用软件来解决这一问题，肯定是希望以专家系统的形式出现，就是把随即想到的零碎的原则输入进去，比如哪些东西常用、哪些怕压、哪些太小这些，然后由程序给出最终的答案。

很显然，用传统的方法很难对这样的问题领域建模，因为会有大量隐含的自然规则在里面。如果说这样的例子没有普遍意义，那么我们做软件开发究竟是为了解决什么样的问题呢？或者说现阶段我们能解决哪些问题呢？

通常来说，我们想软件为我们解决现实问题。那么如果放在远古时代，那些在山洞里居住靠打猎为生的用户很可能就会迫切要求解决前面提到的找东西的问题。而在信息化时代其实是信息化本身带来了更多的问题，实际上现有的软件大部分都是在解决软件化、数字化之后的这些附加问题。比如有很大一部分软件解决的是数据库本身的问题，或者说计算机世界的问题。而真正的现实问题仍是软件开发复杂性的根源所在！

目前还得不出什么有用的结论，可能只有一个结论是确定的——没有银弹。还有就是Lippman的演讲摘要里说到“统治了25年之久的面向对象编程范式已经到达了它的极限，它们难以随着程序规模的扩展而扩展”。可能以后回过头来看，现在正是处于一个新旧开发方法过渡的黑暗的历史时期。

总之很悲观，象前面star_in_sky说的，“每种开发方法都有一定的适用范围”。OO也好，泛型也罢，我们可能这辈子也找不到真正灵活高效的软件开发方法，只能埋头苦写代码，或许等实现了强AI才能把程序员彻底解放出来。