两年前我开始上大学，从那时起我一直听到“先设计你的课程”。我有时会问自己，如果我的解决方案首先应该是一堆对象！有人说你没有看到它的好处，因为你的代码库非常小 - 大学项目。项目规模的借口只是不要沮丧。如果解决方案适合项目，我相信它也应该是正确的项目的宏版本。
我不是说OOP是坏的，我只是觉得它在教室里被滥用，像我这样的学生日夜被告知OOP是正确的方式。
恕我直言，正确的答案不应该来自教授，我更愿意听听现场真正的工程师。OOP始终是正确的方法吗？
OOP何时是最好的方法？
OOP什么时候不好？
这是一个非常普遍的问题。我不是要求明确的答案，只是来自该领域的一些真实的设计经验。
我不关心表现。我在问设计。我知道这是现实生活中的工程。
=============================================== ===================================
感谢所有贡献。我选择了诺斯雷德纳的回答，因为她总体上回答了我的问题，并说服我对以下内容的看法不对： 如果解决方案适合项目，我相信它也应该是正确的项目的宏版本。
答案 0 :(得分：80)
教授的缺点在于，他们无法让你接受多年来一直在进行的大型，令人厌恶的课程，而这些课程正由许多不同的程序员进行。他们必须使用相当难以令人信服的玩具示例，并试图诱骗你看到更大的画面。
基本上，他们不得不吓唬你相信当一辆HO型号火车撞到你时，它会把你的腿撕掉。只有最有说服力的教授才能做到。
“如果解决方案适合项目，我相信它也应该是正确的项目的宏版本。”
这是我不同意的地方。一个小项目适合你的大脑。它的大版本可能不会。对我来说，OO的好处是隐藏了足够多的细节，以便大局仍然可以塞进我的脑海。如果您缺少OO，您仍然可以管理，但这意味着找到其他方法来隐藏复杂性。
密切关注真正的目标 - 生成可靠的代码。 OO在大型程序中运行良好，因为它可以帮助您管理复杂性。它还可以帮助重用。
但OO不是目标。好的代码是目标。如果程序方法有效并且永远不复杂，那么你就赢了！
答案 1 :(得分：17)
话虽如此，速度jalf，OOP主要是为管理复杂性而设计的。由一两个学生写的关于家庭作业时间的大学项目对于像这样的大型项目来说不是一个现实的设置，因此这些例子感觉（并且是）玩具的例子。
此外，重要的是要意识到并非每个人都以同样的方式看待OOP。有些人看到它关于封装，并创建非常复杂的巨大类，但隐藏他们的状态与任何外部调用者。其他人希望确保给定的对象只负责做一件事并制作很多小班。有些人寻求的对象模型能够密切反映程序试图与之相关的真实世界抽象，其他人则将对象模型视为如何组织问题的技术架构，而不是现实世界的商业模式。 OOP没有一种真正的方式，但其核心是作为管理复杂性和保持大型程序随时间更易维护的方式而引入的。
答案 2 :(得分：13)
当您的数据可以很好地构建到对象中时，OOP是正确的方法。
例如，对于正在处理来自传感器的输入字节流的嵌入式设备，可能没有太多可以明确客观化的内容。
同样，在ABSOLUTE对性能的控制至关重要的情况下（每个周期都很重要），OOP方法可能会带来可能非常重要的成本。
在现实世界中，大多数情况下，您的问题可以通过对象非常好地描述，但law of leaky abstractions一定不能忘记！
行业通常会在很大程度上解决使用正确工具的问题，您可以在很多地方看到OOP。通常会针对高性能和低级别进行例外处理。当然，没有严格的规则。
如果你坚持使用它，你可以用螺丝锤击......
答案 3 :(得分：11)
我的5美分：
OOP只是一个更大模式的一个实例：通过将大问题分解为更小的问题来处理复杂性。我们虚弱的思想仅限于他们在任何特定时间都可以处理的少量想法。即使是中等规模的商业应用程序也有比大多数人可以完全保持一个完整的心理图像更多的移动部件。软件工程中一些比较成功的设计范例充分利用了处理复杂性的概念。无论是将您的体系结构分层，将程序分解为模块，执行功能细分，使用预构建的组件，利用独立的Web服务，还是在问题和解决方案空间中识别对象和类。这些都是驯服复杂的野兽的工具。
OOP在几类问题上特别成功。当你可以用“事物”和它们之间的相互作用来思考问题时，它运作良好。当您处理数据，用户界面或构建通用库时，它可以很好地工作。这些类别的应用程序的普及有助于使OOP无处不在。其他类别的问题需要其他或其他工具。操作系统区分内核和用户空间，并部分隔离进程以避免复杂性蠕变。函数式编程使数据不可变，以避免多线程发生的依赖关系网格。既不是经典的OOP设计，但它们在自己的领域中至关重要且成功。
在您的职业生涯中，您可能会遇到比您自己完全解决的问题和系统更大的问题。您的老师不仅试图为您提供目前的交易工具。他们试图表达，当您尝试模拟现实世界的问题时，可以使用模式和工具。为您的工具箱积累一系列工具并为工作选择合适的工具符合您的最佳利益。 OOP是一个强大的工具，但到目前为止还不是唯一的工具。
答案 4 :(得分：9)
不...... OOP并不总是最好的方法。
（确实如此）OOP设计是最好的方法，可以将您的问题最好地建模为一组可以通过彼此通信/使用来实现目标的对象。
好问题......但我猜测科学/分析应用可能是最好的例子。他们的大部分问题最好通过函数式编程而不是面向对象的编程来实现。
......话虽如此，让火焰开始吧。我确信有漏洞，我很想知道为什么。
答案 5 :(得分：6)
OOP总是正确的方法吗？
不。
当OOP是最佳方法时？
什么时候帮助你。
当OOP是一种糟糕的方法时？
当它阻碍你时。
这非常具体。有时你不需要OOP，有时它不能用你正在使用的语言，有时它确实没有区别。
我会说这个，但是当涉及到技术和最佳实践时，继续仔细检查教授告诉你的内容。仅仅因为他们是老师并不意味着他们是专家。
答案 6 :(得分：5)
将OOP的P视为原则而不是编程可能会有所帮助。无论您是否将每个域概念都表示为对象，主要的OO原则（封装，抽象，多态）在解决特定问题方面都非常有用，尤其是在软件变得更复杂时。拥有可维护的代码比在“纯”对象层次结构中表示所有内容更重要。
答案 7 :(得分：4)
我的经验是，OOP主要用于小规模 - 定义具有特定行为的类，并维护许多不变量。然后我基本上只使用它作为另一种数据类型用于泛型或函数式编程。
尝试仅仅根据OOP设计整个应用程序只会导致庞大的类层次结构，意大利面条代码，其中所有内容都隐藏在5层间接后面，甚至最小，最琐碎的工作单元最终需要三秒钟才能完成执行。
当与其他方法结合使用时，OOP很有用。
但最终，每个程序都是关于做，而不是关于 。 OOP就是“存在”。关于表示“这是一辆汽车。汽车有四个轮子。车是绿色的。”
在您的应用程序中建模汽车并不有趣。模拟*汽车做东西很有意思。流程是有趣的，简而言之，它们是您的计划应该围绕的组织。个别课程可以帮助你表达你的流程应该做什么（如果你想谈论汽车的东西，拥有一个汽车对象比谈论它所构成的所有单个组件更容易，但唯一的原因是你想要谈论这辆车根本就是因为发生了什么事情。用户正在驾驶或者出售它，或者你正在模拟如果有人用锤子敲击它会发生什么？
所以我更倾向于考虑功能。当然，这些函数可能对对象起作用，但函数是我的程序关于的函数。而且他们不必“属于”任何特定的阶级。
答案 8 :(得分：3)
像大多数这种性质的问题一样，答案是“它取决于”。
弗雷德里克·布鲁克斯（Frederick P. Brooks）表示，“The Mythical Man-Month”中最好的是“没有单一的策略，技巧或技巧可以指数级地提高程序员的生产力。”你不会用宽剑做手术切口，你也不会在剑斗中使用手术刀。OOP有很多好处，但您需要熟悉这种模式才能充分利用这些优势。了解和理解OOP还允许您为解决方案创建更清晰的程序实现，因为关注点分离的基本概念。
答案 9 :(得分：1)
在向系统添加新功能或维护/改进系统时，我已经看到了使用OOP的一些最佳结果。不幸的是，在上大学时获得这种体验并不容易。
答案 10 :(得分：1)
我还没有在行业中开展一个既不是功能性也不是OOP的项目。它真的取决于您的要求以及最适合他们的解决方案（也许是最便宜的？）。
答案 11 :(得分：1)
学习OOA，OOD＆amp; OOP技能将使大多数程序员受益，因此它对大学来说非常有用。
答案 12 :(得分：1)
标题问一个问题，帖子问另一个问题。你想知道什么？
OOP是一个重要的范例，它受到了重视。如果元编程变得巨大，它将得到更多的关注。 Java和C＃是目前使用最多的两种语言（参见：SO标签按使用次数）。我认为无论如何都说OOP是一个伟大/可怕的范例。我认为你的问题可以用最古老的格言来概括：“当锤子是你的工具时，一切看起来像钉子。”
答案 13 :(得分：1)
OOP的相关性和历史可以追溯到20世纪60年代的Simula语言，作为一种在概念上设计软件的方法，其中开发的代码定义了源的结构和与之相关的一般允许的交互。显而易见的优点是，定义明确且创造良好的对象具有自我辩解性，并且始终可重复且可靠;理想情况下也可以扩展和覆盖。
我唯一知道OOP是一种'坏方法'的时候是在资源可用性受到限制的嵌入式系统编程工作中;当然，假设您的环境允许您访问它们（如前所述）。
答案 14 :(得分：0)
OOP通常是一种很好的方法，但它确实带来了一定的开销，至少是概念性的。例如，我不为小型程序做OO。但是，这是你真正需要学习的东西，所以我可以看到在大学环境中要求它用于小型课程。
如果我必须进行认真的计划，我将使用OOP。如果没有，我不会。
这是针对我一直在做的问题（包括建模，一些游戏和一些随机的事情）。其他领域可能有所不同，但我没有经验。
答案 15 :(得分：0)
我的意见，免费提供，值得一样......
OOD / OOP是一种工具。工具的好坏取决于使用它的人，以及在特定情况下使用它的适当程度取决于问题。如果我给你一把锯子，你就会知道如何砍伐木头，但你不一定能够建造房屋。
我所接受的嗡嗡声是函数式编程是未来的潮流，因为它对多线程环境非常友好，所以当你毕业时，OO可能已经过时了。 ; - ）