Антипаттерны в проектировании

[Majestio]

Буэнос ночес, амигос!

Всем известно, что определённые приёмы программирования привносят в процесс проектирования определённые ништяки. Сорян, но вынужден дать линки на свой собственный сайт:

• Шпаргалка по шаблонам проектирования
• S.O.L.I.D на примерах С++
• S.O.L.I.D на шаблонах проектирования GoF

Но вопрос! А когда это и в каких случаях это желание систематизированности и каноничности привносит неоправданный оверхед?
Какие для этого признаки? И что делать в таких случаях?

[Felan]

О, холиварчик

С моей т.з. никогда!

Думаю что в этом и заключается профессиональный опыт.

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

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

Вопрос применимости паттернов заключается в том, будешь ли ты забивать шурупы.

И вот тут всплывают опыт, профессионализм и знания: ты точно можешь отличить шуруп от гвоздя? А точно можешь правильно выбрать где нужны гвозди а где шурупы?

Но это требует серьезного образования и опыта.

Если ты фронтендер все бытие которого ограничено одной страницей у тебя нет еще 3-х человек которые ее тоже развивают, у тебя просто не будет никогда нужды в паттернах. Ну может че-нить самое простое только.

Я бы сформулировал так, это нажно если оно решает какую-то проблему.

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


Если это не раашет никакой конкретной проблемы, то это лишнее.

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


В целом, если серьезно.
Систематизированность должна быть всегда.
Каноничности не должно быть никогда, мы не в церкви.
Шаблоны проектирования это известный способ решить известную проблему. А так же пусть упростить общение между программистами. Один говорит у нас тут обсервер, и всем все понятно.

ПСЖ Для меня стало открытием что современные недоучки вообще не в курсе, что кроме MVVM и синглтона есть еще множество других шаблонов. Они про это просто не знают.

[Qraizer]

В одном предложении о паттернах я бы резюмировал, что о них знать полезно, но гораздо полезнее знать об антипатернах.

[sharky72]

Цитата Qraizer @ 27.02.26, 15:00

В одном предложении о паттернах я бы резюмировал, что о них знать полезно, но гораздо полезнее знать об антипатернах.

Некоторые антипаттерны - сложно выявить. Особенно если проект очень большой. А паттерны - это если честно нужны только на собесах. Большая часть и так используется в повседневной жизни или большинстве фреймворков. Знать надо чтобы сказать что это использовал Хотя для меня наиболее сложным и важным был принцип подстановки Liskov, его труднее всего соблюдать и очень часто хочется нарушить.

P.S. Принцип KISS тоже очень важен

Сообщение отредактировано: sharky72 - 28.02.26, 17:13

[Majestio]

Я помню, достаточно давно, когда я еще практически не был знаком с паттернами проектирования, я встретил прикольный гифчик. Который "повествовал", как из обычного "Hello world" можно наваять инфраструктуру из порядка 10 классов, формально обвязать избыточностью. И все строго по мануалам проектирования по шаблонам, и не подкопаешься!!!

Там "формально" оценивались условия и перспективы - и также формально применялись паттерны проектирования.

Очень обидно, что тогда я просто посмеялся - а гифчик надо было бы сохранить!

[Qraizer]

Та это и нынче несложно сделать при желании.

[Majestio]

И всеж ... хочется вернуть обсуждение в русло топика ...
Давайте обсудим, к примеру, "синглтон". Говорят - практика так себе. А мне вот для хранения "глобального конфига" очень даже нравится. Предлагайте варианты лучше

[sharky72]

Цитата Majestio @ 03.03.26, 01:55

И всеж ... хочется вернуть обсуждение в русло топика ...
Давайте обсудим, к примеру, "синглтон". Говорят - практика так себе. А мне вот для хранения "глобального конфига" очень даже нравится. Предлагайте варианты лучше

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

[Felan]

Цитата Majestio @ 03.03.26, 01:55

И всеж ... хочется вернуть обсуждение в русло топика ...
Давайте обсудим, к примеру, "синглтон". Говорят - практика так себе. А мне вот для хранения "глобального конфига" очень даже нравится. Предлагайте варианты лучше

Синглтон это не структурный паттерн. Он ни хороший ни плохой. Он отлично решает специфические задачи и очень плохо когда им пытаются решить задачи которые не должны им решаться. Ключевое слово "НЕ должны". Потому что они могут им быть решены в значительной степени.

Просто любой проект в течении своей жизни изменяется, и то, что в начале было одной задачей, и хорошо решалось синглтоном, например, со временем может трансформироваться и стать по сути другой задачей, которая уже не рашается синглтоном. И проблема тут в том, что синглтон очень "жесткий", его очень сложно зименить. Он глобальный.

Пример из жизни.

