Проектируем чашку, человека и метод "пить" 

Никогда ещё человек не пил так осознанно

Предлагаю разнести человека и чашку в разные микросервисы =)

Очень важна постановка задачи Сидит мужик, листает газету, видит объявление: Раскидать песок. 500₽ Позвонил, заказчик: - Придёшь, раскидаешь песок, заплачу 500₽, договорились? Мужик согласился. Приходит, а там 3 камаза песка. Говорит заказчику: - Тут 3 камаза песка, подними оплату Заказчик ни в какую. "Мы договорились, слово держи" Мужик взял жменю песка, швырнул в сторону и говорит: - Давай оплату - ?? - Мы не договаривались, что раскидаю весь песок

Отличное видео и подача. Очень хочется ещё подобных видео

Такой контент я давно искал. Но ютуб считает что в рекомендации лучше положить как 8 лет назад Камаз утонул

Задача кажется слишком абстрактной, по этому ее так не просто решить. Тут следует уточнить для чего мы моделируем данную систему. К примеру это может быть симулятор процессов организма человека или Игра, где человек может пить. И для каждого типа системы следует подбирать подходящую модель.

Хотели банан, а получили гориллу с бананом в джунглях. Реализация огонь 🔥

Реализовывал бы эту задачу первым, самым быстрым и простым способом. Если бы появлялись новые требования, переписывал бы код, двигаясь к последнему способу по мере необходимости. Новые требования могут и не появиться, а мы сделаем 10 уровней абстракций, которые нам не понадобятся.

Не хватает примера реализации кодом в итоге. Вроде понятно, но вдруг не так понял.

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

В начале видео говорится, что необходимо спроектировать ситуацию в ооп парадигме. На самом деле получилась анемичная модель, которую дергает контроллер. Мало того что паттерн mvc предполагает логику размещать в моделе, а не в контроллере, так ещё и нарушается один из главных принципов ооп дизайна - information expert. Контроллер управляет состоянием чашки и человека, вместо самих сущностей. Полученное решение напоминает паттерн transaction script

Конечно тут представлен простой пример, но мне кажется он отражает суть современной разработки. Можно гнаться сколь угодно за принципами и паттернами, но когда вы попадаете в среду, где предметная область для вас в новинку, а требования и сроки уже обозначены, вы будете проектировать архитектуру под текущие требования так, как вам кажется правильно. При этом вы еще n-ое количество раз будете пересматривать свои наработки. А когда вам покажется, что вы все контролируете, то появится требование, осознав которое, вы прошепчете у себя в голове: "*лядь, как я сразу это не учел?"

Побольше таких нужно, спасибо!

Предлагаю объединить сущность сосуд и человек Человеко-сосуд Тогда человек может пить из другого человека хоть до бесконечности

Каждое видео очень воодушевляет. Спасибо за ёмкое объяснение таких тонких (особенно для новичков) моментов! 😌

Спасибо за видео! Прекрасный формат видео (рубрика)! Лайк

Классный разбор! Спасибо за труды) на самом деле на таких абстрактных, но близких к реальному миру, вещах интересно пробовать учиться проектировать. Такое упражнение для мозга)

Потрясающая🌞 подача материала 🌞 Понятно даже мне

Очень понятное обяснение не только про проектирование, но и про применение ратернов, очень классно!)

Отличный материал, хотелось бы продолжения. Спасибо

Прекрасное видео!! 👍🏻 Благодарю!! Всё предельно понятно!! 😊

Очень полезное видео! Спасибо за информацию.

Первый раз в жизни увидел настолько крутое объяснение mvc, продолжайте, у вас потенциал, с удовольствием послушал бы и про другие паттерны.

Чисто доступно и понятно. + за продолжение подобных видео.

Спасибо! Очень интересно по содержанию. Очень круто по визуалу!

Весьма поучительно, спасибо!

Очень круто!!! Спасибо огромное за контент)

Круто! Спасибо за видео. Буду использовать

Спасибо, очень интересно было посмотреть

Первый видос который досмотрел до конца. Оооч интересный формат :)

Очень круто ! Впринципе ничего сложного если правильно начинать с самого начала. Почаще нужны такие видео. Это приблизительно тоже самое как осваивание речи у малых детей. Звуки. Буквы. Слова. ...

Для полного разрыва шаблона после Лисков и SRP новичку следует изучить принцип KISS

Очень полезное видео! Много в чем разобрался.

Спасибо за видео, классный ролик

Спасибо, было интересно! Не хватило только визуализации в виде кода.

Отличный пример как программист вместо решения задачи сразу пишет свой фреймворк. Если не известны вектора развития компонентов этого решения то и усложнять не надо. На третьем добавлении схожего функционала сразу обозначится вектор, и надо будет только его учесть. В итоге меньше кода, и он будет отражать предметную область, а не непонятные фантазии программистов (замечу, программистов много, а проект один, а значит проще понимание кода проекта). А также проще отрефакторить код одного экрана, чем 10 файлов. P.S. Кстати, в третьем решении вся сложность будем в этом контроллере, где придётся обрабатывать, что лошадь не пьёт из стакана, а только из ведра, попахивает кучей if-ов, или ещё одним паттерном на 10 файлов.

