问题标签 [anti-patterns]

您在公司的生产环境中见过的最邪恶或最危险的代码片段是什么？我从来没有遇到过我认为是故意恶意和邪恶的生产代码，所以我很想看看其他人发现了什么。

我见过的最危险的代码是一个存储过程，它距离我们的核心生产数据库服务器有两个链接服务器。存储过程接受任何 NVARCHAR(8000) 参数并通过双跳 sp_executeSQL 命令在目标生产服务器上执行该参数。也就是说，sp_executeSQL 命令执行了另一个 sp_executeSQL 命令，以便跳转两个链接的服务器。哦，链接服务器帐户在目标生产服务器上具有系统管理员权限。

很多人似乎都同意，单例模式有许多缺点，有些人甚至建议完全避免这种模式。这里有一个很好的讨论。请将有关单例模式的任何评论指向该问题。

我的问题：是否有其他设计模式应该避免或小心使用？

我正在开发一个带有数据库后端的 10 页网站。有 500 多个对象在使用中，试图在 ASP.Net 中实现 MVP 模式。我正在从单页跟踪代码执行，我的手指已经在 Visual Studio 中的 F-11 上停留了大约 40 分钟，似乎没有尽头，一个网页可能有 1000 多个方法调用！然而，如果只有 50 个对象，那将是一回事，代码执行会蜿蜒穿过所有这些对象，就像数百万只蚂蚁在它们巨大的土堆房子里疯狂地工作，到处都是对象隧道。 因此，一种新的反模式诞生了：AntFarm。

AntFarm也被称为“OO-Madnes”、“OO-Fever”、OO-ADD 或简单的设计模式迷。

这不是我第一次看到这种情况，我在其他公司的同事也不是第一次看到。似乎这种风格正在被积极宣传，或者无论如何是对周围众多OO / DP福音的误解......

我想在反模式中引入一个反模式：GST 或“Get Stuff Done”AKA“Get Sh** done”AKA GRD (GetRDone)。这种模式专注于它所说的，以一种简单的方式完成工作。我可能会尝试在以后的帖子中对其进行更多概述，或者请分享您对这种解毒剂模式的想法。

无论如何，在我写作的时候，我正处于 AntFarm 反模式的一个很好的例子中（作为奖励，没有文档或评论）。请分享您对这种反模式如何变得如此流行的想法，我们如何避免它，以及如何在必须使用的实时系统中撤消或处理这种模式！

我记得在某处看到过关于此的辩论，并且目前正在考虑删除我正在处理的系统中的每个业务对象继承的基础对象。它包含一些属性、一些数据库逻辑和一些构造函数逻辑。

这是一个反模式，还是陪审团还在外面？有一个基础合同来继承会更好吗，这需要在每个对象中完成一定数量的样板编码？

编辑：我确实喜欢 dsimcha 并且觉得它很好地反映了这个问题，我仍然很高兴听到任何进一步的答案

OO 编程中的一个典型问题是菱形问题。我有两个子类 B 和 C 的父类 A。A 有一个抽象方法，B 和 C 实现它。现在我有一个子类 D，它继承了 B和C。菱形问题现在是，D 应该使用什么实现，B 的一个还是 C 的一个？

人们声称 Java 不知道钻石问题。我只能对接口进行多重继承，因为它们没有实现，所以我没有钻石问题。这是真的吗？我不这么认为。见下文：

[移除车辆示例]

钻石问题是否总是导致糟糕的类设计以及程序员和编译器都不需要解决的问题，因为它本来就不应该存在？

更新：也许我的例子选择不当。

看到这张图片

_{（来源：suffolk.edu）}

当然，您可以在 C++ 中将 Person 设为虚拟，因此内存中只有一个 person 实例，但恕我直言，真正的问题仍然存在。您将如何为 GradTeachingFellow 实施 getDepartment()？考虑一下，他可能是一个部门的学生并在另一个部门任教。因此，您可以返回一个部门或另一个部门；这个问题没有完美的解决方案，而且没有实现可能被继承（例如，学生和教师都可以是接口）这一事实似乎并不能解决我的问题。

我是不是唯一一个有时会采取看似简单但错误的方式摆脱某些设计情况的人？我承认我已经分享了有问题的 Singleton 对象。除此之外，众所周知，我会制作一两个上帝对象以使事情看起来更容易。

即使您知道不应该使用反模式，您是否曾经使用过？

所以我在另一篇文章中看到了下面的“坏”片段，但我看到的唯一选择涉及修补 Python。

我该怎么做才能避免这种“反模式”？

我说的是经典的企业应用程序。通常托管在某种应用程序服务器或容器中。没什么花哨的，只是实体、服务、演示/UI 和关系存储。

每当我synchronized在这样的应用程序中看到关键字（在方法或块上）时，我都会非常怀疑。在我看来，这要么是不了解基本架构概念的标志（例如，域模型未在多个客户端之间共享），要么是更糟糕的标志，表明架构实际上非常拙劣。

你在这里分享我的想法吗？还是我完全偏离了轨道？您是否有在经典企业应用程序中实际需要同步的用例？

当 rpc（如 Java RMI 或某种 Web 服务调用）或消息队列（如 JMS）是更好的解决方案时，暂存表是否是一种反模式，或者暂存表是否可以更好地解决问题？

澄清：

暂存表是指记录由一个或多个进程附加到一个或多个表的情况，然后由第二个或多个进程读取并对其进行操作。我不是指那些旨在反映间隔结束状态（一天结束、支付期结束等）的表格。在大多数情况下，登台表的模式非常模仿应用程序数据类型，例如客户或帐户。

这种反模式的潜在原因：

1) 两个进程的所有者之间的业务单元墙可防止写入或读取暂存的进程被修改。

2) 对 staging 写入或读取的进程信心不足，导致开发人员使用 table 来防止“以防万一发生故障”的数据丢失

3）缺乏知识或DGAS（不要给^％$@）态度

我们都听说过过早优化，但是您如何看待过早重构？你认为有这样的事情吗？这就是我的意思。

首先，阅读 Martin Fowler 的开创性著作《重构》从字面上改变了我在编程方面的生活。

然而，我注意到的一件事是，如果我开始过快地重构一个类或框架，我有时会发现自己被编码到一个角落里。现在，我怀疑问题本身并不是真正的重构，而可能是过早/糟糕的设计决策/假设。

您对这个问题有什么想法、见解和/或意见？您对此问题有什么建议或常见的反模式吗？

编辑：

通过阅读您的答案并更多地反思这个问题，我想我已经意识到我在这种情况下的问题实际上是一个“过早的设计”问题，而不一定是“过早的重构”。在编码过程的早期，我一直在假设一个设计并朝那个方向重构。保持一定程度的设计不可知论并专注于重构以实现干净的代码，我有一点耐心，这将使我不会走上这些设计兔子的道路。