План на ближайшие посты по шаблонам проектирования

Тема с шаблонами зашла, она как обычно вызывает разные чувства, но комментариев много и интерес есть. Я хочу сделать цикл прямо обучающих постов, в которых мы кое что разберем. Однако, сразу хочу обозначить. Это ни в коем случае не стандартное вот шаблон вот поехали. Мы попробуем разобраться со смысловой частью программирования, в которой появляются шаблоны с рассмотрением проблемы, альтернатив, плюсов минусов и так далее. И что важно, даже когда мы будем говорить про паттерны, мы не будем говорить про набор классов как это описано в большинстве мест, мы будем говорить про организацию кода, которая решает реальную проблему, не зависимо от того, на каком языке мы пишем. На выходе у вас должно появиться более четкое понимание проблем, которые вызывает сложный код и как это код можно упростить (или усложнить) разными решениями. Первый пост будет завтра, а тут немного комментариев на те комментарии, которые вы оставляли к посту:

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

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

> Неироничный вопрос: а чем программистов так пугают ифы? Ветвление - фундаментальная конструкция в языках программирования. А то иной раз вместо простого ифа два интерфейса, пять классов, абстрактная фабрика абстрактных синглтонов (утрировано). Так происходит от бездумного применения паттернов ради паттернов, потому что так написали в книжках умные дядьки. Простые вещи должны быть простыми.

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

> Интересно, кто-то на практике сталкивался с потребностью поменять базу во время жизни приложения?

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

> А в чем вообще разница между медиатором и адаптером?)

Поговорим) Однако тут надо идти от проблематики, в которых эти паттерны возникают.

p.s. Знаете ли вы что такое динамическая диспетчеризация и мультидиспетчеризация?

2 минуты

26 февраля 2024