You Ain’t Gonna Need It. Делать нужно то, что нужно, то что стоит в задаче, а то, чего в задаче нет, делать не нужно. А если когда-то заказчик что-то поменяет, то он заплатит за новую задачу. А нам опять нужно будет делать только то, что нужно, то что в задаче... Жду новое видео!

Вот это я ппозрел)) Видео просто топ! Вот бы еще разобрать на примерах)

Первое видео про ООП, которое я нашел для себя очень интересным

После этого видео мне кажется я стал хуже понимать ООП и задался вопросом, а понимал ли вообще.

Второму видео точно лайк за продолжение первого, за оба.

Браво, шикарно рассказал

Видео точно отражает три стадии мучения программиста при получении новой задачи: 1) и так сойдет 2) а что если?... 3) господи, что ЭТО?!!!

Классное видео, спасибо)

Интересно!!

То есть у человека будут открыты методы изменяющие его состояние при питье, без самого питья?

Лукас и коммент в поддержку автора канала!)

За такой подробный разбор спасибо. Правда, спасибо. Задача хоть и простая, но повзволяет сразу увидеть, как мыслит человек. Я бы первым своим решением-приближением сделал бы функцию типа human_drink_from_cup() нарочно без классов. Всё-таки задача стояла примитивная, а мы начали фантазировать, а что будет если...

Какое название контроллера посоветуете для 3го варианта реализации? humanVessalController с функцией drink()

Супервидос, спасибо

Тю, по факту ты пришел к 2xDTO да ActionHandler, можно даже прикрутить третью DTO, которая описывает саму жидкость и "переливать" её из одной ДТО в другую. Но! Ты правильно заметил в самом начале, что очень важно "можем ли мы изменять систему", потому что иногда такое вот усложнение просто нерационально и не имеет смысла, если ты точно уверен, что никаких векторов развития никуда и никогда не будет в обозримом будущем, а нужно просто сделать в лоб и забыть. Типичная проблема программистов - когда просят построить садовую тачку, мы, по привычке, закладываем в конструкцию возможность расширения для реализации полётов на ней в космос с табором цыган на борту.

Спасибо 🙌🔝

Очень неожиданная концовка, смотрел с упоением. Спасибо.

Дядя Боб? Вы здорово выглядите)

я бы очень хотел больше подобных роликов, пусть в них будет говориться одно и тоже, желательно конечно усложнение проекта, которого нам дают, но стольже просте объяснение

Прикольно, спасибо!

Круто, спасибо

Клево, когда можно посмотреть контент в котором вообще ничего не понятно, но реально интересно

5:30 Хорошее объяснение интерфейса..,.... 5+!

Super!😁😁😁😉 А это нормально если мы сделаем следующую иерархию интерфесов для класса кружки: > INTERFACES СпособныйСодержатьЖидкостьИнтерфейс (из шланга воду льют нам прямо в рот, то есть воздушная среда, способная содержать жидкость) ^ УглублениеИнтерфейс (жидкость в лужах) ^ СосудИнтерфейс (классы: кружек, бутылок) < INTERFACES Таким образом: class UserActionControllerInterface { function drink(человекИнтерфейс, СпособныйСодержатьЖидкостьИнтерфейс); } Ок?

soer, ты Большой Человек)

Хотелось бы увидеть пример реализации класса, представляющего процесс пития.

Спасибо

Подскажите, что используется для рисования на фоне какого-то контента на экране

Забавно смотреть как java-ООП продается программистам как универсальное средство в котором можно мешать котлеты и мухи, а потом эти же программисты всеми правдами и неправдами пытаются отделить котлеты от мух, но на уровне архитектуры :)

Так выходит, что human не человек, а кукла, который не может сам пить, а нужно, чтобы кто-то поил

Имхо. Проблема третьего варианта в том, что там нет ООП. Это называется анемичная модель, где у нас есть сервисы, они являются чем-то вроде процедур, а есть ентити, которые просто тупые стракты. Проблема такого подхода, что у нас нет как таковой объектной модели и мы любым случайным сеттером

Сущность Существо. Сущность Емкость. Сущность Жидкость. Все наследуется от этих глобальных классов. человек корова, бутылка чашка корыто. вода чай ром. Это первое что пришло мне в голову.. Больше такого материала! Очень круто!

3:00 Не совсем понятно, а почему нарушается LSP если мы даже не видим реализации? Вдруг код написан так, что замена Cup > Bottle и наоборот ничего не поломает в коде, а значит LSP нарушен не будет?

Скажите пожалуйста, а в какой программе вы рисуете?

Круто.👍

