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

@bodesign5446

3 жыл бұрын

Ахахах +++

@bukanaka

2 жыл бұрын

😂🤔

@vladisslavss

Жыл бұрын

😂😂😂

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

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

@purplep3466

3 жыл бұрын

надо было NDA подписывать

@roman-bolkhovitin

3 жыл бұрын

"Рабинович с одной стороны и Одесское пароходство с другой..." (с) анекдот

@DubinArtur

3 жыл бұрын

@@roman-bolkhovitin хD

@scarlatum

3 жыл бұрын

@Старший Санитар " - Если хоть кому-то расскажешь, что мы тут самосвалы с песком разгружаем на халяву - Мы быстро тебе жизнь подпортим. "

@daveshouldaine2520

3 жыл бұрын

@@dmtpp он пример тебе показывает, а ты язвишь, негодяй

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

@IINOCON

3 жыл бұрын

Согласен. С таким объяснением даже новички без особого труда поймут смысл ооп.

@dmitryzagorevskiy507

3 жыл бұрын

Согласен. Мне тоже не хватает такой информации.

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

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

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

@scarlatum

3 жыл бұрын

Оно конечно здорово, когда тебе это не нужно будет поддерживать и расширять. Сделать на коленке фундамент из дерьма и палок, чтобы хоть как-то, а потом удивляться - Что же это разработка стала такой дорогой и долгой.

@dmitrypichugin7449

3 жыл бұрын

Норм, я бы взял 2 вариант, для тестов, которые не пишу. А по поводу обновления стейта человека подумать надо, чтобы он не стал анемичной моделью которая работает только через сервисы, но и сам по себе что то мог.

@konstantinkouptsov7513

3 жыл бұрын

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

@vladislavkotsuba7202

2 жыл бұрын

@@konstantinkouptsov7513 как же жизненно

@themescaline9207

2 жыл бұрын

Вот где становится явной важность корректности и полноты требований к задаче. При простой постановке задачи - есть Человек, который Пьет из Кружки, явно нужно использовать первый вариант. Просто другие варианты противоречат KISS и YAGNI.

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

@Acid31337

2 жыл бұрын

Дело в том, что любая задача которую нужно запрограммировать должна в конечном итоге совершать какие-либо I/O операции, иметь side-эффекты. Это должен быть вывод на экран, запись на диск и передача данных по сети, вывод звука. Задача должна быть сформулирована в этих терминах, иначе это это очередной фейк, и подмена понятий. Так происходит с каждым ООП-туториалом, потому что ООП, так получается, крайне скверно ложится на то чтобы задача была описана в терминах того что должен сделать компьютер, вот и приходится придумывать манявселенную с человек.пить и прочими мяукающими котами и гавкающими собаками. В реальности получаются Фабрики.СделатьАбстрактныйОбъект и Менеджеры.ЗапуститьПроцесс2

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

@Dovmial

Жыл бұрын

это уже система вампиризма

@postoronny

Жыл бұрын

Да! И тогда можно будет не только пить человеку, но и даже переливать из бутылки в чашку.

@agens9538

Ай бұрын

ты про свою жену?

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

@S0ERDEVS

3 жыл бұрын

Так фреймворки же берут на себя всю грязную работу, никто с нуля не пишет. Или вы пишете?

@sebler8523

3 жыл бұрын

@@S0ERDEVS В веб-разработке, скорее всего, никто с нуля не пишет, но есть множество других доменов. Например готовые фреймворки для автомобильной индустрии мне не известны. Однако там так же успешно используются и микро сервисы, и MVC, и дизайн паттерны.

@Dovmial

Жыл бұрын

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

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

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

@Dovmial

Жыл бұрын

нет, ты путаешь модель и сущность. Доменную модель с доменной логикой, контроллером, моделью данных. Модель может быть пакетом (слоем), в котором есть отдельные доменные модели и отдельные бизнес-правила. Контроллер уже предоставляет методы, формализующие пользовательские запросы, отделяя интерфейс (GUI) от реализации (данных и бизнес-правил). Есть и другой вариант MVVM, там без контроллера, каждой пользовательской страничке присуща некоторая бизнес-сущность. Вообще, модель данных как раз должна быть максимально простой (плоской), без поведения., обычно хранится в базе в виде таблиц. На ее основе уже можно создавать сущности (через интерфейс) с поведением, которые и будут реализовывать присущую только им логику. А в случае на видео, логика не относится к одной сущности, бизнес-действие должно поменять состояние сразу нескольких объектов. Поэтому его нельзя приписывать к этим сущностям.

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

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

@user-in6wn6up1s

3 жыл бұрын

Поэтому Роберт Мартин топит за TDD, чтобы можно было делать безболезненный рефакторинг.

@dmitriyobidin6049