Андроид. Приложение которое общается со сканером. Изначально один из типов сканов мог загружаться и на разных экранах можно было смотреть всякие его параметры. И все было хорошо, пока через несколько лет не понадобилось загружать два разных скана этого типа для обработки и сравнения.

И вдруг оказалось, что вся логика загрузки\рассчетов завязана на синглтон которые еще и промежуточные данные кеширует, и просто невозможно просто взять и сделать еще одну копию.

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

Тут дело не в самом синглтоне как таковом. Дело в том, что его очень сложно модифицировать когда он пророс во все места проекта.

Это как с наследованием. Лучше его избегать. Так в этом случае, лучше было не делать синглтон, тем более, что никих особых преимуществ он не дает тут. Глобальный объект можно и без него создать.

Этот паттерн нужен когда момент создание объекта не контролируется напрямую. Как например бин в апаче (откуда, как я понимаю, и растут ноги синглтона). А если объект создается "напрямую", то смысла в синглтоне просто нет.

Добавлено 03.03.26, 15:30

Цитата sharky72 @ 03.03.26, 13:54

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

Правильно убеждали.
"Заранее аллоцирован" и "Синглтон" вообще никак не связаны.

Все можно сильно заранее аллоцировать и без синглтона (ну правда есть всякие фреймворки разной кривизны которые могут требовать этого, но тут про это не сказано, поэтому мы про общий случай)
Синглтон нужен когда объект создается в неконролируемом контексте и он обязан быть в одном экзепляре. (как например всякие Java Beans и модули Apache)
Если момент создания конролируется напрямую, то и синглтонить смысла нет.

Сообщение отредактировано: Felan - 03.03.26, 15:30

[Qraizer]

Если объект глобальный, однако его характеристики могут стать известны только в ран-тайм, синглон хорошее решение. Проблемы будут, если глобальный объект исходно был неверным архитектурным решением.

[Felan]

Вот это конечно не С++, но мне кажется проблема на лицо.

Очередной "Паттерн".

Хотя лично я не сичитаю что такие вещи следует называть паттернами. Это скорее архитектура. Ну да ладно.

И лично я твердо убежден, что в данном случае автора и подельников надо принудительно лечить.

[D_KEY]

Цитата Qraizer @ 03.03.26, 20:39

Если объект глобальный, однако его характеристики могут стать известны только в ран-тайм, синглон хорошее решение. Проблемы будут, если глобальный объект исходно был неверным архитектурным решением.

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

А люди почему-то склонны принимать архитектурные решения как можно раньше (а надо, наоборот, принимать их как можно позже).

В итоге делают тот же синглтон, а потом от него отказаться сложно становится. Ещё хуже, если вместо рефакторинга костыли строят.

[Qraizer]

Хм. Если принимать архитектурные решения как можно позже, ничего так и не будет написано. Однако можно писать так, чтобы архитектурные изменения могли бы легче интегрироваться в имеющийся код.
Синтетически. Вот у нас синглтон, заменяющий глобальный объект. Вот функция, возвращающая ссылку на него и используемая для получения доступа к синглтону. На первом вызове она его создаёт, на последующих возвращает уже созданные экземпляр. Типичная и простая реализация. У меня так испытательный стенд устроен. Он напичкан разными шелесками: от генератора аналоговых сигналов в широком диапазоне частот и напряжений до ARINC и CAN. Их реализуют как раз сигнлтоны и представляющие их классы, т.к. конфигурация стенда определяется файлом параметрических данных, и там же определяются характеристики сигналов управления и наблюдения. Бац! понадобилось добавить новый CAN. Хорошо, если это другая шелеска, для неё напишется свой класс и свой синглтон, но вот если такая же, то упс. Ну и ничего страшного: как-нибудь вводим их идентификацию, пусть и просто индексами, заменяем синглтон CANа на мап CANов с ключём-идентификатором, в функцию доступа вводим параметр – и вуаля. Написать код, по-новому парсящий параметрический файл, всё равно пришлось бы, а ошибки компиляции выявят все места запроса синглтона.

[D_KEY]

Цитата Qraizer @ 08.03.26, 16:00

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

Мне кажется, что ты упускаешь "как можно" в том предложении
Принимаешь тогда, когда уже нельзя не принять. Но как можно позже, потому что ты будешь иметь больше знаний.

Добавлено 08.03.26, 19:49

Цитата Qraizer @ 08.03.26, 16:00

Однако можно писать так, чтобы архитектурные изменения могли бы легче интегрироваться в имеющийся код.

[Majestio]

Цитата Felan @ 03.03.26, 15:19

Правильно убеждали.
"Заранее аллоцирован" и "Синглтон" вообще никак не связаны.

Вот тут да, я боюсь - надо согласиться! Ибо очень часто сама инициализация данных синглтона происходит, скажем так, lazy. А именно - при первом к нему обращении. И то, что он объявлен глобально - совсем не значит, что он "построен" полностью в первую очередь!