OOP是现实世界中占主导地位的编程模型吗？

对象永不？好吧，几乎没有

在ACM通讯的VIEWPOINT部分中，我找到了一篇有趣的文章，标题为“ Objects Never？Well，Hardever Ever ”。这与“对象优先”或“对象迟”的观点截然不同。他建议“从不设对象”或“由对象开设研究生院”。

作者讨论了OOP，并提出了有关在现实世界编程环境中如何使用OOP的问题。他认为OOP不是主要的编程模型。他声称，例如，有70％的编程是针对OOP不太适合的嵌入式系统完成的。

当一些大学的教授想谈论OOP的好处时，他们谈论的是代码重用。他又说，作为另一个例子，这不是现实世界中的真实情况。重用代码比大学声称的要难：

我声称使用OOP并不像大多数人所相信的那样普遍，它不如其支持者所声称的那样成功，因此，没有理由证明它在CS课程中的中心地位。

我很高兴知道堆栈溢出中的人们对此有何看法？从程序员的角度来看，OOP是占主导地位的编程模型吗？

如果我应该只选择/学习/使用一种方法，那么它是否是面向对象的？为什么？

在ACM通讯的VIEWPOINT部分

如果您对实际编程感兴趣，那么ACM之类的程序是您想要阅读的最新资料。这些通常是伪科学出版物，在现实世界中没有任何应用。这些通常是出于宣传的非正统观点，是为了使作家与众不同并提升自己。

我声称使用OOP并不像大多数人所相信的那样普遍，它不如其支持者所声称的那样成功，因此，没有理由证明它在CS课程中的中心地位。

我倾向于不同意你的观点。OOP广泛传播并且效果很好。数量上，基于OOP的项目可能已经超过了其他策略的发展（让我们谈论15-20年的现代时间）。

但是，OOP不是灵丹妙药。它适用于某些开发，不适用于其他开发。就像其他方法一样。

但我需要提到的一件事是，课程应传达不同方法的知识。如果基于OOP，那是错误的。如果基于FP，那是错误的。它应该涵盖所有内容或完全不涉及该主题。

PS为什么要关心什么是主导而不是什么？只要选择适合手头项目的数字，然后将数字留给“研究人员”即可。

如果OOP是您所知道的唯一范例，那么也许您应该了解更多。但是，实际上，OOP到底是什么意思？是Java还是C ++？这是否意味着Smalltalk？这是否意味着可设置的值位和结束时间？（嗨，Scheme！）这是否意味着消息发送？（嗨，Erlang！）

简而言之，这似乎是一个有趣的问题。“ OO 有用吗？” 是一个更好的问题。而且，似乎是这样。（当然是给我的。）

所有开发人员都在哪里做那些“ 70％的编程”？在所有开发人员中，我知道只有不到1％的人在嵌入式系统上工作。

因此，我们有3个选择：

1. 我是独一无二的，您所有的朋友都真正从事嵌入式编程
2. 70％的开发人员被锁在地下室
3. 该统计数据已组成，文章为废话

除非我看到一些证据表明选项1或2实际上是正确的，否则我将选择选项3。

（顺便说一句，我不考虑现代移动开发嵌入式编程，移动开发通常是面向对象的，毕竟苹果强迫您使用* Objective * C来为iPhone开发）

我没有跟进的事实，但是OOP并不是主要的编程模型。试想一下，所有内部应用程序都是由参加过视觉基础课程或在Excel中进行过宏编程的人开发的。

许多应用程序都在执行命令式编程，其中所有逻辑都堆积在一个类或视图中。这可能是遍布整个企业的大多数内部简单应用程序。

这样做没有错，有几种方法可以解决相同的问题。有些比其他的更合适。

就像您指出的那样，OOP并非在所有情况下都有用。还有其他型号。

OOP是否是主要的编程模型无关紧要，只需将不同的模型适合不同的情况即可。

没有银弹。

Moti Ben Ari争论的是一个学术断言，这已经毫无意义。但是，他指出自己从未发现OOP是“有意义的”，显然它对成千上万的开发人员和软件工程师都适用，并且已在许多系统中使用...