3 жыл бұрын

@@user-in6wn6up1s Как тесты, написанные для 1 варианта помогут сделать безболезненный рефакторинг в последний вариант? :) Да там процентов 90 тестов надо будет переписывать, и еще неизвестно сколько писать новых :) Тесты нужны при точечных доработках и расширении системы скорее, нежели при глобальном рефакторинге.

@user-in6wn6up1s

3 жыл бұрын

@@dmitriyobidin6049 никак, если изменились интерфейсы и разделение на модули, то и тесты придется переписать. Но по крайней мере тесты провоцируют писать более мелкие и узкоспециализированные модули. Просто если у нас весь проект состоит не только из этих двух классов, а есть что-то еще, то тесты позволят убедиться, что остальный проект не сломается, пока мы переписываем эти два класса с тестами на них.

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

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

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

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

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

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

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

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

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

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

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

@spacerecluse

3 жыл бұрын

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

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

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

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

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

@bubblesort6368

3 жыл бұрын

Любой проект на java spring открой)

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

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

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

Интересно!!

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

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

@user-zh5xl9bb8z

3 жыл бұрын

И, однажды, на требование добавление нового сосуда, заказчик услышит сумму в 100500 человеко-часов и пошлет Вас и Ваш подход далеко-далеко

@user-dn7qr7vs1h

3 жыл бұрын

@@user-zh5xl9bb8z на это есть другие приемы работы. Например "если общий код встречается 3 и более раза, то нужно обобщить и переиспользовать". Цифра 3 может меняться в зависимости от, но метод довольно полезный как средство сдерживания и оверинжиниринга, и повторения кода.

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

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

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

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

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

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

@GagikHarutyunyan_dev

2 жыл бұрын

😂

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

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

@pin689

3 жыл бұрын

Соер сам не понимает ООП, ещё и людям пытается что-то обяснять. ваша ошибка в том что вы почему-то воспринимаете слова Соер как правду

@jeromewicks3896

2 жыл бұрын

@@pin689 никто не понимает ООП, только думают, что понимают. И у каждого свой ООП

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

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

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

@crutchmaster9637

3 жыл бұрын

То есть надо всё переписывать, когда станет известно. Ну ок..

@S0ERDEVS

3 жыл бұрын

1. Давно уже придумали фреймворки. Там все что нужно для 3-го варианта реализовано, генераторы кода есть и прочие "плюшки". 2. Вы про полиморфизм слышали? Например, ad-hoc полиморфизм без всяких if-ов вызовет вам нужную реализацию, если же про языки с утиной типизацией и поддержкой мультипарадигм, то там есть замечательные декларативные подходы вместо if/switch, которые используют функции первого порядка. Да и контроллер может существовать не в одном варианте, если речь про модульный подход, то можно конфигурировать модуль, использовать DI и т.д. Короче нет там никаких "кучи if-ов". Было бы желание думать, а не решений полно.

@user-zg4dv7xf6t

3 жыл бұрын

@@crutchmaster9637 лично мне проще переписать 10 строк кода, а не 10 файлов. А Вам?

@crutchmaster9637

3 жыл бұрын

@@user-zg4dv7xf6t Строк кода минимум на тысячу надо умножить и подумать еще раз.

@user-zg4dv7xf6t

3 жыл бұрын

@@S0ERDEVS Вы комментируете 3-е решение в абстрактном вакууме, а не в реальном проекте, где что-то меняется, в задаче изначально неправильный акцент выставлен, что-то неизвестно на момент первых итераций, когда программисты уходят и болеют, ищутся баги по куче файлов, человек пытается уложить в голову логику. Это решение вообще это всё игнорирует. Понятно, что где-то такой подход реально отлично ложится и спасает от проблем в будущем, но не в случае рядовой задачи "попить воды". Примеры уж тогда надо подбирать более корректней, чтобы не было иллюзий, что там где есть решение в одну строку, надо генерировать кучу новых файлов и новых абстракций

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

@fj8017

3 жыл бұрын

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

@sergeyt4118

3 жыл бұрын

@UCYB1-bWEzfKGTBSt6a5YoHw а ведь реально, если посмотреть на весь процесс инициализации (рождения) нового экземпляра человека (разных классов / национальностей и тп, унаследованных об супер-классов вверх по иерархии), то инстинкты - это firmware запрограммированный в контроллере физобъекта (с помощью биодисков- генов), а обучение в процессе жизни - это натаскивание его нейронной сетки через звуковые, световые и прочие интерфейсы (рефлексы как драйверы соответствующих IO-девайсов у человека); языки общения тоже разные у разных групп людей (но все так или иначе компилируются в некий гуманоидный IL низкого уровня), шины (СМИ, племенные и родовые связи) и брокеры сообщений тоже имеются - и многие великие "менеджеры (ака манипуляторы)" давно эти фреймворки выучили :)) весь "гософициоз" с его законами и документами очень уж филофоски напоминают xml

