мне очень нравятся слайды проблема/решение, в которых в решении всегда написано: "ну, как-то так, чтобы это решало условия возникновения проблемы". спасибо, Сергей, за отличный материал. случайно наткнулся, а смотрю с большим удовольствием. если бы мне 15 лет назад преподавали ооп так, работал бы сео, наверное ).
Давно искал подобных разъяснений о том, а что я же все-таки делаю не так?) Возможно я один такой, но чтоб почувствовать необходимость в распределении обязанностей в приложении пришлось понабить шишек, и собственноручно слепить пару десятков "God object" и, таки, столкнуться с тем что переиспользовать код(или не дай бог сменить какую-нить библиотеку, когда ее использование, как вы говорили, равномерно размазано как г...) стало геморроем всей жизни). Жаль что я не смог понять этого раньше. Спасибо за видео. Успехов!
индерекшн как бы намекает тебе, что наебаться в полиморфизме невероятно просто, а потом хлопает тебя по плечу и добавляет: "думай о маштабируемости системы".
Замечательно все рассказано, однако про Indirection я немного выпал в осадок.. имелось в виду когда нам жизненно важен класс А, а если нам плевать на класс А, то тогда мы с таким же успехом интерфейс со своей новой реализацией, какой нам нужно будем использовать у себя в классе.. ну тут ладно, короче говоря полиморфизм, pure fabrication и indirection это по сути об одном и том же.. благо в русском языке есть свои абстракции (называется "Эта фигня - та фигня") : в чем разница интерфейсов и абстрактных классов? - ни в чем нет разницы, все примерно одна фигня. что такое патерны? -чтобы эта фиговина не мешала другой фиговине, потомушо будет фигня. как всей это фигней пользоваться? -нафигачить кучу фигни для фиговин, и чтобы фигни и фиговин было не меньше, чем не нифига , но и не больше чем дофига короче, чтобы понять я начал записывать и рисовать))) спасибо за интересные мысли, самое интересное что именно к этой реализации я и приходил посоянно
Ну почему так мало вопросов в конце! У меня как раз вопрос про пример Indirection, где Сергей показывал пример Client и Server. Таймкод: 22:50 Получается этому принципу следует паттерн "Порты и Адаптеры"? Интерфейс IServer является портом внутреннего слоя, где находится класс Client, а конкретные реализации этого интерфейса внешними адаптерами? Еще вопрос, в каком пакете располагать класс Client и IServer, и в каком конкретные реализации интерфейса IServer? Из гексагональной архитектуры вычитал, что Client и IServer (порт) следует располагать в Domain слое т.к. это основная бизнес логика, а уже конкретные реализации интерфейса IServer (адаптеры) во внешних слоях? Нет никаких трудностей в написании классов и функционала приложения так сказать в лоб, а вот как это все архитектурно грамотно расположить и распределить... вот это очень интересная задача! Не смотря на дату видео, буду надеяться на получение ответа :-) Смотрю этот курс лекций и попутно рефакторю свой простенький учебный проект. Очень много нового и полезного узнаю в каждом видео! Хотел бы в живую присутствовать на лекции :-)
Пример который шел с полиморфизмом. Мне как-то на суппорт дали код с linq2sql (это было лет 10-12 назад). Все эти автоматически генеренные классы были раскиданы по всему коду. Эта вся срань дала проблемы с производительностью и пришлось менять страницы!!! (Asp.net web-forms) Яркий пример почему надо все таки оборачивать эти фреймворки по обращению к БД. И вообще, я в них вижу мало пользы, по правде. У многих из них проблемы с производительностью, да и чем плох SQL, его понимают все. Переключение разных БД (SQL server, oracle, etc) то конечно такое, не часто встречается.
Может конечно не очень удачный пример, но как я поняла это имеется ввиду под принципом чистой искуственности. Допустим проходит какая-то хим реакция и чтобы ее описать надо решить не линейную систему уравнений, нам с точки зрения реакции интересен только выход по продуктам и тепло, а как мы считаем в общем-то пофигу. В другой реакции нам опять нужен расчет системы, но часный случай, и тп. Так почему бы не создать класс математика, который соберет в себе чисто решение систем уравнений. Он на прямую вообще не знает о нашей предметной области, и интуитивно к ней не относится => является искусственным(обслуживающим)
Мини-дискуссию-разъяснение на 21:00 можно было ли объяснить тем,что первоначальный класс (B) ведёт за собой цепочку огромного количества обращений к другим классам(не видимых за кадром, так сказать), а Петькин класс (B1) уже не будет это делать? Или это не имеет разницы?
Для тех кому интересно почитать подробнее про Гексагональную архитектуру (habrahabr.ru/post/267125/), правда привязка к PHP, которую сформулировал Алистер Коберн (en.wikipedia.org/wiki/Alistair_Cockburn) на своем сайте (alistair.cockburn.us/Hexagonal+architecture), и из поста на хабре в комментах на английском интересный доклад Mathias Verraes (ruclips.net/video/ZJ63ltuwMaE/видео.html) по организации всесторонней защиты бизнес-логики (правда тоже с привязкой к PHP) + реализованный по этому принципу проект (github.com/norzechowicz/mydrinks)
+Иван Иванов Несмотря на то, что архитектура называется гексагональной, что должно указывать на фигуру с определенным количеством граней, основной мыслью все же является то, что граней у этой фигуры много. Каждая грань представляет собой «порт» доступа к нашему приложению или же его связь с внешним миром.
У меня немного каша. Маленькие объекты это хорошо, хорошо дробить по каждой логике на мелкие части (до разумного конечно), но при этом, дробя, мы тут же создаем большее число зависимостей (которые будут инклудится в класс), то есть следуя одному мы нарушаем другое (интересно получается). Значит надо сделать промежуточный класс, чтобы собрать некоторые классы в группу?? Ну мы же только что для этого раздробили. Бесконечный цикл. И не факт что это группа будет правильной (по смыслу да, по использованию нет). Конечно как ответ может быть то, что следует текущий класс разбить так же на мелкие части, но извините, так абстрагироваться (упрощать систему) не получиться. В общем это напоминает перетягивание одеяла (например та же ситуация с DI , тут нам говорят внутри создавай объект где он требуется, и тут же внедрение зависимостей решение всех бед, создавай объекты и решай зависимости в одном месте). Я понимаю слова автора о том, что паттерны не панацея и нужно думать, но советы, которые противоречат друг другу при первом же углубление - это уже не наука, а догма. Я так же могу создавать такие абстрактные паттерны - "ешь витамины в меру, мало витаминов - недостаточно. Много - плохо. Поэтому ешь в меру!!!" (Круто да? А разве я не прав? И получается, тот кто согласен, возрадует мой паттерн, а тот кто поймет, что его на...ли будет его осуждать, вива холивар!) В теории программирования явно имеются проблемы и эти проблемы в программистах, которые занимаются теорией больше чем практикой, печатая конвейерном книги о правильном коде. :)
+Sergey Nemchinsky Хороший вопрос от Евгения Гикс. Прямо картинка со связями от которой мы раньше(на этапе информ. эксперта) избавлялись вырисовалась в конце 1 занятия по GRASP, когда речь шла о мелких классах. Хотелось бы все же знать ответ, потому что проблема сформулирована, а вот задача "не формализуема", как ответил автор. Что значит "вручную - более чем исполнима" и почему не получается это озвучить. Спасибо.
Трудно согласиться, что полиморфизм упрощает программу. Наоборот имхо. Просто if из программы переносится на проверку уже во время runtime. Более того, if проверяется во время компиляции и выдаст ошибку до выполнения (я не защищаю множество вложенных if). В случае полиморфизма ошибка может выползти у клиента, при попытке создать класс, интерфейс которого устарел из за разных jar-файлов. Ну и вызвать метод на другом хосте можно. Для этого есть Remote Method Invocation или CORBA.
+Виктор Гиль да нет, не трудно. Лопатить код бизнес логики для того чтобы добавлять\модифицировать функционал гораздо сложнее (где эти зависимости? Что они должны были делать 6 лет тому назад, когда этот код писался?), нежели подменить какую-то формализованую рализацию зависимости за фасадом.
IMMLF Если бы вы когда нибудь работали программистом, то никогда бы не согласились переписывать бизнес логику. Потому что не пойманная вовремя ошибка в бизнес логике, означает убытки в сотни миллионов. Если бы вы были настоящим программистом, то знали, что для полной проверки логики, надо 2 в степени количества if в программе. А при 32 if это уже 4294967296 тестовых последовательности. И люди столько не живут, чтобы это проверить. И после этого вы утверждаете что легко перепишите бизнес логику, которая проверялась годами? Вас гнать надо, подальше от программирования имхо.
+Виктор Гиль вы не поняли то, что я написал, но поспешили кричать, что меня надо гнать подальше от программирования. Успокойтесь и прочитайте мой комментарий еще раз. Желательно вслух.
+Виктор Гиль Я имел в виду, что полиморфизм (как и принцип, так и паттерн) на архитектурном уровне таки упрощает построение программ (систем). Мне с этим легко согласится, а не трудно.
Прочитал несколько книг по ООП и только после просмотра лекций начал что-то понимать. Сергей, спасибо.
Низкий Вам поклон, Сергей! Лучший анализ/обзор паттернов и принципов, которые я видел/читал/слышал от коллег.
мне очень нравятся слайды проблема/решение, в которых в решении всегда написано: "ну, как-то так, чтобы это решало условия возникновения проблемы".
спасибо, Сергей, за отличный материал. случайно наткнулся, а смотрю с большим удовольствием. если бы мне 15 лет назад преподавали ооп так, работал бы сео, наверное ).
Очень полезные видео. Спасибо, огромное.
Странно, что так мало просмотров
Сергей, спасибо огромное за лекции, полезнейшая штука для самообучения!
Давно искал подобных разъяснений о том, а что я же все-таки делаю не так?) Возможно я один такой, но чтоб почувствовать необходимость в распределении обязанностей в приложении пришлось понабить шишек, и собственноручно слепить пару десятков "God object" и, таки, столкнуться с тем что переиспользовать код(или не дай бог сменить какую-нить библиотеку, когда ее использование, как вы говорили, равномерно размазано как г...) стало геморроем всей жизни). Жаль что я не смог понять этого раньше. Спасибо за видео. Успехов!
Огромное спасибо! Все доступно.
Спасибо
Качество хорошее - уже прилично! :-)
я так и не понял,чем полиморфизм отличается от индерекшен...а в остальном все прекрасно разжевано. спасибо за контент)
индерекшн как бы намекает тебе, что наебаться в полиморфизме невероятно просто, а потом хлопает тебя по плечу и добавляет: "думай о маштабируемости системы".
Замечательно все рассказано, однако про Indirection я немного выпал в осадок.. имелось в виду когда нам жизненно важен класс А, а если нам плевать на класс А, то тогда мы с таким же успехом интерфейс со своей новой реализацией, какой нам нужно будем использовать у себя в классе.. ну тут ладно, короче говоря полиморфизм, pure fabrication и indirection это по сути об одном и том же..
благо в русском языке есть свои абстракции (называется "Эта фигня - та фигня") :
в чем разница интерфейсов и абстрактных классов?
- ни в чем нет разницы, все примерно одна фигня.
что такое патерны?
-чтобы эта фиговина не мешала другой фиговине, потомушо будет фигня.
как всей это фигней пользоваться?
-нафигачить кучу фигни для фиговин, и чтобы фигни и фиговин было не меньше, чем не нифига , но и не больше чем дофига
короче, чтобы понять я начал записывать и рисовать)))
спасибо за интересные мысли, самое интересное что именно к этой реализации я и приходил посоянно
уррррааааа - новые видео
Ну почему так мало вопросов в конце! У меня как раз вопрос про пример Indirection, где Сергей показывал пример Client и Server. Таймкод: 22:50
Получается этому принципу следует паттерн "Порты и Адаптеры"? Интерфейс IServer является портом внутреннего слоя, где находится класс Client, а конкретные реализации этого интерфейса внешними адаптерами?
Еще вопрос, в каком пакете располагать класс Client и IServer, и в каком конкретные реализации интерфейса IServer?
Из гексагональной архитектуры вычитал, что Client и IServer (порт) следует располагать в Domain слое т.к. это основная бизнес логика, а уже конкретные реализации интерфейса IServer (адаптеры) во внешних слоях?
Нет никаких трудностей в написании классов и функционала приложения так сказать в лоб, а вот как это все архитектурно грамотно расположить и распределить... вот это очень интересная задача! Не смотря на дату видео, буду надеяться на получение ответа :-)
Смотрю этот курс лекций и попутно рефакторю свой простенький учебный проект. Очень много нового и полезного узнаю в каждом видео! Хотел бы в живую присутствовать на лекции :-)
Пример который шел с полиморфизмом. Мне как-то на суппорт дали код с linq2sql (это было лет 10-12 назад). Все эти автоматически генеренные классы были раскиданы по всему коду. Эта вся срань дала проблемы с производительностью и пришлось менять страницы!!! (Asp.net web-forms)
Яркий пример почему надо все таки оборачивать эти фреймворки по обращению к БД. И вообще, я в них вижу мало пользы, по правде. У многих из них проблемы с производительностью, да и чем плох SQL, его понимают все. Переключение разных БД (SQL server, oracle, etc) то конечно такое, не часто встречается.
Сергей, спасибо за ваши лекции. Хочу спросить, я часто использую дто для удобства, как правильнее поступать чтобы не нарушать паттерны?
9 весомых причин использовать интерфейсы)
Может конечно не очень удачный пример, но как я поняла это имеется ввиду под принципом чистой искуственности. Допустим проходит какая-то хим реакция и чтобы ее описать надо решить не линейную систему уравнений, нам с точки зрения реакции интересен только выход по продуктам и тепло, а как мы считаем в общем-то пофигу. В другой реакции нам опять нужен расчет системы, но часный случай, и тп. Так почему бы не создать класс математика, который соберет в себе чисто решение систем уравнений. Он на прямую вообще не знает о нашей предметной области, и интуитивно к ней не относится => является искусственным(обслуживающим)
примерно, да
Мини-дискуссию-разъяснение на 21:00 можно было ли объяснить тем,что первоначальный класс (B) ведёт за собой цепочку огромного количества обращений к другим классам(не видимых за кадром, так сказать), а Петькин класс (B1) уже не будет это делать? Или это не имеет разницы?
Я бы перевел Protected Variations как "Безопасное изменение".
Pure Fabrication, это Repository в DDD? 🤔
Для тех кому интересно почитать подробнее про Гексагональную архитектуру (habrahabr.ru/post/267125/), правда привязка к PHP, которую сформулировал Алистер Коберн (en.wikipedia.org/wiki/Alistair_Cockburn) на своем сайте (alistair.cockburn.us/Hexagonal+architecture), и из поста на хабре в комментах на английском интересный доклад Mathias Verraes (ruclips.net/video/ZJ63ltuwMaE/видео.html) по организации всесторонней защиты бизнес-логики (правда тоже с привязкой к PHP) + реализованный по этому принципу проект (github.com/norzechowicz/mydrinks)
+Иван Иванов Несмотря на то, что архитектура называется гексагональной, что должно указывать на фигуру с определенным количеством граней, основной мыслью все же является то, что граней у этой фигуры много. Каждая грань представляет собой «порт» доступа к нашему приложению или же его связь с внешним миром.
У меня немного каша.
Маленькие объекты это хорошо, хорошо дробить по каждой логике на мелкие части (до разумного конечно), но при этом, дробя, мы тут же создаем большее число зависимостей (которые будут инклудится в класс), то есть следуя одному мы нарушаем другое (интересно получается).
Значит надо сделать промежуточный класс, чтобы собрать некоторые классы в группу?? Ну мы же только что для этого раздробили. Бесконечный цикл. И не факт что это группа будет правильной (по смыслу да, по использованию нет).
Конечно как ответ может быть то, что следует текущий класс разбить так же на мелкие части, но извините, так абстрагироваться (упрощать систему) не получиться.
В общем это напоминает перетягивание одеяла (например та же ситуация с DI , тут нам говорят внутри создавай объект где он требуется, и тут же внедрение зависимостей решение всех бед, создавай объекты и решай зависимости в одном месте).
Я понимаю слова автора о том, что паттерны не панацея и нужно думать, но советы, которые противоречат друг другу при первом же углубление - это уже не наука, а догма. Я так же могу создавать такие абстрактные паттерны - "ешь витамины в меру, мало витаминов - недостаточно. Много - плохо. Поэтому ешь в меру!!!" (Круто да? А разве я не прав? И получается, тот кто согласен, возрадует мой паттерн, а тот кто поймет, что его на...ли будет его осуждать, вива холивар!)
В теории программирования явно имеются проблемы и эти проблемы в программистах, которые занимаются теорией больше чем практикой, печатая конвейерном книги о правильном коде. :)
+Sergey Nemchinsky
Хороший вопрос от Евгения Гикс. Прямо картинка со связями от которой мы раньше(на этапе информ. эксперта) избавлялись вырисовалась в конце 1 занятия по GRASP, когда речь шла о мелких классах.
Хотелось бы все же знать ответ, потому что проблема сформулирована, а вот задача "не формализуема", как ответил автор. Что значит "вручную - более чем исполнима" и почему не получается это озвучить.
Спасибо.
+Sergey Nemchinsky
Спасибо за ответ.
Вот только маркер посвежее бы..)) ничего не видно
Трудно согласиться, что полиморфизм упрощает программу. Наоборот имхо. Просто if из программы переносится на проверку уже во время runtime. Более того, if проверяется во время компиляции и выдаст ошибку до выполнения (я не защищаю множество вложенных if). В случае полиморфизма ошибка может выползти у клиента, при попытке создать класс, интерфейс которого устарел из за разных jar-файлов.
Ну и вызвать метод на другом хосте можно. Для этого есть Remote Method Invocation или CORBA.
+Виктор Гиль да нет, не трудно. Лопатить код бизнес логики для того чтобы добавлять\модифицировать функционал гораздо сложнее (где эти зависимости? Что они должны были делать 6 лет тому назад, когда этот код писался?), нежели подменить какую-то формализованую рализацию зависимости за фасадом.
IMMLF Если бы вы когда нибудь работали программистом, то никогда бы не согласились переписывать бизнес логику. Потому что не пойманная вовремя ошибка в бизнес логике, означает убытки в сотни миллионов. Если бы вы были настоящим программистом, то знали, что для полной проверки логики, надо 2 в степени количества if в программе. А при 32 if это уже 4294967296 тестовых последовательности. И люди столько не живут, чтобы это проверить. И после этого вы утверждаете что легко перепишите бизнес логику, которая проверялась годами? Вас гнать надо, подальше от программирования имхо.
+Виктор Гиль вы не поняли то, что я написал, но поспешили кричать, что меня надо гнать подальше от программирования. Успокойтесь и прочитайте мой комментарий еще раз. Желательно вслух.
IMMLF Если я ответил на ваш комментарий, значит читать умею. Потрудитесь тогда объяснить, что же вы имели ввиду?
+Виктор Гиль Я имел в виду, что полиморфизм (как и принцип, так и паттерн) на архитектурном уровне таки упрощает построение программ (систем). Мне с этим легко согласится, а не трудно.
Омг, что там за крестьяне на лекции сидят
Качество хорошее - уже прилично! :-)