但是，实际上，我的回答的重点是，陈述一个模型或另一个模型是否占主导地位有什么好处，那是盲目的使用它的良好理由吗？当然不是。

这实际上是一个很难可靠回答的问题。最大的原因是像我这样的人，他们在定制的内部应用程序中工作，而代码从未离开过我们的建筑物。我们在这里使用OO吗？我并不是说。还有多少其他程序员有类似的工作？他们也不说。我们确实有求职网站，但并非所有职位都已发布，并且并非所有职位都是针对真实职位的，这与招聘人员试图收集姓名列表不同。

即使我确实说过在工作的地方使用OO，这是否也意味着链接文章中的传统定义：对象，类，继承？还是说我主要将对象用作组织代码的一种方式？还是这意味着我真的只是对接口编程而几乎不使用继承？我仍然没有说，但是其中哪些真正算作OO？

直到回答完上述问题，再问问OO是否有用才有意义，更不用说占主导地位了。

当然是这样，因为这是管理层锁定的最新流行语。它也提供了比命令式编程更好的封装和抽象性，因此我认为从oop到下一个过渡的过程所花费的时间可能要比oop所必须的更长。

PS2：如果我应该只选择/学习/使用一种方法，那么是OOP还是不是？为什么？

如果您只想学习一个，则应该选择其他领域。

您应该了解类型和封装以及OOP的所有其他优点，然后学习如何使用函数式编程来完成这些相同的事情。

OOP绝对是现实世界中最主要的编程模型之一。

让我们面对现实吧，即使是设计数字硬件的人，也就是芯片设计人员自己，都在过渡到SystemVerilog和SystemC的组合。这些是面向对象的编程语言。

哪里不使用OOP？好吧，如果您正在编码设备驱动程序，那么很难想象为什么需要通用编程或多重继承，或者如果您正在执行AI函数式编程技术，那么从头上变得容易得多。尽管还有很多其他情况，但足以说明，OOP在寡头编程世界中是一个非常强大的地方。

我会说不。

我知道那里有大量的代码是使用“面向对象”语言编写的，但通常我发现代码只是将过程包装在类中。（这不一定是一件坏事）。我所看到的用这些语言编写的面向对象更多的代码往往是类之间的依赖关系的可怕混乱，这些依赖关系通常是无法维护的。

OO应该是关于在完全独立的对象之间传递消息的，我们确实在当今的代码中看到了这一点，但是在更大的层面上，即，我们将这些对象实现为dll或程序集或COM对象。我听说过“组件”。

因此，我认为是否使用OO并不重要-如果代码在其生命周期内是可维护的，在设计时就可以重复使用，并且可以快速开发，那么我不在乎如果它是纯过程性的或半面向对象的或完全面向对象的。我怀疑是否有人会告诉您主要样式是否是这些样式中的任何一种，但是我冒昧地猜测，即使将样式分解为类而不是函数，程序样式也将是最常见的样式。

我认为区分通过应用面向对象方法获得的解决方案和使用面向对象范例实现的解决方案很重要。我对好的面向对象软件的看法是将两种解决方案结合在一起。如果您考虑对象，并且尊重对象定义和交互，并且可以使用该结构来解决问题，那么您将获得一个灵活而健壮的代码。但是，如果您使用对象来使用过程范式来解决代码，则最终会遇到一些讨厌的组合，这些组合将无法利用Objects的优点。

我真的很喜欢我的代码是面向对象的，而且我已经意识到，起初创建一个好的结构可能会有些烦人，但是当处理当今的灵活性和客户端闪存需求时，我认为值得努力。

我不假装知道确切的数字，甚至不做一个粗略的猜测，但是有很多不涉及OOP的编程项目。我与工业机器人合作。这些程序往往是相当简单和直接的过程代码。实际的机器人操作系统更是如此。

我们使用的许多“工具”都是基于OOP的，但是它们在PC上而不是在机器人控制器上运行。其中包括编辑器，模拟和实用程序。