The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
设计模式是…来吧，你知道它们是什么。我们喜欢它们，也讨厌它们。我们喜欢它们是因为它们让我们能够编写不需要思考的代码。当我们看到某人习惯于不加思考地编写代码时，我们讨厌它们。我错了吗？现在，让我试着浏览所有这些设计模式，并向你展示我有多么喜欢或讨厌每一个。按字母顺序跟我来。
抽象工厂。还可以。
适配器。不错。
桥接。不错。
建造者。可怕的概念，因为它鼓励我们创建和使用大型、复杂的对象。如果你需要一个建造者，那么你的代码中肯定有问题。重新设计它，使得通过构造函数轻松创建任何对象。
责任链。看起来不错。
命令。还可以。
组合。不错；也看看这个。
数据传输对象。真是个遗憾。
装饰者。我最喜欢的。我强烈推荐你使用它。
外观。坏主意。在面向对象编程中，我们只需要对象，不需要对象的外观。这种设计模式在精神上非常过程化，因为外观只不过是一组过程的集合。
工厂方法。这个似乎还可以。不好！
享元。这是一个权宜之计，我认为它不是一个好的设计模式。除非有真正紧急的性能问题，否则我建议你不要使用它。但是将其称为设计模式…绝不可能。用于解决Java中的性能问题？是的。
解释器。还可以，但我不喜欢这个名称。”表达式”会是一个更好的替代。
迭代器。坏主意，因为它是可变的。最好使用不可变的“游标”。
延迟初始化。还可以。
标记。这是一个糟糕的主意，还有反射和类型转换。
MVC。糟糕的主意，因为它非常过程化。控制器是这个概念中关键的破坏因素。我们需要真正的对象，而不是过程化的控制器。
中介者。我不喜欢它。尽管它听起来像是一种降低复杂性和耦合性的技术，但它并不真正面向对象。这个中介者是谁？只是对象之间的一个“通道”吗？为什么对象不能直接通信呢？因为它们太复杂？让它们变得更小、更简单，而不是发明这些中介者。
备忘录。这个想法意味着对象是可变的，而我一般反对这种想法。
模块。如果维基百科关于这个模式的描述是正确的，那么它比单例模式还要糟糕。
多例。非常糟糕的主意。和单例一样糟糕。
空对象。不错。顺便说一句，看看为什么NULL是不好的。
对象池。不错。
观察者。这个想法不错，但名称不好，因为它以-ER结尾。一个更好的名称是“源”和“目标”。源生成事件，目标监听它们。
ORM。糟糕并且“冒犯人”，看看这个。
原型。好主意，但它与面向对象编程有什么关系？
代理。不错。
RAII。这是一个非常好的模式，我强烈推荐你使用它。
仆人。非常糟糕的主意，因为它非常过程化。
单例。它是所有反模式中的王者。不管怎样，离它远点。
规约。还可以。
状态。虽然它没有明说，但我觉得在大多数情况下使用这个模式会导致可变性，而我通常反对这种代码特性。
策略。好模式。
模板方法。是错误的，因为实现继承是过程化的。
访问者。一个相当过程化的概念，将对象视为可以操纵的数据结构。
我对并发模式也没有意见；它们都是好的，因为它们几乎与面向对象编程无关。
如果你知道其他设计（反）模式，请在下方的评论中告诉我。我会在这里添加它们。
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-27 at 13:39
