OOP 在大学里被滥用了吗？ [关闭]答案

【问题标题】：Is OOP abused in universities? [closed]OOP 在大学里被滥用了吗？ [关闭]
【发布时间】：2009-07-21 21:44:56
【问题描述】：

我两年前开始上大学，从那以后我一直听到“首先设计你的课程”。我有时真的会问自己，我的解决方案应该首先是一堆对象吗？有人说你看不到它的好处，因为你的代码库非常小——大学项目。项目规模的借口只是不要让我感到厌烦。如果该解决方案与该项目配合得很好，我相信它也应该是该项目的宏版本的正确解决方案。

我并不是说 OOP 不好，我只是觉得它在教室里被滥用，像我这样的学生日夜被告知 OOP 是正确的方法。

恕我直言，正确的答案不应该来自教授，我更喜欢从该领域的真正工程师那里听到。

OOP 总是正确的方法吗？

OOP 何时是最佳方法？

OOP 什么时候是不好的方法？

这是一个非常笼统的问题。我不是在要求明确的答案，只是从该领域获得一些真实的设计经验。

我不关心性能。我问的是设计。我知道这是现实生活中的工程。

================================================ ====================================

感谢所有贡献。我选择了 Nosredna 的答案，因为她总体上解决了我的问题，并让我相信我在以下方面是错误的： 如果该解决方案与项目配合得很好，我相信它应该也是该项目的宏版本的正确解决方案。

【问题讨论】：

为什么？
@jalf，因为它是主观的，没有一个正确的答案。
向您的教授提出一个有趣的问题：“请提供您编写的最大的面向对象和功能性应用程序的描述，最好部署为供您以外的其他人使用。”我想知道他们指导我如何开发严肃系统的依据。
@Kevin 这不是主观的。阅读投票最多的答案。它们没有任何主观性。
@duffymo 辉煌 :) 从现在开始我会问每个教授这个问题！

标签： language-agnostic oop

【解决方案1】：

教授们的缺点是他们不能让你参与那些持续数年、由许多不同的程序员参与的庞大、令人讨厌的程序。他们必须使用相当没有说服力的玩具示例，并试图诱使您看到更大的图景。

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

“如果该解决方案与该项目配合得很好，我相信它应该也是该项目的宏版本的正确解决方案。”

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

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

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

【讨论】：

+1 来自我。写得很好，诺斯雷德娜。不是您第一个非常有价值的答案，也不是最后一个。
是的。这是让我希望我能多次投票赞成一个答案的答案之一。
>>> OO 的好处是隐藏了足够多的细节，这样大局仍然可以塞进我的脑海。完美的解释！ :o)
我希望我可以为此添加一个以上的赞成票。你对程序代码做了鬼鬼祟祟的评论，这是 OO 的全部意义 [简化事物]

【解决方案2】：

OOP 是一个真实世界的计算机概念，大学将遗弃在课程之外。当你申请工作时，你会被期望熟悉它。

话虽如此，步履蹒跚，OOP 主要是为了管理复杂性而设计的。由一两个学生在家庭作业时间编写的大学项目对于这样的大型项目来说并不现实，因此这些示例感觉（并且是）玩具示例。

此外，重要的是要意识到并非每个人都以同样的方式看待 OOP。有些人看到了封装，并制作了非常复杂的大型类，但对任何外部调用者隐藏了它们的状态。其他人则希望确保给定对象只负责做一件事并创建很多小类。一些人寻求一种对象模型，该对象模型与程序试图与之相关的现实世界抽象密切相关，另一些人则将对象模型视为关于如何组织问题的技术架构，而不是现实世界的业务模型。 OOP 没有一种真正的方法，但它的核心是作为一种管理复杂性和保持大型程序随着时间推移更易于维护的方法而引入的。

【讨论】：

深思熟虑的回答。了解 OOP 中的多样性有助于理解如何将其轻松转换为空洞的流行语。
确实如此。任何编写Java程序的人都在一个类的主要功能中没有使用OOP。话虽如此，使用对象的方式有好有坏。

