问OOP在大学里被滥用了吗？

EN

教授们的缺点是，他们不能让你使用那些持续了多年的、由许多不同程序员负责的庞大的、令人讨厌的程序。他们必须使用相当不令人信服的玩具例子，并试图诱使你看到更大的前景。

本质上，他们不得不吓唬你，让你相信，当一辆HO轨距模型列车撞到你时，它会把你的腿撕掉。只有最有说服力的教授才能做到这一点。

“如果解决方案与项目进展良好，我认为这个方案也应该适用于该项目的宏版本。”

这就是我不同意的地方。一个小项目适合你的大脑。它的大版本可能不会。对我来说，OO的好处是隐藏了足够的细节，这样我的脑海中仍然可以有更大的图景。如果您缺少OO，您仍然可以管理，但这意味着要找到其他方法来隐藏复杂性。

关注真正的目标--生成可靠的代码。OO在大型程序中运行良好，因为它帮助您管理复杂性。它还可以帮助重用。

但目标不是目标。好的代码是目标。如果程序方法有效，而且永远不会变得复杂，那么你就赢了！

当您的数据可以很好地结构化为对象时，OOP是正确的方法。

例如，对于正在处理来自传感器的字节流的嵌入式设备，可能没有什么可以明确地进行对象化。

同样，在对性能的绝对控制至关重要的情况下(当每个周期都很重要时)，OOP方法可能会引入计算成本，这可能是非常重要的。

在现实世界中，通常情况下，您的问题可以很好地用对象来描述，尽管不能忘记漏抽象定律！

工业界通常最终会决定，在大多数情况下，使用合适的工具来完成这项工作，而且在许多地方都可以看到OOP。高性能和低级别通常会有例外情况.当然，没有硬性规定。

如果你坚持的时间够长的话，你可以把螺丝钉进去.

我的5美分：

OOP只是更大模式的一个实例:通过将一个大问题分解成更小的问题来处理复杂性。我们软弱的头脑被限制在他们在任何时候都能处理的少数想法上。即使是中等规模的商业应用程序，其移动部件也比大多数人一次能够完全保持完整的精神状态的部分要多。在软件工程中，一些比较成功的设计范例利用了处理复杂性的概念。无论是将架构分解成层、将程序分解为模块、对操作进行功能分解、使用预先构建的组件、利用独立的web服务，还是在问题和解决方案空间中识别对象和类。这些都是驯服复杂的野兽的工具。

OOP在几类问题中尤其成功。当你能从“事物”和它们之间的相互作用的角度来思考这个问题时，它就会工作得很好。当您处理数据、用户界面或构建通用库时，它工作得很好。这类应用的普及使得OOP变得无处不在。其他类型的问题需要其他或额外的工具。操作系统区分内核和用户空间，并在一定程度上隔离进程以避免复杂性的增加。函数编程保持数据不可变，以避免多线程时出现的依赖网格。您的经典OOP设计也不是，但它们在自己的领域是关键的和成功的。

在你的职业生涯中，你很可能会面临比你自己能完全解决的更大的问题和系统。你的老师不仅试图给你配备现有的行业工具。他们试图传达的是，当你试图模拟现实世界的问题时，你可以使用一些模式和工具。为工具箱积累一组工具，并为工作选择合适的工具，这是您最感兴趣的。OOP是一个强大的工具，但到目前为止并不是唯一的工具。