От того, что вы что-то переименовали, а для чего-то предложили другие способы реализации, идеи поменялись. Кстати, набор паттернов расширяется, далее паттерны того же уровня, что GoF, сейчас есть и новые.
Итераторы, например, не часть языка. В Python есть, скажем, протокол итератора. В 90% случаев, конечно, его и надо реализовывать. Но не всегда. Полно объектов с методом next(), например. И иногда это даже оправдано.
Собственно, до итераторов, надеюсь, дойду, пока нет смысла обсуждать.
А вот Observer? До сих пор на многих языках полно интерфейсов с методом on_что-то-там(), и это старый добрый Observer. Хотя есть другие способы нотификации объектов о событиях, но никакой не универсален. А сама идея жива.
Реализации меняются. И сильно. Примеры тут — это вообще не напоминает примеры в GoF, но ключевое в их паттернах — идеи. Итератор — не языковая конструкция, это идея отделить контекст итерации от итерируемого контейнера. Синглетон — это не про функцию, возвращающую свою статическую переменную, как это часто делали в C++. Это про саму идею объекта, существующего в одном экземпляре.
О самих паттернах я тут не пишу. Я пишу, как это можно (и как не надо) их реализовывать в современном Python, это более прикладная вещь.
Это хорошо. Но когда вы знаете, какой набор компонентов планируете добавить. А в случае с построением картографического объекта я часто этого вообще не знал. Допустим, получил от читалки исходного формата — добавил. Там это всё накапливается. Это тот случай, когда иммутабельность будет как минимум не очень эффективна. И реально долго заполняются контейнеры компонентов. Иногда добавление вообще в Observer.
Так что вариант в стиле ФП хорош, но он не покрывает 100%. В вашем примере он, наверное, идеален, но в моём — непригоден.
Погодите, каким образом именно паттерн, а не один из способов реализации? Это лишь один из нескольких вариантов. Вот, кстати, хорошо, что заговорили, надо будет об этом в следующей статье написать.
Самая частая моя реализация — есть, скажем, CrtObjectBuilder. Его инициализируешь, потом постепенно наполняешь, вызывая всякие add_attr(), add_id(), add_ref(), add_points() неизвестное количество раз, он копит. Потом зовешь build(), тот возвращает CrtObject, пакуя данные. В этом варианте вообще нет иммутабельности, но это тоже билдер.
Собственно, реализация и должна меняться. Она изначально была разная в разных языках. Я потому этот цикл задуман.
Что до встроенных итераторов — опять же, это языковой механизм. В Python вот тоже есть протокол итератора, но это не значит, что нельзя сделать класс с методом next(). Изредка это даже имеет смысл.
А вот почему builder — это ФП? Вы говорите о реализации его цепочкой вызовов? Так цепочка вызовов — это не суть паттерна. Суть в том, что есть "рабочий стол" (объект-builder), есть способы "прикрутить" к собираемому новые части, а в конце — забрать результат. Когда-то я много писал конвертацию карт. И там было полно билдеров вообще без цепочек вызовов (ты изначально не знаешь, сколько и чего добавишь, цепочку не написать). Имхо, если правильно понял вас, именно цепочки напоминают ФП. Но это просто один способ оформления паттерна.
Но в принципе мы об одном — способы реализации в языке очень эволюционируют и подстраиваются под реальность. Поэтому чуть не под каждый язык можно писать книжку, как там реализовать паттерны.
Мне кажется, вы перепутали два уровня. В языке появились механизмы для более простой реализации паттернов. Это не значит, что паттерны потеряли смысл. Паттерн — это мотивация плюс решение. От того, что для реализация команды вы стали использовать замыкание, паттерн никуда не делся. Замыкание — это не сам паттерн, это лишь языковой механизм для его воплощения. У него ещё много применений. И книга GoF больше про саму идею паттернов, этот слой там не устаревает практически.
Я, собственно, написал, для чего синглетон можно и нужно использовать (например, корневой интерфейс библиотеки, желательно — без состояния) и почему обычно его стоит избегать. И это очень узкая область. Никакому ООП он не противоречит совершенно, просто у него сейчас очень мало валидных сценариев использования. И потом, как можно не иметь жизненного цикла? И как синглетон может не быть объектом? У него просто специфический жизненный цикл.
А что паттерны GoF устарели — не согласен категорически. ООП (не языки) изменилось за 30 лет мало. Подозреваю, вы просто не нуждаетесь во многих паттернах в повседневной деятельности.
Мой личный топ — Builder (а как собрать, скажем, картографический объект, где куча возможных элементов?), Visitor (а как ещё после парсинга грамматики работать с AST?), Observer (это вообще в современном ПО часто), Iterator (на каждом шагу), Chain of Responsibility (в обработке запросов очень частый), Adapter. Это только то, что постоянно используется. Есть редкие, парочку вообще никогда не пришлось использовать в реальном ПО — Bridge, скажем.
И никуда это не уходило. Просто очень много теперь есть и других паттернов. И архитектурных (уровнем повыше), и кодировочных (уровнем пониже). Паттерны — это вообще стандартные решения. И паттерны GoF вполне живы, просто много есть других паттернов.
Это, на мой взгляд, не так. Эти паттерны вообще не про языки, хотя реализуются в разных языках иногда по-разному. Скажем, какой-нибудь Visitor как использовался для обхода и преобразования AST в парсерах и компиляторов 30 лет назад, так и используется. Итераторы и фабрики как были, так и есть (и наличие в Python стандартного протокола итератора ничего не меняет, полно и нестандартных реализаций). Прототипы, адаптеры — что поменялось? И всё так же. ООП изменилось не так сильно, менялись в основном языки. Никуда эти идеи не делись, просто опыта их реализации добавилось, появились новее решения. Это не так ново, как в 90-х, когда я это прочитал, но по-прежнему существует.
К счастью, такого нет, защита не нужна, она встроенная. Обычные импорты, сколько и как ни делай, дают ровно один элемент в sys.modules. Способ задания пути влияет на поиск модуля и адресацию его в конкретном месте — и только. Вот если грузить исходники руками, задавая имя модуля — да, поломать можно, но это надо именно ломать, не ограничиваясь стандартным механизмом.
Да, чем его меньше, тем обычно лучше. Я несколько раз наступил на грабли ещё на C++ в 90-х, потом, как и писал, делал только для корневого интерфейса модуля.
Механизм хороший. Но это не решает вопроса работы в многопоточном окружении. По сути, это та же функция get_что-то-там(), но только скрытая, выглядящая как создание атрибута. К тому, как организовано само создание, это ничего не добавит, к сожалению.
Мысль понимаю, сам 30 лет работаю, но я не вполне уверен, что это про SOLID именно. Очень по-разному пишут те, кто на тему архитектуры и её осмысления всерьёз думает и читает, и те, кто пишет как попало.
А та мысль, которую я у него выхватил — она, имхо, и вовсе замечательная. Книгу младшим коллегам советую.
"Чистый код" не читал. И не планирую. Прочёл "Чистую архитектуру". Ценное там, как мне кажется, есть. Но вот этого ценного на страницу-две. Наиболее ценна ваша бизнес-логика, наименее — фреймворки и инфраструктура. Архитектура слоями, наиболее глубиннные и ценные слои не должны явно зависеть о внешних. Вся книга. Дальше идёт высасывание из пальца пяти надуманных принципов SOLID. Книгу даже советую, но там слишком много лишнего.
Но тоже надо постараться. Редактировать sys.path между загрузками, скажем.
Но я всё равно бы скорее стал работать с классом без экземпляра. Впрочем, это тоже рабочий способ.
Тоже, кстати, вариант.
От того, что вы что-то переименовали, а для чего-то предложили другие способы реализации, идеи поменялись. Кстати, набор паттернов расширяется, далее паттерны того же уровня, что GoF, сейчас есть и новые.
Итераторы, например, не часть языка. В Python есть, скажем, протокол итератора. В 90% случаев, конечно, его и надо реализовывать. Но не всегда. Полно объектов с методом next(), например. И иногда это даже оправдано.
Собственно, до итераторов, надеюсь, дойду, пока нет смысла обсуждать.
А вот Observer? До сих пор на многих языках полно интерфейсов с методом on_что-то-там(), и это старый добрый Observer. Хотя есть другие способы нотификации объектов о событиях, но никакой не универсален. А сама идея жива.
Реализации меняются. И сильно. Примеры тут — это вообще не напоминает примеры в GoF, но ключевое в их паттернах — идеи. Итератор — не языковая конструкция, это идея отделить контекст итерации от итерируемого контейнера. Синглетон — это не про функцию, возвращающую свою статическую переменную, как это часто делали в C++. Это про саму идею объекта, существующего в одном экземпляре.
О самих паттернах я тут не пишу. Я пишу, как это можно (и как не надо) их реализовывать в современном Python, это более прикладная вещь.
Это хорошо. Но когда вы знаете, какой набор компонентов планируете добавить. А в случае с построением картографического объекта я часто этого вообще не знал. Допустим, получил от читалки исходного формата — добавил. Там это всё накапливается. Это тот случай, когда иммутабельность будет как минимум не очень эффективна. И реально долго заполняются контейнеры компонентов. Иногда добавление вообще в Observer.
Так что вариант в стиле ФП хорош, но он не покрывает 100%. В вашем примере он, наверное, идеален, но в моём — непригоден.
Погодите, каким образом именно паттерн, а не один из способов реализации? Это лишь один из нескольких вариантов. Вот, кстати, хорошо, что заговорили, надо будет об этом в следующей статье написать.
Самая частая моя реализация — есть, скажем, CrtObjectBuilder. Его инициализируешь, потом постепенно наполняешь, вызывая всякие add_attr(), add_id(), add_ref(), add_points() неизвестное количество раз, он копит. Потом зовешь build(), тот возвращает CrtObject, пакуя данные. В этом варианте вообще нет иммутабельности, но это тоже билдер.
Собственно, реализация и должна меняться. Она изначально была разная в разных языках. Я потому этот цикл задуман.
Что до встроенных итераторов — опять же, это языковой механизм. В Python вот тоже есть протокол итератора, но это не значит, что нельзя сделать класс с методом next(). Изредка это даже имеет смысл.
А вот почему builder — это ФП? Вы говорите о реализации его цепочкой вызовов? Так цепочка вызовов — это не суть паттерна. Суть в том, что есть "рабочий стол" (объект-builder), есть способы "прикрутить" к собираемому новые части, а в конце — забрать результат. Когда-то я много писал конвертацию карт. И там было полно билдеров вообще без цепочек вызовов (ты изначально не знаешь, сколько и чего добавишь, цепочку не написать). Имхо, если правильно понял вас, именно цепочки напоминают ФП. Но это просто один способ оформления паттерна.
Но в принципе мы об одном — способы реализации в языке очень эволюционируют и подстраиваются под реальность. Поэтому чуть не под каждый язык можно писать книжку, как там реализовать паттерны.
Тьфу, не создание, адресация атрибута, конечно.
Мне кажется, вы перепутали два уровня. В языке появились механизмы для более простой реализации паттернов. Это не значит, что паттерны потеряли смысл. Паттерн — это мотивация плюс решение. От того, что для реализация команды вы стали использовать замыкание, паттерн никуда не делся. Замыкание — это не сам паттерн, это лишь языковой механизм для его воплощения. У него ещё много применений. И книга GoF больше про саму идею паттернов, этот слой там не устаревает практически.
Я, собственно, написал, для чего синглетон можно и нужно использовать (например, корневой интерфейс библиотеки, желательно — без состояния) и почему обычно его стоит избегать. И это очень узкая область. Никакому ООП он не противоречит совершенно, просто у него сейчас очень мало валидных сценариев использования. И потом, как можно не иметь жизненного цикла? И как синглетон может не быть объектом? У него просто специфический жизненный цикл.
А что паттерны GoF устарели — не согласен категорически. ООП (не языки) изменилось за 30 лет мало. Подозреваю, вы просто не нуждаетесь во многих паттернах в повседневной деятельности.
Мой личный топ — Builder (а как собрать, скажем, картографический объект, где куча возможных элементов?), Visitor (а как ещё после парсинга грамматики работать с AST?), Observer (это вообще в современном ПО часто), Iterator (на каждом шагу), Chain of Responsibility (в обработке запросов очень частый), Adapter. Это только то, что постоянно используется. Есть редкие, парочку вообще никогда не пришлось использовать в реальном ПО — Bridge, скажем.
И никуда это не уходило. Просто очень много теперь есть и других паттернов. И архитектурных (уровнем повыше), и кодировочных (уровнем пониже). Паттерны — это вообще стандартные решения. И паттерны GoF вполне живы, просто много есть других паттернов.
Со статьёй или с предыдущим оратором? Я-то тоже поныне всё это использую.
Это, на мой взгляд, не так. Эти паттерны вообще не про языки, хотя реализуются в разных языках иногда по-разному. Скажем, какой-нибудь Visitor как использовался для обхода и преобразования AST в парсерах и компиляторов 30 лет назад, так и используется. Итераторы и фабрики как были, так и есть (и наличие в Python стандартного протокола итератора ничего не меняет, полно и нестандартных реализаций). Прототипы, адаптеры — что поменялось? И всё так же. ООП изменилось не так сильно, менялись в основном языки. Никуда эти идеи не делись, просто опыта их реализации добавилось, появились новее решения. Это не так ново, как в 90-х, когда я это прочитал, но по-прежнему существует.
К счастью, такого нет, защита не нужна, она встроенная. Обычные импорты, сколько и как ни делай, дают ровно один элемент в sys.modules. Способ задания пути влияет на поиск модуля и адресацию его в конкретном месте — и только. Вот если грузить исходники руками, задавая имя модуля — да, поломать можно, но это надо именно ломать, не ограничиваясь стандартным механизмом.
Да, чем его меньше, тем обычно лучше. Я несколько раз наступил на грабли ещё на C++ в 90-х, потом, как и писал, делал только для корневого интерфейса модуля.
Механизм хороший. Но это не решает вопроса работы в многопоточном окружении. По сути, это та же функция get_что-то-там(), но только скрытая, выглядящая как создание атрибута. К тому, как организовано само создание, это ничего не добавит, к сожалению.
Ну, это, по сути, обработанные материалы лекции, где я использовал каждый кривой вариант для объяснения кучи общепитоновских вещей.
Да, и не только технической. С гуманитарной не лучше.
Мысль понимаю, сам 30 лет работаю, но я не вполне уверен, что это про SOLID именно. Очень по-разному пишут те, кто на тему архитектуры и её осмысления всерьёз думает и читает, и те, кто пишет как попало.
А та мысль, которую я у него выхватил — она, имхо, и вовсе замечательная. Книгу младшим коллегам советую.
"Чистый код" не читал. И не планирую. Прочёл "Чистую архитектуру". Ценное там, как мне кажется, есть. Но вот этого ценного на страницу-две. Наиболее ценна ваша бизнес-логика, наименее — фреймворки и инфраструктура. Архитектура слоями, наиболее глубиннные и ценные слои не должны явно зависеть о внешних. Вся книга. Дальше идёт высасывание из пальца пяти надуманных принципов SOLID. Книгу даже советую, но там слишком много лишнего.