The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
设计模式是…拜托，你知道它们是什么。它们是我们喜欢和讨厌的东西。我们喜欢它们是因为它们让我们能够毫不费力地编写代码。当我们看到一个习惯性地不假思索地编写代码的人的代码时，我们讨厌它们。我错了吗？现在，让我试着浏览一遍它们并展示给你看我对每个模式的喜爱或厌恶程度。按照字母顺序跟着我。
抽象工厂。没问题。
Adapter。好东西！
桥接模式。好的选择！
Builder。这个概念很糟糕，因为它鼓励我们创建和使用大而复杂的对象。如果你需要一个构造器，在你的代码中已经存在问题。通过重构使得任何对象都可以通过其构造函数轻松创建。
责任链模式。看起来不错。
命令。没问题。
外观模式。不好的想法。在面向对象编程中，我们只需要对象，而不是对象的外观。这个设计模式在本质上更倾向于过程化，因为外观仅仅是一组过程的集合。
轻量级。以我看来，这是一个权宜之计，所以它不是一个好的设计模式。我建议您在没有真正关键的性能问题时不要使用它。但是称其为设计模式…绝对不行。Java中解决性能问题的一种修复方案？是的。
前端控制器。糟糕的想法，以及整个MVC。这是非常过程化的，所以。
解释器。这个名字还行，但我不喜欢。”表达式”会是一个更好的选择。
迭代器。这个想法不好，因为它是可变的。拥有不可变的“光标”会更好。
懒加载。没问题。
MVC。这个想法不好，因为它非常过程化。Controllers是这个概念中关键的破碎元素。我们需要真正的对象，而不是过程化的控制器。
中介者。我不喜欢它。尽管听起来像是一种降低复杂性和耦合度的技术，但它并不真正是面向对象的。这个中介者是谁？只是对象之间的一个”通道”吗？为什么对象不能直接通信？因为它们太复杂吗？应该让它们更小更简单，而不是发明这些中介者。
Memento。这个概念意味着对象是可变的，在一般情况下，我对此持反对态度。
模块。如果维基百科对这个模式的解释是正确的，那它比单例模式还要糟糕。
多例。真的是个很糟糕的主意。和单例模式一样。
Null Object。这个不错。顺便说一下，可以看看为什么 NULL 是不好的。
对象池。很好的一个。
观察者。这个概念很好，但名字不好，因为它以-ER结尾。一个更好的名字应该是”源”和”目标”。源生成事件，目标监听这些事件。
原型。好主意，但它与面向对象编程有什么关系？
代理。不错。
单例模式。这是所有反模式中的王者。无论如何，都要远离它。
规范。没问题。
状态。虽然没有明确说明，但我认为在大多数情况下，使用这个模式会导致可变性，这是我通常不赞成的一种代码特征。
策略。一个很好的。
模板方法 是错误的，因为实现继承是过程式的。
访客。这是一个相当过程化的概念，将对象视为数据结构，我们可以对其进行操作。
I have nothing against concurrency patterns either; they are all good, since they have almost nothing to do with object-oriented programming.
如果你知道一些其他的设计（反）模式，请在下面的评论中告诉我。我会在这里添加它们。
Translated by ChatGPT gpt-3.5-turbo/002 on 2023-08-25 at 06:53
