java - OOP的缺点？

Question

就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用资料或专业知识的支持，但这个问题可能会引发辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开， visit the help center寻求指导。

关闭 9年前。

通常我不想知道 OOP 的缺点的细节，但是当我在最近参加的一次采访中发生争执时感觉有点奇怪。发布给我的问题是告诉我 object-oriented programming 的一个缺点。 (哎呀)。那时，我觉得 OOP 是继过程模型和函数模型之后最成熟的编程层次。所以我回复他说我没有看到任何负面的东西。

但是面试官说很少，如果他不介意，我让他列出一个。他举了一个我不太理解的例子。他说 OOP 模式没有严格执行继承规则，并引用了卫星/火箭的例子，在火箭发射过程中， body 部位会周期性地分解以减轻重量，并表示继承不支持这一点。

他的例子让我觉得很奇怪，原因是在这个例子中应用了继承。

我知道他举的例子几乎没有任何意义，但我有这个疑问 -

Can we unplug class hierarchies dynamically (I am kind of confident in Java it's not possible) in an ideal object-oriented design?

Answer 1

Just because you have a hammer, doesn't mean everything is a nail.

我发现很多人经常混淆何时申请composition与 inheritance当使用 OOP 作为编程风格时。你从面试问题中引用的例子似乎就是这种混淆的例子。

我从经验中学到的一件事是，虽然继承是表达设计中实体之间“IS-A”关系的一个很好的范例，但通常更倾向于组合而不是继承 .

但是，让我们来看看面试官问题的症结所在:OOP 什么时候是一个糟糕的范式选择？。

OOP 最适合大型、多开发人员、多模块项目。对于“小型开发” - 例如脚本或转换处理，它可能需要大量开销，而不必增加值(value)。但即使在这些情况下，除非您正在编写一次性代码，否则我认为大型解决方案通常是从较小的解决方案演变而来的，因此尽早建立结构和关注点分离可以避免您日后的烦恼。

最终，OOP 编程还需要一定程度的设计严谨性和规划，以及对 core principles of object orientation 的理解。 . 如果您不愿意花时间学习和理解这些原则......好吧，也许 OOP 编程不适合你。

除此之外，某些类型的问题也适用于其他编程风格。例如，转换处理完全可以修改为 functional style of programming - 计算结果并将其传递给连续的转换步骤以产生最终结果。必须搜索或查询域以获取某些匹配信息的问题可以解决 query languages (如 SQL)，您在其中以声明方式而非命令方式描述您的意图。

能够识别您正在解决的问题类型对于选择使用哪种语言或工具大有帮助。正确的工具可以使工作变得更容易......错误的可以让它变得更难 - 或者不可能。