我经常听到有人说对象在代码重用方面还没有交付。你同意吗？如果您认为他们还没有，为什么不呢？

不，不一定。

对象提供更好的语义，代码/功能的组织性以及可能的易用性。

设计良好的库可实现代码重用的承诺，而不是对象本身。

老实说，我不确定“代码重用”是否真的是任何人所追求的（或者至少应该在此之后）。我的理念是“软件组件”，这意味着可以通过良好的界面来实现更好的可维护性，并避免不必要的耦合。“代码重用”是有时可能发生的事情之一-不必要的重复代码表示您以错误的方式组织了事情，当然这是很难维护的。

为了更直接地回答这个问题，有很多不错的工具可以避免重复您自己：继承，特征，委托，高阶函数等。其中，人们倾向于将继承与整个OO混淆-以及如果您问我，他们也倾向于过度使用它。也许这就是某些“ OO糟透了”的氛围的来源：在没有自然权利的地方发现继承卡住了:)

不，“对象”并没有使代码重用变得更容易或更普遍。防止代码在模块化程序中重复使用的相同担忧（与编写一次性例程相比，设计，测试和记录通用API所需的前期工作要多得多，而所有事务的重担可能是无主-打算重用的逻辑可能无法针对其实际用途进行很好的优化）适用于OO程序，另外还担心设计不良的对象模型可能会阻碍对可重用的其他对象的重用码。

OO是许多问题的便捷抽象，但请警惕80年代至90年代的炒作：它在神奇地解决了我们交易的基本问题之外，还为您在睡眠时为您带来华夫饼。

我不希望所有对象都可以重用，但是我们确实有很多对象可以在许多不同的项目上重用。我们还有一些对象只能在一个项目中重用。我们经常会使用同一项目的Click-Once桌面应用程序，Web应用程序和电话应用程序使用相同的业务对象（或数据传输对象）以及业务逻辑对象。

您从哪里听说OO不能实现重用？那是什么原因呢？也许他们的物体设计迫使他们陷入那种境地。

一些程序员将以任何语言和样式复制和粘贴。

真正好的程序员可以避免大多数情况下使用几乎任何语言进行复制和粘贴。

我发现OO模式倾向于鼓励重用。我见过以非OO风格编写的Java代码（由于糟糕的ORM而使数据与代码分离），并且重用确实很痛苦-但是在OO中，相同的程序员在设计方面做得更好（和重复使用）。

同样，在我们使用非oo模式或oo反模式的情况下，例如setter / getter，switch语句，匿名内部类，巨大的函数等，我已经看到代码重用下降而样板上升……显着。

ps。我知道人们会遇到上一段的问题，所以我会解释一下。

setter和getter引起OO问题，因为它们允许您对对象的成员进行操作（对象应操纵其OWN成员）。这会将在您的类上运行的代码分布到其他所有类中，这需要您在setter / getter周围复制功能。 。这也适用于“属性”，只是因为“属性”简单易用并不能使它们在所有情况下都“良好”。

匿名内部类中的代码根本无法重用，人们忘记了很多东西（例如侦听器）可以而且应该是成熟的类-这也适用于闭包！如果您使用匿名内部类来实现诸如侦听器之类的东西，则与将代码提取到方法或它自己的类中并调用它相比，您更有可能只是复制并粘贴您的实现。封闭还可以提高可重用性-仅取决于您如何使用它们。

在许多情况下，您可以使用的功能决定了代码的结构。在帮助您可视化所有代码及其交互方式时，OO甚至功能更强大，但这是另一个问题。

与楼梯间或其他健身设备可以减轻体重相比，对象再利用代码的能力不再强大。必须激励开发人员正确使用工具。

一旦软件团队在重用经过测试的代码上比在保留所有细节方面拥有更高的价值，您将看到更多的细粒度对象和方法，从而实现了更多的代码重用。

是

OOP为您提供了更多重用代码的方法

没有

没有银弹

这取决于

关于您投入的内容以及您期望得到的回报！

是。良好的面向对象编程可促进关注点分离，低耦合，高内聚和信息隐藏。这些对于可重用的代码都是至关重要的。

我认为OOP的主要好处是模块化和可修改性，而不是重用，但这是另一个问题。

对象使代码可以重新使用，但是这并不是最有效的方法。我认为代码重用是通过与对象相关的技术（例如继承，多态性，重载和模板）来促进的。

是的，他们的确如此，从超类clear扩展（继承）的能力有助于代码的重用，我不确定有人会反驳。您可以简单地扩展一个类并覆盖一个方法，而使用超类中的其余方法，如果这不能帮助代码重用，那么我不知道这是什么

到目前为止，他们是否已经实现了代码重用的承诺？是的，如果牢记OOP的程序明智地应用了设计模式。否则，大多数情况下不会。但是考虑到Adobe系统，Google等使用C ++或Java或其他OOP语言编写的大规模非琐事程序的普及，我想说OOP在逐步淘汰之前还有很长的路要走。那个时候将更适合提出这个问题，并可能有助于为新的范例提供基础工作。