@ext2korwin

3 жыл бұрын

​@@fj8017 класс Human - это не человек, а некоторый "представитель" человека в нашей системе. И так получается, что представители не обязаны разделять свойств и отношений тех, кого представляют. Например, есть муж и жена, которые разводятся, а есть адвокаты - их представители в этом процессе. Маловероятно, что адвокаты тоже разводятся при этом. Или классический пример с наследованием квадрата от прямоугольника отражает тот же феномен. Поэтому я бы не стал утверждать, что объекты в ООП так уж далеки от реальности. Просто мы оперируем не самими объектами, а их поведением.

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

@pin689

3 жыл бұрын

Так в итоге у него и получился процедурный стиль. Две структуры (human и cup) и функция (action). ООП тут и нет никакого

Спасибо 🙌🔝

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

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

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

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

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

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

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

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

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

@crutchmaster9637

3 жыл бұрын

Жаба-ооп - это такая религия. (У них там даже есть должности евангелистов) Вот, кто-то проповедовал, кто-то уверовал, а потом выясняется, что земля не плоская.

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

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

Спасибо

Круто.👍

Лучший!

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

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

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

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

@bubblesort6368

3 жыл бұрын

Любым случайным сеттером можем сломать доменную логику.

@crutchmaster9637

3 жыл бұрын

>Проблема третьего варианта в том, что там нет ООП. Не вижу в этом никакой проблемы.

@S0ERDEVS

3 жыл бұрын

Здесь нет бизнес-логики, поэтому о какой "анемичной модели" может идти речь? У нас есть транзакция и DTO-ка которая служит для переноса данных. При появлении бизнес-логики (и об этом было сказано в видео) она попадает в человека. Попробуйте сделать "не анемичную" модель с имеющимися данными, тогда вылезет много вопросов.

@bubblesort6368

3 жыл бұрын

​@@S0ERDEVS Спасибо за ответ. Если инварианты будут обеспечиваться на уровне entity, например при отрицательном количестве жидкости в чашке будет вылетать исключение, а класс Drink будет передавать его в представление то это допустимый вариант.

супер

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

класс👍

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

@redserjogha

3 жыл бұрын

@@dmtpp Чтобы делать сложные и масштабные вещи, необходимо досконально постичь азы. Чтобы написать Войну и Мир, нужно сначала изучить азбуку, освоить слова и составление предложений. Эти вещи показательны. Я решил бы вопрос почти так же, но без класса-посредника, реализующего процесс пития. Мне вот и интересно как он будет реализован, будет ли агрегатом или композитом человека, а может вообще будет унаследован от глобальной божественной сущности Бахуса?

@IgorLynn

3 жыл бұрын

@@redserjogha класс может быть реализован как действие, где сначала читается состояние кружки и в соответствии с ним изменяется состояние человека. Это действие, опционально, так же может выбрасывать событие, что оно произвело процесс опорожнение кружки и наполнение жидкостью человека. В последствии, все кто слушали это событие, могут начать своё действие, например: проверка на то, что именно было выпито и вызов соответствующей реакции (ухудшение самочувствия или его улучшение, гипотермия/гипертермия, отравление/излечение, восстановление водного баланса или же дегидратация организма).

@evgenasd8892

3 жыл бұрын

@@IgorLynn вы не. Observer описали в своем примере?

@IgorLynn

3 жыл бұрын

@@evgenasd8892 да, но он опционален. Суть в том что мы вводим третью сущность и она просто меняет состояние двух моделей. У меня когда-то была похожая проблема, где было 2 космических корабля и они могли друг друга атаковать и наносить урон. Дилемма была в том, что не понятно у кого должно быть право наносить урон; должен ли атакующий корабль содержать метод DealDamage() и отнимать прочность/щиты у корабля которого он атакует или корабль который получает урон, должен содержать метод ReceiveDamage() и решать какой урон ему может нанести атакующий его корабль? По факту же, ни у кого из них не должно быть такой привилегии и доверия.

@evgenasd8892

3 жыл бұрын

@@IgorLynn спасибо

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

@Enthusiast91

3 жыл бұрын

Тип жидкости не влияет на сосуд, а на человека влияет ) А что бы влиять на сосуд, тут уже появляется вид жидкости - например кислота, расплавленный металл, лава. Крч мне кажется тут уже зависит от уровня абстракции и решаемой задачи.

@userAS456

2 жыл бұрын

@@Enthusiast91 вот и вопрос, что если жидкость способна влиять на сосуд со временем(кислота, лава) чтобы материал сосуда на это влиял, но при этом не реализовывать одно в другом

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

