面向对象何时不是正确的解决方案？

Question

我最近遇到一些意见，说不应该总是使用面向对象的设计/编程。
您是否知道一些不会受益且不应使用面向对象设计的用例？

例如：有一些问题（担忧）将从AOP中受益。

Answer 1

使用其他范例（如函数编程）可以最好地表达一些问题。此外，声明性范例允许更加强大的关于代码正确性的形式推理。有关具有某些优势的语言的良好示例，请参阅Erlang，由于范例的基本特性，这些优势无法与OO语言真正匹配。

其他语言范例更适合的问题域示例包括database queries (SQL)，expert systems (Prolog, CLIPS etc.)或Statistical computing (R)。

Answer 2

根据我的经验，其中一个不受OO设计影响的地方是低端嵌入式系统。执行OO需要一定的开销，有时候你无法负担这笔费用。在标准PC中，开销非常小，甚至不值得考虑，但在低端嵌入式系统中，开销可能很大。

Answer 3

横向关注问题受益于面向方面编程（AOP）。通过横切，我的意思是可以使应用程序的各个部分受益并且实际上不属于特定对象的功能。记录通常作为示例给出。安全可能是另一个。例如，为什么Person对象应该知道有关日志记录的任何信息，或者应该允许谁访问它？

Answer 4

很容易想到的一个......数据库网络应用程序 在这种情况下，遵循一个被接受的框架更有意义..而不是找出一个漂亮的OOP设计。例如如果你必须使用JOIN和ORDER BYs进行某种复杂的查询.. SQL将踢对象。

根据问题选择解决方案......而不是解决问题直到它适合解决方案。

Answer 5

这里要理解的基本原则是，没有可以应用于所有问题域的通用方法，范例或方法。这些通常旨在满足特定的一组问题，并且可能无法针对其他域进行优化。

它就像典型问题的算法（例如排序）。不存在适用于所有可能的场景或数据集的通用算法。

OOP也是如此。我不会将它应用于基本上与AI相关的问题，并且可以使用声明性编程更好地解决。我肯定不会用它来开发需要最高性能和速度的设备驱动程序。

Answer 6

OOP和AOP不是互斥的，是互补的。

至于OO，肯定存在不太适合的情况。如果没有我们所拥有的是OO语言。对于纯粹的数字运算任务，很多人仍然喜欢Fortran。当您处理并发性和并行性时，函数式语言非常有用。

此外，当您的应用程序主要只是一个带有GUI的数据库（例如CRM应用程序）时，即使您可能使用OO语言来构建它，OO也不是很有用。

Answer 7

OO设计的优点是可扩展性和可维护性。因此，在不需要这些功能的情况下使用它并没有多大用处。对于非常具体的短期需求，这些应用程序非常小。 （你会考虑用批处理文件或脚本语言做的事情）

Answer 8

如果你使用的编程语言不容易让你使用OOP，我不会打扰OOP。我们在我的工作场所使用BDL，这是一个程序性的。我曾经试图做一些OOP，嗯，这只是一个很大的哎呀。不应该打扰。

Answer 9

不够好？我不知道我是否可以提出一个例子，但我知道一些真正简单的应用程序在使用完全面向对象的设计模型开始时可能看不到任何“好处”。但是，如果它真的是程序性的和微不足道的，那么最终可能需要重新访问。

Answer 10

我会告诉你访问维基百科并阅读他们关于不同类型的编程语言的文章。

说一种编程“不够好”没有任何意义。 每种类型都有一个目的。你无法比较它们。他们不会做同样的事情。

Answer 11

任何时候你都不能想到OO的好理由是避免它的好时机。 （听起来很滑稽，但我很认真。）

Answer 12

如果你正在创建一个非常简单的应用程序或程序应用程序，OOP可能会有点太多，正如其他海报所说的那样。另外，我认为AOP不一定需要替换OOP，如果它有助于加强良好的OOP设计。

Answer 13

回应Nigel，SQL似乎几乎隐含地与任何类型的抽象（包括子查询和函数）不兼容。

Answer 14

嗯，OOP与任何东西都不是特别正交（除了可能是获得多态的其他方式）所以......呃......无论如何。

Answer 15

如果你做好设计，面向对象的编程就是很好的解决方案。