Шаблоны проектирования ... Мы любим их, потому что они позволяют нам писать код, не задумываясь. Мы ненавидим их, когда видим код того, кто привык писать код, не задумываясь. Я ошибаюсь? Теперь, позвольте мне показать вам, как я люблю или ненавижу каждого из них.
36 паттернов всего, 14 отлично+5 хорошо
Абстрактная фабрика(Abstract Factory).
Адаптер(Adapter)
Мост(Bridge)
Цепочка ответственности (Chain of Responsibility)
Command
Композитный (Composite)
Декоратор (Decorator). Мой любимый. Я настоятельно рекомендую вам использовать его
Ленивая инициализация (Lazy Initialization)
Нулевой объект (Null Object). Неплохо. Кстати, посмотрите, почему NULL это плохо
Пул объектов (Object Pool)
Proxy
RAII. Это действительно хорошая идея, и я настоятельно рекомендую вам ее использовать.
Спецификация (Specification)
Стратегия (Strategy)
Состояние (State).
Хотя это не подразумевается, я считаю, что в большинстве случаев
использование этого шаблона приводит к изменчивости кода, что обычно я
осуждаю.
Опытный образец(Prototype). Хорошая идея, но какое это имеет отношение к ООП?
Наблюдатель (Observer).
Идея хорошая, но название плохо, так как оно заканчивается на -ER.
Гораздо лучше было бы «Источник» (Source) и «Цель» (Target). Источник
генерирует события, и Цель слушает их.
Фабричный метод (Factory method) Этот кажется ОК.
Переводчик(Interpreter). Все нормально, но имя мне не нравится. «Выражение» (Expression) было бы гораздо лучшей альтернативой.
Я также не имею ничего против моделей параллелизма(concarency patterns); Все они хороши, поскольку они почти не имеют отношения к объектно-ориентированному программированию.
Зло
Строитель (Builder).
Ужасная концепция, поскольку она побуждает нас создавать и использовать
большие, сложные объекты. Если вам нужен строитель, в вашем коде уже
что-то не так. Реорганизуйте его, чтобы любой объект легко создавался
через его конструкторы.
Объект передачи данных (Data Transfer Object). Это просто позор.
Фасад (Fasade). Плохая идея. В ООП нам нужны объекты и только объекты, а не фасады для них. Этот шаблон проектирования очень процедурный по своему духу, поскольку фасад представляет собой не что иное, как набор процедур.
Легковес(Flyweight). Это, как я вижу, обходное решение, так что это не очень хорошая модель. Я бы рекомендовал вам не использовать его, если не существует действительно критической проблемы с производительностью. Но называя это образцом дизайна ... никак. Исправить проблему производительности в Java? Да.
Передний контроллер(Front Controller). Ужасная идея, как и вся MVC. Это очень процедурно, вот почему.
Итератор (iterator). Плохая идея, так как она изменчива. Было бы гораздо лучше иметь неизменные «курсоры».
Маркер (Marker). Это ужасная идея, наряду с отражением и типом литья.
MVC. Плохая идея, так как это очень процедурно. Контроллеры являются ключевым сломанным элементом в этой концепции. Нам нужны реальные объекты, а не процедурные контроллеры.
Посредник (Mediator). Мне это не нравится. Несмотря на то, что это звучит как метод уменьшения сложности и сцепления, он не является объектно-ориентированным. Кто этот посредник? Просто «канал» между объектами? Почему объекты не должны напрямую обмениваться данными? Потому что они слишком сложны? Сделайте их меньше и проще, чем изобретайте эти посредники.
Снимок (Memento). Эта идея подразумевает, что объекты изменяемы, что я вообще против.
Модуль (Module). Если Википедия права в отношении этого шаблона, это нечто более страшное, чем Синглтон.
Multitone. Действительно плохая идея. То же, что и Синглтон.
ORM. Это ужасно и «оскорбительно»;
Слуга (Servant). Очень плохая идея, потому что это очень процедурно.
Одиночка (Singleton). Это король всех анти-шаблонов. Держитесь подальше от этого любой ценой.
Шаблонный метод (Template method). Неверно, поскольку наследование наследования является процедурным.
Посетитель (Visitor). Довольно процедурная концепция, которая рассматривает объекты как структуры данных, которыми мы можем манипулировать.
Комментариев нет:
Отправить комментарий