在大学中滥用OOP吗？ [关闭]

Question

已关闭 。 这个问题是基于观点的 。 它当前不接受答案。

---

想改善这个问题吗？ 更新问题，以便通过编辑此帖子以事实和引用的形式回答。

去年关闭。

我两年前开始上大学，从那以后，我一直听到“首先设计您的课程”。 有时候，我真的问自己，我的解决方案首先应该是一堆对象！ 有人说您看不到它的好处，因为您的代码库很小-大学项目。 项目规模的借口就是不要让我失望。 如果该解决方案适合该项目，那么我相信该项目的宏版本也应该是正确的解决方案。

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

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

OOP始终是正确的方法吗？

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

什么时候OOP不好？

这是一个非常普遍的问题。 我不是要确定的答案，而只是要求一些实际的设计经验。

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

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

感谢所有的贡献。 我选择Nosredna回答，是因为她总体上回答了我的问题，并说服我在以下方面做错了： 如果该项目的解决方案很好，那么我认为该项目的宏版本也应该是正确的解决方案。

Answer 1

教授们的缺点是，他们无法让您进入已经运行了许多年的大型讨厌程序，许多不同的程序员正在从事这些程序。 他们必须使用不太令人信服的玩具示例，并试图诱使您看到更大的图景。

本质上，他们必须吓have您相信，当HO规模型火车撞到您时，它会把您的腿撕掉。 只有最有说服力的教授才能做到。

---

“如果解决方案适合该项目，那么我相信该项目的宏版本也应该是正确的解决方案。”

那就是我不同意的地方。 一个小项目适合您的大脑。 它的大版本可能不会。 对我来说，面向对象的好处是隐藏了足够多的细节，因此大局仍然可以塞进我的脑海。 如果您缺乏OO，则仍然可以进行管理，但这意味着寻找其他隐藏复杂性的方法。

密切关注真实目标-生成可靠的代码。 OO在大型程序中效果很好，因为它可以帮助您管理复杂性。 它还有助于重用。

但是OO不是目标。 好的代码是目标。 如果一种程序方法行之有效且从未变得复杂，那您就赢了！

Answer 2

OOP是一个现实世界的计算机概念，大学将被遗弃在课程之外。 当您申请工作时，您会被要求精通。

话虽这么说，OOP最初只是设计用来管理复杂性的一种方式。 由一个或两个学生编写的有关家庭作业时间的大学项目对于像这样的大型项目而言并不是一个现实的设置，因此示例可以感觉到（并且是）玩具示例。

同样，重要的是要认识到并非每个人都真正以相同的方式看待OOP。 一些人看到了有关封装的知识，并创建了非常复杂的大型类，但对任何外部调用者隐藏了它们的状态。 其他人希望确保给定的对象仅负责做一件事，并创建许多小类。 一些人寻求一个对象模型，该对象模型紧密地反映了程序试图关联的现实世界的抽象，另一些人则将对象模型视为关于如何组织问题的技术体系结构，而不是现实世界的业务模型。 with OOP, but at its core it was introduced as a way of managing complexity and keeping larger programs more maintainable over time. OOP没有 ，但是它的核心是作为一种管理复杂性并使大型程序随着时间的推移更易于维护的方法而引入的。

Answer 3

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

例如，对于正在处理来自传感器的字节输入流的嵌入式设备，可能没有太多可以清楚地客观化的东西。

同样，在绝对控制性能至关重要的情况下（每个周期都非常重要），OOP方法可能会带来成本，而这些成本在计算时可能并不平凡。

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

最终，行业通常最终会决定使用正确的工具来完成工作，并且您可以在许多地方看到OOP。 高性能和低级别通常会出现例外。 当然，没有硬性规定。

如果您将螺丝钉住足够长的时间，可以将其锤打。

Answer 4

我的5美分：

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

OOP在几类问题上特别成功。 当您可以根据“事物”及其之间的相互作用来思考问题时，它会很好地工作。 当您处理数据，使用用户界面或构建通用库时，它的效果很好。 这些类型的应用程序的普及使OOP随处可见。 其他类别的问题需要其他或其他工具。 操作系统区分内核空间和用户空间，并部分隔离进程以避免复杂性上升。 函数式编程使数据保持不变，从而避免了多线程时发生的依赖关系网状问题。 您的经典OOP设计也不是，但它们在各自领域中至关重要且成功。

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

