Очень важна постановка задачи Сидит мужик, листает газету, видит объявление: Раскидать песок. 500₽ Позвонил, заказчик: - Придёшь, раскидаешь песок, заплачу 500₽, договорились? Мужик согласился. Приходит, а там 3 камаза песка. Говорит заказчику: - Тут 3 камаза песка, подними оплату Заказчик ни в какую. "Мы договорились, слово держи" Мужик взял жменю песка, швырнул в сторону и говорит: - Давай оплату - ?? - Мы не договаривались, что раскидаю весь песок
Задача кажется слишком абстрактной, по этому ее так не просто решить. Тут следует уточнить для чего мы моделируем данную систему. К примеру это может быть симулятор процессов организма человека или Игра, где человек может пить. И для каждого типа системы следует подбирать подходящую модель.
Дело в том, что любая задача которую нужно запрограммировать должна в конечном итоге совершать какие-либо I/O операции, иметь side-эффекты. Это должен быть вывод на экран, запись на диск и передача данных по сети, вывод звука. Задача должна быть сформулирована в этих терминах, иначе это это очередной фейк, и подмена понятий. Так происходит с каждым ООП-туториалом, потому что ООП, так получается, крайне скверно ложится на то чтобы задача была описана в терминах того что должен сделать компьютер, вот и приходится придумывать манявселенную с человек.пить и прочими мяукающими котами и гавкающими собаками. В реальности получаются Фабрики.СделатьАбстрактныйОбъект и Менеджеры.ЗапуститьПроцесс2
Реализовывал бы эту задачу первым, самым быстрым и простым способом. Если бы появлялись новые требования, переписывал бы код, двигаясь к последнему способу по мере необходимости. Новые требования могут и не появиться, а мы сделаем 10 уровней абстракций, которые нам не понадобятся.
Оно конечно здорово, когда тебе это не нужно будет поддерживать и расширять. Сделать на коленке фундамент из дерьма и палок, чтобы хоть как-то, а потом удивляться - Что же это разработка стала такой дорогой и долгой.
Норм, я бы взял 2 вариант, для тестов, которые не пишу. А по поводу обновления стейта человека подумать надо, чтобы он не стал анемичной моделью которая работает только через сервисы, но и сам по себе что то мог.
Не расширял и не переписывал бы, а просто перешёл бы на другой проект. А на этот проект пришёл бы какой нибудь другой разработчик, от которого бы потребовалось расширить функционал. И тот бы сначала схватился за голову и стал переписывать то, что уже написано (надеюсь, что третьим способом, но не факт), при этом срывая дедлайны, работая овертайм и делая заказчика очень недовольным. А теперь представь, что второй человек - это ты. (А первый был кодер из Индии.)
Вот где становится явной важность корректности и полноты требований к задаче. При простой постановке задачи - есть Человек, который Пьет из Кружки, явно нужно использовать первый вариант. Просто другие варианты противоречат KISS и YAGNI.
Это конечно весело, но на деле усложнение системы.Все же помнят про KISS и бритву Оккама. Вот мы заложили эту возможность расширения системы, хорошо, а расширения - никогда не произошло, но кодовая база стала сложнее для понимания новым разработчика и они уже чтобы решить задачу по добавлению новой логики - тратят не 10 минут, а 2 часа, потому что в реальных проектах будет на DrinkController, а какая-нибудь монструозная фигня, с фасадами, прокидыванием событий, мостами, медиаторами, декораторами фабриками и прочим-прочим и чтобы добраться уже до самой логики - придется нехило постараться. В общем. На мой взгляд - второй вариант - неидеален, но он прост, он довольно расширяем, а главное он не прячет логику за отдельной сущностью. Опять же, тут пример довольно простой, но ведь взяв на вооружения подобные принципы - люди начинают все декомпозировать-декомпозировать, выделять сущности(вот вам выпивака, закусака и наливака, а вместе они образуют студента), выделять интерфейсы, в итоге куча каких-то кусков логики лежат в воздухе а как оно собственно работает - может понять только тот кто это написал(и то не факт), либо человек, которому не жаль было потратить неделю времени.
@@S0ERDEVS В веб-разработке, скорее всего, никто с нуля не пишет, но есть множество других доменов. Например готовые фреймворки для автомобильной индустрии мне не известны. Однако там так же успешно используются и микро сервисы, и MVC, и дизайн паттерны.
поэтому сначала рисуются схемы из которых сразу понятно, что с чем взаимодействует и куда вносить изменения. И не придется десятки тысяч строк кода вычитывать, прыгая по файлам, каждый раз. Если схем нет, то надо в первую очередь их сделать. а потом уже браться за изменения. Иначе, нередко дешевле будет заново переписать на современный лад.
Классный разбор! Спасибо за труды) на самом деле на таких абстрактных, но близких к реальному миру, вещах интересно пробовать учиться проектировать. Такое упражнение для мозга)
Конечно тут представлен простой пример, но мне кажется он отражает суть современной разработки. Можно гнаться сколь угодно за принципами и паттернами, но когда вы попадаете в среду, где предметная область для вас в новинку, а требования и сроки уже обозначены, вы будете проектировать архитектуру под текущие требования так, как вам кажется правильно. При этом вы еще n-ое количество раз будете пересматривать свои наработки. А когда вам покажется, что вы все контролируете, то появится требование, осознав которое, вы прошепчете у себя в голове: "*лядь, как я сразу это не учел?"
@@ОлегМосягин-р8й Как тесты, написанные для 1 варианта помогут сделать безболезненный рефакторинг в последний вариант? :) Да там процентов 90 тестов надо будет переписывать, и еще неизвестно сколько писать новых :) Тесты нужны при точечных доработках и расширении системы скорее, нежели при глобальном рефакторинге.
@@dmitriyobidin6049 никак, если изменились интерфейсы и разделение на модули, то и тесты придется переписать. Но по крайней мере тесты провоцируют писать более мелкие и узкоспециализированные модули. Просто если у нас весь проект состоит не только из этих двух классов, а есть что-то еще, то тесты позволят убедиться, что остальный проект не сломается, пока мы переписываем эти два класса с тестами на них.
В начале видео говорится, что необходимо спроектировать ситуацию в ооп парадигме. На самом деле получилась анемичная модель, которую дергает контроллер. Мало того что паттерн mvc предполагает логику размещать в моделе, а не в контроллере, так ещё и нарушается один из главных принципов ооп дизайна - information expert. Контроллер управляет состоянием чашки и человека, вместо самих сущностей. Полученное решение напоминает паттерн transaction script
нет, ты путаешь модель и сущность. Доменную модель с доменной логикой, контроллером, моделью данных. Модель может быть пакетом (слоем), в котором есть отдельные доменные модели и отдельные бизнес-правила. Контроллер уже предоставляет методы, формализующие пользовательские запросы, отделяя интерфейс (GUI) от реализации (данных и бизнес-правил). Есть и другой вариант MVVM, там без контроллера, каждой пользовательской страничке присуща некоторая бизнес-сущность. Вообще, модель данных как раз должна быть максимально простой (плоской), без поведения., обычно хранится в базе в виде таблиц. На ее основе уже можно создавать сущности (через интерфейс) с поведением, которые и будут реализовывать присущую только им логику. А в случае на видео, логика не относится к одной сущности, бизнес-действие должно поменять состояние сразу нескольких объектов. Поэтому его нельзя приписывать к этим сущностям.
You Ain’t Gonna Need It. Делать нужно то, что нужно, то что стоит в задаче, а то, чего в задаче нет, делать не нужно. А если когда-то заказчик что-то поменяет, то он заплатит за новую задачу. А нам опять нужно будет делать только то, что нужно, то что в задаче... Жду новое видео!
@@ИванИванов-р1г4х на это есть другие приемы работы. Например "если общий код встречается 3 и более раза, то нужно обобщить и переиспользовать". Цифра 3 может меняться в зависимости от, но метод довольно полезный как средство сдерживания и оверинжиниринга, и повторения кода.
нет там ни каких стадий мучений, с опытом ты клепаешь эти интерфейсы и классы по 50+ штук в день не задумываясь. паттерн простейший - стратегия. про то что метод пить должен иметь единственную ответственность так же прозрачно.
@@dmtpp Чтобы делать сложные и масштабные вещи, необходимо досконально постичь азы. Чтобы написать Войну и Мир, нужно сначала изучить азбуку, освоить слова и составление предложений. Эти вещи показательны. Я решил бы вопрос почти так же, но без класса-посредника, реализующего процесс пития. Мне вот и интересно как он будет реализован, будет ли агрегатом или композитом человека, а может вообще будет унаследован от глобальной божественной сущности Бахуса?
@@redserjogha класс может быть реализован как действие, где сначала читается состояние кружки и в соответствии с ним изменяется состояние человека. Это действие, опционально, так же может выбрасывать событие, что оно произвело процесс опорожнение кружки и наполнение жидкостью человека. В последствии, все кто слушали это событие, могут начать своё действие, например: проверка на то, что именно было выпито и вызов соответствующей реакции (ухудшение самочувствия или его улучшение, гипотермия/гипертермия, отравление/излечение, восстановление водного баланса или же дегидратация организма).
@@evgenasd8892 да, но он опционален. Суть в том что мы вводим третью сущность и она просто меняет состояние двух моделей. У меня когда-то была похожая проблема, где было 2 космических корабля и они могли друг друга атаковать и наносить урон. Дилемма была в том, что не понятно у кого должно быть право наносить урон; должен ли атакующий корабль содержать метод DealDamage() и отнимать прочность/щиты у корабля которого он атакует или корабль который получает урон, должен содержать метод ReceiveDamage() и решать какой урон ему может нанести атакующий его корабль? По факту же, ни у кого из них не должно быть такой привилегии и доверия.
Очень круто ! Впринципе ничего сложного если правильно начинать с самого начала. Почаще нужны такие видео. Это приблизительно тоже самое как осваивание речи у малых детей. Звуки. Буквы. Слова. ...
За такой подробный разбор спасибо. Правда, спасибо. Задача хоть и простая, но повзволяет сразу увидеть, как мыслит человек. Я бы первым своим решением-приближением сделал бы функцию типа human_drink_from_cup() нарочно без классов. Всё-таки задача стояла примитивная, а мы начали фантазировать, а что будет если...
Super!😁😁😁😉 А это нормально если мы сделаем следующую иерархию интерфесов для класса кружки: > INTERFACES СпособныйСодержатьЖидкостьИнтерфейс (из шланга воду льют нам прямо в рот, то есть воздушная среда, способная содержать жидкость) ^ УглублениеИнтерфейс (жидкость в лужах) ^ СосудИнтерфейс (классы: кружек, бутылок) < INTERFACES Таким образом: class UserActionControllerInterface { function drink(человекИнтерфейс, СпособныйСодержатьЖидкостьИнтерфейс); } Ок?
я бы очень хотел больше подобных роликов, пусть в них будет говориться одно и тоже, желательно конечно усложнение проекта, которого нам дают, но стольже просте объяснение
Тю, по факту ты пришел к 2xDTO да ActionHandler, можно даже прикрутить третью DTO, которая описывает саму жидкость и "переливать" её из одной ДТО в другую. Но! Ты правильно заметил в самом начале, что очень важно "можем ли мы изменять систему", потому что иногда такое вот усложнение просто нерационально и не имеет смысла, если ты точно уверен, что никаких векторов развития никуда и никогда не будет в обозримом будущем, а нужно просто сделать в лоб и забыть. Типичная проблема программистов - когда просят построить садовую тачку, мы, по привычке, закладываем в конструкцию возможность расширения для реализации полётов на ней в космос с табором цыган на борту.
В некоторых книжках пишут, мол, ООП нужен ещё и для того, чтобы не абстрагироваться от реального мира и что обычному человеку легче мыслить в рамках ООП. Чем больше изучаю, тем больше понимаю, что это не так. ООП становится всё дальше от реальности.
@UCYB1-bWEzfKGTBSt6a5YoHw а ведь реально, если посмотреть на весь процесс инициализации (рождения) нового экземпляра человека (разных классов / национальностей и тп, унаследованных об супер-классов вверх по иерархии), то инстинкты - это firmware запрограммированный в контроллере физобъекта (с помощью биодисков- генов), а обучение в процессе жизни - это натаскивание его нейронной сетки через звуковые, световые и прочие интерфейсы (рефлексы как драйверы соответствующих IO-девайсов у человека); языки общения тоже разные у разных групп людей (но все так или иначе компилируются в некий гуманоидный IL низкого уровня), шины (СМИ, племенные и родовые связи) и брокеры сообщений тоже имеются - и многие великие "менеджеры (ака манипуляторы)" давно эти фреймворки выучили :)) весь "гософициоз" с его законами и документами очень уж филофоски напоминают xml
@@fj8017 класс Human - это не человек, а некоторый "представитель" человека в нашей системе. И так получается, что представители не обязаны разделять свойств и отношений тех, кого представляют. Например, есть муж и жена, которые разводятся, а есть адвокаты - их представители в этом процессе. Маловероятно, что адвокаты тоже разводятся при этом. Или классический пример с наследованием квадрата от прямоугольника отражает тот же феномен. Поэтому я бы не стал утверждать, что объекты в ООП так уж далеки от реальности. Просто мы оперируем не самими объектами, а их поведением.
Отличный пример как программист вместо решения задачи сразу пишет свой фреймворк. Если не известны вектора развития компонентов этого решения то и усложнять не надо. На третьем добавлении схожего функционала сразу обозначится вектор, и надо будет только его учесть. В итоге меньше кода, и он будет отражать предметную область, а не непонятные фантазии программистов (замечу, программистов много, а проект один, а значит проще понимание кода проекта). А также проще отрефакторить код одного экрана, чем 10 файлов. P.S. Кстати, в третьем решении вся сложность будем в этом контроллере, где придётся обрабатывать, что лошадь не пьёт из стакана, а только из ведра, попахивает кучей if-ов, или ещё одним паттерном на 10 файлов.
1. Давно уже придумали фреймворки. Там все что нужно для 3-го варианта реализовано, генераторы кода есть и прочие "плюшки". 2. Вы про полиморфизм слышали? Например, ad-hoc полиморфизм без всяких if-ов вызовет вам нужную реализацию, если же про языки с утиной типизацией и поддержкой мультипарадигм, то там есть замечательные декларативные подходы вместо if/switch, которые используют функции первого порядка. Да и контроллер может существовать не в одном варианте, если речь про модульный подход, то можно конфигурировать модуль, использовать DI и т.д. Короче нет там никаких "кучи if-ов". Было бы желание думать, а не решений полно.
@@S0ERDEVS Вы комментируете 3-е решение в абстрактном вакууме, а не в реальном проекте, где что-то меняется, в задаче изначально неправильный акцент выставлен, что-то неизвестно на момент первых итераций, когда программисты уходят и болеют, ищутся баги по куче файлов, человек пытается уложить в голову логику. Это решение вообще это всё игнорирует. Понятно, что где-то такой подход реально отлично ложится и спасает от проблем в будущем, но не в случае рядовой задачи "попить воды". Примеры уж тогда надо подбирать более корректней, чтобы не было иллюзий, что там где есть решение в одну строку, надо генерировать кучу новых файлов и новых абстракций
Сущность Существо. Сущность Емкость. Сущность Жидкость. Все наследуется от этих глобальных классов. человек корова, бутылка чашка корыто. вода чай ром. Это первое что пришло мне в голову.. Больше такого материала! Очень круто!
Всегда стараюсь делать как в последнем варианте. При дальнейшем развитии системы, когда "инфраструктура" уже готова можно извращаться как угодно, подменяя само описание взаимодействия через стратегию. Написать переливание из чашки в другую чашку или высасывание мозгов человека другим человеком можно будет относительно быстро и красиво.
@@ДмитрийМязин-л5ш при этом самые кринжевые варианты - это как раз таки хотелки заказчика. Например, чтение pdf ж***й и выдача анализа этого pdf ртом...
Очень правильно все изложено, но не согласен с аналогией с MVC. MVC - это все-таки другое (ну контроллер точно в данном случае должен быть заменен на бизнес логику), а тут чистая 3-ех слойная архитектура - UI, бизнес логика (BL), и data access layer (DAL)
3:00 Не совсем понятно, а почему нарушается LSP если мы даже не видим реализации? Вдруг код написан так, что замена Cup > Bottle и наоборот ничего не поломает в коде, а значит LSP нарушен не будет?
В этой модели действительно легко написать так, чтобы ничего не поломалось. Но когда бутылка и чашка обрастут другим функционалом, уже вероятны проблемы. И просто логически бутылка не является чашкой. Это как минимум будет сбивать с толку при чтении кода
Создаем новые классы желудок, печень, почка (одна), горло, рот, рука (одна), пиписька опционально - попа. Через агрегацию внедряем в человека. Никакого наследования. Потом, по цепочке (забыл паттерн) передаем чашку (сосуд) и человека в каждый класс. Ранее названные органы изменяют состояние человека и чашки.
Забавно смотреть как java-ООП продается программистам как универсальное средство в котором можно мешать котлеты и мухи, а потом эти же программисты всеми правдами и неправдами пытаются отделить котлеты от мух, но на уровне архитектуры :)
Жаба-ооп - это такая религия. (У них там даже есть должности евангелистов) Вот, кто-то проповедовал, кто-то уверовал, а потом выясняется, что земля не плоская.
Имхо. Проблема третьего варианта в том, что там нет ООП. Это называется анемичная модель, где у нас есть сервисы, они являются чем-то вроде процедур, а есть ентити, которые просто тупые стракты. Проблема такого подхода, что у нас нет как таковой объектной модели и мы любым случайным сеттером
Здесь нет бизнес-логики, поэтому о какой "анемичной модели" может идти речь? У нас есть транзакция и DTO-ка которая служит для переноса данных. При появлении бизнес-логики (и об этом было сказано в видео) она попадает в человека. Попробуйте сделать "не анемичную" модель с имеющимися данными, тогда вылезет много вопросов.
@@S0ERDEVS Спасибо за ответ. Если инварианты будут обеспечиваться на уровне entity, например при отрицательном количестве жидкости в чашке будет вылетать исключение, а класс Drink будет передавать его в представление то это допустимый вариант.
Осталось сделать последний шаг - избавиться от состояний. Т.е. заменить "action" на функцию и заменить интерфейсы алгебраическими типами. И вот уже нормальная функциональная модель, без всяких костылей. Кстати, в первом примере полиморфизм тоже есть - ad-hoc polymorphism.
@@РусланСитников-у4м ровно наоборот :) "мыслить как компьютер" - мыслить императивно, моделируя Машину Тьюринга в голове (операциональная семантика), описывая последовательность инструкций. А в математике наоборот, торжество декларативности (денотационная семантика). В математике (и функциональщине) мы обычно не расписываем последовательность инструкций для получения чего-то, а описываем свойства этого чего-то.
@@АнимусАнанимус декларативный подход это подача данных на вход и заявление того что мы ждём на выходе, а как это уже будет реализовано - для нас чёрный ящик, шаги мы не описываем. В ФП мы ведь как раз таки описываем последовательность команд в виде последовательности вызова функций, т.е. применяем императивный подход, разве нет так?
@@РусланСитников-у4м Нет. Последовательность никак не противоречит декларативному подходу. Очевидно, что некоммутативные операции зависят от порядка выполнения, при любом подходе. Императивный подход это не про последовательность. Это про то, что операции могут изменять внешнее, по отношению к функции, состояние, в то время как функции зависят только их аргументов.
Первое что приходит на ум - это структура человек для которой реализован типаж Drink. Есть тип сумма(enum) Vessel, которая содержит все возможные сосуды.
Тип жидкости не влияет на сосуд, а на человека влияет ) А что бы влиять на сосуд, тут уже появляется вид жидкости - например кислота, расплавленный металл, лава. Крч мне кажется тут уже зависит от уровня абстракции и решаемой задачи.
@@Enthusiast91 вот и вопрос, что если жидкость способна влиять на сосуд со временем(кислота, лава) чтобы материал сосуда на это влиял, но при этом не реализовывать одно в другом
Спасибо за видео. Пора уже на патреон подписываться. Контент очень качественный. Жень, а смотри какая штука получается с этим mvc. Вроде все у нас объектно-ориентированное и по всем Solid и прочее. Но это все красиво работает когда состояние объекта в памяти долго висит. Чаще же нижний слой с состоянием уже хранится в сторедже каком то. И тут как возникает тема, что фактически у нас остаётся только метод перегонки из одного состояния в другое. И почему бы не взять для этого функциональный язык или какой то более функциональный подход. Вот все больше всяких апи и микро сервисов пишется, которые просто данные перегоняют, и по факту мы просто функцию оборачиваем в класс, в котором нам больше ничего не надо. И внимание вопрос, зачем тогда вообще класс и ООП в таких проектах
Функциональный подход - прекрасен. Вопрос лишь в том как такие реализации поддерживать на большой дистанции и большой командой. Плюс ООП, в том что он более структурированный. Тогда как функциональщики любят в любых непонятных ситуациях заворачивать функции в другие функции, что в итоге приводит к сложностям в поддержке, дебаге и прозводительности.
Все эти парадигмы: процедурная, функциональная, ООП, etc. созданы для борьбы (преодоления) со сложност(ью/и). Философски, существует два подхода к представлению мира: атрибутивный и функциональный. Представляют вселенную в виде супер-пупер-гипертекста атрибутивисты, а функционалисты в виде взаимодействующих потоков энергии-вещества. ООП использует оба подхода, функциональный - методами, атрибутивный - полями, и борется со сложностью инкапсуляцией и абстрагированием. Это самая компромиссная и простая для понимания парадигма, оттого она и столь жизнеспособна.
@@mikhailkh8560 ФП подход помогает хорошо структуировать код - чистые функции это уже очень хорошо фаргментированая сущность с очень прозрачной и предсказуемой природотой. И на выходе получается приложение где первыми идут данные а потом операции над ними, которые легко композируются и тестируются, "грязные" области тоже будут, но они будут более локализированы, что только плюс в контексте структурировании программы. А по поводу функций обёрнутых в функции... тут ничего сложного нет, вы же наверно заворачиваете объекты внутри объекты и умеете работать и понимать такой код - вот так же с функциями, только по проще :)
@@ievgenk.8991 В теории я с вами абсолютно согласен. А вот на практике ни разу ничего хорошего не видел. Наверное я просто не везучий. А есть на условном гитхабе проект написанный подобным образом, при этом читаемый, расширяемый, легко, дебажащийся и живой?
хочу увидеть как все эти рассуждения будут применены для создание игры на юнити, где будет человек, и он будет пить и всё это с этими концепциями. и показать на практике как добавлять новый функционал в программе
Уважаемый S0ER, есть вопрос. Не совсем понятны в вашем варианте интерфейсы человека и ёмкости. Насколько я понял, предполагается, что у человека есть метод наподобие Drink(liquidType, volume), а у ёмкости метод получения её содержимого? Или команда (а насколько я понимаю, здесь использован именно этот шаблон) Drink просто в лобовую меняет состояние человека через get/set? Но тогда человек получается какой-то весьма анемичной моделью данных, которая уже ничего не инкапсулирует. Так же непонятно, как решается проблема "раздувания" модели человека - ведь каждая новая команда может влиять на совершенно разные детали состояния человека, и их число также будет расти. Насколько я понимаю, если заказчик хочет интенсивно расширять модель влияний на человека, то что-то всё равно будет раздуваться. В таком случае, возможно, ситуацию бы несколько упростил паттерн Состояние, только в модели человека был бы не один экземпляр состояния, а несколько (по количеству интересующих нас, как разработчиков, органов). Т.е. у каждого органа - своя сущность, а модель человека стала бы агрегатом в терминах DDD.
я не просто так заостряю на этом внимание. есть такой запах кода - если мы не можем быстро и однозначно придумать короткое название для класса, которое будет отражать его суть, то возможно этот класс задизайнен плохо
хорошее объяснение, работать будет. только вот весь этот паттерн, происходит из ущербности принципов построения С++ классов. Объект дринк - фактически состояний не имеет. Человек и чашка сводятся к набору интерфейсов суть которые геттеры и сеттеры. В альтернативной реальности Лиспа, есть CLOS, который изначально говорит что классы сводятся к геттерам и сеттерам, а вместо виртуальных классов действий, существуют обобщенные методы, не принадлежащие к классам. Создав одну обобщенную функцию вы можете добавлять туда взаимодействия произвольного кличества типов объектов. Т.е CLOS позволяет избежать создания трех не нужных сущностей действия и 2х интерфейсов. т.е сам этот паттерн уже заложен в CLOS.
Комментарии как всегда выявляют довольно плотную группу людей которые хотят совершать ошибки под лозунгом "делаем в лоб, чтобы быстро дать заказчику ценность. И потом даже не учиться на них под лозунгом из серии "нельзя было предусмотреть, заказчик внёс несовместимые требования". Это вместо того чтобы понять что проблема в тебе как разработчике. Автор же ролика не говорит что он построил идеальную систему про кружки. Он пытается донести как на практике использовать понятие вектор развития и управлять энтропией которая при этом порождается. А комментаторы *от сохи" концентрируются на каких то не важных деталях.
@@S0ERDEVS Я задал вопрос исходя из того, что вы представили на диаграмме, а не исходя из своего понимания. Я пытаюсь понять, что вы имели в виду. Или я не правильно понимаю картинку, и Action-Drink находится не в слое бизнес логики?
@@S0ERDEVS Объясните пожалуйста картинку. Я думал, что на ней изображены снизу вверх три слоя: 1. Слой данных 2. Слой обработки данных (т.е. бизнес логика) 3. Слой представления данных Которые в свою очередь соответствуют: 1. Model 2. Controller 3. View из MVC паттерна
С точки зрения чистой архитектуры на данное чаепитие должен быть UseCase-интерактор, который будет манипулировать взаимодействием хумана и чашки, за тем отправит результат куда следует.
Как насчёт создать базовый класс Сосуд и создать класс Человек который наследуется от Сосуда, ведь человек в этой задачи ничто иное как сосуд! И стакан сосуд, а жидкость это данные которые перетекают из одного сосуда в другой. Вот она красота истинного ООП!
Через полиморфизм тоже норм будет. Метод пить у человека, сосуд абстрактный класс с состоянием, обработкой исключений и виртуальным методом опустошить. Внутри своего пить, человек вызывает метод опустошить сосуда.
3 вариант похож на то как это принято в Golang. Есть 2 интерфейса и функция обеспечивающая их взаимодействие. Ошибки пробрасываются наружу для обработки.
Никогда ещё человек не пил так осознанно
Ахахах +++
😂🤔
😂😂😂
Отличное видео и подача. Очень хочется ещё подобных видео
Согласен. С таким объяснением даже новички без особого труда поймут смысл ооп.
Согласен. Мне тоже не хватает такой информации.
Предлагаю разнести человека и чашку в разные микросервисы =)
Очень важна постановка задачи
Сидит мужик, листает газету, видит объявление: Раскидать песок. 500₽
Позвонил, заказчик:
- Придёшь, раскидаешь песок, заплачу 500₽, договорились?
Мужик согласился.
Приходит, а там 3 камаза песка. Говорит заказчику:
- Тут 3 камаза песка, подними оплату
Заказчик ни в какую. "Мы договорились, слово держи"
Мужик взял жменю песка, швырнул в сторону и говорит:
- Давай оплату
- ??
- Мы не договаривались, что раскидаю весь песок
надо было NDA подписывать
"Рабинович с одной стороны и Одесское пароходство с другой..." (с) анекдот
@@roman-bolkhovitin хD
@Старший Санитар " - Если хоть кому-то расскажешь, что мы тут самосвалы с песком разгружаем на халяву - Мы быстро тебе жизнь подпортим. "
@@dmtpp он пример тебе показывает, а ты язвишь, негодяй
Задача кажется слишком абстрактной, по этому ее так не просто решить. Тут следует уточнить для чего мы моделируем данную систему. К примеру это может быть симулятор процессов организма человека или Игра, где человек может пить. И для каждого типа системы следует подбирать подходящую модель.
Дело в том, что любая задача которую нужно запрограммировать должна в конечном итоге совершать какие-либо I/O операции, иметь side-эффекты.
Это должен быть вывод на экран, запись на диск и передача данных по сети, вывод звука.
Задача должна быть сформулирована в этих терминах, иначе это это очередной фейк, и подмена понятий.
Так происходит с каждым ООП-туториалом, потому что ООП, так получается, крайне скверно ложится на то чтобы задача была описана в терминах того что должен сделать компьютер, вот и приходится придумывать манявселенную с человек.пить и прочими мяукающими котами и гавкающими собаками.
В реальности получаются Фабрики.СделатьАбстрактныйОбъект и Менеджеры.ЗапуститьПроцесс2
Такой контент я давно искал. Но ютуб считает что в рекомендации лучше положить как 8 лет назад Камаз утонул
Реализовывал бы эту задачу первым, самым быстрым и простым способом.
Если бы появлялись новые требования, переписывал бы код, двигаясь к последнему способу по мере необходимости.
Новые требования могут и не появиться, а мы сделаем 10 уровней абстракций, которые нам не понадобятся.
Оно конечно здорово, когда тебе это не нужно будет поддерживать и расширять.
Сделать на коленке фундамент из дерьма и палок, чтобы хоть как-то, а потом удивляться - Что же это разработка стала такой дорогой и долгой.
Норм, я бы взял 2 вариант, для тестов, которые не пишу.
А по поводу обновления стейта человека подумать надо, чтобы он не стал анемичной моделью которая работает только через сервисы, но и сам по себе что то мог.
Не расширял и не переписывал бы, а просто перешёл бы на другой проект. А на этот проект пришёл бы какой нибудь другой разработчик, от которого бы потребовалось расширить функционал. И тот бы сначала схватился за голову и стал переписывать то, что уже написано (надеюсь, что третьим способом, но не факт), при этом срывая дедлайны, работая овертайм и делая заказчика очень недовольным. А теперь представь, что второй человек - это ты. (А первый был кодер из Индии.)
@@konstantinkouptsov7513 как же жизненно
Вот где становится явной важность корректности и полноты требований к задаче. При простой постановке задачи - есть Человек, который Пьет из Кружки, явно нужно использовать первый вариант. Просто другие варианты противоречат KISS и YAGNI.
Хотели банан, а получили гориллу с бананом в джунглях.
Реализация огонь 🔥
Очень понятное обяснение не только про проектирование, но и про применение ратернов, очень классно!)
Первый раз в жизни увидел настолько крутое объяснение mvc, продолжайте, у вас потенциал, с удовольствием послушал бы и про другие паттерны.
Не хватает примера реализации кодом в итоге. Вроде понятно, но вдруг не так понял.
Любой проект на java spring открой)
Это конечно весело, но на деле усложнение системы.Все же помнят про KISS и бритву Оккама. Вот мы заложили эту возможность расширения системы, хорошо, а расширения - никогда не произошло, но кодовая база стала сложнее для понимания новым разработчика и они уже чтобы решить задачу по добавлению новой логики - тратят не 10 минут, а 2 часа, потому что в реальных проектах будет на DrinkController, а какая-нибудь монструозная фигня, с фасадами, прокидыванием событий, мостами, медиаторами, декораторами фабриками и прочим-прочим и чтобы добраться уже до самой логики - придется нехило постараться.
В общем. На мой взгляд - второй вариант - неидеален, но он прост, он довольно расширяем, а главное он не прячет логику за отдельной сущностью. Опять же, тут пример довольно простой, но ведь взяв на вооружения подобные принципы - люди начинают все декомпозировать-декомпозировать, выделять сущности(вот вам выпивака, закусака и наливака, а вместе они образуют студента), выделять интерфейсы, в итоге куча каких-то кусков логики лежат в воздухе а как оно собственно работает - может понять только тот кто это написал(и то не факт), либо человек, которому не жаль было потратить неделю времени.
Так фреймворки же берут на себя всю грязную работу, никто с нуля не пишет. Или вы пишете?
@@S0ERDEVS В веб-разработке, скорее всего, никто с нуля не пишет, но есть множество других доменов. Например готовые фреймворки для автомобильной индустрии мне не известны. Однако там так же успешно используются и микро сервисы, и MVC, и дизайн паттерны.
поэтому сначала рисуются схемы из которых сразу понятно, что с чем взаимодействует и куда вносить изменения. И не придется десятки тысяч строк кода вычитывать, прыгая по файлам, каждый раз. Если схем нет, то надо в первую очередь их сделать. а потом уже браться за изменения. Иначе, нередко дешевле будет заново переписать на современный лад.
Классный разбор! Спасибо за труды) на самом деле на таких абстрактных, но близких к реальному миру, вещах интересно пробовать учиться проектировать. Такое упражнение для мозга)
Конечно тут представлен простой пример, но мне кажется он отражает суть современной разработки. Можно гнаться сколь угодно за принципами и паттернами, но когда вы попадаете в среду, где предметная область для вас в новинку, а требования и сроки уже обозначены, вы будете проектировать архитектуру под текущие требования так, как вам кажется правильно. При этом вы еще n-ое количество раз будете пересматривать свои наработки. А когда вам покажется, что вы все контролируете, то появится требование, осознав которое, вы прошепчете у себя в голове: "*лядь, как я сразу это не учел?"
Поэтому Роберт Мартин топит за TDD, чтобы можно было делать безболезненный рефакторинг.
@@ОлегМосягин-р8й Как тесты, написанные для 1 варианта помогут сделать безболезненный рефакторинг в последний вариант? :) Да там процентов 90 тестов надо будет переписывать, и еще неизвестно сколько писать новых :)
Тесты нужны при точечных доработках и расширении системы скорее, нежели при глобальном рефакторинге.
@@dmitriyobidin6049 никак, если изменились интерфейсы и разделение на модули, то и тесты придется переписать. Но по крайней мере тесты провоцируют писать более мелкие и узкоспециализированные модули. Просто если у нас весь проект состоит не только из этих двух классов, а есть что-то еще, то тесты позволят убедиться, что остальный проект не сломается, пока мы переписываем эти два класса с тестами на них.
Потрясающая🌞 подача материала 🌞
Понятно даже мне
Спасибо за видео! Прекрасный формат видео (рубрика)! Лайк
Побольше таких нужно, спасибо!
Каждое видео очень воодушевляет.
Спасибо за ёмкое объяснение таких тонких (особенно для новичков) моментов! 😌
Предлагаю объединить сущность сосуд и человек
Человеко-сосуд
Тогда человек может пить из другого человека хоть до бесконечности
это уже система вампиризма
Да! И тогда можно будет не только пить человеку, но и даже переливать из бутылки в чашку.
ты про свою жену?
В начале видео говорится, что необходимо спроектировать ситуацию в ооп парадигме. На самом деле получилась анемичная модель, которую дергает контроллер. Мало того что паттерн mvc предполагает логику размещать в моделе, а не в контроллере, так ещё и нарушается один из главных принципов ооп дизайна - information expert. Контроллер управляет состоянием чашки и человека, вместо самих сущностей. Полученное решение напоминает паттерн transaction script
нет, ты путаешь модель и сущность. Доменную модель с доменной логикой, контроллером, моделью данных. Модель может быть пакетом (слоем), в котором есть отдельные доменные модели и отдельные бизнес-правила. Контроллер уже предоставляет методы, формализующие пользовательские запросы, отделяя интерфейс (GUI) от реализации (данных и бизнес-правил). Есть и другой вариант MVVM, там без контроллера, каждой пользовательской страничке присуща некоторая бизнес-сущность.
Вообще, модель данных как раз должна быть максимально простой (плоской), без поведения., обычно хранится в базе в виде таблиц. На ее основе уже можно создавать сущности (через интерфейс) с поведением, которые и будут реализовывать присущую только им логику. А в случае на видео, логика не относится к одной сущности, бизнес-действие должно поменять состояние сразу нескольких объектов. Поэтому его нельзя приписывать к этим сущностям.
Спасибо! Очень интересно по содержанию. Очень круто по визуалу!
Прекрасное видео!! 👍🏻 Благодарю!! Всё предельно понятно!! 😊
You Ain’t Gonna Need It. Делать нужно то, что нужно, то что стоит в задаче, а то, чего в задаче нет, делать не нужно. А если когда-то заказчик что-то поменяет, то он заплатит за новую задачу. А нам опять нужно будет делать только то, что нужно, то что в задаче... Жду новое видео!
И, однажды, на требование добавление нового сосуда, заказчик услышит сумму в 100500 человеко-часов и пошлет Вас и Ваш подход далеко-далеко
@@ИванИванов-р1г4х на это есть другие приемы работы. Например "если общий код встречается 3 и более раза, то нужно обобщить и переиспользовать".
Цифра 3 может меняться в зависимости от, но метод довольно полезный как средство сдерживания и оверинжиниринга, и повторения кода.
Лукас и коммент в поддержку автора канала!)
Для полного разрыва шаблона после Лисков и SRP новичку следует изучить принцип KISS
Чисто доступно и понятно. + за продолжение подобных видео.
Когда меня спросят почему я люблю процедурный стиль - я покажу это видео
Так в итоге у него и получился процедурный стиль. Две структуры (human и cup) и функция (action). ООП тут и нет никакого
Отличный материал, хотелось бы продолжения. Спасибо
Видео точно отражает три стадии мучения программиста при получении новой задачи: 1) и так сойдет 2) а что если?... 3) господи, что ЭТО?!!!
нет там ни каких стадий мучений, с опытом ты клепаешь эти интерфейсы и классы по 50+ штук в день не задумываясь. паттерн простейший - стратегия. про то что метод пить должен иметь единственную ответственность так же прозрачно.
Первое видео про ООП, которое я нашел для себя очень интересным
Хотелось бы увидеть пример реализации класса, представляющего процесс пития.
@@dmtpp Чтобы делать сложные и масштабные вещи, необходимо досконально постичь азы. Чтобы написать Войну и Мир, нужно сначала изучить азбуку, освоить слова и составление предложений. Эти вещи показательны. Я решил бы вопрос почти так же, но без класса-посредника, реализующего процесс пития. Мне вот и интересно как он будет реализован, будет ли агрегатом или композитом человека, а может вообще будет унаследован от глобальной божественной сущности Бахуса?
@@redserjogha класс может быть реализован как действие, где сначала читается состояние кружки и в соответствии с ним изменяется состояние человека. Это действие, опционально, так же может выбрасывать событие, что оно произвело процесс опорожнение кружки и наполнение жидкостью человека. В последствии, все кто слушали это событие, могут начать своё действие, например: проверка на то, что именно было выпито и вызов соответствующей реакции (ухудшение самочувствия или его улучшение, гипотермия/гипертермия, отравление/излечение, восстановление водного баланса или же дегидратация организма).
@@IgorLynn вы не. Observer описали в своем примере?
@@evgenasd8892 да, но он опционален. Суть в том что мы вводим третью сущность и она просто меняет состояние двух моделей.
У меня когда-то была похожая проблема, где было 2 космических корабля и они могли друг друга атаковать и наносить урон. Дилемма была в том, что не понятно у кого должно быть право наносить урон; должен ли атакующий корабль содержать метод DealDamage() и отнимать прочность/щиты у корабля которого он атакует или корабль который получает урон, должен содержать метод ReceiveDamage() и решать какой урон ему может нанести атакующий его корабль? По факту же, ни у кого из них не должно быть такой привилегии и доверия.
@@IgorLynn спасибо
Второму видео точно лайк за продолжение первого, за оба.
После этого видео мне кажется я стал хуже понимать ООП и задался вопросом, а понимал ли вообще.
Соер сам не понимает ООП, ещё и людям пытается что-то обяснять. ваша ошибка в том что вы почему-то воспринимаете слова Соер как правду
@@pin689 никто не понимает ООП, только думают, что понимают. И у каждого свой ООП
Весьма поучительно, спасибо!
Очень круто !
Впринципе ничего сложного если правильно начинать с самого начала.
Почаще нужны такие видео.
Это приблизительно тоже самое как осваивание речи у малых детей.
Звуки.
Буквы.
Слова.
...
Вот это я ппозрел))
Видео просто топ! Вот бы еще разобрать на примерах)
За такой подробный разбор спасибо. Правда, спасибо. Задача хоть и простая, но повзволяет сразу увидеть, как мыслит человек. Я бы первым своим решением-приближением сделал бы функцию типа human_drink_from_cup() нарочно без классов. Всё-таки задача стояла примитивная, а мы начали фантазировать, а что будет если...
Super!😁😁😁😉
А это нормально если мы сделаем следующую иерархию интерфесов для класса кружки:
> INTERFACES
СпособныйСодержатьЖидкостьИнтерфейс (из шланга воду льют нам прямо в рот, то есть воздушная среда, способная содержать жидкость)
^
УглублениеИнтерфейс (жидкость в лужах)
^
СосудИнтерфейс (классы: кружек, бутылок)
< INTERFACES
Таким образом:
class UserActionControllerInterface
{
function drink(человекИнтерфейс, СпособныйСодержатьЖидкостьИнтерфейс);
}
Ок?
я бы очень хотел больше подобных роликов, пусть в них будет говориться одно и тоже, желательно конечно усложнение проекта, которого нам дают, но стольже просте объяснение
Какое название контроллера посоветуете для 3го варианта реализации? humanVessalController с функцией drink()
Тю, по факту ты пришел к 2xDTO да ActionHandler, можно даже прикрутить третью DTO, которая описывает саму жидкость и "переливать" её из одной ДТО в другую. Но! Ты правильно заметил в самом начале, что очень важно "можем ли мы изменять систему", потому что иногда такое вот усложнение просто нерационально и не имеет смысла, если ты точно уверен, что никаких векторов развития никуда и никогда не будет в обозримом будущем, а нужно просто сделать в лоб и забыть. Типичная проблема программистов - когда просят построить садовую тачку, мы, по привычке, закладываем в конструкцию возможность расширения для реализации полётов на ней в космос с табором цыган на борту.
😂
Так выходит, что human не человек, а кукла, который не может сам пить, а нужно, чтобы кто-то поил
В некоторых книжках пишут, мол, ООП нужен ещё и для того, чтобы не абстрагироваться от реального мира и что обычному человеку легче мыслить в рамках ООП. Чем больше изучаю, тем больше понимаю, что это не так. ООП становится всё дальше от реальности.
@UCYB1-bWEzfKGTBSt6a5YoHw а ведь реально, если посмотреть на весь процесс инициализации (рождения) нового экземпляра человека (разных классов / национальностей и тп, унаследованных об супер-классов вверх по иерархии), то инстинкты - это firmware запрограммированный в контроллере физобъекта (с помощью биодисков- генов), а обучение в процессе жизни - это натаскивание его нейронной сетки через звуковые, световые и прочие интерфейсы (рефлексы как драйверы соответствующих IO-девайсов у человека);
языки общения тоже разные у разных групп людей (но все так или иначе компилируются в некий гуманоидный IL низкого уровня), шины (СМИ, племенные и родовые связи) и брокеры сообщений тоже имеются - и многие великие "менеджеры (ака манипуляторы)" давно эти фреймворки выучили :))
весь "гософициоз" с его законами и документами очень уж филофоски напоминают xml
@@fj8017 класс Human - это не человек, а некоторый "представитель" человека в нашей системе. И так получается, что представители не обязаны разделять свойств и отношений тех, кого представляют. Например, есть муж и жена, которые разводятся, а есть адвокаты - их представители в этом процессе. Маловероятно, что адвокаты тоже разводятся при этом. Или классический пример с наследованием квадрата от прямоугольника отражает тот же феномен.
Поэтому я бы не стал утверждать, что объекты в ООП так уж далеки от реальности. Просто мы оперируем не самими объектами, а их поведением.
Очень круто!!!
Спасибо огромное за контент)
Отличный пример как программист вместо решения задачи сразу пишет свой фреймворк. Если не известны вектора развития компонентов этого решения то и усложнять не надо. На третьем добавлении схожего функционала сразу обозначится вектор, и надо будет только его учесть. В итоге меньше кода, и он будет отражать предметную область, а не непонятные фантазии программистов (замечу, программистов много, а проект один, а значит проще понимание кода проекта). А также проще отрефакторить код одного экрана, чем 10 файлов. P.S. Кстати, в третьем решении вся сложность будем в этом контроллере, где придётся обрабатывать, что лошадь не пьёт из стакана, а только из ведра, попахивает кучей if-ов, или ещё одним паттерном на 10 файлов.
То есть надо всё переписывать, когда станет известно. Ну ок..
1. Давно уже придумали фреймворки. Там все что нужно для 3-го варианта реализовано, генераторы кода есть и прочие "плюшки".
2. Вы про полиморфизм слышали? Например, ad-hoc полиморфизм без всяких if-ов вызовет вам нужную реализацию, если же про языки с утиной типизацией и поддержкой мультипарадигм, то там есть замечательные декларативные подходы вместо if/switch, которые используют функции первого порядка. Да и контроллер может существовать не в одном варианте, если речь про модульный подход, то можно конфигурировать модуль, использовать DI и т.д. Короче нет там никаких "кучи if-ов". Было бы желание думать, а не решений полно.
@@crutchmaster9637 лично мне проще переписать 10 строк кода, а не 10 файлов. А Вам?
@@АлексейТитов-д9э Строк кода минимум на тысячу надо умножить и подумать еще раз.
@@S0ERDEVS Вы комментируете 3-е решение в абстрактном вакууме, а не в реальном проекте, где что-то меняется, в задаче изначально неправильный акцент выставлен, что-то неизвестно на момент первых итераций, когда программисты уходят и болеют, ищутся баги по куче файлов, человек пытается уложить в голову логику. Это решение вообще это всё игнорирует. Понятно, что где-то такой подход реально отлично ложится и спасает от проблем в будущем, но не в случае рядовой задачи "попить воды".
Примеры уж тогда надо подбирать более корректней, чтобы не было иллюзий, что там где есть решение в одну строку, надо генерировать кучу новых файлов и новых абстракций
Очень полезное видео! Много в чем разобрался.
5:30 Хорошее объяснение интерфейса..,.... 5+!
Клево, когда можно посмотреть контент в котором вообще ничего не понятно, но реально интересно
Супервидос, спасибо
Первый видос который досмотрел до конца. Оооч интересный формат :)
Интересно!!
Очень полезное видео! Спасибо за информацию.
Сущность Существо. Сущность Емкость. Сущность Жидкость. Все наследуется от этих глобальных классов. человек корова, бутылка чашка корыто. вода чай ром. Это первое что пришло мне в голову.. Больше такого материала! Очень круто!
Круто! Спасибо за видео. Буду использовать
Спасибо 🙌🔝
Всегда стараюсь делать как в последнем варианте. При дальнейшем развитии системы, когда "инфраструктура" уже готова можно извращаться как угодно, подменяя само описание взаимодействия через стратегию. Написать переливание из чашки в другую чашку или высасывание мозгов человека другим человеком можно будет относительно быстро и красиво.
@@ДмитрийМязин-л5ш при этом самые кринжевые варианты - это как раз таки хотелки заказчика. Например, чтение pdf ж***й и выдача анализа этого pdf ртом...
Интересует вариант выпивания чашкой человека
То есть у человека будут открыты методы изменяющие его состояние при питье, без самого питья?
Очень правильно все изложено, но не согласен с аналогией с MVC. MVC - это все-таки другое (ну контроллер точно в данном случае должен быть заменен на бизнес логику), а тут чистая 3-ех слойная архитектура - UI, бизнес логика (BL), и data access layer (DAL)
3:00 Не совсем понятно, а почему нарушается LSP если мы даже не видим реализации? Вдруг код написан так, что замена Cup > Bottle и наоборот ничего не поломает в коде, а значит LSP нарушен не будет?
В этой модели действительно легко написать так, чтобы ничего не поломалось. Но когда бутылка и чашка обрастут другим функционалом, уже вероятны проблемы. И просто логически бутылка не является чашкой. Это как минимум будет сбивать с толку при чтении кода
Спасибо за видео, классный ролик
Создаем новые классы желудок, печень, почка (одна), горло, рот, рука (одна), пиписька опционально - попа. Через агрегацию внедряем в человека. Никакого наследования. Потом, по цепочке (забыл паттерн) передаем чашку (сосуд) и человека в каждый класс. Ранее названные органы изменяют состояние человека и чашки.
Спасибо, очень интересно было посмотреть
что-то про MVC Остапа понесло). Это просто две модели, взаимодействующие между собой через интерфейс
Спасибо, было интересно! Не хватило только визуализации в виде кода.
Дядя Боб? Вы здорово выглядите)
Забавно смотреть как java-ООП продается программистам как универсальное средство в котором можно мешать котлеты и мухи, а потом эти же программисты всеми правдами и неправдами пытаются отделить котлеты от мух, но на уровне архитектуры :)
Жаба-ооп - это такая религия. (У них там даже есть должности евангелистов) Вот, кто-то проповедовал, кто-то уверовал, а потом выясняется, что земля не плоская.
Браво, шикарно рассказал
Имхо. Проблема третьего варианта в том, что там нет ООП. Это называется анемичная модель, где у нас есть сервисы, они являются чем-то вроде процедур, а есть ентити, которые просто тупые стракты. Проблема такого подхода, что у нас нет как таковой объектной модели и мы любым случайным сеттером
Любым случайным сеттером можем сломать доменную логику.
>Проблема третьего варианта в том, что там нет ООП.
Не вижу в этом никакой проблемы.
Здесь нет бизнес-логики, поэтому о какой "анемичной модели" может идти речь? У нас есть транзакция и DTO-ка которая служит для переноса данных. При появлении бизнес-логики (и об этом было сказано в видео) она попадает в человека.
Попробуйте сделать "не анемичную" модель с имеющимися данными, тогда вылезет много вопросов.
@@S0ERDEVS Спасибо за ответ. Если инварианты будут обеспечиваться на уровне entity, например при отрицательном количестве жидкости в чашке будет вылетать исключение, а класс Drink будет передавать его в представление то это допустимый вариант.
Осталось сделать последний шаг - избавиться от состояний. Т.е. заменить "action" на функцию и заменить интерфейсы алгебраическими типами. И вот уже нормальная функциональная модель, без всяких костылей.
Кстати, в первом примере полиморфизм тоже есть - ad-hoc polymorphism.
Чем ближе к совершенству, тем ближе к функциональщине (или к математике) :D
Вы предлагаете мыслить как компьютер?
@@РусланСитников-у4м ровно наоборот :)
"мыслить как компьютер" - мыслить императивно, моделируя Машину Тьюринга в голове (операциональная семантика), описывая последовательность инструкций.
А в математике наоборот, торжество декларативности (денотационная семантика). В математике (и функциональщине) мы обычно не расписываем последовательность инструкций для получения чего-то, а описываем свойства этого чего-то.
@@АнимусАнанимус декларативный подход это подача данных на вход и заявление того что мы ждём на выходе, а как это уже будет реализовано - для нас чёрный ящик, шаги мы не описываем. В ФП мы ведь как раз таки описываем последовательность команд в виде последовательности вызова функций, т.е. применяем императивный подход, разве нет так?
@@РусланСитников-у4м Нет. Последовательность никак не противоречит декларативному подходу. Очевидно, что некоммутативные операции зависят от порядка выполнения, при любом подходе. Императивный подход это не про последовательность. Это про то, что операции могут изменять внешнее, по отношению к функции, состояние, в то время как функции зависят только их аргументов.
Хотелось бы увидеть решение этой задачи в стиле Типажей и Структур как в Rust. Будет ли это проще?
Первое что приходит на ум - это структура человек для которой реализован типаж Drink. Есть тип сумма(enum) Vessel, которая содержит все возможные сосуды.
Классное видео, спасибо)
Понравилось видео, MVC подходом реализации задачи впечатлён.
Прикольно, спасибо!
А действие даже не "пить", а скорее "перелить" из IVessel в IVessel. Тогда можно будет и из чайника в чашку перелить, а потом уже в человека
Тип жидкости не влияет на сосуд, а на человека влияет ) А что бы влиять на сосуд, тут уже появляется вид жидкости - например кислота, расплавленный металл, лава. Крч мне кажется тут уже зависит от уровня абстракции и решаемой задачи.
@@Enthusiast91 вот и вопрос, что если жидкость способна влиять на сосуд со временем(кислота, лава) чтобы материал сосуда на это влиял, но при этом не реализовывать одно в другом
Круто, спасибо
Спасибо за видео. Пора уже на патреон подписываться. Контент очень качественный.
Жень, а смотри какая штука получается с этим mvc. Вроде все у нас объектно-ориентированное и по всем Solid и прочее. Но это все красиво работает когда состояние объекта в памяти долго висит. Чаще же нижний слой с состоянием уже хранится в сторедже каком то. И тут как возникает тема, что фактически у нас остаётся только метод перегонки из одного состояния в другое. И почему бы не взять для этого функциональный язык или какой то более функциональный подход.
Вот все больше всяких апи и микро сервисов пишется, которые просто данные перегоняют, и по факту мы просто функцию оборачиваем в класс, в котором нам больше ничего не надо. И внимание вопрос, зачем тогда вообще класс и ООП в таких проектах
Функциональный подход - прекрасен. Вопрос лишь в том как такие реализации поддерживать на большой дистанции и большой командой.
Плюс ООП, в том что он более структурированный. Тогда как функциональщики любят в любых непонятных ситуациях заворачивать функции в другие функции, что в итоге приводит к сложностям в поддержке, дебаге и прозводительности.
Все эти парадигмы: процедурная, функциональная, ООП, etc. созданы для борьбы (преодоления) со сложност(ью/и). Философски, существует два подхода к представлению мира: атрибутивный и функциональный. Представляют вселенную в виде супер-пупер-гипертекста атрибутивисты, а функционалисты в виде взаимодействующих потоков энергии-вещества. ООП использует оба подхода, функциональный - методами, атрибутивный - полями, и борется со сложностью инкапсуляцией и абстрагированием. Это самая компромиссная и простая для понимания парадигма, оттого она и столь жизнеспособна.
@@mikhailkh8560 ФП подход помогает хорошо структуировать код - чистые функции это уже очень хорошо фаргментированая сущность с очень прозрачной и предсказуемой природотой. И на выходе получается приложение где первыми идут данные а потом операции над ними, которые легко композируются и тестируются, "грязные" области тоже будут, но они будут более локализированы, что только плюс в контексте структурировании программы.
А по поводу функций обёрнутых в функции... тут ничего сложного нет, вы же наверно заворачиваете объекты внутри объекты и умеете работать и понимать такой код - вот так же с функциями, только по проще :)
@@ievgenk.8991 В теории я с вами абсолютно согласен. А вот на практике ни разу ничего хорошего не видел. Наверное я просто не везучий.
А есть на условном гитхабе проект написанный подобным образом, при этом читаемый, расширяемый, легко, дебажащийся и живой?
Очень неожиданная концовка, смотрел с упоением. Спасибо.
soer, ты Большой Человек)
Если не сформулирована чётко цель, то такое нельзя надёжно спроектировать, потому что нельзя определить уровень абстракции
Поговорка "Моешь чашку - думай о чашке" зазвучала по-новому))
Молодец, грамотно. Думал будешь drink прикручивать к человеку, а потом к чашке попадая в классическую ловушку ООП.
что за классическая ловушка?
@@alexjuly7097 когда создают иерархическую систему, что бы объединить два необьединямых множества.
хочу увидеть как все эти рассуждения будут применены для создание игры на юнити, где будет человек, и он будет пить и всё это с этими концепциями. и показать на практике как добавлять новый функционал в программе
Уважаемый S0ER, есть вопрос. Не совсем понятны в вашем варианте интерфейсы человека и ёмкости. Насколько я понял, предполагается, что у человека есть метод наподобие Drink(liquidType, volume), а у ёмкости метод получения её содержимого? Или команда (а насколько я понимаю, здесь использован именно этот шаблон) Drink просто в лобовую меняет состояние человека через get/set? Но тогда человек получается какой-то весьма анемичной моделью данных, которая уже ничего не инкапсулирует. Так же непонятно, как решается проблема "раздувания" модели человека - ведь каждая новая команда может влиять на совершенно разные детали состояния человека, и их число также будет расти. Насколько я понимаю, если заказчик хочет интенсивно расширять модель влияний на человека, то что-то всё равно будет раздуваться. В таком случае, возможно, ситуацию бы несколько упростил паттерн Состояние, только в модели человека был бы не один экземпляр состояния, а несколько (по количеству интересующих нас, как разработчиков, органов). Т.е. у каждого органа - своя сущность, а модель человека стала бы агрегатом в терминах DDD.
Вагон лайков отправлен на разгрузку: 🖤🖤🖤🖤🖤🖤🖤🖤🖤🖤
После этого всего правда у меня остался вопрос - а как назвать класс, который будет пить из кружки в человека?
простите за каламбур
PourDrinkIntoHuman :)
@@ДмитрийМязин-л5ш так как назвать то?
@@gennady8263 название класса должно быть существительным
я не просто так заостряю на этом внимание.
есть такой запах кода - если мы не можем быстро и однозначно придумать короткое название для класса, которое будет отражать его суть,
то возможно этот класс задизайнен плохо
@@ДмитрийМязин-л5ш забавно, мы вернулись к самому первому решению, только слово Human заменили на HumanController :)
хорошее объяснение, работать будет. только вот весь этот паттерн, происходит из ущербности принципов построения С++ классов. Объект дринк - фактически состояний не имеет. Человек и чашка сводятся к набору интерфейсов суть которые геттеры и сеттеры. В альтернативной реальности Лиспа, есть CLOS, который изначально говорит что классы сводятся к геттерам и сеттерам, а вместо виртуальных классов действий, существуют обобщенные методы, не принадлежащие к классам. Создав одну обобщенную функцию вы можете добавлять туда взаимодействия произвольного кличества типов объектов. Т.е CLOS позволяет избежать создания трех не нужных сущностей действия и 2х интерфейсов. т.е сам этот паттерн уже заложен в CLOS.
Подскажите, что используется для рисования на фоне какого-то контента на экране
@@patrickowens7665 я спрашивал, что использует именно автор в своих роликах.
А не твое мнение идиота.
Комментарии как всегда выявляют довольно плотную группу людей которые хотят совершать ошибки под лозунгом "делаем в лоб, чтобы быстро дать заказчику ценность. И потом даже не учиться на них под лозунгом из серии "нельзя было предусмотреть, заказчик внёс несовместимые требования". Это вместо того чтобы понять что проблема в тебе как разработчике. Автор же ролика не говорит что он построил идеальную систему про кружки. Он пытается донести как на практике использовать понятие вектор развития и управлять энтропией которая при этом порождается. А комментаторы *от сохи" концентрируются на каких то не важных деталях.
В MVC паттерне бизнес логика представляется в модели. Почему на диаграмме бизнес логика находится к контроллере? 16:37
А что в твоем понимании бизнес логика в этой задаче?
@@S0ERDEVS Я задал вопрос исходя из того, что вы представили на диаграмме, а не исходя из своего понимания. Я пытаюсь понять, что вы имели в виду. Или я не правильно понимаю картинку, и Action-Drink находится не в слое бизнес логики?
@Seb Ler ты неправильно понимаешь картинку и Action-Drink это не бизнес-логика.
@@S0ERDEVS Объясните пожалуйста картинку. Я думал, что на ней изображены снизу вверх три слоя:
1. Слой данных
2. Слой обработки данных (т.е. бизнес логика)
3. Слой представления данных
Которые в свою очередь соответствуют:
1. Model
2. Controller
3. View
из MVC паттерна
@@S0ERDEVS, а бизнес-логика в этой задаче вообще есть? Где она?
С точки зрения чистой архитектуры на данное чаепитие должен быть UseCase-интерактор, который будет манипулировать взаимодействием хумана и чашки, за тем отправит результат куда следует.
Интерфейс не наследуется, он реализуется.
Как насчёт создать базовый класс Сосуд и создать класс Человек который наследуется от Сосуда, ведь человек в этой задачи ничто иное как сосуд! И стакан сосуд, а жидкость это данные которые перетекают из одного сосуда в другой. Вот она красота истинного ООП!
А второй способ позволит реализовать изменение стейтов обоих объектов в транзакции? 🧐
Через полиморфизм тоже норм будет. Метод пить у человека, сосуд абстрактный класс с состоянием, обработкой исключений и виртуальным методом опустошить. Внутри своего пить, человек вызывает метод опустошить сосуда.
Круто.👍
Кабздец. Как было хорошо во времена qbasic and turbo pascal.
Иди масштабируй свой код теперь на этих языках. Если ты маразматик, любящий писать всё с 0 каждый раз, то пожалуйста
спасибо за совет, но в нем я ненуждаюсь
Спасибо
3 вариант похож на то как это принято в Golang.
Есть 2 интерфейса и функция обеспечивающая их взаимодействие. Ошибки пробрасываются наружу для обработки.
Это наверное ещё один намек что это не ООП дизайн)
А почему чашка - "cap", а не "cup"?
1:21 - правый нижний угол ;)
Спасибо! за разбор. Но жаль, что нет UML-диаграмм.
человек- обьект, чашка - обьект, а действие это простая функция ,или класс в котором методы это действия?