我两年前开始上大学，从那时起我一直听到“首先设计你的课程”。有时我真的会问自己，我的解决方案首先应该是一堆对象吗？有人说你看不到它的好处，因为你的代码库非常小——大学项目。项目规模这个借口根本无法让我接受。如果该解决方案与该项目配合良好，我相信它也应该是该项目的宏观版本的正确解决方案。
我并不是说 OOP 不好，我只是觉得它在课堂上被滥用了，像我这样的学生日夜被告知 OOP 是正确的方式.
恕我直言，正确的答案不应该来自教授，我更喜欢从该领域的真正工程师那里听到。
OOP 总是正确的方法吗？
什么时候 OOP 是最好的方法？
什么时候 OOP 是一个糟糕的方法？
这是一个非常普遍的问题。我并不要求明确的答案，只是要求一些来自该领域的真实设计经验。
我不关心表现。我问的是设计。我知道这是现实生活中的工程。
=================================================== ==================================
感谢所有的贡献。我选择了 Nosredna 的答案，因为她概括地回答了我的问题，并让我相信我在以下方面是错误的：如果该解决方案与该项目配合良好，我相信它也应该是该项目的宏观版本的正确解决方案。
教授们的缺点是他们不能让你参与持续数年、由许多不同的程序员共同开发的庞大、令人讨厌的程序。他们必须使用相当不令人信服的玩具示例，并试图诱骗您看到更大的图景。
从本质上讲，他们必须吓唬你，让你相信当 HO 轨距模型火车撞到你时，它会把你的腿撕下来。只有最有说服力的教授才能做到这一点。
“如果该解决方案与该项目配合良好，我相信它也应该是该项目的宏观版本的正确解决方案。”
这就是我不同意的地方。一个小项目适合你的大脑。它的大版本可能不会。对我来说，面向对象的好处是隐藏了足够的细节，这样我的头脑中仍然可以塞满大局。如果你缺乏面向对象，你仍然可以管理，但这意味着寻找其他方法来隐藏复杂性。
关注真正的目标——生成可靠的代码。面向对象在大型程序中效果很好，因为它可以帮助您管理复杂性。它还有助于可重用性。
但U不是目标。好的代码是目标。如果程序方法可行且永远不会变得复杂，那么您就赢了！
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
