问题标签 [anti-patterns]

你今天在编程中看到的最糟糕的（由于流行或严重性）抽象反转的例子是什么？

对于那些不熟悉这个概念的人，抽象反转是在高级构造之上实现低级构造。更准确地说，假设您有构造 A 和 B。B 在 A 之上实现，但 A 没有在任何地方公开。因此，如果您真的需要较低级别的构造 A，那么您最终会在 B 之上实现 A，而 B 首先是根据 A 实现的。请参阅http://en.wikipedia.org/wiki/Abstraction_inversion。

作为对我之前的问题的跟进 具有组合通用边界的函数，例如：

因为这不能从未指定的对象转换，所以您需要了解一些实际实现这些接口的对象。在我看来，需要知道要传递给的对象参数的具体类型doStuff(T a)违反了得墨忒耳定律。

该函数没有指定需要知道实际的类（可能有很多不同的类），我真的不想知道它，因为知道这个类会增加我代码库中的依赖性。

使用这些界限是一种反模式吗？如果是这样，一个人应该如何最好地避免它？

案例场景涉及一个指定对象的接口是持久的，而另一个指定的对象具有相关实体。这种情况下的doStuff(T a)函数在相关实体被持久化时会持久化。但是，非持久实体也可以有相关实体，但不应由doStuff(T a)函数处理

反模式：必须至少存在两个关键元素才能正式区分实际的反模式与简单的坏习惯、坏做法或坏主意：

• 一些重复的行动模式、过程或结构，最初看起来是有益的，但最终产生的不良后果多于有益结果，以及
• 一个重构的解决方案，有明确的文档记录，在实际实践中得到证明并且可重复。

投票支持您曾经多次“在野外”看到的 TDD 反模式。
James Carr 的博客文章和 关于测试驱动开发的相关讨论 yahoogroup

如果您发现了一个“未命名”的.. 也发布它们。请为每个反模式发布一篇文章，以使选票有意义。

我的既得利益是找到前 n 个子集，以便我可以在不久的将来在午餐盒会议上讨论它们。

Subversion 允许您使用externals嵌入其他存储库的工作副本，从而允许在您的项目中轻松控制第三方库软件的版本。

虽然这些似乎非常适合库的重用和供应商软件的版本控制，但它们并非没有批评者：

请不要使用 Subversion 外部工具（或其他工具中的类似工具），它们是反模式，因此没有必要

使用外挂是否存在隐患？请解释为什么它们会被视为反模式。

我们所有使用关系数据库的人都已经了解（或正在学习）SQL 是不同的。引出所需的结果并有效地完成这一过程涉及一个乏味的过程，其部分特征是学习不熟悉的范例，并发现我们最熟悉的一些编程模式在这里不起作用。您见过（或您自己承诺过）的常见反模式是什么？

我发现不该做的事情比应该做的事情更难学。

根据我的经验，专家与中级的区别在于能够从各种看似等效的方式中进行选择，以做同样的事情。

那么，当涉及到 JavaScript 时，哪些事情不应该做，为什么？

我可以为 Java 找到很多这样的内容，但由于 JavaScript 的典型上下文（在浏览器中）与 Java 非常不同，我很想知道结果如何。

我刚刚重构了一些位于我正在处理的类的不同部分的代码，因为它是一系列嵌套的条件运算符 (?:)，通过一个相当简单的 switch 语句 (C#) 变得更加清晰。

您什么时候会触摸与您正在处理的代码不直接相关的代码以使其更清晰？

我最近开始在 Java 中工作，并被介绍给一切事物的 getter 和 setter 的狂野而疯狂的世界。起初我讨厌它，但很快就习惯了。太习惯了。

最近我花了很多时间来更多地思考班级设计。我正在尝试做的一件事是避免为所有事情做 getter 和 setter 的陷阱。然而，我所做的大部分工作都是处理主要是数据容器的实体，我不确定在这些情况下 getter 和 setter 是否真的不合适。

这是一个使用公共属性的简单示例。

这是一个使用私有属性并使用 getter 和 setter 的简单示例。

在这些示例中， thename和description字段都应该可以更改。

我觉得 getter/setter 示例更清晰，并且隐藏了 whatname和descriptionare 的实现细节。如果需要，它还允许稍后在片场进行验证。

我已经阅读了一些关于 getter 和 setter 是邪恶的和/或反模式的讨论，但感觉这些可能不适用于这种情况。

也许有一些我还没有考虑过的选择。我愿意接受建议！

我不断看到问题浮出水面，这些问题引用了数据库表中名为 DateLastUpdated 之类的列。我不明白。

我见过的唯一伴随字段是 LastUpdateUserId 之类的。从来没有迹象表明为什么会发生更新；甚至更新是什么。

最重要的是，该字段有时是从触发器中写入的，其中可用的上下文更少。

当然，它甚至远不及审计线索。所以这不能成为理由。如果在日志或其他任何地方有审计线索，这个字段将是多余的。

我错过了什么？为什么这种模式如此受欢迎？

我目前正在为一个客户工作，他们因为“性能原因”而对更改糟糕的不可测试和不可维护的代码感到震惊。很明显，有很多误解普遍存在，原因不被理解，而只是盲目相信。

我遇到的一种这样的反模式是需要将尽可能多的类标记为密封的内部......

*重新编辑：我认为将所有内容标记为内部密封（在 C# 中）作为过早的优化。*

我想知道人们可能知道或遇到的其他一些性能反模式是什么？