Answer 5

1. 不... OOP并不总是最好的方法。

2. （正确）OOP设计是最好的方法，可以将您的问题最好地建模为一组对象，这些对象可以通过相互交流/使用来实现您的目标。

3. 好问题...但是我猜科学/分析应用程序可能是最好的例子。 他们的大多数问题最好通过函数式编程而不是面向对象的编程来解决。

...话虽如此，让燃烧开始。 我敢肯定有漏洞，我很想学习为什么。

Answer 6

OOP始终是正确的方法吗？

不。

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

何时有帮助。

什么时候OOP不好？

当它阻碍了你。

确实是如此具体。 有时您不需要OOP，有时您所使用的语言无法使用OOP，有时确实没有什么不同。

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

Answer 7

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

Answer 8

我的经验是，OOP在小范围内最有用-定义具有某些行为的类，并维护许多不变量。 然后，我基本上只是将其用作通用或函数编程的另一种数据类型。

试图仅根据OOP设计整个应用程序只会导致庞大的类层次结构，意粉代码，其中所有内容都隐藏在5层间接中间，甚至最小，最琐碎的工作单元也要花费三秒钟的时间才能执行。

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

但最终，每个程序都这样做 ，不是为 。 OOP是关于“存在”的。 关于表达“这是一辆汽车。汽车有4个轮子。汽车是绿色的”。

在您的应用程序中对汽车建模并不有趣。 为汽车做事的模型很有趣。 流程是有趣的，并且简而言之，它们就是您的程序应组织的内容。 那里有单独的类可以帮助您表达您的流程应该做什么（如果您想谈论汽车事物，拥有汽车对象比谈论其组成的所有单个组件要容易得多，但这是唯一的原因想要谈论这辆车完全是因为它发生了什么。用户正在驾驶或出售它，或者您正在建模如果有人用锤子敲打它会发生什么情况）

所以我更喜欢从功能上考虑。 这些功能可能对对象进行操作，当然，但功能是那些我的计划是什么 。 而且他们不必“属于”任何特定的班级。

Answer 9

像大多数这种性质的问题一样，答案是“取决于情况”。

弗雷德里克·布鲁克斯（Frederick P. Brooks）说，“在《 神话的月刊 》中，最好的是：“没有任何一种战略，技术或技巧可以成倍地提高程序员的生产力。” 您不会使用宽阔的剑进行手术切口，也不会在剑术中使用手术刀。

OOP有许多惊人的好处，但是您需要对模式感到满意才能利用这些好处。 由于关注点分离的基本概念，了解和理解OOP还可以使您为解决方案创建更简洁的过程实现。

Answer 10

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

Answer 11

我尚未从事该行业中既不是功能性也不是OOP的结合的项目。 它确实取决于您的要求，以及对他们来说最好的（也许最便宜的）解决方案是什么。

Answer 12

1. OOP并不总是最好的方法。 但是，这是大多数应用程序中的最佳方法。
2. 在任何适合对象和对象交互的系统中，OOP是最好的方法。 大多数业务应用程序最好以面向对象的方式实现。
3. 对于小型的一次性应用程序而言，OOP是一种不好的方法，在这种情况下，开发对象框架的成本将超出当前的需求。

学习OOA，OOD和OOP技能将使大多数程序员受益，因此对于大学来说绝对有用。

Answer 13

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

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

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

Answer 14

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

我唯一知道OOP是“错误的方法”是在嵌入式系统编程过程中，其中资源可用性受到限制。 当然，这是假设您的环境完全允许您访问它们（如上所述）。

Answer 15

OOP通常是一种很好的方法，但是它确实会带来一定的开销，至少是概念上的开销。 例如，我不为小程序做OO。 但是，这确实是您确实需要学习的东西，因此我可以看到在大学环境中的小型程序中需要它。

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

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

Answer 16

我的意见，免费提供，值得...

OOD / OOP是一种工具。 工具的好坏取决于使用工具的人，在特定情况下使用工具的适当程度取决于问题。 如果我给您锯，您将知道如何砍柴，但不一定能盖房子。

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