Комментарии 34
Отличный подбор! Вспомнился ещё Эрик Эванс с его несгибаемой синей книгоой Domain-Driven Design: Tackling Complexity in the Heart of Software. Ей не почти 20 лет, но тоже живее всех живых в своей области.
Если ваш друг Жора придумал паттерн, это не паттерн.
GoF писали текстовый редактор на Java и оттуда насобирали идей на целую книжку. Почему в наше время Жора не может проделать тот же трюк с другой предметной областью или языком?
В GoF на первых же страницах писали, что главная их задача в книжке - показать принцип, - а сами паттерны это просто иллюстрация и призывали искать свои.
Но все восприняли эти примеры как догмы (ведения же ни кто ни читает) и принялись тиражировать как обезьяны по поводу и без повода.
У меня просто есть история про разное понимание паттерна Unit of Work. Один участник дискуссии думал, что UoW это то же самое, что и транзакция и может быть вложенной. А другой опирался на описание паттерна в книге Фаулера. Там про вложенность ничего нет.
Вместо того, чтобы сократить время разговора, паттерн стал причиной спора. Поэтому не соглашусь с вами. Паттерны нужны для передачи информации о проектных решениях в коде. Если программисты будут понимать их по разному, неизбежны проблемы.
Не, это точно не транзакция, у Фаулера как раз и сказано, что он, в том числе, нужен чтобы не держать транзакцию открытой. Это уже тема ближе к ДДД.
Паттерны они потому и "паттерны", что конкретная реализация может сильно отличаться. Поэтому споры - это нормально, пока аргументы разумны и конкретны (т е для данной ситуации и проекта) Ну и отсюда вытекает необходимость "диктатуры" на проекте - последнее решение за одним человеком, Иначе действительно будут бесполезные холивары.
Про сам Uow - в первую очередь это "единица работы", т е набор связанных измененных данных (в случае ДДД там будут "сущности") изменения которых должны быть либо сохранены в хранилище целиком, либо отброшены. Это по сути всё определение. Есть там внутри транзакция, или нет - это детали реализации. Если хранилище поддерживает транзакции, то вполне может так быть что лучше сделать одну транзакцию на один UoW. Может быть и две транзакции, но тогда должен быть двухфазный комит, что бы обеспечить атомарность. Ну и могут наверное быть и вложенные транзакции, но зачем ? По мне пахнет анти-паттерном. Всё зависит от требований и условий.
А как же SICP?
Тоже промелькнула эта мысль. Виноват ТС - дал статье слишком общее название. Хочется сразу много нестареющих и не устаревших книжек сюда подпихнуть. Даже перечислять не буду.
Вы правы, что хороших книг гораздо больше, чем здесь написано. Но объять необъятное нельзя, Козьма Прутков это точно установил.
Я сначала в заголовке написал, что речь про ООП и даже про .NET, но потом решил, что длинный заголовок зло, и перенёс ООП и .NET в хабы. Мне казалось, они бросаются в глаза и задают какой-то контекст.
Что касается SICP, то у меня несколько материалов, навеянных этой книгой. В частности, предыдущая статья на хабре.
Инверсия зависимостей (Dependency Inversion) — не самая простая концепция. Её трудно объяснить на пальцах ... Чтобы принцип работал, нужно придумать, как внедрять зависимости.
Не совсем. Принцип проектирования Dependency Inversion Principe (DIP) показывает как можно ослабить зависимости слоев высокого уровня от деталей реализации. На бытовом уровне: вместо того чтобы соглашаться на условиях поставщика услуг, вы предлагаете ему заключить контракт на собственных условиях (ломая позицию исполнителя "у нас стандартный договор"). В этом случае вы будете зависеть только от условий своего же контракта, а не прихотей конкретного исполнителя. Противоположность - прямая зависимость, когда слой высокого уровня использует интерфейсы более низкого.
Dependency Injection (DI) это шаблон проектирования, предлагающий типовые варианты для настройки объекта в рантайме, при котором значения полей задаются внешней сущностью. Это одна из реализаций принципа Inversion of Control Principe (IoC, aka Hollywood Principe - "Don't call us, we'll call you"). Противоположность - создание или запрос зависимостей самостоятельно, как например в паттерне Factory Method или Service Locator.
Принципы DIP и IoC на уровне идей чем-то похожи. Здесь первый подсказывает как менять отношение между объектами, а второй - поведение. DI просто один из способов собирать все вместе.
Звучит как приглашение прочитать. Я бы присоединил к первой книжке ещё Гради Буча, Джефа Элджера и, наверное, ещё и Шлеер С, Меллор С. Объектно-ориентированный анализ: моделирование мира в состояниях.
Хм, визитор всегда казался понятным и самым элегантным, а вот всякие там фабричные строители избыточными и ненужными
Статья в первую очередь вокруг ООП, поэтому я бы добавил Бертран Мейер. Объектно-ориентированное конструирование программных систем.
Настоящий паттерн, как элемент общего языка, должен быть описан в популярной книге или в статье на посещаемом ресурсе
Настоящий паттерн существует в написанном так или иначе коде независимо от того, описан он где-то или нет.
Культ карго, как и принято в ООП. И набор книг сугубо вокруг него.
Не соглашусь. Паттерны придумывают люди для каких-то целей. И паттерны это всегда результат осмысления существующего кода, результат поиска закономерностей.
Описание паттерна очень важно для передачи смысла. Если вы дадите классу название OrderRepository, читатель вас поймёт. А вот если назовёте его OrderManager — то, скорее всего, нет. Manager может быть чем угодно.
Главное не пытаться все 23 паттерна использовать одновременно. К сожалению, встречал подобное,и это даже говнокодом трудно было назвать :(
А как насчёт "The art of computer programming", Knuth, 1968? В четырёх томах, однако.
Я бы сюда же еще добавил "Introduction to Algorithms", Thomas H. Cormen, 1990. А Кнут конечно для сильных духом, я лет 10 назад не смог толком осилить, а сейчас как-то руки всё не доходят.
Знаю только одного человека, который прочитал три тома Кнута еще будучи студентом. Он реально крут и глядя на него я понял, что не учился в универе, а валял дурака ))
Кнут конечно для сильных духом, я лет 10 назад не смог толком осилитьОн не так что бы очень сложен, просто нужен другой подход. Не как к книге по программированию, а как к достаточно сжатому справочнику с включением учебных материалов. Поэтому просто читать недостаточно, каждую главу надо самому разбирать, плюс с завидной периодичностью нужно знание математики хотя бы на уровне первых 2 курсов универа. Тогда нормально идет:)
Интересно сможем ли когда-нибудь прочесть серию полностью, первый раз в глаза увидели в 96 кажется трехтомник. Сейчас 4 том только в альфаверсии, а в планах аж до 7 если верить википедии.
Да, тоже очень хорошая книга. Время от времени перечитываю любимые места. К сожалению, кажется, она всё-таки устарела даже как учебный курс. Но я бы рекомендовал её читать для расширения кругозора. Кнут очень эрудированный автор, кстати, владеет русским языком. И эта эрудиция очень заметна.
А как же Кнут, Кормен и подобные?
Я бы дополнил несколькими классическими трудами: "Искусство программирования", "Алгоритмы + структуры данных = программы" и книгой красного дракона
Не знал, что дядюшка Боб был редактором журнала о программировании)
Сейчас бы в 2к22 продолжать рекомендовать Clean Code
https://qntm.org/clean
В статье рекомендуется другая книга — Clean Archicteture.
О_О отличная статья.
Прям хорошо разъяснила почему зачастую глядя на (clean code или "clean code") хочется его выкинуть весь и написать как в ссылке на репозиторий.
Чтобы все действия в одном месте, а не замаскированные размазывания преобразований по 15 функциям.
Неустаревающие книги?