Проектируем чашку, человека и метод "пить"
Vložit
- čas přidán 14. 04. 2021
- #soer #itubeteam
Основной канал для общения и публикации новых видео - Телегарм - t.me/softwareengineervlog
Спонсорство - donate.s0er.ru
Сайт платным контентом - soer.pro
Зеркало для видео Дзен Видео - zen.yandex.ru/id/5f578bdf22e2...
GitHub - github.com/soerdev
Чат для программистов - / discord
Группа ВК - codeartblog
Никогда ещё человек не пил так осознанно
Ахахах +++
😂🤔
😂😂😂
Предлагаю разнести человека и чашку в разные микросервисы =)
Очень важна постановка задачи
Сидит мужик, листает газету, видит объявление: Раскидать песок. 500₽
Позвонил, заказчик:
- Придёшь, раскидаешь песок, заплачу 500₽, договорились?
Мужик согласился.
Приходит, а там 3 камаза песка. Говорит заказчику:
- Тут 3 камаза песка, подними оплату
Заказчик ни в какую. "Мы договорились, слово держи"
Мужик взял жменю песка, швырнул в сторону и говорит:
- Давай оплату
- ??
- Мы не договаривались, что раскидаю весь песок
надо было NDA подписывать
"Рабинович с одной стороны и Одесское пароходство с другой..." (с) анекдот
@@roman-bolkhovitin хD
@Старший Санитар " - Если хоть кому-то расскажешь, что мы тут самосвалы с песком разгружаем на халяву - Мы быстро тебе жизнь подпортим. "
@@dmtpp он пример тебе показывает, а ты язвишь, негодяй
Отличное видео и подача. Очень хочется ещё подобных видео
Согласен. С таким объяснением даже новички без особого труда поймут смысл ооп.
Согласен. Мне тоже не хватает такой информации.
Такой контент я давно искал. Но ютуб считает что в рекомендации лучше положить как 8 лет назад Камаз утонул
Задача кажется слишком абстрактной, по этому ее так не просто решить. Тут следует уточнить для чего мы моделируем данную систему. К примеру это может быть симулятор процессов организма человека или Игра, где человек может пить. И для каждого типа системы следует подбирать подходящую модель.
Дело в том, что любая задача которую нужно запрограммировать должна в конечном итоге совершать какие-либо I/O операции, иметь side-эффекты.
Это должен быть вывод на экран, запись на диск и передача данных по сети, вывод звука.
Задача должна быть сформулирована в этих терминах, иначе это это очередной фейк, и подмена понятий.
Так происходит с каждым ООП-туториалом, потому что ООП, так получается, крайне скверно ложится на то чтобы задача была описана в терминах того что должен сделать компьютер, вот и приходится придумывать манявселенную с человек.пить и прочими мяукающими котами и гавкающими собаками.
В реальности получаются Фабрики.СделатьАбстрактныйОбъект и Менеджеры.ЗапуститьПроцесс2
Хотели банан, а получили гориллу с бананом в джунглях.
Реализация огонь 🔥
Реализовывал бы эту задачу первым, самым быстрым и простым способом.
Если бы появлялись новые требования, переписывал бы код, двигаясь к последнему способу по мере необходимости.
Новые требования могут и не появиться, а мы сделаем 10 уровней абстракций, которые нам не понадобятся.
Оно конечно здорово, когда тебе это не нужно будет поддерживать и расширять.
Сделать на коленке фундамент из дерьма и палок, чтобы хоть как-то, а потом удивляться - Что же это разработка стала такой дорогой и долгой.
Норм, я бы взял 2 вариант, для тестов, которые не пишу.
А по поводу обновления стейта человека подумать надо, чтобы он не стал анемичной моделью которая работает только через сервисы, но и сам по себе что то мог.
Не расширял и не переписывал бы, а просто перешёл бы на другой проект. А на этот проект пришёл бы какой нибудь другой разработчик, от которого бы потребовалось расширить функционал. И тот бы сначала схватился за голову и стал переписывать то, что уже написано (надеюсь, что третьим способом, но не факт), при этом срывая дедлайны, работая овертайм и делая заказчика очень недовольным. А теперь представь, что второй человек - это ты. (А первый был кодер из Индии.)
@@konstantinkouptsov7513 как же жизненно
Вот где становится явной важность корректности и полноты требований к задаче. При простой постановке задачи - есть Человек, который Пьет из Кружки, явно нужно использовать первый вариант. Просто другие варианты противоречат KISS и YAGNI.
Не хватает примера реализации кодом в итоге. Вроде понятно, но вдруг не так понял.
Любой проект на java spring открой)
Это конечно весело, но на деле усложнение системы.Все же помнят про KISS и бритву Оккама. Вот мы заложили эту возможность расширения системы, хорошо, а расширения - никогда не произошло, но кодовая база стала сложнее для понимания новым разработчика и они уже чтобы решить задачу по добавлению новой логики - тратят не 10 минут, а 2 часа, потому что в реальных проектах будет на DrinkController, а какая-нибудь монструозная фигня, с фасадами, прокидыванием событий, мостами, медиаторами, декораторами фабриками и прочим-прочим и чтобы добраться уже до самой логики - придется нехило постараться.
В общем. На мой взгляд - второй вариант - неидеален, но он прост, он довольно расширяем, а главное он не прячет логику за отдельной сущностью. Опять же, тут пример довольно простой, но ведь взяв на вооружения подобные принципы - люди начинают все декомпозировать-декомпозировать, выделять сущности(вот вам выпивака, закусака и наливака, а вместе они образуют студента), выделять интерфейсы, в итоге куча каких-то кусков логики лежат в воздухе а как оно собственно работает - может понять только тот кто это написал(и то не факт), либо человек, которому не жаль было потратить неделю времени.
Так фреймворки же берут на себя всю грязную работу, никто с нуля не пишет. Или вы пишете?
@@S0ERDEVS В веб-разработке, скорее всего, никто с нуля не пишет, но есть множество других доменов. Например готовые фреймворки для автомобильной индустрии мне не известны. Однако там так же успешно используются и микро сервисы, и MVC, и дизайн паттерны.
поэтому сначала рисуются схемы из которых сразу понятно, что с чем взаимодействует и куда вносить изменения. И не придется десятки тысяч строк кода вычитывать, прыгая по файлам, каждый раз. Если схем нет, то надо в первую очередь их сделать. а потом уже браться за изменения. Иначе, нередко дешевле будет заново переписать на современный лад.
В начале видео говорится, что необходимо спроектировать ситуацию в ооп парадигме. На самом деле получилась анемичная модель, которую дергает контроллер. Мало того что паттерн mvc предполагает логику размещать в моделе, а не в контроллере, так ещё и нарушается один из главных принципов ооп дизайна - information expert. Контроллер управляет состоянием чашки и человека, вместо самих сущностей. Полученное решение напоминает паттерн transaction script
нет, ты путаешь модель и сущность. Доменную модель с доменной логикой, контроллером, моделью данных. Модель может быть пакетом (слоем), в котором есть отдельные доменные модели и отдельные бизнес-правила. Контроллер уже предоставляет методы, формализующие пользовательские запросы, отделяя интерфейс (GUI) от реализации (данных и бизнес-правил). Есть и другой вариант MVVM, там без контроллера, каждой пользовательской страничке присуща некоторая бизнес-сущность.
Вообще, модель данных как раз должна быть максимально простой (плоской), без поведения., обычно хранится в базе в виде таблиц. На ее основе уже можно создавать сущности (через интерфейс) с поведением, которые и будут реализовывать присущую только им логику. А в случае на видео, логика не относится к одной сущности, бизнес-действие должно поменять состояние сразу нескольких объектов. Поэтому его нельзя приписывать к этим сущностям.
Конечно тут представлен простой пример, но мне кажется он отражает суть современной разработки. Можно гнаться сколь угодно за принципами и паттернами, но когда вы попадаете в среду, где предметная область для вас в новинку, а требования и сроки уже обозначены, вы будете проектировать архитектуру под текущие требования так, как вам кажется правильно. При этом вы еще n-ое количество раз будете пересматривать свои наработки. А когда вам покажется, что вы все контролируете, то появится требование, осознав которое, вы прошепчете у себя в голове: "*лядь, как я сразу это не учел?"
Поэтому Роберт Мартин топит за TDD, чтобы можно было делать безболезненный рефакторинг.
@@user-in6wn6up1s Как тесты, написанные для 1 варианта помогут сделать безболезненный рефакторинг в последний вариант? :) Да там процентов 90 тестов надо будет переписывать, и еще неизвестно сколько писать новых :)
Тесты нужны при точечных доработках и расширении системы скорее, нежели при глобальном рефакторинге.
@@dmitriyobidin6049 никак, если изменились интерфейсы и разделение на модули, то и тесты придется переписать. Но по крайней мере тесты провоцируют писать более мелкие и узкоспециализированные модули. Просто если у нас весь проект состоит не только из этих двух классов, а есть что-то еще, то тесты позволят убедиться, что остальный проект не сломается, пока мы переписываем эти два класса с тестами на них.
Побольше таких нужно, спасибо!
Предлагаю объединить сущность сосуд и человек
Человеко-сосуд
Тогда человек может пить из другого человека хоть до бесконечности
это уже система вампиризма
Да! И тогда можно будет не только пить человеку, но и даже переливать из бутылки в чашку.
ты про свою жену?
Каждое видео очень воодушевляет.
Спасибо за ёмкое объяснение таких тонких (особенно для новичков) моментов! 😌
Спасибо за видео! Прекрасный формат видео (рубрика)! Лайк
Классный разбор! Спасибо за труды) на самом деле на таких абстрактных, но близких к реальному миру, вещах интересно пробовать учиться проектировать. Такое упражнение для мозга)
Потрясающая🌞 подача материала 🌞
Понятно даже мне
Очень понятное обяснение не только про проектирование, но и про применение ратернов, очень классно!)
Отличный материал, хотелось бы продолжения. Спасибо
Прекрасное видео!! 👍🏻 Благодарю!! Всё предельно понятно!! 😊
Очень полезное видео! Спасибо за информацию.
Первый раз в жизни увидел настолько крутое объяснение mvc, продолжайте, у вас потенциал, с удовольствием послушал бы и про другие паттерны.
Чисто доступно и понятно. + за продолжение подобных видео.
Спасибо! Очень интересно по содержанию. Очень круто по визуалу!
Весьма поучительно, спасибо!
Очень круто!!!
Спасибо огромное за контент)
Круто! Спасибо за видео. Буду использовать
Спасибо, очень интересно было посмотреть
Первый видос который досмотрел до конца. Оооч интересный формат :)
Очень круто !
Впринципе ничего сложного если правильно начинать с самого начала.
Почаще нужны такие видео.
Это приблизительно тоже самое как осваивание речи у малых детей.
Звуки.
Буквы.
Слова.
...
Для полного разрыва шаблона после Лисков и SRP новичку следует изучить принцип KISS
Очень полезное видео! Много в чем разобрался.
Спасибо за видео, классный ролик
Спасибо, было интересно! Не хватило только визуализации в виде кода.
Отличный пример как программист вместо решения задачи сразу пишет свой фреймворк. Если не известны вектора развития компонентов этого решения то и усложнять не надо. На третьем добавлении схожего функционала сразу обозначится вектор, и надо будет только его учесть. В итоге меньше кода, и он будет отражать предметную область, а не непонятные фантазии программистов (замечу, программистов много, а проект один, а значит проще понимание кода проекта). А также проще отрефакторить код одного экрана, чем 10 файлов. P.S. Кстати, в третьем решении вся сложность будем в этом контроллере, где придётся обрабатывать, что лошадь не пьёт из стакана, а только из ведра, попахивает кучей if-ов, или ещё одним паттерном на 10 файлов.
То есть надо всё переписывать, когда станет известно. Ну ок..
1. Давно уже придумали фреймворки. Там все что нужно для 3-го варианта реализовано, генераторы кода есть и прочие "плюшки".
2. Вы про полиморфизм слышали? Например, ad-hoc полиморфизм без всяких if-ов вызовет вам нужную реализацию, если же про языки с утиной типизацией и поддержкой мультипарадигм, то там есть замечательные декларативные подходы вместо if/switch, которые используют функции первого порядка. Да и контроллер может существовать не в одном варианте, если речь про модульный подход, то можно конфигурировать модуль, использовать DI и т.д. Короче нет там никаких "кучи if-ов". Было бы желание думать, а не решений полно.
@@crutchmaster9637 лично мне проще переписать 10 строк кода, а не 10 файлов. А Вам?
@@user-zg4dv7xf6t Строк кода минимум на тысячу надо умножить и подумать еще раз.
@@S0ERDEVS Вы комментируете 3-е решение в абстрактном вакууме, а не в реальном проекте, где что-то меняется, в задаче изначально неправильный акцент выставлен, что-то неизвестно на момент первых итераций, когда программисты уходят и болеют, ищутся баги по куче файлов, человек пытается уложить в голову логику. Это решение вообще это всё игнорирует. Понятно, что где-то такой подход реально отлично ложится и спасает от проблем в будущем, но не в случае рядовой задачи "попить воды".
Примеры уж тогда надо подбирать более корректней, чтобы не было иллюзий, что там где есть решение в одну строку, надо генерировать кучу новых файлов и новых абстракций
You Ain’t Gonna Need It. Делать нужно то, что нужно, то что стоит в задаче, а то, чего в задаче нет, делать не нужно. А если когда-то заказчик что-то поменяет, то он заплатит за новую задачу. А нам опять нужно будет делать только то, что нужно, то что в задаче... Жду новое видео!
И, однажды, на требование добавление нового сосуда, заказчик услышит сумму в 100500 человеко-часов и пошлет Вас и Ваш подход далеко-далеко
@@user-zh5xl9bb8z на это есть другие приемы работы. Например "если общий код встречается 3 и более раза, то нужно обобщить и переиспользовать".
Цифра 3 может меняться в зависимости от, но метод довольно полезный как средство сдерживания и оверинжиниринга, и повторения кода.
Вот это я ппозрел))
Видео просто топ! Вот бы еще разобрать на примерах)
Первое видео про ООП, которое я нашел для себя очень интересным
После этого видео мне кажется я стал хуже понимать ООП и задался вопросом, а понимал ли вообще.
Соер сам не понимает ООП, ещё и людям пытается что-то обяснять. ваша ошибка в том что вы почему-то воспринимаете слова Соер как правду
@@pin689 никто не понимает ООП, только думают, что понимают. И у каждого свой ООП
Второму видео точно лайк за продолжение первого, за оба.
Браво, шикарно рассказал
Видео точно отражает три стадии мучения программиста при получении новой задачи: 1) и так сойдет 2) а что если?... 3) господи, что ЭТО?!!!
нет там ни каких стадий мучений, с опытом ты клепаешь эти интерфейсы и классы по 50+ штук в день не задумываясь. паттерн простейший - стратегия. про то что метод пить должен иметь единственную ответственность так же прозрачно.
Классное видео, спасибо)
Интересно!!
То есть у человека будут открыты методы изменяющие его состояние при питье, без самого питья?
Лукас и коммент в поддержку автора канала!)
За такой подробный разбор спасибо. Правда, спасибо. Задача хоть и простая, но повзволяет сразу увидеть, как мыслит человек. Я бы первым своим решением-приближением сделал бы функцию типа human_drink_from_cup() нарочно без классов. Всё-таки задача стояла примитивная, а мы начали фантазировать, а что будет если...
Какое название контроллера посоветуете для 3го варианта реализации? humanVessalController с функцией drink()
Супервидос, спасибо
Тю, по факту ты пришел к 2xDTO да ActionHandler, можно даже прикрутить третью DTO, которая описывает саму жидкость и "переливать" её из одной ДТО в другую. Но! Ты правильно заметил в самом начале, что очень важно "можем ли мы изменять систему", потому что иногда такое вот усложнение просто нерационально и не имеет смысла, если ты точно уверен, что никаких векторов развития никуда и никогда не будет в обозримом будущем, а нужно просто сделать в лоб и забыть. Типичная проблема программистов - когда просят построить садовую тачку, мы, по привычке, закладываем в конструкцию возможность расширения для реализации полётов на ней в космос с табором цыган на борту.
😂
Спасибо 🙌🔝
Очень неожиданная концовка, смотрел с упоением. Спасибо.
Дядя Боб? Вы здорово выглядите)
я бы очень хотел больше подобных роликов, пусть в них будет говориться одно и тоже, желательно конечно усложнение проекта, которого нам дают, но стольже просте объяснение
Прикольно, спасибо!
Круто, спасибо
Клево, когда можно посмотреть контент в котором вообще ничего не понятно, но реально интересно
5:30 Хорошее объяснение интерфейса..,.... 5+!
Super!😁😁😁😉
А это нормально если мы сделаем следующую иерархию интерфесов для класса кружки:
> INTERFACES
СпособныйСодержатьЖидкостьИнтерфейс (из шланга воду льют нам прямо в рот, то есть воздушная среда, способная содержать жидкость)
^
УглублениеИнтерфейс (жидкость в лужах)
^
СосудИнтерфейс (классы: кружек, бутылок)
< INTERFACES
Таким образом:
class UserActionControllerInterface
{
function drink(человекИнтерфейс, СпособныйСодержатьЖидкостьИнтерфейс);
}
Ок?
soer, ты Большой Человек)
Хотелось бы увидеть пример реализации класса, представляющего процесс пития.
@@dmtpp Чтобы делать сложные и масштабные вещи, необходимо досконально постичь азы. Чтобы написать Войну и Мир, нужно сначала изучить азбуку, освоить слова и составление предложений. Эти вещи показательны. Я решил бы вопрос почти так же, но без класса-посредника, реализующего процесс пития. Мне вот и интересно как он будет реализован, будет ли агрегатом или композитом человека, а может вообще будет унаследован от глобальной божественной сущности Бахуса?
@@redserjogha класс может быть реализован как действие, где сначала читается состояние кружки и в соответствии с ним изменяется состояние человека. Это действие, опционально, так же может выбрасывать событие, что оно произвело процесс опорожнение кружки и наполнение жидкостью человека. В последствии, все кто слушали это событие, могут начать своё действие, например: проверка на то, что именно было выпито и вызов соответствующей реакции (ухудшение самочувствия или его улучшение, гипотермия/гипертермия, отравление/излечение, восстановление водного баланса или же дегидратация организма).
@@IgorLynn вы не. Observer описали в своем примере?
@@evgenasd8892 да, но он опционален. Суть в том что мы вводим третью сущность и она просто меняет состояние двух моделей.
У меня когда-то была похожая проблема, где было 2 космических корабля и они могли друг друга атаковать и наносить урон. Дилемма была в том, что не понятно у кого должно быть право наносить урон; должен ли атакующий корабль содержать метод DealDamage() и отнимать прочность/щиты у корабля которого он атакует или корабль который получает урон, должен содержать метод ReceiveDamage() и решать какой урон ему может нанести атакующий его корабль? По факту же, ни у кого из них не должно быть такой привилегии и доверия.
@@IgorLynn спасибо
Спасибо
Подскажите, что используется для рисования на фоне какого-то контента на экране
@@patrickowens7665 я спрашивал, что использует именно автор в своих роликах.
А не твое мнение идиота.
Забавно смотреть как java-ООП продается программистам как универсальное средство в котором можно мешать котлеты и мухи, а потом эти же программисты всеми правдами и неправдами пытаются отделить котлеты от мух, но на уровне архитектуры :)
Жаба-ооп - это такая религия. (У них там даже есть должности евангелистов) Вот, кто-то проповедовал, кто-то уверовал, а потом выясняется, что земля не плоская.
Так выходит, что human не человек, а кукла, который не может сам пить, а нужно, чтобы кто-то поил
В некоторых книжках пишут, мол, ООП нужен ещё и для того, чтобы не абстрагироваться от реального мира и что обычному человеку легче мыслить в рамках ООП. Чем больше изучаю, тем больше понимаю, что это не так. ООП становится всё дальше от реальности.
@UCYB1-bWEzfKGTBSt6a5YoHw а ведь реально, если посмотреть на весь процесс инициализации (рождения) нового экземпляра человека (разных классов / национальностей и тп, унаследованных об супер-классов вверх по иерархии), то инстинкты - это firmware запрограммированный в контроллере физобъекта (с помощью биодисков- генов), а обучение в процессе жизни - это натаскивание его нейронной сетки через звуковые, световые и прочие интерфейсы (рефлексы как драйверы соответствующих IO-девайсов у человека);
языки общения тоже разные у разных групп людей (но все так или иначе компилируются в некий гуманоидный IL низкого уровня), шины (СМИ, племенные и родовые связи) и брокеры сообщений тоже имеются - и многие великие "менеджеры (ака манипуляторы)" давно эти фреймворки выучили :))
весь "гософициоз" с его законами и документами очень уж филофоски напоминают xml
@@fj8017 класс Human - это не человек, а некоторый "представитель" человека в нашей системе. И так получается, что представители не обязаны разделять свойств и отношений тех, кого представляют. Например, есть муж и жена, которые разводятся, а есть адвокаты - их представители в этом процессе. Маловероятно, что адвокаты тоже разводятся при этом. Или классический пример с наследованием квадрата от прямоугольника отражает тот же феномен.
Поэтому я бы не стал утверждать, что объекты в ООП так уж далеки от реальности. Просто мы оперируем не самими объектами, а их поведением.
Имхо. Проблема третьего варианта в том, что там нет ООП. Это называется анемичная модель, где у нас есть сервисы, они являются чем-то вроде процедур, а есть ентити, которые просто тупые стракты. Проблема такого подхода, что у нас нет как таковой объектной модели и мы любым случайным сеттером
Любым случайным сеттером можем сломать доменную логику.
>Проблема третьего варианта в том, что там нет ООП.
Не вижу в этом никакой проблемы.
Здесь нет бизнес-логики, поэтому о какой "анемичной модели" может идти речь? У нас есть транзакция и DTO-ка которая служит для переноса данных. При появлении бизнес-логики (и об этом было сказано в видео) она попадает в человека.
Попробуйте сделать "не анемичную" модель с имеющимися данными, тогда вылезет много вопросов.
@@S0ERDEVS Спасибо за ответ. Если инварианты будут обеспечиваться на уровне entity, например при отрицательном количестве жидкости в чашке будет вылетать исключение, а класс Drink будет передавать его в представление то это допустимый вариант.
Сущность Существо. Сущность Емкость. Сущность Жидкость. Все наследуется от этих глобальных классов. человек корова, бутылка чашка корыто. вода чай ром. Это первое что пришло мне в голову.. Больше такого материала! Очень круто!
3:00 Не совсем понятно, а почему нарушается LSP если мы даже не видим реализации? Вдруг код написан так, что замена Cup > Bottle и наоборот ничего не поломает в коде, а значит LSP нарушен не будет?
В этой модели действительно легко написать так, чтобы ничего не поломалось. Но когда бутылка и чашка обрастут другим функционалом, уже вероятны проблемы. И просто логически бутылка не является чашкой. Это как минимум будет сбивать с толку при чтении кода
Скажите пожалуйста, а в какой программе вы рисуете?
Круто.👍
Очень правильно все изложено, но не согласен с аналогией с MVC. MVC - это все-таки другое (ну контроллер точно в данном случае должен быть заменен на бизнес логику), а тут чистая 3-ех слойная архитектура - UI, бизнес логика (BL), и data access layer (DAL)
А второй способ позволит реализовать изменение стейтов обоих объектов в транзакции? 🧐
А действие даже не "пить", а скорее "перелить" из IVessel в IVessel. Тогда можно будет и из чайника в чашку перелить, а потом уже в человека
Тип жидкости не влияет на сосуд, а на человека влияет ) А что бы влиять на сосуд, тут уже появляется вид жидкости - например кислота, расплавленный металл, лава. Крч мне кажется тут уже зависит от уровня абстракции и решаемой задачи.
@@Enthusiast91 вот и вопрос, что если жидкость способна влиять на сосуд со временем(кислота, лава) чтобы материал сосуда на это влиял, но при этом не реализовывать одно в другом
Подскажите книги по паттернам проектирования
Я запутался. А чем тогда это отличается от "entity component system" ?
Лучший!
Класс! Спасибо, а то вечно не учтенка возникает при расширении
Спасибо! за разбор. Но жаль, что нет UML-диаграмм.
3 вариант похож на то как это принято в Golang.
Есть 2 интерфейса и функция обеспечивающая их взаимодействие. Ошибки пробрасываются наружу для обработки.
Это наверное ещё один намек что это не ООП дизайн)
Когда меня спросят почему я люблю процедурный стиль - я покажу это видео
Так в итоге у него и получился процедурный стиль. Две структуры (human и cup) и функция (action). ООП тут и нет никакого
Получается интерфейс IDrinkable будет иметь методы взятия состояния? Типа get_liquid(int count) и другие...
Он может и должен влиять на состояние объекта косвенно, например вызывая методы добавить жидкость, убавить жидкость, при этом ему не обязательно знать сколько жидкости в сосуде
@@BASic_37 Надо выкидывать exception если закончилась жидкость в сосуде или переполнился мочевой пузырь
супер
Всегда стараюсь делать как в последнем варианте. При дальнейшем развитии системы, когда "инфраструктура" уже готова можно извращаться как угодно, подменяя само описание взаимодействия через стратегию. Написать переливание из чашки в другую чашку или высасывание мозгов человека другим человеком можно будет относительно быстро и красиво.
@@user-bf7hk9ds6k при этом самые кринжевые варианты - это как раз таки хотелки заказчика. Например, чтение pdf ж***й и выдача анализа этого pdf ртом...
Интересует вариант выпивания чашкой человека
класс👍
Не могу не отметить, что разбиение на 3 уровня также есть и в различных системах автоматизации и если абстрагироваться от конкретного назначения каждого из уровней, то они часто и по духу совпадают с MVC. Видимо удачное количество для декомпозиции.
что-то про MVC Остапа понесло). Это просто две модели, взаимодействующие между собой через интерфейс
Осталось сделать последний шаг - избавиться от состояний. Т.е. заменить "action" на функцию и заменить интерфейсы алгебраическими типами. И вот уже нормальная функциональная модель, без всяких костылей.
Кстати, в первом примере полиморфизм тоже есть - ad-hoc polymorphism.
Чем ближе к совершенству, тем ближе к функциональщине (или к математике) :D
Вы предлагаете мыслить как компьютер?
@@user-sy6jp7wd8y ровно наоборот :)
"мыслить как компьютер" - мыслить императивно, моделируя Машину Тьюринга в голове (операциональная семантика), описывая последовательность инструкций.
А в математике наоборот, торжество декларативности (денотационная семантика). В математике (и функциональщине) мы обычно не расписываем последовательность инструкций для получения чего-то, а описываем свойства этого чего-то.
@@user-dn7qr7vs1h декларативный подход это подача данных на вход и заявление того что мы ждём на выходе, а как это уже будет реализовано - для нас чёрный ящик, шаги мы не описываем. В ФП мы ведь как раз таки описываем последовательность команд в виде последовательности вызова функций, т.е. применяем императивный подход, разве нет так?
@@user-sy6jp7wd8y Нет. Последовательность никак не противоречит декларативному подходу. Очевидно, что некоммутативные операции зависят от порядка выполнения, при любом подходе. Императивный подход это не про последовательность. Это про то, что операции могут изменять внешнее, по отношению к функции, состояние, в то время как функции зависят только их аргументов.
Уважаемый S0ER, есть вопрос. Не совсем понятны в вашем варианте интерфейсы человека и ёмкости. Насколько я понял, предполагается, что у человека есть метод наподобие Drink(liquidType, volume), а у ёмкости метод получения её содержимого? Или команда (а насколько я понимаю, здесь использован именно этот шаблон) Drink просто в лобовую меняет состояние человека через get/set? Но тогда человек получается какой-то весьма анемичной моделью данных, которая уже ничего не инкапсулирует. Так же непонятно, как решается проблема "раздувания" модели человека - ведь каждая новая команда может влиять на совершенно разные детали состояния человека, и их число также будет расти. Насколько я понимаю, если заказчик хочет интенсивно расширять модель влияний на человека, то что-то всё равно будет раздуваться. В таком случае, возможно, ситуацию бы несколько упростил паттерн Состояние, только в модели человека был бы не один экземпляр состояния, а несколько (по количеству интересующих нас, как разработчиков, органов). Т.е. у каждого органа - своя сущность, а модель человека стала бы агрегатом в терминах DDD.
Интерфейс не наследуется, он реализуется.
хочу увидеть как все эти рассуждения будут применены для создание игры на юнити, где будет человек, и он будет пить и всё это с этими концепциями. и показать на практике как добавлять новый функционал в программе
Создаем новые классы желудок, печень, почка (одна), горло, рот, рука (одна), пиписька опционально - попа. Через агрегацию внедряем в человека. Никакого наследования. Потом, по цепочке (забыл паттерн) передаем чашку (сосуд) и человека в каждый класс. Ранее названные органы изменяют состояние человека и чашки.
Правильно ли понимаю, что в итоге будет еще один класс, например на клиентском уровне, который говорит, что этому человеку нужно попить из этого сосуда, и вызывает метод контроллера передавая туда человека и сосуд ?
Спасибо за видео. Пора уже на патреон подписываться. Контент очень качественный.
Жень, а смотри какая штука получается с этим mvc. Вроде все у нас объектно-ориентированное и по всем Solid и прочее. Но это все красиво работает когда состояние объекта в памяти долго висит. Чаще же нижний слой с состоянием уже хранится в сторедже каком то. И тут как возникает тема, что фактически у нас остаётся только метод перегонки из одного состояния в другое. И почему бы не взять для этого функциональный язык или какой то более функциональный подход.
Вот все больше всяких апи и микро сервисов пишется, которые просто данные перегоняют, и по факту мы просто функцию оборачиваем в класс, в котором нам больше ничего не надо. И внимание вопрос, зачем тогда вообще класс и ООП в таких проектах
Функциональный подход - прекрасен. Вопрос лишь в том как такие реализации поддерживать на большой дистанции и большой командой.
Плюс ООП, в том что он более структурированный. Тогда как функциональщики любят в любых непонятных ситуациях заворачивать функции в другие функции, что в итоге приводит к сложностям в поддержке, дебаге и прозводительности.
Все эти парадигмы: процедурная, функциональная, ООП, etc. созданы для борьбы (преодоления) со сложност(ью/и). Философски, существует два подхода к представлению мира: атрибутивный и функциональный. Представляют вселенную в виде супер-пупер-гипертекста атрибутивисты, а функционалисты в виде взаимодействующих потоков энергии-вещества. ООП использует оба подхода, функциональный - методами, атрибутивный - полями, и борется со сложностью инкапсуляцией и абстрагированием. Это самая компромиссная и простая для понимания парадигма, оттого она и столь жизнеспособна.
@@mikhailkh8560 ФП подход помогает хорошо структуировать код - чистые функции это уже очень хорошо фаргментированая сущность с очень прозрачной и предсказуемой природотой. И на выходе получается приложение где первыми идут данные а потом операции над ними, которые легко композируются и тестируются, "грязные" области тоже будут, но они будут более локализированы, что только плюс в контексте структурировании программы.
А по поводу функций обёрнутых в функции... тут ничего сложного нет, вы же наверно заворачиваете объекты внутри объекты и умеете работать и понимать такой код - вот так же с функциями, только по проще :)
@@ievgenk.8991 В теории я с вами абсолютно согласен. А вот на практике ни разу ничего хорошего не видел. Наверное я просто не везучий.
А есть на условном гитхабе проект написанный подобным образом, при этом читаемый, расширяемый, легко, дебажащийся и живой?
Понравилось видео, MVC подходом реализации задачи впечатлён.
А код можно увидеть? Который родился как результат проектирования.
9:30 в cataclysmDDA именно так и сделали. Всё тупо повешали на player.
Почувствовал себя очень умным, т.к. подумал об model-controller сразу при постановке задачи. Либо реализовать через dependency injection, если у нас во главе проекта стоит human
ВАУ
Хотелось бы увидеть решение этой задачи в стиле Типажей и Структур как в Rust. Будет ли это проще?
Первое что приходит на ум - это структура человек для которой реализован типаж Drink. Есть тип сумма(enum) Vessel, которая содержит все возможные сосуды.