Design Patterns and Anti-Patterns, Love and Hate

The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:

Шаблоны проектирования - это… Да ладно, вы знаете, что это такое. Это то, что мы любим и ненавидим. Мы любим их, потому что они позволяют нам писать код, не задумываясь. Мы ненавидим их, когда видим код от человека, привыкшего писать код, не задумываясь. Я ошибаюсь? Теперь позвольте мне пройтись по всем из них и показать вам, насколько я люблю или ненавижу каждый из них. Следуйте за мной, в алфавитном порядке.

Абстрактная фабрика. Все в порядке.

Адаптер. Хороший!

Мост. Хорошо!

Строитель. Ужасная концепция, так как она побуждает нас создавать и использовать большие, сложные объекты. Если вам нужен строитель, то уже есть что-то неправильное в вашем коде. Перестройте его так, чтобы любой объект можно было легко создать через его конструкторы.

Цепочка обязанностей. Кажется нормальным.

Command. Все в порядке.

Компоновщик. Хороший; также посмотрите это.

Data Transfer Object. Просто жаль.

Декоратор. Мой любимый вариант. Я настоятельно рекомендую его использовать.

Фасад. Плохая идея. В ООП нам нужны объекты и только объекты, а не фасады для них. Этот шаблон проектирования очень процедурный по своей сути, так как фасад не более чем совокупность процедур.

Фабричный метод. Этот кажется в порядке. Это плохо!

Flyweight. По моему мнению, это временное решение, поэтому это не хороший шаблон проектирования. Я бы рекомендовал не использовать его, если только у вас действительно критические проблемы с производительностью. Но назвать это шаблоном проектирования… нет никакого смысла. Исправление проблемы производительности в Java? Да.

Фронт-контроллер. Ужасная идея, так же как и весь MVC. Он очень процедурный, вот почему.

Интерпретатор. В целом, но мне не нравится это название. “Выражение” было бы гораздо лучшей альтернативой.

Итератор. Плохая идея, так как он изменяемый. Было бы гораздо лучше иметь неизменяемые “курсоры”.

Ленивая инициализация. Все в порядке.

Маркер. Это ужасная идея, вместе с отражением и приведением типов.

MVC. Плохая идея, так как она очень процедурная. Контроллеры - это главные недостаточные элементы в этой концепции. Нам нужны реальные объекты, а не процедурные контроллеры.

Посредник. Мне это не нравится. Несмотря на то, что звучит как техника для снижения сложности и связности, она на самом деле не является полноценным объектно-ориентированным подходом. Кто такой этот посредник? Просто “канал” между объектами? Зачем объектам необходимо общаться через него? Потому что они слишком сложны? Сделайте их меньше и проще, а не изобретайте такие посредники.

Мементо. Эта идея предполагает, что объекты являются изменяемыми, что я в принципе не поддерживаю.

Модуль. Если Википедия права относительно этого паттерна, то это что-то еще более ужасное, чем Singleton.

Мультизтон. Действительно плохая идея. То же самое, что и Синглтон.

Null Object. Хорошая штука. Кстати, посмотрите Почему NULL плохо.

Пул объектов. Хороший.

Наблюдатель. Идея хорошая, но название плохое, так как оно оканчивается на -ER. Гораздо лучшим вариантом были бы “Источник” и “Получатель”. Источник генерирует события, а Получатель прослушивает их.

ORM. Это ужасно и “оскорбительно”; посмотрите это.

Прототип. Хорошая идея, но что она имеет общего с ООП?

Прокси. Хороший.

RAII. Это действительно хорошая штука, и я настоятельно рекомендую вам ее использовать.

Слуга. Очень плохая идея, потому что она сильно процедурная.

Одиночка. Он - король всех анти-паттернов. Держитесь от него подальше любой ценой.

Спецификация. Это хорошо.

State. Хотя это не подразумевается, я считаю, что в большинстве случаев использование этого шаблона приводит к изменяемости, характеристике кода, с которой я в основном не согласен.

Стратегия. Хорошая.

Шаблонный метод. неправильный, так как наследование реализации процедурное.

Посетитель. Довольно процедурная концепция, которая рассматривает объекты как структуры данных, которыми мы можем манипулировать.


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:55

sixnines availability badge   GitHub stars