Жирный лайк 👍🏻

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

@vitalylarichev1059

3 жыл бұрын

@@patrickowens7665 я спрашивал, что использует именно автор в своих роликах. А не твое мнение идиота.

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

@user-dn7qr7vs1h

3 жыл бұрын

Чем ближе к совершенству, тем ближе к функциональщине (или к математике) :D

@user-sy6jp7wd8y

3 жыл бұрын

Вы предлагаете мыслить как компьютер?

@user-dn7qr7vs1h

3 жыл бұрын

@@user-sy6jp7wd8y ровно наоборот :) "мыслить как компьютер" - мыслить императивно, моделируя Машину Тьюринга в голове (операциональная семантика), описывая последовательность инструкций. А в математике наоборот, торжество декларативности (денотационная семантика). В математике (и функциональщине) мы обычно не расписываем последовательность инструкций для получения чего-то, а описываем свойства этого чего-то.

@user-sy6jp7wd8y

3 жыл бұрын

@@user-dn7qr7vs1h декларативный подход это подача данных на вход и заявление того что мы ждём на выходе, а как это уже будет реализовано - для нас чёрный ящик, шаги мы не описываем. В ФП мы ведь как раз таки описываем последовательность команд в виде последовательности вызова функций, т.е. применяем императивный подход, разве нет так?

@AlexeyGogots

3 жыл бұрын

​@@user-sy6jp7wd8y Нет. Последовательность никак не противоречит декларативному подходу. Очевидно, что некоммутативные операции зависят от порядка выполнения, при любом подходе. Императивный подход это не про последовательность. Это про то, что операции могут изменять внешнее, по отношению к функции, состояние, в то время как функции зависят только их аргументов.

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

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

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

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

@orlem5837

3 жыл бұрын

@@user-bf7hk9ds6k при этом самые кринжевые варианты - это как раз таки хотелки заказчика. Например, чтение pdf ж***й и выдача анализа этого pdf ртом...

@henson2k

3 жыл бұрын

Интересует вариант выпивания чашкой человека

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

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

@bubblesort6368

3 жыл бұрын

Это наверное ещё один намек что это не ООП дизайн)

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

ВАУ

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

Наша жизнь - Матрица

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

ООП 🙃🙃🙃

Как насчёт создать базовый класс Сосуд и создать класс Человек который наследуется от Сосуда, ведь человек в этой задачи ничто иное как сосуд! И стакан сосуд, а жидкость это данные которые перетекают из одного сосуда в другой. Вот она красота истинного ООП!

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

С точки зрения чистой архитектуры на данное чаепитие должен быть UseCase-интерактор, который будет манипулировать взаимодействием хумана и чашки, за тем отправит результат куда следует.

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

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

@expurple

2 жыл бұрын

В этой модели действительно легко написать так, чтобы ничего не поломалось. Но когда бутылка и чашка обрастут другим функционалом, уже вероятны проблемы. И просто логически бутылка не является чашкой. Это как минимум будет сбивать с толку при чтении кода

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

@mikhailkh8560

3 жыл бұрын

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

@redserjogha

3 жыл бұрын

Все эти парадигмы: процедурная, функциональная, ООП, etc. созданы для борьбы (преодоления) со сложност(ью/и). Философски, существует два подхода к представлению мира: атрибутивный и функциональный. Представляют вселенную в виде супер-пупер-гипертекста атрибутивисты, а функционалисты в виде взаимодействующих потоков энергии-вещества. ООП использует оба подхода, функциональный - методами, атрибутивный - полями, и борется со сложностью инкапсуляцией и абстрагированием. Это самая компромиссная и простая для понимания парадигма, оттого она и столь жизнеспособна.

@ievgenk.8991

3 жыл бұрын

@@mikhailkh8560 ФП подход помогает хорошо структуировать код - чистые функции это уже очень хорошо фаргментированая сущность с очень прозрачной и предсказуемой природотой. И на выходе получается приложение где первыми идут данные а потом операции над ними, которые легко композируются и тестируются, "грязные" области тоже будут, но они будут более локализированы, что только плюс в контексте структурировании программы. А по поводу функций обёрнутых в функции... тут ничего сложного нет, вы же наверно заворачиваете объекты внутри объекты и умеете работать и понимать такой код - вот так же с функциями, только по проще :)

@mikhailkh8560

3 жыл бұрын

@@ievgenk.8991 В теории я с вами абсолютно согласен. А вот на практике ни разу ничего хорошего не видел. Наверное я просто не везучий. А есть на условном гитхабе проект написанный подобным образом, при этом читаемый, расширяемый, легко, дебажащийся и живой?

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

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

Отличное решение. Я был почти почти почти прав..

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

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

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