собственные смыслы и расширять их определения. На одной из работ дали мне задание реализовать UoW. Я реализовал. Шеф посмотрел и спрашивает: а их можно вкладывать друг в друга, единицы работы? Конечно, нет, нельзя. Он мне говорит, что должно быть можно. Я ему говорю, что точно нет. Не предусмотрено такой опции у единицы работы.
Что оказалось. Оказалось, что он всегда считал, что единицы работы это транзакции. В некоторых БД транзакции действительно можно вкладывать. В некоторых нет. А единицы работы, как они описаны у Фаулера в книге, действительно ничего подобного не предполагают.
У паттернов есть один плюс — они позволяют передавать много информации от программиста, который проектирует-пишет код к программисту, который его поддерживает. Если я говорю, что здесь Decorator, то поддерживающий программист получает сразу много информации, чего ожидать, а чего не надо.
Поэтому, моё мнение, надо пользоваться определениями паттернов, данными в широко известной литературе. Не надо придумывать, что есть Singleton, и чем он может быть. Тот Singleton, который описан у GoF, называют анти-паттерном.
ну хз. с одной стороны олдскулы сводит от всех этих бессысленных споров в курилках чьё понимание паттерна более правильное. а сдругой если молиться на диаграммы классов из гоф, то их как-бы и не существует. если я в гопнете вместо ваяния коллбек интерфейсов для паблиш/сабскрайба и стратегий юзаю делегаты посахарённые лямбдами, то это как бы к этим паттерным отношения не имеет, что немножко странно.
Не совсем так. Разные языки дают разные средства для реализации. Делегат это готовая реализация пабсаба, сделанная в полном соответствии с рекомендациями GoF. Они там тоже ребята не дураки были, писали, не жёстко привязываясь к языку. Именно поэтому через yield в C# (и в Python), вполне себе реализуется паттерн Iterator. Просто писать ручками приходится гораздо меньше.
Обсуждают сегодня