大家觉得面向对象怎么样。。

star_in_sky

OO编程起源的很早，并不能说是什么新型的技术。为什么会流行起来？

可能是OO被当作了是解决软件工业中的“银弹”；“OO”的关键特点又

是相对容易理解的，这样就比较容易培养从业人员。工业界可以有大量的

人手使用。

大家都可以看到，现在很多东西，言必称“OO”，不关什么都要用OO来套。

但是结果呢，软件工业没有“银弹”，很多用所谓的“OO”设计出来的东西

可以说是根本没有达到OO所宣传出来的那种效果：易维护、易扩展等等之类。

从个人的经验来看，OO之所以陷入这个圈子，可能和下面的几个原因有关：

1. OO被过渡吹捧，导致大家无论什么都用OO去套。其实每种设计方法都有
   它合适的一面，而OO却被当作了万精油。

2. 我们的设计能力有限。其实用OO设计程序是很难的，一不小心就会导致
  过渡设计，从而快速提升了程序的复杂度；换句话说：我们做不到“合适的OO设计”。

3. 用OO设计的时候，我们太喜欢“创新”了，结果写出了一堆只有你才能够
  理解的东西，而对整个项目组而言，却无法维护、理解。

4. 本末倒置：用OO的时候，我们过渡的关注如何设计公有函数、私有函数，相互的
  对象接口、集成等等这些东西；而彻底忽略了“计算机数据如何组织－－数据结构”
  以及算法，这些程序设计的根本问题。
  因为：数据结构的组织是比较难的，惯性思维让我们回避了这些问题，幻想用OO
   去解决。其实，那是自欺欺人。

当然，我并不否认OO的优点，说了这么多，只是说说我心中的看法。

至于我，我比较倾向于：设计程序需要的数据结构，围绕统一的数据结构去使用相关
的算法。至于是不是用OO，那要看情况了。

楼主所提到那个例子：
foreach( _shape in _container )
{
        _shape.Draw();
}

你不觉得书中的例子是否太完美了？难道真正的产品中，
重新绘制一个图形会有这么简单么？
举个例子如果，新增的形状(假设叫做：myshape)绘图
是一个非常特殊的操作，你为了实现它(Draw)，需要增加
一个参数：Draw(XXX)，那么你该怎样把myshape融入你的框架结构啊？

呵呵。OO书中的例子都比较简单，他们主要展现了结构方面的
问题，告诉你结构应该如何去做。但是OO中的例子都会忽略
数据结构方面的内容，特别是新增加的体系如何融入现有框架，
是否有潜在问题？这都不会告诉你的。

好的设计是让程序变得简化，而非复杂。这个不是某个单独的设计
技术可以做到的。

flw

能讲一下不同意的原因吗？
pmerofc 发表于 2010-04-19 10:40

这句话的意思是说我同意吧。

zxrjkl

回复 33# pmerofc
对；C＋＋不仅支持面向对象，还支持面向过程，还支持泛型，是一门极为复杂的语言
我就特别喜欢泛型，将模板与运算符重载结合起来

shan_ghost

面向对象还是可以的， 不过不是想面向对象就能面向对象的， 生搬硬套， 做表面功夫， 只能带来更大的架子， ...
zylthinking 发表于 2010-04-19 09:39

    顶一个。


其实以前我就发帖说过，所谓面向对象其实是对一些良好设计风格的总结和概括——比如linux/unix泛文件概念之类。

达到面向对象水平的代码显然会非常简洁、稳定、易于重用和扩充，但这并不是说用了某种OO语言或者用了某些OO术语就是面向对象，否则就不是。

正相反，因为人类思维倾向于把事物分类化、条理化；而稍有整理的代码自然而然就显现出某种OO的特征。


但另一方面，想要恰当的分类化、条理化，是需要足够积累的。
就好像我嘲笑某操作系统教材说“现代操作系统有如下几种 实时、分时、批处理和网络操作系统”是一个可笑如“动物、植物和苹果”的错误一样，生搬硬套的分类不仅不会简化问题，不会让问题变得清晰、有条理，反而会搞得越来越复杂。


而OO语言，则不过是一种“可机读的代码内嵌文档”；由于虚假宣传以及沽名钓誉的种种“对象发现方法论”“面向对象程序设计”之类垃圾书/理论的推波助澜，导致很多人脑子里觉得“使用支持机读代码内嵌文档的语言编写代码”就等同于OO。

一方面，对“可机读的代码内嵌文档”的支持，从某种意义上说，对优秀工程师确实是一项福利——这可以让他们不用对初级工程师说太多废话，看看我的类结构不就全都知道了！
对于初级工程师来说，这个支持可以使得“机读内嵌文档后自动排错”，显然也是一种福利。

但另一方面，“可机读的代码内嵌文档”必然导致格式方面的要求——而且这个要求必然会是全方位的，否则就可能导致“内嵌机读文档”这个功能不能正常工作。

这必然会带给工程师很多额外负担。
这些负担里面最坏最不可原谅的，就是它强迫你必须对你所有的问题分类——而且，由于机器硬件限制，这种分类并不兼容于客观世界的其他领域（典型如正方形 not is a 长方形）。
于是，这——由于错误的分类，或者分类虽然正确，但在更广阔的问题域里会与其他分类思路/系统（或者叫分类哲学）发生抵触——就会额外衍生出无数问题。

哲学讨论永无止尽也永无对错，甚至于数学公理系统完善到一定程度就必然带来悖论——凭一个程序员，凭着三脚猫的“跟着我一步一步发现对象”教程，就能把一个大系统设计得丝丝入扣、毫无内部矛盾？尤其是这个系统还要额外引入“可机读的代码内嵌文档支持系统”的时候！


所以，一个负责任、有深度的工程师/设计师，在使用OO语言时，他或许能在某些方面感觉到这套东西带来了一点点轻松或者便利；但在更多方面——恰恰相反，他反而要为大量本不必要的分类、以及因为分类而衍生出的大量问题（这些问题往往极为微妙，以至于解释给大多数人听他们都听不懂）付出大量的精力。


而传统语言正好相反——你完全可以设计自己的“内嵌文档格式”，并且只在需要写文档给机器知道的时候才去写机读文档（比如GTK所做的那样）；如果一个问题很难分类或者没有必要分类，那么你就可以不分类。

毕竟，一个优秀工程师的目标，应该是做出“泛文件系统”这样灵活、稳定且几十年不变的经典设计，而不是ace那样堆砌大量类和设计模式的烂摊子。


——还是很久以前的老话，人们发现优秀的系统设计满足三个要素：封装、继承、多态，于是他们就天真的揣测，如果能强迫/辅助程序员把一切系统都搞的满足封装、继承、多态这幸福三要素，或许就能一劳永逸的解决软件复杂度问题。
——然而，如上文所述，生搬硬套出来的“幸福三要素”其实是一种负担，不仅不解决实际问题，反而会引入额外的复杂性，并且遮住人们的眼睛。
——幸福三要素本身没有错误，但它是设计出来的，不是模仿出来的，更不是强迫出来的。

渣渣鸟

我是来看吹牛的。
{:3_200:}

www1862

原来是我误读了，抱歉！
pmerofc 发表于 2010-04-19 10:46

英式中文？