Cухой антипаттерн

Когда-то давно, будучи самоучкой и услышав слово паттерн, я пошел читать, что же это такое. Я тогда недоумевал, почему использование свойств языков являются паттернами и удивлялся, когда находил среди них, доселе придуманных мною решений. Затем, однажды, я накнулся на один ответ на SO, с таковой сутью: паттерны это то чем один человек объясняет другому, что и почему он написал. Когда вы пишите, вы должны думать в терминах языка и задачи, а не о том, какой паттерн лучше приткнуть. Не знаю если если так было у вас, но количество аббревиатур в тексте настораживает.

Ещё одна из ошибок тут в том, что разработчик продолжает следовать плану, поставленным оценкам, и это происходит «в тишине», ведь ответственности как бы нет, она лежит на всей команде, принявшей такое решение и такую оценку.

То есть вы сами утверждаете, что допустили ошибку в планировании, во внутрекомандной коммуникации, в затягивании проблемы, в том, что не адаптировали архитектуру под измененные требования, но обвиняете при этом не собственную лень и непрофессиональное поведение, а принцип DRY.

Вы поставите табу на паттерне Strategy, заставите всю команду пользоваться функциями, неправильно запланируете время на следующий компонент, повторите ту же ошибку и потом поставите табу на букве S из принципа SOLID. И так далее, пока не поймете, что основная проблема не в паттернах, а в вас.

На момент сдачи второй истории, компонент уже был обречен, и чем дальше, тем хуже.

И снова. Зная, что у вас есть хрупкое место — вы продолжали делать это место все хуже и хуже, обвиняя Стратегию, а не самих себя.

Вариант избавления от дублирования через...

На самом деле вы забыли ещё более приятный вариант — через полиморфизм. Стратегия — более узкий паттерн, чем универсальный метод для DRY. И полиформизм одновременно позволил бы избежать дублирования и не осложнил приложение как использование стратегии.

abstract class ThreeViewPageLayout {
  methodA () { /* code here */ } 
  methodB () { /* code here */ }
  methodC () { /* code here */ }
  runMethod () {
    methodA();
    methodB();
    methodC();
  }
}

class FirstPage extends ThreeViewPageLayout {
  methodB () { /* new code here */ }
}

class SecondPage extends ThreeViewPageLayout {
  methodB () { /* new code here */ }
}

class ThirdPage extends ThreeViewPageLayout {
  methodA () { /* new code here */ }
  methodB () { /* new code here */ }
}

Иногда программисты на самом деле идут более сложный способом, чем существует и потом страдают из-за этого. Но основная проблема на в Стратегии, а в вас. Когда вы поняли, что ваш код — плох, что его дальнейшая поддержка стоит нарастающих денег и при этом не выделили на его исправление время — именно в этот момент вы допустили самую главную ошибку. Очень часто программисты оправдывают собственную лень желанием сэкономить денег заказчику, но в итоге потом тратят еще больше денег за счет того, что выпускают все более нестабильные модули до тех пор, пока модуль становится столь нестабильный, что приходится переписать его и все части системы, которые с ним взаимодействовали.

Еще этому немало способствует желание заказчика реализовать все «подешевле», Ведь переиспользовать ранее созданный контейнер быстрее, чем реализовать страницу полностью.

А тут нужно было не делать так, как говорит непрофессионал в разработке (ибо его мнение совпадало с желанием программиста делать меньше работы), а устранить мелкий изьян в самом начале, когда он только начал проявлятся.

Когда программисты говорят: «Заказчик лучше знает, что его прям сейчас устроит менее качественный код» меня это удивляет. Код — ответственность программиста. Он сейчас сказал и забыл об этом. И через три месяца спросит именно у вас, почему код не качественный. И у вас не будет прикрыться им, ибо он — непрофессионал и не знает среднесрочного влияния подобных решений. А вы, как профессионал не должны дать ему допустить этой ошибки.

Когда нужно реализовать третий сценарий, который похож на первые два, но не на 100%, возникает желание переиспользовать код, содержащийся в контейнере. Но его не получится переиспользовать частично, можно лишь взять его целиком, поэтому приходится вносить изменения в контейнер, что сразу несет риск сломать другие сценарии.

Похоже не в стратегии дело, а в одновременном нарушении OCP и ISP — начинаем модифицировать вместо того, чтобы расширять, и создаём один общий интерфейс вместо того, чтобы добавить новый.

Если же вы в разработке используете паттерн strategy, и в контейнер бизнес-логика попала — знайте, линию вы уже перешагнули, и стоите по щиколотку в… ммм, болоте.

Весьма и весьма спорно. Контейнер (общепринято — контекст), реализует бизнес-логику, делегируя часть (изменчивую, контекстно зависимую) реализации конкретным стратегиям. Бизнес-задача — отсортировать сущности, именно это и делает контейнер, а сценарий (общепринято — клиент контекста) выбирает стратегию — правило сравнения сущностей. И сама сортировка, и правила сравнения, и логика выбора конкретного правила являются в целом решением бизнес-задачи по сортировке данных в разных ситуациях.

Про запахи: первый признак неправильного использования стратегии, имхо — наличие у неё собственного состояния и/или неявная модификация состояния контейнера.

Если же вы в разработке используете паттерн strategy, и в контейнер бизнес-логика попала — знайте, линию вы уже перешагнули,

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

В программировании UI есть один тонкий момент — нужно уметь различать одинаковые части интерфейса и похожие части интерфейса.

Повторное использование первых — хорошо. Повторное использование вторых приведет к россыпям костылей для каждого конкретного случая и очень хрупкому коду.

Проблема же в том, чтобы понимать, когда надо обобщать, а когда надо плюнуть на DRY и скопипастить.

То есть ваша грустная история о том, что сначала была реализована нормальная стратегия, потом поменялись требования и весь код обложили хаками?

Наивно думать, что, при таком подходе, после пары итераций «Вариант через прямую агрегацию» не превратиться в 50 строчек копипасты.

Так что это в кансерватории проблемы. Ну там, если вы генерити код страничек из БЛ — стратегия вам не поможет, конечно.

Когда в угоду DRY, сам того не замечая, разработчик жертвует принципом SRP

Скорее, «пытается применить DRY, игнорируя SRP, а потом удивляется, почему получилась тяжеловесная конструкция, которая тем не менее валится от малейшего неосторожного движения».

Есть мнение из лагеря Clojure, что проблема не в DRY самом по себе, а в DRY + мейнстрим ООП.

То есть DRY + наследование кода, жестко привязанное к иерархии.

Как результат, ваш «вариант через прямую агрегацию» весьма напоминает функциональное решение проблемы. В функциональном варианте аналог «стратегии» был бы первоклассной функцией, передаваемой как параметр.

Правило, по которому один элемент равен другому или больше-меньше есть бизнес-логика.

Почему-то сразу вспомнились интерфейсы (=«стратегии» на языке дизайн-паттернов) Comparable и Comparator из Java. Помню, писал компараторы даже для Java-методов для одного интерпретатора. Ничего, нормально всё сработало. Магическое слово «бизнес-логика» ещё не повод не выносить алгоритм сравнения в «стратегию».