面向对象编程是解决复杂性的一种方法吗？

Question

你认为面向对象编程是一种解决复杂性的方法吗？为什么？这个话题可能有点争议，但我的意图是从这里的专家知道为什么！

Answer 1

复杂性是没有解决办法的。

在“神秘的男人月”中，弗雷德·布鲁克斯讨论了编程中偶然和本质复杂性之间的区别。意外的复杂性是由我们的工具和方法造成的，比如必须用一种语言编写和测试额外的代码，因为我们不能直接表达我们的想法，诸如此类的事情。新的方法和技术可以减少意外的复杂性。我可以比25年前更快更好地编写程序，因为我有更好的语言和工具。

本质的复杂性来源于这样一个事实，即我们试图对编程所做的事情本质上是复杂的，并且存在着不可弥补的复杂性。在这种情况下，“基本”的意思是“与事物的本质有关”，而不是“非常必要”。

因此，他声称不会有灵丹妙药，编写软件将继续是困难的。

我强烈建议你读他的书:具体来说，我推荐银周年版，并附加一篇文章“没有银弹”。在这方面，他审查了复杂问题的拟议解决办法，并考虑了它们的影响。(他发现最有效的是收缩包装软件--只写一次复杂的东西，然后卖出数千或数百万份。)

现在，面向对象的编程在正确的情况下，通过创建抽象和隐藏复杂性来提供帮助。类的对象具有特定的定义行为，我们可以对其进行推理，而不关心实现的复杂性。适当地编写类之间的耦合性很低，如果你能克服它的话，分而治之是处理复杂性的一种很好的方法。它们还具有很高的凝聚力，因为它们是一组功能和数据，彼此之间关系非常密切。

Answer 2

我希望你很快会得到一些更好的答案，但这里有一个简单的答案：

OOP通过将软件建模的方式更接近于我们对世界上其他一切事物建模的方式来帮助解决复杂性问题。通常来说，想象一个与墙壁物体交互的球物体比想象一系列例程和数据结构来做同样的事情要容易得多，因为它更接近我们与现实世界的交互方式。

*因为没有什么能“解决”复杂性

Answer 3

我认为当前主流的OOP定义并不是管理复杂性的好解决方案。

如果你回到它的根源，我相信艾伦·凯在很大程度上受到了"lisp“的影响。

因为Lisp并没有被主流的采用所破坏，所以它可能设法保存了它的核心价值。所以我认为，看看lisp是如何解决这个复杂问题的，我们可以用它作为判断OOP在处理复杂性方面有多有用的基础。

如果您看SICP的“第3a课: Henderson埃舍尔示例”的结尾，Hal Abelson提出，复杂性的管理不是通过将任务分解为较小的子任务，而是通过创建抽象层。在最高级别，您可以将复杂问题的解决方案表示为较低抽象级别的解决方案。

我认为OOP最初是作为一种机制来创建这些抽象层。

不幸的是，现在OOP (Ab)被用来编写意大利面代码/结构。

我将做一个例子:一个FPS多人游戏。

在最高级别，游戏的工作方式是让一群玩家绕着地图跑来跑去，用武器互相射击。

在下一级，我们必须讨论地图、武器和球员。也许我们可以把它们说成是在游戏世界中相互作用的实物。

在下一个较低的层次，我们可以讨论物体如何在物理上相互作用(运动、碰撞等)。

以此类推。

这意味着，(我引用了SICP的话)，在每一层，我们不仅解决了一个特定的问题，还解决了一类与我们试图解决的问题相近的问题。因此，如果问题的描述有一个小的变化，它可能只需要一个小的改变在解决方案。

因此，使用OOP的明智方法是创建抽象层，在每个抽象级别上，您可以使用直接在下面的级别上的“对象”来解决手头的问题。

这是我在演讲中引用的一点：http://www.youtube.com/watch?v=CYtrfncMqHQ