我认为面向对象相对面向过程的思想更贴近人的思维,可以构建现实世界模型的映射,使得面向对象编写的代码,便于管理和维护。类把数据和行为(算法)溶为一体,使得编程语言活泼生动反映客观世界。
v;
.....
v.sort();
个人这样好些,希望大家讨论
58 个解决方案
1,类似CObject呵呵.这可不是好事,很容易出现菱形之类的继承的。除非你的类都用单继承.
我觉得这两个都算不上“缺陷”,顶多是两个值得讨论的话题。
面向对象是不是万能的?类是不是该有单根体系?这些以前已经有过很多争论。
至于说孤立函数对于成员函数的优势,“Exceptional C++”三卷本中有相关的论述,当然也不见得完全正确,因为这里本来就没啥正不正确的,不过值得参考。
典型的井底之蛙……
.net/java 的类组织形式的确适合快速开发,尤其是语言的快速掌握。但 OOP 体质是有着先天缺陷的,你这个题目取反了,应该说是对比 C++ 你应该发现 .net/java 的先天缺陷才对。
OOP 体质是什么先天缺陷呢?看我的博文吧,在 C# 和 F# 里面有着比较详细的讨论,JAVA 的情况只能更糟。
你这两点其实都是站在 OOP 的视角上来看的,严格的 OOP 体系才有 object 基类和算法和数据结构封闭在类体内的情况出现。
或者你认为你可以通过 JAVA 写出我在
http://blog.csdn.net/hikaliv/archive/2009/09/16/4559927.aspx
文中所举的更优的例子。
或者你认为 OOP 可以写出如我在
http://blog.csdn.net/hikaliv/archive/2009/08/10/4431824.aspx
中所举的算法,不要求你写得比之高效,你能写出来就行。
至少能让你明白,到底谁才有缺陷。
语言都有自己的优势,放弃优势,向别的语言靠拢,必要性不是很大吧...
C++没有所谓的超类,是为了兼容c的一些特点,保持高效率。而且可能会存在不同的类,他们不具有共同的祖先,没必要有一个共同的超类。
第二个恰恰是为了实现面向对象的同时保持对类的具体类型不知情,实现隔离性,这也是泛型设计的目的。
超类?为什么一定要有个超类呢
这个不管总哪方面讲都不能算是个缺陷
上边JAVA,C#能实现,而C++好像在VC MFC提供这种机制,标准C++好像没有,除非自己写一个吧。
1. 如果全部使用同一个基类,则在程序中就会出现大量的基类使用。那麽程序将大部份时间用来分辨衍生类。那麽C++变成Java那麽的低效,那不如直接用Java吧。
2. 容器与算法分离的优点,正正就是保持其抽象,使容器与算法拥有各自的发展方向,C++标准认为string就是一个容器与算法捆绑在一起的失败之作。
楼主可能对C++认识未深,看到的是C++的表象,不知道C++背後为工程人员的一片苦心。
真正意义上的C++仅仅只是提供了一个非常严谨、灵活的语言核心而已。而你说的那些全都被称为库,或是框架。
在不同平台下都有其各自的框架。比如,一个不怎么样的MFC框架就有CObject,对应于Java的Object。
而一个非常优秀的Coco Framework则定义了Object作为所有类的超类,并且也对应于Java的Object。
STL库主要是用于泛型。而你用Java所举的例子其实是比较糟糕的。你使用了反射,这对于运行时的存储器占用而言非常高。
而C++大多用于系统或嵌入式应用开发,对运行时性能以及存储空间的要求相对较高。
楼主也可以用C#开发的Vista和用C++开发的Win7进行对比一下,结果是显而易见的。
11 楼,你使用了
反射。这正是我在文章中批判的。
既然你觉得你懂 OOP,那么应该会有这样的认识:
当你用基类来推导派生类时,你并不知道派生类的情况。你无法预知派生类是什么情况,所以你有两种方法来解决这个问题:一个是机制上的,反射;一个是算法上的,你要遍历所有可能的情况。而反射本质上也是一种遍历。你觉得你的代码“很简单”,而背后隐藏着多么复杂而臃肿的过程,表现上是看不出来的。EFFECTIVE 系列对这类问题有过很多的讨论。不管是 EFECTIVE C# 还是 JAVA。
还有,反射是运行时的,C++ 和 F# 强调编译时,比如C++模板和F#内联泛型。你能用 OOP 语言写出模板或者内联泛型么?你是写不出来的。放心吧。而 C++ 和 F# 可以做到,而且运行时泛型也可以写,只不过认为这不值得而不愿意去实际操作罢了。
你写出了东西,但却没有跳出思想。你的有点那什么的留言,我删除了,鉴于你的那些回复,我不想说什么,劝你,该删除的是应该是你的固化思维。
或者你好像并没有看懂我在文章中肯定什么,批判什么。你的代码和回复印证了我的批判。
每个语言都有自己的定位,
在一种语言中是优点的特性,跑到定位不同的语言里,可能就是缺陷,
TIOBE统计数据表明,Java>C>Php>C++,并没有出现哪种语言一边倒的迹象。
可以肯定,楼主看过的书很少。至少没有完整的看完一本书。
裘宗燕翻译《C++程序设计语言》
第386页的容器设计。讨论了这个问题。
第二个问题就是大家认为其优秀的原因。你却把它看做是缺点!
内联函数只是宏,宏的级别早在C中就已经实现了,
你举得例子不能算是OOP本质缺陷,只能算是使用OO思想设计时候容易产生的缺陷。
无论是JAVA,C#编译器都有能力实现这种宏级别的检查机制,编译器其实能做到这些,为什么没有加入呢。
你举得那个F#例子,说明在编译前函数地址已经是确定的。
而JAVA 思想本质是强调在狂平台特性,在运行前函数是不知道确切地址的!
而C#思想也是如此,尽管只是在windows跨平台。
而C++在使用多肽的时候,父类指针指向派生类的时候,调用派上类函数的时候,地址也是无法确定的,也是在运行时候确定的。
一句话,不要为了面向对象而面向对象。
面向对象不是万能的。
举个简单例子,你能用面向对象进行图像编程?这涉及到大量线性代数,概率之类的数学计算。
如果你真能这么搞,恭喜你,数学不用再搞抽象了,数学不用再号称对象无关了,你可以把面向对象的概念引入数学了。
STL之类的就是数据结构算法之类的,你真要坚持,用彻底的面向对象搞个STL吧,Java面向对象比较彻底些,或者你可以用Java搞个STL库,或者用Java搞图像编程,随你怎么搞罗~
特别讨厌那种就知道在网上说这种语言不行,那种语言不好的人。俗话说:“金无足赤,人无完人。”
更何况是一门由人设计出来的语言,能没有缺陷吗?也不想一想如果没有缺陷那它还能叫做C++吗?也不
想一想,要不是C++有这些所谓的缺陷,那各位以为它还会有这么多的激情吗?
楼主,面向对象又不是一切,你看看人家的blog吧。
泛型,ducking type,functional prog都很精彩啊。
楼主既然已经对java、C#什么的这么了解,又何必再搅C++浑水。
你既然要学门新的,不如考虑erlang、lisp、haskell。。。。
1 所有对象不是从一个基类派生的。
C++,应该有一个超类,是所有类的基类 提供所有对象的基本方法,类似于JAVA中Object类。
-----
C++的类是表示一个概念,并不一定要求用一个你说的超类来把这些概念联系到一起。好比C里面的整数,包括char, short, long, int,你觉得C有没有必要在定义一个种“整数”类型来表示所有的这些整数类型呢?
2 类把数据和行为(算法)溶为一体,使得编程语言活泼生动反映客观世界。而在STL的模型,是把数据结构,算法,和迭代器区分使用的,个人认为不符合面向对象的思维。
-----
为啥一定要用面向对象去理解STL呢?再说那些搞JAVA的不是也提倡MVC,将数据,控制,视图分离吗?只是你把类看成了组成世界的一切。不过范型貌似在概念上更加道法自然,只是编成语言并没有过多地展现而已。
范型的算法就是,不管你是什么类,不管你具有什么样的基类,只要你具备这个算法的要求,那你就可以使用这个算法。不过这两点面向对象和范型并不冲突,只是看你从哪个角度去理解这个世界罢了。
LZ不接受和不理解C++的思维方式,只是没看透背后的道理。
显然面向过程更符合人类思维,书本上那些什么汽车飞机的例子根本就不是真正的面向对象,纯粹是用来骗你入门的,面向对象里三大特征:封装、继承、多态,这些例子仅仅体现前两个,只能算高级的基于对象或阉割的面向对象,多台才是面向对象最本质的特征,而一旦有多态,一旦有抽象类,一旦有设计模式了,面向对象就不是正常的人类思维了,仅仅是为了维护方便。
人的通常思维是顺序的,而不是跳跃和继承的,尤其对于我们这些工匠思维的工科人员,面向对象也许更符合艺术家的思维,但是对于程序人员来说,没学过面向对象的很难理解面向对象的那种封装、那种抽象的“为什么”(说过了,不要用汽车飞机交通工具的例子,那不是面向对象),而熟练地面向对象设计人员,安全是根据经验和设计模式理论在设计,他对于面向对象的理解是建立在已有的知识基础上,而非人类的自然思维
大家可以去看看设计模式的书就能理解我所说的,通常设计模式不会涉及到具体的语言,不需要编程的基础,但是,不会编程乃至于会编程但经验不足的人,看设计模式基本看不懂,为什么这些“符合人类思维习惯的面向对象设计模式”你没有知识和经验基础却看不懂,唯一的解释就是“它实际上不是人类的正常思维方式”,而仅仅是一种适合于软件开发、降低维护成本的的方式。
1 java不是也有原生类型吗? long boolen啥的
2 面向对象不是万能的,对象和对象之间的关系,不一定很密切,不要指望所有的对象都成为一个继承体系。
难道还指望int 和float这些原生类型都有继承关系?
Please note that object-oriented programming is not a panacea. "OOP" does not simply mean "good" - if there are no inherent hierarchical relationships among the fundamental concepts in your problem then no amount of hierarchy and virtual functions will improve your code. The strength of OOP is that there are many problems that can be usefully expressed using class hierarchies - the main weakness of OOP is that too many people try to force too many problems into a hierarchical mould. Not every program should be object-oriented. As alternatives, consider plain classes, generic programming, and free-standing functions (as in math, C, and Fortran).
Generic programming is in some ways more flexible than object-oriented programming. In particular, it does not depend on hierarchies. For example, there is no hierarchical relationship between an int and a string. Generic programming is generally more structured than OOP; in fact, a common term used to describe generic programming is "parametric polymorphism", with "ad hoc polymorphism" being the corresponding term for object-oriented programming. In the context of C++, generic programming resolves all names at compile time; it does not involve dynamic (run-time) dispatch. This has led generic programming to become dominant in areas where run-time performance is important.
Please note that generic programming is not a panacea. There are many parts of a program that need no parameterization and many examples where run-time dispatch (OOP) is needed.
http://topic.csdn.net/u/20091118/22/c30c52e4-2ee1-43f5-9fe2-913908029d8b.html?58983
http://www2.research.att.com/~bs/bs_faq.html#oop
建议所有论坛中c++ers都到这看一下
Bjarne Stroustrup's FAQ
http://www2.research.att.com/~bs/bs_faq.html#oop
有时候,某些事物的优点在一些人的眼里反而容易成了确定啊
凡事有利必有弊