【解决方案3】：

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

例如，对于处理来自传感器的传入字节流的嵌入式设备，可能没有太多可以明确客观化的内容。

此外，在对性能进行绝对控制至关重要的情况下（当每个周期都很重要时），OOP 方法可能会引入计算成本可能并不小。

在现实世界中，大多数情况下，您的问题可以用对象很好地描述，尽管不能忘记 law of leaky abstractions！

行业最终在很大程度上最终解决了为工作使用正确的工具，您可以在许多地方看到 OOP。高性能和低级通常会出现异常。当然，没有硬性规定。

如果你坚持足够长的时间，你可以敲入一个螺丝......

【讨论】：

我想说 OOP 是正确的方法*对于您的应用程序的子集可以很好地结构化为对象“。我想不出任何应用程序都可以很好地映射到对象（不再比我能想到的使用所有名词而不使用动词的语言），但是每个应用程序都有一些可以用 OOP 很好地表示的点点滴滴。
我认为 OOP 不仅是对您的数据进行建模，它还为您提供如何构建程序以使其易于更改和理解的建议。

【解决方案4】：

我的 5 美分：

OOP 只是更大模式的一个实例：通过将大问题分解为更小的问题来处理复杂性。我们虚弱的头脑仅限于他们在任何特定时间可以处理的少数想法。即使是一个中等规模的商业应用程序也有更多的活动部分，大多数人一次都无法完全保持完整的心理画面。软件工程中一些更成功的设计范例利用了处理复杂性的概念。无论是将您的架构分解为层、将程序分解为模块、对操作进行功能分解、使用预构建的组件、利用独立的 Web 服务，还是在您的问题和解决方案空间中识别对象和类。这些都是驯服复杂的野兽的工具。

OOP 在几类问题上特别成功。当您可以根据“事物”以及它们之间的相互作用来考虑问题时，它会很好地工作。当您处理数据、用户界面或构建通用库时，它工作得很好。这些类别的应用程序的流行有助于使 OOP 无处不在。其他类别的问题需要其他或附加工具。操作系统区分内核空间和用户空间，并部分隔离进程以避免复杂性蔓延。函数式编程保持数据不可变，以避免多线程出现的依赖关系网格。您的经典 OOP 设计也不是，但它们在各自的领域中至关重要且成功。

在您的职业生涯中，您可能会面临比您完全靠自己一个人无法解决的更大的问题和系统。您的老师不仅试图为您配备当前的行业工具。他们试图传达的是，当您尝试对现实世界的问题进行建模时，有一些模式和工具可供您使用。为您的工具箱积累一系列工具并为工作选择合适的工具符合您的最大利益。 OOP 是一个强大的工具，但到目前为止还不是唯一的。

【讨论】：

【解决方案5】：

不...OOP 并不总是最好的方法。
（正确）OOP 设计是最好的方法，当您的问题可以最好地建模为一组可以通过相互通信/使用来实现您的目标的对象时。
好问题...但我猜科学/分析应用程序可能是最好的例子。他们的大部分问题最好通过函数式编程而不是面向对象编程来解决。

...话虽如此，让燃烧开始吧。我确定有漏洞，我很想知道原因。

【讨论】：

很遗憾，您的第二点毫无意义。
我会选择模糊而不是毫无意义......如果你不能轻松定义你的对象，这是一个好兆头，表明你的问题不太适合 OOP（或者你只是不'不了解对象设计...这是另一个问题）。
毫无意义？我把它作为一个重要的计算机科学领域的一个例子，它没有被 O-O 深入渗透。这怎么没有意义？向我 +1 以获得好的答案。
OOP 是将问题建模为一组对象，这些对象通过相互通信和使用来实现您的目标。这是一个定义，因此当问题可以使用 OOP 进行最佳建模时，简化为 OOP 设计是最好的方法。

【解决方案6】：

OOP 总是正确的方法吗？

没有。

什么时候 OOP 是最好的方法？

