长话短说：我发现Java 反模式是不可或缺的资源。对于初学者和专业人士一样。我还没有为 C# 找到类似的东西。所以我会以社区 wiki 的形式公开这个问题，并邀请大家分享他们的知识。由于我是 C# 新手，我对此非常感兴趣，但不能从一些反模式开始：/

以下是我发现特别适用于 C# 而不是其他语言的答案。

我只是复制/粘贴这些！考虑看看这些评论。

投掷NullReferenceException

抛出错误的异常：

属性与公共变量

类中的公共变量（使用属性代替）。

除非该类是一个简单的数据传输对象。

不理解 bool 是一种真正的类型，而不仅仅是一种约定

或者，甚至更好

像这样的结构经常被开发人员使用C，C++其中布尔值的概念只是一种约定（0 == false，其他任何东西都是 true）；在 C# 或其他具有真正布尔值的语言中，这不是必需的（或可取的）。

使用using()

在适当的地方不使用using：

我发现了这种模式（或反模式），我对此非常满意。

我觉得它很敏捷：

有时我会使用它的表亲：

我不需要创建人工元组和计数参数并将 %s 匹配位置保留在元组内。

你喜欢它吗？会/会使用它吗？是/否，请解释。

我经常发现自己使用字符串操作（拆分、搜索、替换、连接、+、连接）构建选择器。

是好是坏？

我从这篇文章Object中了解到，在 JavaScript 中修改原型是一种反模式。但是，我很好奇它是否被广泛认为是修改其他“内置”原型的反模式。

例如：假设我们想添加一个setPixel(x,y,color)函数到CanvasRenderingContext2D- 以抽象出获取上下文图像数据的职责，将像素设置为某种颜色，然后将图像数据放回原处。

我没有测试过这段代码，但你明白了。这样的事情是否违反“最佳实践”？

我在依赖注入方面相对不熟练，我想学习一些在使用 DI 时分别使用和避免的最佳实践和反模式。

我正在做一个反病毒项目，通过反汇编和分析它的代码。所以我想要一个可疑恶意模式代码的列表，这样我就可以观察哪些是可疑的，哪些不是？

所以我只想要一个可疑模式的列表。

（代理设置除外！）

我花了一些时间在这里写一个关于我遇到的问题的更好模式的问题 - 一个对几乎每个属性 getter 执行一些条件初始化的类，因为基类中的初始化依赖于继承类的数据，而这些数据不是施工时可用。

在编写问题时，我得出结论，在继承器构造上进行初始化是更好的做法。这将要求每个继承类调用父类初始化方法，但我认为它更好，因为：

1. 我不必记住在每个新属性 getter/setter 的基类中进行初始化。
2. 我在调试时不会意外触发初始化（请参阅我的问题here）

如果您曾经有过更改属性 getter 中状态的代码，您认为这绝对合理吗？你能举一个这样的例子吗？（或者甚至描述模式？）

我只能想到代理访问，在属性访问之前你不想执行初始化......

有人建议我使用工厂/静态方法进行初始化——这实际上是一个好主意（当构造简单时，当继承类之间不统一时会有点困难），但是在我有机会提交回复之前，答案就被删除了. 太糟糕了。

在阅读了这个反模式以及关于它的许多担忧之后再次感到困惑。

如果我有一个域模型并捕获必须保存在数据传输对象中的数据，这是否会使我的域模型成为数据的包装器？在那种情况下，我将使用贫血域模型。但是，如果我在该包装器上添加足够的域逻辑，那么它在什么时候成为真正的域模型呢？

我的印象是，捕获必须在域模型中保留的内容违反了良好实践，并创建了贫乏的域模型反模式。但是，如果您使用关系数据库，则无法避免挑选出构成对象状态的部分并保存它。

因为我对这些概念很困惑，所以我不确定我写的东西是否有意义。随时要求澄清。

什么时候设计模式会让你的软件变得更糟？

我看过一个程序，他们在 GUI 和逻辑之间使用外观模式。他们认为不能通过此传输任何对象，因此仅使用原始类型，这使得编码变得困难。

在 Go 编程语言中如何实现单例设计模式？