对于C/C++,什么时候不使用面向对象编程是有益的？

当我用C/C++进行编码时,我发现自己总是试图将所有内容都融入到OOP方法中.但我意识到,我并不总是强迫一切都进入这个模具.使用OOP方法有哪些优点/缺点？我对NOT使用OOP的优点/缺点更感兴趣(例如,不使用OOP有优化优势吗？).谢谢,让我知道.

1> Brian R. Bon..：

---

当然,很容易解释为什么OOP是一件好事的百万理由.这些包括:设计模式,抽象,封装,模块化,多态和继承.

---

何时不使用OOP:

将方形钉子放在圆孔中: 当不需要时,不要把所有东西都包在课堂上.有时没有必要,额外的开销只会让你的代码更慢更复杂.

对象状态可能变得非常复杂:Joe Armstrong发明Erlang时 引用了一个非常好的引用:

面向对象语言的问题在于它们具有所有这些隐含的环境,它们随身携带.你想要一个香蕉,但你得到的是一只拿着香蕉和整个丛林的大猩猩.

您的代码已经不是OOP:如果旧代码不是OOP,则不值得移植代码.Richard Stallman在1995年引用了一句话

向Emacs添加OOP显然不是一种改进; 我在使用Lisp Machine窗口系统时使用OOP,我不同意通常认为它是一种优秀的编程方式.

使用C的可移植性:您可能需要将一组函数导出到C.虽然您可以通过创建一个结构和一组函数来模拟C中的OOP,这些函数的第一个参数是指向该结构的指针,但它并不总是自然的.

您可以在本文题为" 面向对象语言的糟糕工程属性"中找到更多理由.

维基百科的面向对象编程页面也讨论了一些优缺点.

---

我同意答案:它可能更慢,但不需要!但是为什么它更难阅读(如果你知道语言 - 但如果你现在不使用语言,那么非OOP代码也难以阅读.)？我的意思是:看OOP代码就像在观看儿童教育视频一样:你有一个A类玩B类,其目的是控制C类等等.在非OOP中,你有一个函数调用其他函数.无穷无尽的复杂性,所以你必须在改变任何东西之前理解一切.(在OOP中,您只需要了解您正在处理的模块).

2> Andrew Sheph..：

---

面向对象编程的一个思想流派是,您应该将所有在类上操作的函数作为类中的方法.

C++大师之一Scott Meyers实际上在本文中反对这一观点:

非成员函数如何改进封装.

他基本上说,除非有一个真正令人信服的理由,否则你应该保持该课程的SEPARATE功能.否则,班级可能会变成这个庞大的无法控制的混乱局面.

根据之前大型项目的经验,我完全赞同他.

---

这一观点: