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

【问题标题】：Symptoms and alternatives to overused OOP过度使用 OOP 的症状和替代方案
【发布时间】：2011-01-13 21:59:54
【问题描述】：

最近我对 OOP 失去了信任。我已经看过很多抱怨常见的 OOP 误用或只是简单的过度使用。我不表示 is-a 和 has-a 关系之间的常见混淆。我是说处理关系数据库时的 ORM 问题，从 C# 继承的过度使用以及几年的寻找在代码中具有与 Scott Meyers 相同的错误封装信念在 Effective C++ 的第 23 条中提到

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

有没有人知道任何好的参考资料（作者、书籍、文章）可以得到开始了吗？

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

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

【问题讨论】：

过度使用继承？？那是什么？
使用继承，最好使用聚合。
关系型数据库有它自己的问题，所以T-SQL之类的东西正在发展成全语言，你可以写Java SQL Server程序等等。另外ORM也不错，我自己写的很可用的。并为诺亚的评论+1，真的，过度使用继承是什么？！
@dzendras - 既然可以复制/粘贴，为什么还要使用聚合？？
我不确定我是否信任这个“疯狂的埃迪”。

标签： c++ oop reference

【解决方案1】：

我可以向您推荐一本书Agile Principles, Patterns, and Practices in C#。示例当然是在 C# 中，但本书的思想是通用的。它不仅涵盖敏捷，还关注不良实践，并在示例中展示了如何将不良代码转换为好代码。它还包含许多设计模式的描述，并展示了如何在工资单应用程序的半真实示例中实现它们。

【讨论】：

【解决方案2】：

这是必须要做的，但如果你真的想摆脱 OOP，或者至少看看不是 OOP 但使用效果很好的概念：Learn you a Haskell。尝试一种新的编程范式，然后开始查看可以将大部分概念应用回 OOP 语言的地方。这解决了你的第二个问题，不是直接的，但相信我，它会比你想象的更有帮助。

【讨论】：

【解决方案3】：

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

然后是 slammer 一个，sealed 关键字。异常强大，“责任到此为止，别惹我”。在 .NET 框架中以外科手术般的精确度使用，我从未发现过不恰当地使用 sealed 的案例。在 C++ 中也缺少，但有一些晦涩的方法来实现它。

但是，是的，WPF 对象模型很糟糕。继承 6 层深度并像依赖属性一样使用后门是令人反感的。传承难，我们去逛街吧。

【讨论】：

在 C++ 中，static 将函数或对象限制为文件可见性。 sealed 没有等价物（除了涉及虚拟继承的混乱黑客攻击）。
Uhm... C++ 确实有一种清晰而简单的方法（与 C 相同）来限制对您自己的 module（库/可执行文件）的类的访问：Don '不要在标题中发布对象。关于密封类...我知道诀窍有一段时间了，简单而不傻，写起来更复杂更昂贵...但我从来没有觉得我真的需要密封一个班级。
在 C++ 中，您可以通过将类的构造函数设为私有来密封类。（当然，然后提供另一种实例化它的方法。）
@David：密封类以确保不违反假设通常很有用，特别是对于缺少虚拟析构函数的类，如果通过对父类的指针/引用进行析构，则会导致 UB。一个光辉的例子是std::vector<T> 和其他容器，人们不时尝试对其进行子类化，因为在 SO 上的搜索会显示给您。
@JSBangs：是的，你可以这样做，但它会弄得一团糟......一方面，该类型不再是类的方法或朋友之外的默认构造。

【解决方案4】：

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

编辑：

话虽如此，我不知道我是否真的会去看看虚幻引擎。他们做一些奇怪的事情是为了让他们的内容管道对开发者来说更容易......这使得他们的代码......好吧，看看你是否真的想知道。

【讨论】：

游戏行业在很大程度上痴迷于 15 年前任何很酷的编程范式，因为现在他们不再认为它“太慢”了。
是的 jalf，那是因为他们现在都在 OO :)

【解决方案5】：

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

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

【讨论】：