当它对你有帮助时。

什么时候 OOP 是一种不好的方法？

当它阻碍你时。

这真的很具体。有时您不需要 OOP，有时它在您使用的语言中不可用，有时它真的没有任何区别。

不过，我要说的是，在技术和最佳实践方面，我们会继续仔细检查您的教授告诉您的内容。仅仅因为他们是老师并不意味着他们是专家。

【讨论】：

-1 你基本上写了一个重言式。 OOP 在好的时候是好的，在不好的时候就不是。你可以对汽油价格、天气、狗粮说同样的话。
我见过光荣的过程式编程和丑陋的面向对象编程。我不认为 OOP 从来没有对错之分，只是不可用、不必要地耗时或根本没有必要。
+1 这就像“什么时候最好用螺丝刀？”一样简单。当您需要转动螺丝时。 “什么时候螺丝刀是不好的方法？”当您需要做一些事情而不是转动螺丝时。当您需要处理对象时，请使用 OOP。完毕。不要想太多。
@rtperson - 不，他说有帮助时很好。这是不同的，并且触及了问题的核心。不幸的是，实际上不可能给出更好的答案，因为每个项目的情况差异很大。
@Michael - 让我稍微说明一下我的观点。什么时候火好？当它帮助你。什么时候火不好？当它伤害你。两个非常无益的答案。如果我向一个三岁的孩子解释火的利弊，我可能会说一些关于它如何让你严重烧伤（受伤的部分）或烹饪你的食物（有用的部分）。斯宾塞的回答不是答案——只是耸了耸肩。

【解决方案7】：

将 OOP 的 P 视为原则而不是编程可能会有所帮助。无论您是否将每个领域概念都表示为一个对象，主要的 OO 原则（封装、抽象、多态）在解决特定问题时都非常有用，尤其是当软件变得越来越复杂时。拥有可维护的代码比在“纯”对象层次结构中表示所有内容更重要。

【讨论】：

+1 ...我相信这被称为便便。说真的，我从个人创伤中了解到 MS Access 和 VBA 不会让我真正做 OOP。但是我提出了 OO 原则，这些原则改变了我所有的 VBA 代码。
@Smandoli 我在使用 VBA 后学习了 OOP，但也因缺乏完整的实现而感到失望。然而，我开始将 OOP 的原理整合到我的 VBA 项目中，这使它们变得更好。

【解决方案8】：

我的经验是，OOP 在小范围内最有用 - 定义具有特定行为的类，并保持许多不变量。然后我基本上只是将它用作另一种数据类型，用于泛型或函数式编程。

试图仅根据 OOP 来设计整个应用程序只会导致巨大的类层次结构臃肿，所有内容都隐藏在 5 层间接后面的意大利面条式代码，甚至最小、最琐碎的工作单元最终也需要 3 秒才能完成执行。

OOP 很有用 --- 与其他方法结合使用时。

但归根结底，每个节目都是关于做，而不是关于存在。 OOP 是关于“存在”的。关于表达“这是一辆汽车。这辆车有四个轮子。这辆车是绿色的”。

在您的应用程序中为汽车建模并不有趣。对汽车进行建模很有趣。进程是有趣的，简而言之，它们是你的程序应该围绕的组织。单独的类可以帮助你表达你的流程应该做什么（如果你想谈论汽车的事情，拥有一个汽车对象比谈论它所组成的所有单独的组件更容易，但唯一的原因是你想要谈论汽车完全是因为它正在发生的事情。用户正在驾驶它，或者出售它，或者你正在模拟如果有人用锤子敲它会发生什么）

所以我更喜欢从功能的角度来思考。当然，这些函数可能对对象进行操作，但这些函数是我的程序关于的。而且他们不必“属于”任何特定的类。

【讨论】：

【解决方案9】：

与大多数此类问题一样，答案是“视情况而定”。

Frederick P. Brooks 在“The Mythical Man-Month”中说得最好，“没有一种单一的策略、技术或技巧可以成倍地提高程序员的生产力。”你不会用阔剑来做手术切口，也不会在剑斗中使用手术刀。

