Проектируем чашку, человека и метод "пить"
HTML-код
- Опубликовано: 24 ноя 2024
- #soer #itubeteam
Основной канал для общения и публикации новых видео - Телегарм - t.me/softwaree...
Спонсорство - donate.s0er.ru
Сайт платным контентом - soer.pro
Зеркало для видео Дзен Видео - zen.yandex.ru/...
GitHub - github.com/soe...
Чат для программистов - / discord
Группа ВК - codeart...
Никогда ещё человек не пил так осознанно
Ахахах +++
😂🤔
😂😂😂
Отличное видео и подача. Очень хочется ещё подобных видео
Согласен. С таким объяснением даже новички без особого труда поймут смысл ооп.
Согласен. Мне тоже не хватает такой информации.
Предлагаю разнести человека и чашку в разные микросервисы =)
Очень важна постановка задачи
Сидит мужик, листает газету, видит объявление: Раскидать песок. 500₽
Позвонил, заказчик:
- Придёшь, раскидаешь песок, заплачу 500₽, договорились?
Мужик согласился.
Приходит, а там 3 камаза песка. Говорит заказчику:
- Тут 3 камаза песка, подними оплату
Заказчик ни в какую. "Мы договорились, слово держи"
Мужик взял жменю песка, швырнул в сторону и говорит:
- Давай оплату
- ??
- Мы не договаривались, что раскидаю весь песок
надо было NDA подписывать
"Рабинович с одной стороны и Одесское пароходство с другой..." (с) анекдот
@@roman-bolkhovitin хD
@Старший Санитар " - Если хоть кому-то расскажешь, что мы тут самосвалы с песком разгружаем на халяву - Мы быстро тебе жизнь подпортим. "
@@dmtpp он пример тебе показывает, а ты язвишь, негодяй
Задача кажется слишком абстрактной, по этому ее так не просто решить. Тут следует уточнить для чего мы моделируем данную систему. К примеру это может быть симулятор процессов организма человека или Игра, где человек может пить. И для каждого типа системы следует подбирать подходящую модель.
Дело в том, что любая задача которую нужно запрограммировать должна в конечном итоге совершать какие-либо I/O операции, иметь side-эффекты.
Это должен быть вывод на экран, запись на диск и передача данных по сети, вывод звука.
Задача должна быть сформулирована в этих терминах, иначе это это очередной фейк, и подмена понятий.
Так происходит с каждым ООП-туториалом, потому что ООП, так получается, крайне скверно ложится на то чтобы задача была описана в терминах того что должен сделать компьютер, вот и приходится придумывать манявселенную с человек.пить и прочими мяукающими котами и гавкающими собаками.
В реальности получаются Фабрики.СделатьАбстрактныйОбъект и Менеджеры.ЗапуститьПроцесс2
Такой контент я давно искал. Но ютуб считает что в рекомендации лучше положить как 8 лет назад Камаз утонул
Реализовывал бы эту задачу первым, самым быстрым и простым способом.
Если бы появлялись новые требования, переписывал бы код, двигаясь к последнему способу по мере необходимости.
Новые требования могут и не появиться, а мы сделаем 10 уровней абстракций, которые нам не понадобятся.
Оно конечно здорово, когда тебе это не нужно будет поддерживать и расширять.
Сделать на коленке фундамент из дерьма и палок, чтобы хоть как-то, а потом удивляться - Что же это разработка стала такой дорогой и долгой.
Норм, я бы взял 2 вариант, для тестов, которые не пишу.
А по поводу обновления стейта человека подумать надо, чтобы он не стал анемичной моделью которая работает только через сервисы, но и сам по себе что то мог.
Не расширял и не переписывал бы, а просто перешёл бы на другой проект. А на этот проект пришёл бы какой нибудь другой разработчик, от которого бы потребовалось расширить функционал. И тот бы сначала схватился за голову и стал переписывать то, что уже написано (надеюсь, что третьим способом, но не факт), при этом срывая дедлайны, работая овертайм и делая заказчика очень недовольным. А теперь представь, что второй человек - это ты. (А первый был кодер из Индии.)
@@konstantinkouptsov7513 как же жизненно
Вот где становится явной важность корректности и полноты требований к задаче. При простой постановке задачи - есть Человек, который Пьет из Кружки, явно нужно использовать первый вариант. Просто другие варианты противоречат KISS и YAGNI.
Хотели банан, а получили гориллу с бананом в джунглях.
Реализация огонь 🔥
Очень понятное обяснение не только про проектирование, но и про применение ратернов, очень классно!)
Первый раз в жизни увидел настолько крутое объяснение mvc, продолжайте, у вас потенциал, с удовольствием послушал бы и про другие паттерны.
В начале видео говорится, что необходимо спроектировать ситуацию в ооп парадигме. На самом деле получилась анемичная модель, которую дергает контроллер. Мало того что паттерн mvc предполагает логику размещать в моделе, а не в контроллере, так ещё и нарушается один из главных принципов ооп дизайна - information expert. Контроллер управляет состоянием чашки и человека, вместо самих сущностей. Полученное решение напоминает паттерн transaction script
нет, ты путаешь модель и сущность. Доменную модель с доменной логикой, контроллером, моделью данных. Модель может быть пакетом (слоем), в котором есть отдельные доменные модели и отдельные бизнес-правила. Контроллер уже предоставляет методы, формализующие пользовательские запросы, отделяя интерфейс (GUI) от реализации (данных и бизнес-правил). Есть и другой вариант MVVM, там без контроллера, каждой пользовательской страничке присуща некоторая бизнес-сущность.
Вообще, модель данных как раз должна быть максимально простой (плоской), без поведения., обычно хранится в базе в виде таблиц. На ее основе уже можно создавать сущности (через интерфейс) с поведением, которые и будут реализовывать присущую только им логику. А в случае на видео, логика не относится к одной сущности, бизнес-действие должно поменять состояние сразу нескольких объектов. Поэтому его нельзя приписывать к этим сущностям.
Классный разбор! Спасибо за труды) на самом деле на таких абстрактных, но близких к реальному миру, вещах интересно пробовать учиться проектировать. Такое упражнение для мозга)
Это конечно весело, но на деле усложнение системы.Все же помнят про KISS и бритву Оккама. Вот мы заложили эту возможность расширения системы, хорошо, а расширения - никогда не произошло, но кодовая база стала сложнее для понимания новым разработчика и они уже чтобы решить задачу по добавлению новой логики - тратят не 10 минут, а 2 часа, потому что в реальных проектах будет на DrinkController, а какая-нибудь монструозная фигня, с фасадами, прокидыванием событий, мостами, медиаторами, декораторами фабриками и прочим-прочим и чтобы добраться уже до самой логики - придется нехило постараться.
В общем. На мой взгляд - второй вариант - неидеален, но он прост, он довольно расширяем, а главное он не прячет логику за отдельной сущностью. Опять же, тут пример довольно простой, но ведь взяв на вооружения подобные принципы - люди начинают все декомпозировать-декомпозировать, выделять сущности(вот вам выпивака, закусака и наливака, а вместе они образуют студента), выделять интерфейсы, в итоге куча каких-то кусков логики лежат в воздухе а как оно собственно работает - может понять только тот кто это написал(и то не факт), либо человек, которому не жаль было потратить неделю времени.
Так фреймворки же берут на себя всю грязную работу, никто с нуля не пишет. Или вы пишете?
@@S0ERDEVS В веб-разработке, скорее всего, никто с нуля не пишет, но есть множество других доменов. Например готовые фреймворки для автомобильной индустрии мне не известны. Однако там так же успешно используются и микро сервисы, и MVC, и дизайн паттерны.
поэтому сначала рисуются схемы из которых сразу понятно, что с чем взаимодействует и куда вносить изменения. И не придется десятки тысяч строк кода вычитывать, прыгая по файлам, каждый раз. Если схем нет, то надо в первую очередь их сделать. а потом уже браться за изменения. Иначе, нередко дешевле будет заново переписать на современный лад.
Побольше таких нужно, спасибо!
Спасибо за видео! Прекрасный формат видео (рубрика)! Лайк
Потрясающая🌞 подача материала 🌞
Понятно даже мне
Спасибо! Очень интересно по содержанию. Очень круто по визуалу!
Каждое видео очень воодушевляет.
Спасибо за ёмкое объяснение таких тонких (особенно для новичков) моментов! 😌
Конечно тут представлен простой пример, но мне кажется он отражает суть современной разработки. Можно гнаться сколь угодно за принципами и паттернами, но когда вы попадаете в среду, где предметная область для вас в новинку, а требования и сроки уже обозначены, вы будете проектировать архитектуру под текущие требования так, как вам кажется правильно. При этом вы еще n-ое количество раз будете пересматривать свои наработки. А когда вам покажется, что вы все контролируете, то появится требование, осознав которое, вы прошепчете у себя в голове: "*лядь, как я сразу это не учел?"
Поэтому Роберт Мартин топит за TDD, чтобы можно было делать безболезненный рефакторинг.
@@ОлегМосягин-р8й Как тесты, написанные для 1 варианта помогут сделать безболезненный рефакторинг в последний вариант? :) Да там процентов 90 тестов надо будет переписывать, и еще неизвестно сколько писать новых :)
Тесты нужны при точечных доработках и расширении системы скорее, нежели при глобальном рефакторинге.
@@dmitriyobidin6049 никак, если изменились интерфейсы и разделение на модули, то и тесты придется переписать. Но по крайней мере тесты провоцируют писать более мелкие и узкоспециализированные модули. Просто если у нас весь проект состоит не только из этих двух классов, а есть что-то еще, то тесты позволят убедиться, что остальный проект не сломается, пока мы переписываем эти два класса с тестами на них.
Предлагаю объединить сущность сосуд и человек
Человеко-сосуд
Тогда человек может пить из другого человека хоть до бесконечности
это уже система вампиризма
Да! И тогда можно будет не только пить человеку, но и даже переливать из бутылки в чашку.
ты про свою жену?
Прекрасное видео!! 👍🏻 Благодарю!! Всё предельно понятно!! 😊
Чисто доступно и понятно. + за продолжение подобных видео.
Отличный материал, хотелось бы продолжения. Спасибо
Когда меня спросят почему я люблю процедурный стиль - я покажу это видео
Так в итоге у него и получился процедурный стиль. Две структуры (human и cup) и функция (action). ООП тут и нет никакого
Не хватает примера реализации кодом в итоге. Вроде понятно, но вдруг не так понял.
Любой проект на java spring открой)
You Ain’t Gonna Need It. Делать нужно то, что нужно, то что стоит в задаче, а то, чего в задаче нет, делать не нужно. А если когда-то заказчик что-то поменяет, то он заплатит за новую задачу. А нам опять нужно будет делать только то, что нужно, то что в задаче... Жду новое видео!
И, однажды, на требование добавление нового сосуда, заказчик услышит сумму в 100500 человеко-часов и пошлет Вас и Ваш подход далеко-далеко
@@ИванИванов-р1г4х на это есть другие приемы работы. Например "если общий код встречается 3 и более раза, то нужно обобщить и переиспользовать".
Цифра 3 может меняться в зависимости от, но метод довольно полезный как средство сдерживания и оверинжиниринга, и повторения кода.
После этого видео мне кажется я стал хуже понимать ООП и задался вопросом, а понимал ли вообще.
Соер сам не понимает ООП, ещё и людям пытается что-то обяснять. ваша ошибка в том что вы почему-то воспринимаете слова Соер как правду
@@pin689 никто не понимает ООП, только думают, что понимают. И у каждого свой ООП
Весьма поучительно, спасибо!
Для полного разрыва шаблона после Лисков и SRP новичку следует изучить принцип KISS
Вот это я ппозрел))
Видео просто топ! Вот бы еще разобрать на примерах)
Очень круто !
Впринципе ничего сложного если правильно начинать с самого начала.
Почаще нужны такие видео.
Это приблизительно тоже самое как осваивание речи у малых детей.
Звуки.
Буквы.
Слова.
...
Второму видео точно лайк за продолжение первого, за оба.
Видео точно отражает три стадии мучения программиста при получении новой задачи: 1) и так сойдет 2) а что если?... 3) господи, что ЭТО?!!!
нет там ни каких стадий мучений, с опытом ты клепаешь эти интерфейсы и классы по 50+ штук в день не задумываясь. паттерн простейший - стратегия. про то что метод пить должен иметь единственную ответственность так же прозрачно.
я бы очень хотел больше подобных роликов, пусть в них будет говориться одно и тоже, желательно конечно усложнение проекта, которого нам дают, но стольже просте объяснение
Первое видео про ООП, которое я нашел для себя очень интересным
Спасибо, было интересно! Не хватило только визуализации в виде кода.
Первый видос который досмотрел до конца. Оооч интересный формат :)
Всегда стараюсь делать как в последнем варианте. При дальнейшем развитии системы, когда "инфраструктура" уже готова можно извращаться как угодно, подменяя само описание взаимодействия через стратегию. Написать переливание из чашки в другую чашку или высасывание мозгов человека другим человеком можно будет относительно быстро и красиво.
@@ДмитрийМязин-л5ш при этом самые кринжевые варианты - это как раз таки хотелки заказчика. Например, чтение pdf ж***й и выдача анализа этого pdf ртом...
Интересует вариант выпивания чашкой человека
Очень полезное видео! Много в чем разобрался.
Круто! Спасибо за видео. Буду использовать
Очень полезное видео! Спасибо за информацию.
За такой подробный разбор спасибо. Правда, спасибо. Задача хоть и простая, но повзволяет сразу увидеть, как мыслит человек. Я бы первым своим решением-приближением сделал бы функцию типа human_drink_from_cup() нарочно без классов. Всё-таки задача стояла примитивная, а мы начали фантазировать, а что будет если...
Клево, когда можно посмотреть контент в котором вообще ничего не понятно, но реально интересно
Очень круто!!!
Спасибо огромное за контент)
Хотелось бы увидеть пример реализации класса, представляющего процесс пития.
@@dmtpp Чтобы делать сложные и масштабные вещи, необходимо досконально постичь азы. Чтобы написать Войну и Мир, нужно сначала изучить азбуку, освоить слова и составление предложений. Эти вещи показательны. Я решил бы вопрос почти так же, но без класса-посредника, реализующего процесс пития. Мне вот и интересно как он будет реализован, будет ли агрегатом или композитом человека, а может вообще будет унаследован от глобальной божественной сущности Бахуса?
@@redserjogha класс может быть реализован как действие, где сначала читается состояние кружки и в соответствии с ним изменяется состояние человека. Это действие, опционально, так же может выбрасывать событие, что оно произвело процесс опорожнение кружки и наполнение жидкостью человека. В последствии, все кто слушали это событие, могут начать своё действие, например: проверка на то, что именно было выпито и вызов соответствующей реакции (ухудшение самочувствия или его улучшение, гипотермия/гипертермия, отравление/излечение, восстановление водного баланса или же дегидратация организма).
@@IgorLynn вы не. Observer описали в своем примере?
@@evgenasd8892 да, но он опционален. Суть в том что мы вводим третью сущность и она просто меняет состояние двух моделей.
У меня когда-то была похожая проблема, где было 2 космических корабля и они могли друг друга атаковать и наносить урон. Дилемма была в том, что не понятно у кого должно быть право наносить урон; должен ли атакующий корабль содержать метод DealDamage() и отнимать прочность/щиты у корабля которого он атакует или корабль который получает урон, должен содержать метод ReceiveDamage() и решать какой урон ему может нанести атакующий его корабль? По факту же, ни у кого из них не должно быть такой привилегии и доверия.
@@IgorLynn спасибо
Лукас и коммент в поддержку автора канала!)
Так выходит, что human не человек, а кукла, который не может сам пить, а нужно, чтобы кто-то поил
В некоторых книжках пишут, мол, ООП нужен ещё и для того, чтобы не абстрагироваться от реального мира и что обычному человеку легче мыслить в рамках ООП. Чем больше изучаю, тем больше понимаю, что это не так. ООП становится всё дальше от реальности.
@UCYB1-bWEzfKGTBSt6a5YoHw а ведь реально, если посмотреть на весь процесс инициализации (рождения) нового экземпляра человека (разных классов / национальностей и тп, унаследованных об супер-классов вверх по иерархии), то инстинкты - это firmware запрограммированный в контроллере физобъекта (с помощью биодисков- генов), а обучение в процессе жизни - это натаскивание его нейронной сетки через звуковые, световые и прочие интерфейсы (рефлексы как драйверы соответствующих IO-девайсов у человека);
языки общения тоже разные у разных групп людей (но все так или иначе компилируются в некий гуманоидный IL низкого уровня), шины (СМИ, племенные и родовые связи) и брокеры сообщений тоже имеются - и многие великие "менеджеры (ака манипуляторы)" давно эти фреймворки выучили :))
весь "гософициоз" с его законами и документами очень уж филофоски напоминают xml
@@fj8017 класс Human - это не человек, а некоторый "представитель" человека в нашей системе. И так получается, что представители не обязаны разделять свойств и отношений тех, кого представляют. Например, есть муж и жена, которые разводятся, а есть адвокаты - их представители в этом процессе. Маловероятно, что адвокаты тоже разводятся при этом. Или классический пример с наследованием квадрата от прямоугольника отражает тот же феномен.
Поэтому я бы не стал утверждать, что объекты в ООП так уж далеки от реальности. Просто мы оперируем не самими объектами, а их поведением.
Спасибо, очень интересно было посмотреть
что-то про MVC Остапа понесло). Это просто две модели, взаимодействующие между собой через интерфейс
5:30 Хорошее объяснение интерфейса..,.... 5+!
Дядя Боб? Вы здорово выглядите)
Интересно!!
Отличный пример как программист вместо решения задачи сразу пишет свой фреймворк. Если не известны вектора развития компонентов этого решения то и усложнять не надо. На третьем добавлении схожего функционала сразу обозначится вектор, и надо будет только его учесть. В итоге меньше кода, и он будет отражать предметную область, а не непонятные фантазии программистов (замечу, программистов много, а проект один, а значит проще понимание кода проекта). А также проще отрефакторить код одного экрана, чем 10 файлов. P.S. Кстати, в третьем решении вся сложность будем в этом контроллере, где придётся обрабатывать, что лошадь не пьёт из стакана, а только из ведра, попахивает кучей if-ов, или ещё одним паттерном на 10 файлов.
То есть надо всё переписывать, когда станет известно. Ну ок..
1. Давно уже придумали фреймворки. Там все что нужно для 3-го варианта реализовано, генераторы кода есть и прочие "плюшки".
2. Вы про полиморфизм слышали? Например, ad-hoc полиморфизм без всяких if-ов вызовет вам нужную реализацию, если же про языки с утиной типизацией и поддержкой мультипарадигм, то там есть замечательные декларативные подходы вместо if/switch, которые используют функции первого порядка. Да и контроллер может существовать не в одном варианте, если речь про модульный подход, то можно конфигурировать модуль, использовать DI и т.д. Короче нет там никаких "кучи if-ов". Было бы желание думать, а не решений полно.
@@crutchmaster9637 лично мне проще переписать 10 строк кода, а не 10 файлов. А Вам?
@@АлексейТитов-д9э Строк кода минимум на тысячу надо умножить и подумать еще раз.
@@S0ERDEVS Вы комментируете 3-е решение в абстрактном вакууме, а не в реальном проекте, где что-то меняется, в задаче изначально неправильный акцент выставлен, что-то неизвестно на момент первых итераций, когда программисты уходят и болеют, ищутся баги по куче файлов, человек пытается уложить в голову логику. Это решение вообще это всё игнорирует. Понятно, что где-то такой подход реально отлично ложится и спасает от проблем в будущем, но не в случае рядовой задачи "попить воды".
Примеры уж тогда надо подбирать более корректней, чтобы не было иллюзий, что там где есть решение в одну строку, надо генерировать кучу новых файлов и новых абстракций
Понравилось видео, MVC подходом реализации задачи впечатлён.
Какое название контроллера посоветуете для 3го варианта реализации? humanVessalController с функцией drink()
Осталось сделать последний шаг - избавиться от состояний. Т.е. заменить "action" на функцию и заменить интерфейсы алгебраическими типами. И вот уже нормальная функциональная модель, без всяких костылей.
Кстати, в первом примере полиморфизм тоже есть - ad-hoc polymorphism.
Чем ближе к совершенству, тем ближе к функциональщине (или к математике) :D
Вы предлагаете мыслить как компьютер?
@@РусланСитников-у4м ровно наоборот :)
"мыслить как компьютер" - мыслить императивно, моделируя Машину Тьюринга в голове (операциональная семантика), описывая последовательность инструкций.
А в математике наоборот, торжество декларативности (денотационная семантика). В математике (и функциональщине) мы обычно не расписываем последовательность инструкций для получения чего-то, а описываем свойства этого чего-то.
@@АнимусАнанимус декларативный подход это подача данных на вход и заявление того что мы ждём на выходе, а как это уже будет реализовано - для нас чёрный ящик, шаги мы не описываем. В ФП мы ведь как раз таки описываем последовательность команд в виде последовательности вызова функций, т.е. применяем императивный подход, разве нет так?
@@РусланСитников-у4м Нет. Последовательность никак не противоречит декларативному подходу. Очевидно, что некоммутативные операции зависят от порядка выполнения, при любом подходе. Императивный подход это не про последовательность. Это про то, что операции могут изменять внешнее, по отношению к функции, состояние, в то время как функции зависят только их аргументов.
Сущность Существо. Сущность Емкость. Сущность Жидкость. Все наследуется от этих глобальных классов. человек корова, бутылка чашка корыто. вода чай ром. Это первое что пришло мне в голову.. Больше такого материала! Очень круто!
Спасибо за видео, классный ролик
хочу увидеть как все эти рассуждения будут применены для создание игры на юнити, где будет человек, и он будет пить и всё это с этими концепциями. и показать на практике как добавлять новый функционал в программе
Спасибо 🙌🔝
Супервидос, спасибо
Имхо. Проблема третьего варианта в том, что там нет ООП. Это называется анемичная модель, где у нас есть сервисы, они являются чем-то вроде процедур, а есть ентити, которые просто тупые стракты. Проблема такого подхода, что у нас нет как таковой объектной модели и мы любым случайным сеттером
Любым случайным сеттером можем сломать доменную логику.
>Проблема третьего варианта в том, что там нет ООП.
Не вижу в этом никакой проблемы.
Здесь нет бизнес-логики, поэтому о какой "анемичной модели" может идти речь? У нас есть транзакция и DTO-ка которая служит для переноса данных. При появлении бизнес-логики (и об этом было сказано в видео) она попадает в человека.
Попробуйте сделать "не анемичную" модель с имеющимися данными, тогда вылезет много вопросов.
@@S0ERDEVS Спасибо за ответ. Если инварианты будут обеспечиваться на уровне entity, например при отрицательном количестве жидкости в чашке будет вылетать исключение, а класс Drink будет передавать его в представление то это допустимый вариант.
Тю, по факту ты пришел к 2xDTO да ActionHandler, можно даже прикрутить третью DTO, которая описывает саму жидкость и "переливать" её из одной ДТО в другую. Но! Ты правильно заметил в самом начале, что очень важно "можем ли мы изменять систему", потому что иногда такое вот усложнение просто нерационально и не имеет смысла, если ты точно уверен, что никаких векторов развития никуда и никогда не будет в обозримом будущем, а нужно просто сделать в лоб и забыть. Типичная проблема программистов - когда просят построить садовую тачку, мы, по привычке, закладываем в конструкцию возможность расширения для реализации полётов на ней в космос с табором цыган на борту.
😂
Очень правильно все изложено, но не согласен с аналогией с MVC. MVC - это все-таки другое (ну контроллер точно в данном случае должен быть заменен на бизнес логику), а тут чистая 3-ех слойная архитектура - UI, бизнес логика (BL), и data access layer (DAL)
Браво, шикарно рассказал
Очень неожиданная концовка, смотрел с упоением. Спасибо.
Super!😁😁😁😉
А это нормально если мы сделаем следующую иерархию интерфесов для класса кружки:
> INTERFACES
СпособныйСодержатьЖидкостьИнтерфейс (из шланга воду льют нам прямо в рот, то есть воздушная среда, способная содержать жидкость)
^
УглублениеИнтерфейс (жидкость в лужах)
^
СосудИнтерфейс (классы: кружек, бутылок)
< INTERFACES
Таким образом:
class UserActionControllerInterface
{
function drink(человекИнтерфейс, СпособныйСодержатьЖидкостьИнтерфейс);
}
Ок?
А действие даже не "пить", а скорее "перелить" из IVessel в IVessel. Тогда можно будет и из чайника в чашку перелить, а потом уже в человека
Тип жидкости не влияет на сосуд, а на человека влияет ) А что бы влиять на сосуд, тут уже появляется вид жидкости - например кислота, расплавленный металл, лава. Крч мне кажется тут уже зависит от уровня абстракции и решаемой задачи.
@@Enthusiast91 вот и вопрос, что если жидкость способна влиять на сосуд со временем(кислота, лава) чтобы материал сосуда на это влиял, но при этом не реализовывать одно в другом
Забавно смотреть как java-ООП продается программистам как универсальное средство в котором можно мешать котлеты и мухи, а потом эти же программисты всеми правдами и неправдами пытаются отделить котлеты от мух, но на уровне архитектуры :)
Жаба-ооп - это такая религия. (У них там даже есть должности евангелистов) Вот, кто-то проповедовал, кто-то уверовал, а потом выясняется, что земля не плоская.
3 вариант похож на то как это принято в Golang.
Есть 2 интерфейса и функция обеспечивающая их взаимодействие. Ошибки пробрасываются наружу для обработки.
Это наверное ещё один намек что это не ООП дизайн)
То есть у человека будут открыты методы изменяющие его состояние при питье, без самого питья?
Кабздец. Как было хорошо во времена qbasic and turbo pascal.
Иди масштабируй свой код теперь на этих языках. Если ты маразматик, любящий писать всё с 0 каждый раз, то пожалуйста
спасибо за совет, но в нем я ненуждаюсь
Интерфейс не наследуется, он реализуется.
Классное видео, спасибо)
Если не сформулирована чётко цель, то такое нельзя надёжно спроектировать, потому что нельзя определить уровень абстракции
Молодец, грамотно. Думал будешь drink прикручивать к человеку, а потом к чашке попадая в классическую ловушку ООП.
что за классическая ловушка?
@@alexjuly7097 когда создают иерархическую систему, что бы объединить два необьединямых множества.
Поговорка "Моешь чашку - думай о чашке" зазвучала по-новому))
Класс! Спасибо, а то вечно не учтенка возникает при расширении
Круто, спасибо
Вот бы увидеть реализацию третьего способа на псевдокоде
Создаем новые классы желудок, печень, почка (одна), горло, рот, рука (одна), пиписька опционально - попа. Через агрегацию внедряем в человека. Никакого наследования. Потом, по цепочке (забыл паттерн) передаем чашку (сосуд) и человека в каждый класс. Ранее названные органы изменяют состояние человека и чашки.
Прикольно, спасибо!
Через полиморфизм тоже норм будет. Метод пить у человека, сосуд абстрактный класс с состоянием, обработкой исключений и виртуальным методом опустошить. Внутри своего пить, человек вызывает метод опустошить сосуда.
Спасибо за видео. Пора уже на патреон подписываться. Контент очень качественный.
Жень, а смотри какая штука получается с этим mvc. Вроде все у нас объектно-ориентированное и по всем Solid и прочее. Но это все красиво работает когда состояние объекта в памяти долго висит. Чаще же нижний слой с состоянием уже хранится в сторедже каком то. И тут как возникает тема, что фактически у нас остаётся только метод перегонки из одного состояния в другое. И почему бы не взять для этого функциональный язык или какой то более функциональный подход.
Вот все больше всяких апи и микро сервисов пишется, которые просто данные перегоняют, и по факту мы просто функцию оборачиваем в класс, в котором нам больше ничего не надо. И внимание вопрос, зачем тогда вообще класс и ООП в таких проектах
Функциональный подход - прекрасен. Вопрос лишь в том как такие реализации поддерживать на большой дистанции и большой командой.
Плюс ООП, в том что он более структурированный. Тогда как функциональщики любят в любых непонятных ситуациях заворачивать функции в другие функции, что в итоге приводит к сложностям в поддержке, дебаге и прозводительности.
Все эти парадигмы: процедурная, функциональная, ООП, etc. созданы для борьбы (преодоления) со сложност(ью/и). Философски, существует два подхода к представлению мира: атрибутивный и функциональный. Представляют вселенную в виде супер-пупер-гипертекста атрибутивисты, а функционалисты в виде взаимодействующих потоков энергии-вещества. ООП использует оба подхода, функциональный - методами, атрибутивный - полями, и борется со сложностью инкапсуляцией и абстрагированием. Это самая компромиссная и простая для понимания парадигма, оттого она и столь жизнеспособна.
@@mikhailkh8560 ФП подход помогает хорошо структуировать код - чистые функции это уже очень хорошо фаргментированая сущность с очень прозрачной и предсказуемой природотой. И на выходе получается приложение где первыми идут данные а потом операции над ними, которые легко композируются и тестируются, "грязные" области тоже будут, но они будут более локализированы, что только плюс в контексте структурировании программы.
А по поводу функций обёрнутых в функции... тут ничего сложного нет, вы же наверно заворачиваете объекты внутри объекты и умеете работать и понимать такой код - вот так же с функциями, только по проще :)
@@ievgenk.8991 В теории я с вами абсолютно согласен. А вот на практике ни разу ничего хорошего не видел. Наверное я просто не везучий.
А есть на условном гитхабе проект написанный подобным образом, при этом читаемый, расширяемый, легко, дебажащийся и живой?
Почувствовал себя очень умным, т.к. подумал об model-controller сразу при постановке задачи. Либо реализовать через dependency injection, если у нас во главе проекта стоит human
Комментарии как всегда выявляют довольно плотную группу людей которые хотят совершать ошибки под лозунгом "делаем в лоб, чтобы быстро дать заказчику ценность. И потом даже не учиться на них под лозунгом из серии "нельзя было предусмотреть, заказчик внёс несовместимые требования". Это вместо того чтобы понять что проблема в тебе как разработчике. Автор же ролика не говорит что он построил идеальную систему про кружки. Он пытается донести как на практике использовать понятие вектор развития и управлять энтропией которая при этом порождается. А комментаторы *от сохи" концентрируются на каких то не важных деталях.
9:30 в cataclysmDDA именно так и сделали. Всё тупо повешали на player.
Спасибо! за разбор. Но жаль, что нет UML-диаграмм.
3:00 Не совсем понятно, а почему нарушается LSP если мы даже не видим реализации? Вдруг код написан так, что замена Cup > Bottle и наоборот ничего не поломает в коде, а значит LSP нарушен не будет?
В этой модели действительно легко написать так, чтобы ничего не поломалось. Но когда бутылка и чашка обрастут другим функционалом, уже вероятны проблемы. И просто логически бутылка не является чашкой. Это как минимум будет сбивать с толку при чтении кода
У Чашки (кстати, 'Cup'), точнее у IDrinkable тоже должен быть метод - Опустевать().
Тогда Человек, пия из IDrinkable и будет вызывать его Опустевать()...
С точки зрения чистой архитектуры на данное чаепитие должен быть UseCase-интерактор, который будет манипулировать взаимодействием хумана и чашки, за тем отправит результат куда следует.
Holy Cursor! У Соера есть живой курсор, я его видел!
И mouse pointer впридачу
soer, ты Большой Человек)
Вагон лайков отправлен на разгрузку: 🖤🖤🖤🖤🖤🖤🖤🖤🖤🖤
Круто.👍
Спасибо
супер
Не могу не отметить, что разбиение на 3 уровня также есть и в различных системах автоматизации и если абстрагироваться от конкретного назначения каждого из уровней, то они часто и по духу совпадают с MVC. Видимо удачное количество для декомпозиции.
Доменные модели остались без поведения, добавили верхний уровень для управления состоянием. Получилось довольно процедурно. Напоминает это www.martinfowler.com/bliki/AnemicDomainModel.html. Если человек хочет пить пусть пьет.
Там же написано:
Application Layer [his name for Service Layer]: Defines the jobs the software is supposed to do and directs the expressive domain objects to work out problems. The tasks this layer is responsible for are meaningful to the business or necessary for interaction with the application layers of other systems. This layer is kept thin. It does not contain business rules or knowledge, but only coordinates tasks and delegates work to collaborations of domain objects in the next layer down. It does not have state reflecting the business situation, but it can have state that reflects the progress of a task for the user or the program.
В этом примере нет бизнес-логики, Action - это сервисное действие, мы не знаем что человек хочет сделать с полученной жидкостью.О том что обработка получения жидкости должна быть в человеке я говорил.
Почему те кто говорят про анемичную модель, упорно не видят неполноту задачи относительно бизнес логики?
@@S0ERDEVS Да, согласен не увидел задачу целиком. Уровень над человеком и чашкой, согласовывает единицу работы. Обработка того, что делает человек с жидкостью и как выливать из чашки жидкость, должно быть ответственностью объектов человека и чашки.
Отличное решение. Я был почти почти почти прав..