【发布时间】：2010-09-19 19:05:29
【问题描述】：
我最近遇到了一些观点，说不应该总是使用面向对象的设计/编程。
您是否知道一些不会受益于也不应该使用面向对象设计的用例？
例如：有一些问题（关注点）会从 AOP 中受益。
【问题讨论】：
-
OOP 适用于需要将两条或更多条信息捆绑在一起的情况。
标签： language-agnostic oop architecture
【发布时间】：2010-09-19 19:05:29
【问题描述】：
不够好？我不知道我是否能举出一个例子，但我知道一些非常简单的应用程序在开始使用完全面向对象的设计模型时可能看不到任何“好处”。但是，如果它是真正的程序性和琐碎的事情，最终可能需要重新访问。
【讨论】：
OO 设计的优点是可扩展性和可维护性。因此，在不需要这些功能的情况下，它没有多大用处。这些将是非常小的应用程序，用于非常特定的短期需求。 （您会考虑以批处理文件或脚本语言的形式执行的操作）
【讨论】：
横切关注点受益于面向方面的编程 (AOP)。通过横切，我的意思是可以使应用程序的各个部分受益并且实际上不属于特定对象的功能。日志记录通常作为示例给出。安全可能是另一个。例如，为什么 Person 对象应该知道有关日志记录的任何信息或应该允许谁访问它？
【讨论】：
-
还要注意，AOP 和 O-O 是互补的范例，并不相互排斥。
正如其他发帖人所说，如果您正在创建一个非常简单的应用程序或程序应用程序，那么 OOP 可能有点过头了。另外，我认为 AOP 不一定需要取代 OOP，如果它有助于加强良好的 OOP 设计的话。
【讨论】：
-
我不是说要替换它。我用它来完成它。但是，还有更多类似的例子吗？
OOP 和 AOP 不是相互排斥的，而是互补的。
至于 OO，当然也有不太适用的情况。如果没有我们所拥有的只是 OO 语言。对于纯粹的数字运算任务，许多人仍然更喜欢 Fortran。当您处理并发性和并行性时，函数式语言很有用。
此外，当您的应用主要只是一个带有 GUI 的数据库时（例如 CRM 应用），即使您可能使用 OO 语言来构建它，OO 也不是很有用。
【讨论】：
我建议你访问维基百科并阅读他们关于不同类型编程语言的文章。
说一种编程“不够好”没有任何意义。 每种类型都有一个目的。你无法比较它们。他们不应该做同样的事情。
【讨论】：
一个很容易想到的...数据库网络应用程序。
在这种情况下，遵循一个公认的框架更有意义……而不是寻求一个好的 OOP 设计。例如如果您必须使用 JOIN 和 ORDER BYs 进行某种复杂的查询.. SQL 会踢对象。
根据问题选择解决方案...而不是锤炼问题直到它适合解决方案。
【讨论】：
有些问题最好用函数式编程等其他范式来表达。此外，声明性范式允许对代码的正确性进行更强大的形式推理。请参阅 Erlang 了解具有某些优势的语言的一个很好的示例，由于范式的基本性质，OO 语言无法真正匹配这些优势。
database queries (SQL)、expert systems (Prolog, CLIPS etc.) 或Statistical computing (R) 是其他语言范式更适合的问题域示例。
【讨论】：
根据我的经验，不能从 OO 设计中受益的地方之一是低端嵌入式系统。执行 OO 需要一定数量的开销，而且有时您无法承受这些开销。在标准 PC 中，开销非常小，甚至不值得考虑，但在低端嵌入式系统中，开销可能很大。
【讨论】：
如果您使用的编程语言不允许您轻松使用 OOP，我不会为 OOP 烦恼。我们在我的工作场所使用 BDL，它是程序化的。我曾经尝试做一些 OOP，嗯，那只是一个很大的 oops。不应该打扰。
【讨论】：
这里要理解的基本原则是，没有可以应用于所有问题领域的通用方法、范式或方法。这些通常是为解决一组特定的问题而设计的，可能不会针对其他领域进行优化。
它就像一个典型问题类型的算法（例如排序）。不可能有适用于所有可能场景或数据集的通用算法。
面向对象编程也是如此。我不会将它应用于本质上与 AI 相关的问题，并且可以使用声明式编程更好地解决。我当然不会将它用于开发需要最高性能和速度的设备驱动程序。
【讨论】：
任何时候你想不出 OO 的好理由都是避免它的好时机。 （听起来很滑稽，但我是认真的。）
【讨论】：
如果你设计得好，面向对象编程是一个很好的解决方案。
【讨论】：
呼应 Nigel，SQL 似乎几乎隐含地与任何类型的抽象（包括子查询和函数）不兼容。
【讨论】：
嗯，OOP 与任何事物都不是特别正交（可能除了其他获得多态性的方法）所以...呃...随便。
【讨论】：