面向对象是非常不适合的软件建模问题的哪些类别？

Question

我试图更好地掌握面向对象编程和设计的适用性。我对一些情况很好奇，在这种情况下，面向对象不仅仅是效率低下或过度消耗，而且非常不合适，而且完全不被推荐。

现在看来，OOP可以应用于非常广泛的软件建模问题，但我想知道OOP什么时候才是所有范例中最糟糕的思想之一。

Answer 1

首先，不要混淆OO建模和OO编程。大多数现代编程语言或多或少都是面向对象的，无论它们是否使用面向对象建模，都可以用于实现大多数设计。我可以按照相对的过程设计(或事件驱动的，或其他风格的)编写一个程序，并且仍然使用Java和它们的实际OO接口。

现在，对于建模，我想说，不要在已经建立了更具体框架的领域中使用OO。例如，如果您处理基于事件的问题，那么使用事件(而不是类)作为构建块来描述您的设计是有意义的，并且仅用于实现(如果您使用OO语言)来决定如何将其映射到类或对象。例如，您可以发现您的所有事件都需要相同的一组方法，因此您可以使用一个类来实现它们。

在我的经验中，使用应用程序域的概念来确定设计的概念，并且只有在实际的实现中，才能更好地确定什么应该成为类或子类，以及什么是重要的方法。在我看来，类和方法在构造代码方面比在构造客户问题时更有用。

Answer 2

有几种方法来看待这个问题。一种方法是从数据抽象的角度出发。(我将忽略从编程范例的角度来看待这个问题，因为@Robert的回答已经做得很好了。)当今使用的两种最流行的数据抽象形式是抽象数据类型和对象。(实际上，有一种非常流行的第三种形式:根本不抽象。)

ADT和对象之间的主要区别在于ADT实例将其表示隐藏在其他类型的实例中，而不是从相同类型的实例中隐藏出来，而对象也将它们的表示从相同类型的其他对象隐藏出来。(如果您熟悉Java，这就是类和接口的区别，类定义ADT，接口定义对象。)

这意味着，由于更高的封装级别，OO具有更灵活和可扩展的潜力。然而，需要访问两个对象的表示的算法是不可能实现的。例如，您无法在OO中有效地连接两个双链接列表，因为您需要访问第一个列表的next指针以及第二个列表的prev指针。如果您调用第一个列表的concat方法，它不能访问第二个列表的内部，反之亦然，有效地做到这一点的唯一方法是将其内部组件公开给另一个列表，即破坏OO封装。(当然，您可以通过迭代第二个列表来连接两个列表，即在O(n)中进行，但在O(1)中不能这样做。)

Answer 3

考虑到OOP的三大支柱：

1. 封装:在对象中隐藏数据和指令的能力。
2. 继承:从另一个对象创建对象的能力
3. 多态:已删除类的对象从基类重写/扩展/继承属性和方法的能力

如果这些好处不能为解决手头的问题提供任何真正的价值，你可以争辩说，也许OOP不是理想的选择，或者至少没有必要。

在实践中，良好的设计和良好编写的OOP带来的好处很少证明，当使用相对较小的应用程序或资源受限的应用程序时，“开销”是不合理的。在野外，我看到了许多用C#和Java等语言构建的ETL过程，它们不一定遵循面向对象的范式。是的，由于这些语言的限制，存在一个“类”，但是所有方法都是静态的，并且存在于一个名为Program.(cs/java)的类中，作为应用程序的入口点。

事实上，很难想象OOP是所有可用编程范式中最糟糕的，但在某些情况下，OOP并不是最理想的范例。可以说是的，面向对象的范式并不总是适合于事件驱动或过程范式的情况，但很难判断它是否比功能范式更适合于这种情况。