OOP 有很多惊人的好处，但您需要熟悉该模式才能利用这些好处。由于关注点分离的基本概念，了解和理解 OOP 还可以让您为解决方案创建更清晰的过程实现。

【讨论】：

【解决方案10】：

在向系统添加新功能或维护/改进系统时，我看到了使用 OOP 的一些最佳结果。不幸的是，在上大学时获得这种体验并不容易。

【讨论】：

【解决方案11】：

我还没有参与过一个不是功能性和 OOP 结合的行业项目。这真的取决于您的要求以及对他们来说最好的（也许是最便宜的？）解决方案。

【讨论】：

我假设您的意思是“程序性”而不是“功能性”。我参与了许多根本没有 OO 的商业项目（汇编和 C）。所以我愿意说，无论什么有效，都有效。但是，将 OO 作为一种工具扔掉是很愚蠢的。大多数大型程序都变得足够复杂，可以从 OO 中受益。
功能性还是程序性？我不知道函数式编程在“野外”如此普遍。

【解决方案12】：

OOP 并不总是最好的方法。但是，它是大多数应用程序中的最佳方法。
OOP 是适用于对象和对象交互的任何系统中的最佳方法。大多数业务应用程序最好以面向对象的方式实现。
OOP 对于小型一次性应用程序来说是一种糟糕的方法，因为开发对象框架的成本将超过当前的需求。

学习 OOA、OOD 和 OOP 技能将使大多数程序员受益，因此大学教授这些技能绝对有用。

【讨论】：

【解决方案13】：

OOP 的相关性和历史可以追溯到 1960 年代的 Simula 语言，它是一种从概念上设计软件的方式，其中开发的代码定义了源代码的结构以及与它的一般允许交互。明显的优点是定义良好且创建良好的对象是自我证明的，并且始终可重复且可靠；理想情况下还可以扩展和覆盖。

我唯一一次知道 OOP 是一种“不好的方法”是在资源可用性受到限制的嵌入式系统编程工作期间；当然，这是假设您的环境完全允许您访问它们（如前所述）。

【讨论】：

【解决方案14】：

标题提出一个问题，而帖子提出另一个问题。你想知道什么？

OOP 是一种主要的范式，它受到了广泛的关注。如果元编程变得庞大，它会得到更多的关注。 Java 和 C# 是目前最常用的两种语言（请参阅：按使用次数划分的 SO 标记）。我认为以任何一种方式说 OOP 是一个伟大/可怕的范例都是无知的。

我认为你的问题最好用一句老话来概括：“当锤子是你的工具时，一切看起来都像钉子。”

【讨论】：

哦，哇，我不喜欢 SO 标记。
我以前在 Stackoverflow 上看过这句谚语。我认为您正在提供保龄球版本。真正的版本是，“当你唯一的工具是 C++ 时，一切看起来都像拇指。”
+1 让我在谷歌上定义它。该版本是我发布的真实版本的损坏。

【解决方案15】：

OOP 通常是一种出色的方法，但它确实会带来一定的开销，至少在概念上是这样。例如，我不为小程序做 OO。然而，这是你真正需要学习的东西，所以我可以看到在大学环境中的小型项目需要它。

如果我必须进行认真的计划，我将使用 OOP。如果没有，我不会。

这是针对我一直在做的问题类别（包括建模、一些游戏和一些随机的事情）。其他领域可能会有所不同，但我没有这方面的经验。

【讨论】：

【解决方案16】：

我的意见，免费提供，价值不亚于......

OOD/OOP 是一种工具。工具的好坏取决于使用它的人，在特定情况下使用它的合适程度取决于问题。如果我给你一把锯子，你会砍木头，但你不一定能盖房子。

我听到的嗡嗡声是，函数式编程是未来的潮流，因为它对多线程环境非常友好，所以到你毕业时，OO 可能已经过时了。 ;-)

【讨论】：