Очень правильно все изложено, но не согласен с аналогией с MVC. MVC - это все-таки другое (ну контроллер точно в данном случае должен быть заменен на бизнес логику), а тут чистая 3-ех слойная архитектура - UI, бизнес логика (BL), и data access layer (DAL)

А второй способ позволит реализовать изменение стейтов обоих объектов в транзакции? 🧐

А действие даже не "пить", а скорее "перелить" из IVessel в IVessel. Тогда можно будет и из чайника в чашку перелить, а потом уже в человека

Подскажите книги по паттернам проектирования

Я запутался. А чем тогда это отличается от "entity component system" ?

Лучший!

Класс! Спасибо, а то вечно не учтенка возникает при расширении

Спасибо! за разбор. Но жаль, что нет UML-диаграмм.

3 вариант похож на то как это принято в Golang. Есть 2 интерфейса и функция обеспечивающая их взаимодействие. Ошибки пробрасываются наружу для обработки.

Когда меня спросят почему я люблю процедурный стиль - я покажу это видео

Получается интерфейс IDrinkable будет иметь методы взятия состояния? Типа get_liquid(int count) и другие...

супер

Всегда стараюсь делать как в последнем варианте. При дальнейшем развитии системы, когда "инфраструктура" уже готова можно извращаться как угодно, подменяя само описание взаимодействия через стратегию. Написать переливание из чашки в другую чашку или высасывание мозгов человека другим человеком можно будет относительно быстро и красиво.

класс👍

Не могу не отметить, что разбиение на 3 уровня также есть и в различных системах автоматизации и если абстрагироваться от конкретного назначения каждого из уровней, то они часто и по духу совпадают с MVC. Видимо удачное количество для декомпозиции.

что-то про MVC Остапа понесло). Это просто две модели, взаимодействующие между собой через интерфейс

Осталось сделать последний шаг - избавиться от состояний. Т.е. заменить "action" на функцию и заменить интерфейсы алгебраическими типами. И вот уже нормальная функциональная модель, без всяких костылей. Кстати, в первом примере полиморфизм тоже есть - ad-hoc polymorphism.

Уважаемый S0ER, есть вопрос. Не совсем понятны в вашем варианте интерфейсы человека и ёмкости. Насколько я понял, предполагается, что у человека есть метод наподобие Drink(liquidType, volume), а у ёмкости метод получения её содержимого? Или команда (а насколько я понимаю, здесь использован именно этот шаблон) Drink просто в лобовую меняет состояние человека через get/set? Но тогда человек получается какой-то весьма анемичной моделью данных, которая уже ничего не инкапсулирует. Так же непонятно, как решается проблема "раздувания" модели человека - ведь каждая новая команда может влиять на совершенно разные детали состояния человека, и их число также будет расти. Насколько я понимаю, если заказчик хочет интенсивно расширять модель влияний на человека, то что-то всё равно будет раздуваться. В таком случае, возможно, ситуацию бы несколько упростил паттерн Состояние, только в модели человека был бы не один экземпляр состояния, а несколько (по количеству интересующих нас, как разработчиков, органов). Т.е. у каждого органа - своя сущность, а модель человека стала бы агрегатом в терминах DDD.

Интерфейс не наследуется, он реализуется.

хочу увидеть как все эти рассуждения будут применены для создание игры на юнити, где будет человек, и он будет пить и всё это с этими концепциями. и показать на практике как добавлять новый функционал в программе

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

Правильно ли понимаю, что в итоге будет еще один класс, например на клиентском уровне, который говорит, что этому человеку нужно попить из этого сосуда, и вызывает метод контроллера передавая туда человека и сосуд ?

Спасибо за видео. Пора уже на патреон подписываться. Контент очень качественный. Жень, а смотри какая штука получается с этим mvc. Вроде все у нас объектно-ориентированное и по всем Solid и прочее. Но это все красиво работает когда состояние объекта в памяти долго висит. Чаще же нижний слой с состоянием уже хранится в сторедже каком то. И тут как возникает тема, что фактически у нас остаётся только метод перегонки из одного состояния в другое. И почему бы не взять для этого функциональный язык или какой то более функциональный подход. Вот все больше всяких апи и микро сервисов пишется, которые просто данные перегоняют, и по факту мы просто функцию оборачиваем в класс, в котором нам больше ничего не надо. И внимание вопрос, зачем тогда вообще класс и ООП в таких проектах

Понравилось видео, MVC подходом реализации задачи впечатлён.

А код можно увидеть? Который родился как результат проектирования.

9:30 в cataclysmDDA именно так и сделали. Всё тупо повешали на player.

Почувствовал себя очень умным, т.к. подумал об model-controller сразу при постановке задачи. Либо реализовать через dependency injection, если у нас во главе проекта стоит human

ВАУ

Хотелось бы увидеть решение этой задачи в стиле Типажей и Структур как в Rust. Будет ли это проще?