过度使用OOP的症状和替代方案

Question

最近我失去了对OOP的信任。我已经看过很多了         有关常见OOP滥用或仅仅过度使用的投诉。我不         意味着is-a和has-a relationship之间的常见混淆。我的意思是         像处理关系数据库时ORM的问题，         从C＃过度使用继承还有几年的期待         代码与Scott Meyers一样具有错误的封装信念         在Effective C ++的第23项中提到

我有兴趣了解更多关于此和非OOP软件的信息         可以比OOP更好地解决某些问题的模式         同行。我相信那里有很多人         就如何将其作为非纯OOP的优势提供良好的建议         语言，如C ++。

有没有人知道任何好的参考（作者，书籍，文章）         开始？

请注意，我正在寻找两个相关但不同的东西：

• OOP概念的常见误用（如第23项）
• OOP不是最佳解决方案的模式（有替代方案）

Answer 1

我可以推荐你一本书Agile Principles, Patterns, and Practices in C#。 例子当然是C＃，但这本书的概念是普遍的。它不仅涵盖敏捷，还关注不良实践，并在示例中显示如何将错误的代码转换为良好的代码。它还包含许多设计模式的描述，并展示了如何在Payroll应用程序的半实例中实现它们。

Answer 2

这必须要做，但是如果你真的想要摆脱OOP或者至少看一下非OOP但使用效率很高的概念：Learn you a Haskell。尝试新的编程范例，然后开始看到可以将大部分概念应用到OOP语言的位置。这解决了你的第二颗子弹，不是直接的，但相信我，它会比你想象的更有帮助。

Answer 3

你提到C＃有点奇怪。它有非常强大的关键字来控制通常的继承苦难。第一个应该是内部关键字。限制模块的可见性的概念。 C ++中完全没有这个概念，构建模型不支持它。否则这是一个伟大的概念，“我只相信我的团队成员能够做到正确”。你当然可以。

然后是slammer，密封关键字。非凡的强大，“降压停在这里，不要惹我”。在.NET框架中使用外科精确度，我从未发现密封使用不当的情况。在C ++中也缺少了，但是通过不明确的方法来实现这一点。

但是，是的，WPF对象模型相当沉重。继承6个级别并使用依赖属性之类的后门是令人反感的。继承很难，我们去购物吧。

Answer 4

我会说看看游戏引擎。在大多数情况下，OOP倾向于导致轻微的性能下降，并且游戏行业似乎痴迷于消除轻微的减速（有时忽略大的减速）。因此，它们的代码虽然通常用支持OOP的语言编写，但最终只会使用OOP元素，这些元素是清洁代码/易于维护所必需的，也可以平衡性能。

编辑：

话虽如此，我不知道我是否真的会去看虚幻。他们做一些奇怪的事情是为了让开发人员更容易使用他们的内容管道...它使他们的代码......好吧，看看你真的想知道。

Answer 5

一种常见的过度使用是在程序/脚本中强制OOP接受一些输入，将其转换为输出，然后退出（并且在过程中不接收来自其他任何地方的输入）。在这些情况下，程序方式更清晰。

典型的例子是在PHP脚本中强制OOP。