04:12 Принцип единственной ответственности 13:26 Принцип открытости-закрытости 20:48 Принцип подстановки Барбары Лисков 27:09 Разделение интерфейса 32:20 Принцип инверсии зависимости
Даже сам мой кайф получил кайф от этого видео! 🎉Сергей, осторожно, так нельзя ! Ваши видео слишком кайфовые! Я чуть не начал биться в конвульсиях от кайфа при просмотре!!! Если серьёзно то спасибо Вам огромное за то как доходчиво, ясно и приятно Вы всё объясняете! Огромная благодарность и уважение Вам!
Серёга рассказывает как солит и не испортить свой проект 😂. Классное видео! Благодарю! Серьезно, очень ему благодарен- очень многому научился по его видео и курсам! Здоровья тебе, уважаемый Сергей. Уважаю тебя, Человечище!!! 🤝🙂
Отличный урок! Один из лучших каналов на Ютуб!!! Мне как новичку в Пайтон не всё понятно из-за отличий между языками, имею ввиду интерфейсы и т.п., сильно отвлекаешься на различия, особенно ближе к концу. Возможно ещё рано над таким думать, но всё же надо двигаться вперёд. Если будет такое же видео только на Пайтоне, то будет вообще улёт. Можно даже в курс по ООП добавить)))
Спасибо за видио - это и остальные - приятная подача - приятно смотреть) А теперь немного критики - класс лучше назвать не SaveComputer а ComputerSaver или ComputerStorage - должно быть существительное, т.к. в человеческом языкие именно существительные обозначают объекты мира которые мы моделируем с помощью классов. И когда не получается придумать нормальное название для класса это часто признак что с классом чтото не так (например он перегружен ответственностью)
19:00 так, а зачем для того что бы сохранить в БД путь к файлу? - А если допустим в облако, то нужно ещё дополнительные данные, тогда или просто убрать нужно path с аргумента интерфейса. Потому что для разных типов сейвов/лоадов нужны свои доданые фишки. Тогда вердикт такой что в методе должен быть только Компютер класс, но ни как не путь к файлу, так как это уже часть для самого сейвера который реализует только сейв в файл, а для дб и для облока, он не нужен
Когда объясняли зависимость интерфесов, нужно наверное было создать интерфейс DrawGeometry с абстрактным методом Draw. При наследовании мы бы получилиLine.Draw(), Circle.Draw(), Rectangle.Draw().если не ошибаюсь,то это был бы паттерн фабрика. По паттернам будет обучение?
Круто, спасибо! Хотелось бы на питоне, конечно, так как смотрю с плейлиста по ООП питону. Но, насколько я понял, ярче всего эти принципы работают со строго-типизированными языками. Так что так, полагаю, лучше
Все же не стоит интерфейсы относить к абстрактным классам. Посредством интерфейсов реализуется полиморфизм(не считая интерфейсы маркёры, функциональные интерфейсы), а функционал абстрактных классов чаще используется в наследовании как суперкласс. Если кто-то запомнит этот тезис и на собеседовании скажет что интерфейс это абстрактный класс, то быть беде.
@@mrakobes228 конечно не будет, полиморфизм это связывание разных классов с общим поведением, наследование от абстрактного класса это расширение супер класса. Рыба может плыть и тапок может плыть, может ли тапок быть потомком рыбы или все же у них есть обобщенное поведение, которое можно объединить через интерфейс добавив полиморфизм?
Спасибо за данное видео. Хотел бы задать следующий вопрос, который больше относится к программированию на С++. Считается ли нарушением принципа подстановки Барбары Лисков, если мы в базовом классе определим виртуальную функцию, с одним поведением, а уже в её классе наследнике мы эту виртуальную функцию переопределяем, т.е. задаём другое поведение? Ведь виртуальные функции и нужны для того чтобы их переопределять.
Очень хорошее видео, познавательное, но учить новичков тому, что интерфейс = абстрактный класс - НЕ хорошо! Если это кто-то читает, то основное (главное) отличие абстрактного класса от интерфейса - это state. У абстрактного класса может быть состояние, у интерфейса - нет. За видео поставил лайк!
Второй Принцип: Закрытости / Открытости. Это тот принцип, благодаря которому раздувается ПО в геометрической прогрессии, а функционал в арифметической!
Да тут каждый второй принцип такой. Например последний принцип инверсии зависимостей потребовал создания двух файлов - интерфейсов. А ведь это простой учебный пример. В реальном коде там этих классов и интерфейсов будут сотнями измеряться походу.
Как можно определить, что разработчик пришел из питона? - Стиль написания snack_case. В java, особенно в энтерпрайз проектах, по -дефолту, используется camelCase. Но видео, как всегда, классное. Спасибо!
Посмотрел видео, понял, что надо повторить тему с полиморфизмом (в питоне). То что тут java - нестрашно, быстро привыкаешь к синтаксису. Особенно если знаком с тайп хинтами. А вот интерфейсы сбивают с толку. Аналогию с питоном не успеваешь строить, как в видео уже следующий принцип разбирается. Я аж чувствую, как мозг физически нагревается))
Сергей, такой вопрос: разве в показанном примере на 18:00 код не нарушает принцип DRY? Ведь, по сути, при дальнейшем расширении программы, мы будем иметь множество классов с практически идентичным функционалом. Пусть это и нарушит принцип единой ответственности, но почему создать отдельный класс Saver, который будет реализовать все функции, связанные с сохранением, нельзя? Разве так не проще?
Конечно, это сильно упрощенные примеры. Принципы SOLID для серьезных проектов. Я здесь лишь показываю идею. Конечно в этих програмках городить такие огороды ни к чему )) Я это сделал лишь для простоты изложения материала - идей принципов SOLID
@@selfedu_rus В таком случае не очень хорошо закрепляется материал, так как пример не отражает "боевую" ситуацию, которая действительно может произойти. Не могли бы Вы привести пример из своего личного опыта, когда Вы использовали этот принцип в своем проекте и он действительно помог в обозримом будущем?
последнее вообще не понял, мы создали IForm интерфейс но при этом от куда нам брать тогда информацию для записи? То что они просто связаны на том что они одного интерфейса, но допустимо как его тогда сохранить если нету информации. Вообще не понял что происходит
так он вначале говорит, что объяснить принципы солид легче на джаве, так как там есть интерфейсы. В питоне тоже вроде можно используя абстрактные классы.
Получается принцип открытости и закрытости, как бы подталкивает для осуществления принципа единственной ответственности, так как нужно каждый раз создавать отдельный класс)
Самая основная проблема подобных видосов это чрезмерное упрощение примеров. Информация вроде подается хорошо. Но вот эти вот "Ну, я просто для примера, напишу вот такие методы, какая разница" или "Ну, назову класс SaveComputer, можно было бы поумнее, но какая разница" очень портят качество. Ну придумайте вы нормальные полноценные законченные примеры, близкие к реальным, без вот этих вот "допущений". Это сильно поднимет качество роликов.
Сергей, спасибо за видео. Скажите, получается второй принцип это использование абстрактных миксинов которые применять нужно при множественном наследовании?
букву S разве не модно было как - то подругому сделать например у класса SHAPE просто оставить метод DRAW и тогда получилось что в классах нужно было бы просто переопределить метод DRAW нежели создавать 3 лишних интерфейса которые наоборот нагружают память
Джава компилируемый язык только наполовину (до создания байт кода). Далее после этого, во время чтения байт кода - это уже гибридный язык , так как работает одновременно и JIT компилятор и интерпретатор в паре чтобы транслировать файл класса (байт код) в исполняемый файл на машинном языке. Чисто компилируемые языки это C, C++, Rust, Go и тд
Заметил интересное(в java базовый класс может хранить ссылку на объект класса-наследника), а что касается методов и переменных класса-наследника?Можно ли их использовать через базовый класс?
касаемо Барбары Лисков, для себя запомнил так, что если в базовом классе метод записывал данные файл, нельзя его переопределить в дочернем, чтобы он этот файл удалял, то бишь логика метода менялась с ног на голову) как то так)
там, в основном, все сводится к правильному набору функций, которые, опять же, должны решать строго ограниченную задачу, а более сложный функционал реализовывать через вызовы более простых функций
В Python не так хорошо все можно продемонстрировать, например, те же абстрактные классы или интерфейсы, полиморфизм, в питоне это скрыто и встроено в саму структуру языка, было бы не так очевидно
Канал хороший смотрю плейлист по питону и по си. Вопрос аа почему принципы Solid по java? будите делать по этому языку плейлист как по си? Или эти принципы к другим языкам то же подходят?
Есть же к.с abstract для создания абстрактных классов, почему автор заостряет внимание именно на интерфейсах, что через них реализуются абстрактные классы?
Именно через интерфейсы и лучше реализовывать солид философию. В плюсах к примеру есть только чистые абстрактные классы, поэтому приходится реализовываться через них. Вообще, каждому языку свойственна своя идиоматическая концепция…
8:55 это реально применяется и делается например визитором но этот вариант тоже нарушает SRP потому что при изменении класса вам надо изменить и сам класс и его лоадер который будет брать его структуру, так что не факт что такое выделение чище по дизайну. А не вот на ходу придумалось решение что самым чистым был бы класс универсального лоадера, который через "что то типа рефлекции" если это про Жабу, смотрит структуру любого обьектаи сохраняет данные типа как JSON. Если надо сохранять не все поля то в классе прописывается какие поля надо сохранять. Не надо в лекции по SOLID говорить белиберду. Отдельно класс который сохраняет специфический обьект специфическим образом непрактично потому что у вас будет n * m таких классов где n количество классов а m виды сохранения.
Все же лучше называть класс не действием - это ведь сущность. Здесь, в примере с Computer, имхо достаточно рассмотреть навязшую в зубах mvc. Есть область хранилища, есть само представление сущности, и есть какой-то контроллер, обеспечивающий взаимодействие хранилища и представления. Имхо🥴
ну, в общем-то, типичные ошибки (странно, что человек, перед тем как учить кого-то, не может просто даже вики открыть - не то что, открыть книжку мартина, где всё это подробно расписано): 1) принцип единственной *ОТВЕТСТВЕННОСТИ* не про то, что класс или метод должен отвечать за одну вещь. даже на вики написано: "A class should have only one reason to change" R. Martin. и где тут что-то про работу класса? принцип о том (и на ютубе есть видео, где дядюшка это поясняет на примерах), что класс должен иметь ОДИН ИСТОЧНИК ДЛЯ ИЗМЕНЕНИЙ. т.е. если этот класс создан по заказу бухгалтерии, для их расчетов, то он не должен меняться по приказу отдела кадров. в противном случае, существует вероятность, что после изменений для кадров, у бухгалтерии отвалится жопа. 2) osp - самое простое. но даже тут чувак нарушает принцип наименования интерфейсов (как и в целом в видео). интерфейс - это прилагательное (или существительное, если это группа объектов). отвечает на вопрос: "какой?". отвечает ли SaveInterface на вопрос "какой?" - вопрос риторический. и ладно бы он придерживался такого написания везде - но нет: тут добавляет Interface, потом пишет интерфейс Shape, без добавления Interface, потом вообще пишет ICircle. чувак, определись уже. 3) принцип лисков не о том, что дочерний класс должен ПОЛНОСТЬЮ повторять ФУНКЦИОНАЛ. вон, в комментах у людей тоже вопрос - "нафига тогда есть переопределение метода?". принцип о том, что дочерний метод должен соответствовать той же БАЗОВОЙ СИГНАТУРЕ, что и родительский. т.е. если у тебя базовый метод принимает число, как аргумент, и возвращает число, то и дочерний метод должен делать то же самое: иметь ПЕРВЫМ аргументом число, и возвращать число. но это не значит, что я в дочерний метод не могу вторым аргументом добавить строку, например. и это не означает, что в теле метода я не могу реализовать другую работу, нежели в базовом. если у меня базовый класс возвращает число, путем возведения аргумента в квадрат, то я в дочернем классе могу вернуть число, путем умножения аргумента на самого себя. или умножить его на 2. или на 10. да, результат будет неправильным, но он будет соответствовать ожидаемому типу. но если ты переопределишь метод, но сделаешь возвращаемый тип строкой, то при подстановке, у тебя сломается программа, если ты захочешь использовать результат, как число, но получишь строку. да, в видео правильно сказано, что изменение свойств класса в переопределенном методе тоже нарушает этот принцип. но это лишь его часть. 4) тут всё понятно, кроме нейминга интерфейсов 5) опять проблемы с наименованием. как язык программирования (sql) может быть типом базы данных? если ты делаешь абстракцию базы данных, то и называй ее DB. базой данных может быть и локальное хранилище - каким боком оно тогда относится к sql?
Это самое прекрасное объяснение SOLID, которое я когда-либо видел!
04:12 Принцип единственной ответственности
13:26 Принцип открытости-закрытости
20:48 Принцип подстановки Барбары Лисков
27:09 Разделение интерфейса
32:20 Принцип инверсии зависимости
Спасибо!
Вижу у Вас талант к преподавательской деятельности.
Спасибо Вам, Сергей. Роста и развития🙏
Однозначно недооцененный лайками ролик. Благодарность автору!
Сергей спасибо за ваш труд! Как всегда кратко, без воды, лаконично и понятно! И еще очень подкупает дружелюбность подачи материала. )))
Супер, отличное объяснения принципов SOLID, на отличных понятных примерах. Спасибо большое!
Даже сам мой кайф получил кайф от этого видео! 🎉Сергей, осторожно, так нельзя ! Ваши видео слишком кайфовые! Я чуть не начал биться в конвульсиях от кайфа при просмотре!!!
Если серьёзно то спасибо Вам огромное за то как доходчиво, ясно и приятно Вы всё объясняете! Огромная благодарность и уважение Вам!
посмотрел весь курс ООП. лучший канал, с ПОНЯТНОЙ информацией. Буду смотреть теперь другие плейлисты канала и преисполняться в своем познании))))
Автор молодец! 👍 Объясняет просто и доходчиво(но достаточно подробно).
Лайк и подписка однозначно.
Это просто классно. Взаимодействие классов примеры отличные. Побольше таких уроков. СПАСИБО
Шикарное объяснение, спасибо!
В джава есть не только интерфейсы, но и абстрактные классы, но за урок спасибо.
Вот это супер полезное видео! А я как раз дошел до того, что начал задумываться о правильном построение ПО! Спасибо!
Серёга рассказывает как солит и не испортить свой проект 😂. Классное видео! Благодарю! Серьезно, очень ему благодарен- очень многому научился по его видео и курсам! Здоровья тебе, уважаемый Сергей. Уважаю тебя, Человечище!!! 🤝🙂
Очень доступное объяснение принципов.
Отличный урок! Один из лучших каналов на Ютуб!!!
Мне как новичку в Пайтон не всё понятно из-за отличий между языками, имею ввиду интерфейсы и т.п., сильно отвлекаешься на различия, особенно ближе к концу. Возможно ещё рано над таким думать, но всё же надо двигаться вперёд.
Если будет такое же видео только на Пайтоне, то будет вообще улёт. Можно даже в курс по ООП добавить)))
Друг мой, ты вообще классно все обьяснил
Самое понятное объяснение этих принципов. Спасибо за видео!)
Самое понятно объяснение из всех что я видел.
Эталон обучающей информации!
Потрясающе здорово. Очень приятный голос, всё спокойно, понятно. Огромное спасибо за труд.
Спасибо. Познавательно и доступно.
Очень хороший курс, действительно кратко, по делу и грамотно, единственное , не хватает темы "абстрактные классы", она бывает полезна.
Хорошее объяснение. Все четко и доходчиво.
Сергей, спасибо за видео.
Очень ждал на вашем канале такого рода видео!
Просто супер объяснение, спасибо огромное!!!
спасибо большое, очень полезный канал
Спасибо! Это лучшее объяснение из всех, которые я видел!
Буковки для продвижения. Автор красавчик.
Спасибо, все наглядно и понятно!
Лайк не глядя)
Лучшее объяснение, спасибо!
Спасибо за труд!
Спасибо за видио - это и остальные - приятная подача - приятно смотреть) А теперь немного критики - класс лучше назвать не SaveComputer а ComputerSaver или ComputerStorage - должно быть существительное, т.к. в человеческом языкие именно существительные обозначают объекты мира которые мы моделируем с помощью классов. И когда не получается придумать нормальное название для класса это часто признак что с классом чтото не так (например он перегружен ответственностью)
Очень хорошее объяснение
19:00 так, а зачем для того что бы сохранить в БД путь к файлу? - А если допустим в облако, то нужно ещё дополнительные данные, тогда или просто убрать нужно path с аргумента интерфейса. Потому что для разных типов сейвов/лоадов нужны свои доданые фишки.
Тогда вердикт такой что в методе должен быть только Компютер класс, но ни как не путь к файлу, так как это уже часть для самого сейвера который реализует только сейв в файл, а для дб и для облока, он не нужен
Огромное спасибо!
Идеально, спасибо огромное!
Я понял. И кажется понял нафига оно надо. Постараюсь сделать свой код лучше.
Супер, дуже класне відео!
Спасибо за познавательные видео
Спасибо! Отличный курс! 💥💥💥
Когда объясняли зависимость интерфесов, нужно наверное было создать интерфейс DrawGeometry с абстрактным методом Draw. При наследовании мы бы получилиLine.Draw(), Circle.Draw(), Rectangle.Draw().если не ошибаюсь,то это был бы паттерн фабрика. По паттернам будет обучение?
Замечательный голос и содержание видео !
Круто, спасибо! Хотелось бы на питоне, конечно, так как смотрю с плейлиста по ООП питону. Но, насколько я понял, ярче всего эти принципы работают со строго-типизированными языками. Так что так, полагаю, лучше
Очень понятно объяснил 👌 спасибо😀
Все же не стоит интерфейсы относить к абстрактным классам. Посредством интерфейсов реализуется полиморфизм(не считая интерфейсы маркёры, функциональные интерфейсы), а функционал абстрактных классов чаще используется в наследовании как суперкласс. Если кто-то запомнит этот тезис и на собеседовании скажет что интерфейс это абстрактный класс, то быть беде.
А как можно сказать ,что интерфейс = класс ?
Тут сама риторика говорит об этом ,что это разные объекты
Не стоит, но в тех же плюсах интерфейсы реализуются чистыми абстрактными классами
По сути и абстрактный класс и интерфейс это абстракции, поправьте если ошибаюсь. И наверное правильнее будет называть их "абстракциями"
А посредством абстрактных классов полиморфности разве не будет?
Конечно будет.
@@mrakobes228 конечно не будет, полиморфизм это связывание разных классов с общим поведением, наследование от абстрактного класса это расширение супер класса.
Рыба может плыть и тапок может плыть, может ли тапок быть потомком рыбы или все же у них есть обобщенное поведение, которое можно объединить через интерфейс добавив полиморфизм?
Очень понравилось, спасибо! Единственное может быть слишком быстро? и конечно для закрепления нужно больше практики.
Спасибо за данное видео. Хотел бы задать следующий вопрос, который больше относится к программированию на С++. Считается ли нарушением принципа подстановки Барбары Лисков, если мы в базовом классе определим виртуальную функцию, с одним поведением, а уже в её классе наследнике мы эту виртуальную функцию переопределяем, т.е. задаём другое поведение? Ведь виртуальные функции и нужны для того чтобы их переопределять.
Очень хорошее видео, познавательное, но учить новичков тому, что интерфейс = абстрактный класс - НЕ хорошо! Если это кто-то читает, то основное (главное) отличие абстрактного класса от интерфейса - это state. У абстрактного класса может быть состояние, у интерфейса - нет. За видео поставил лайк!
Второй Принцип: Закрытости / Открытости.
Это тот принцип, благодаря которому раздувается ПО в геометрической прогрессии, а функционал в арифметической!
Да тут каждый второй принцип такой. Например последний принцип инверсии зависимостей потребовал создания двух файлов - интерфейсов. А ведь это простой учебный пример. В реальном коде там этих классов и интерфейсов будут сотнями измеряться походу.
Классно, с возвращением... Java'у?)
С примерами на пайтон будет?) спасибо 🙏
Как можно определить, что разработчик пришел из питона? - Стиль написания snack_case. В java, особенно в энтерпрайз проектах, по -дефолту, используется camelCase. Но видео, как всегда, классное. Спасибо!
это привычка, последнее время много на питоне писал ))
Ура, побольше java!
спасибо!
Посмотрел видео, понял, что надо повторить тему с полиморфизмом (в питоне). То что тут java - нестрашно, быстро привыкаешь к синтаксису. Особенно если знаком с тайп хинтами. А вот интерфейсы сбивают с толку. Аналогию с питоном не успеваешь строить, как в видео уже следующий принцип разбирается. Я аж чувствую, как мозг физически нагревается))
Сергей, такой вопрос: разве в показанном примере на 18:00 код не нарушает принцип DRY? Ведь, по сути, при дальнейшем расширении программы, мы будем иметь множество классов с практически идентичным функционалом. Пусть это и нарушит принцип единой ответственности, но почему создать отдельный класс Saver, который будет реализовать все функции, связанные с сохранением, нельзя? Разве так не проще?
Конечно, это сильно упрощенные примеры. Принципы SOLID для серьезных проектов. Я здесь лишь показываю идею. Конечно в этих програмках городить такие огороды ни к чему )) Я это сделал лишь для простоты изложения материала - идей принципов SOLID
@@selfedu_rus В таком случае не очень хорошо закрепляется материал, так как пример не отражает "боевую" ситуацию, которая действительно может произойти. Не могли бы Вы привести пример из своего личного опыта, когда Вы использовали этот принцип в своем проекте и он действительно помог в обозримом будущем?
Сергей, снимите пожалуйста видео про SOLID для Python. Спасибо!
А в чём разница? Эти принципы едины для всех ЯП.
абстрактный класс != интерфейс
последнее вообще не понял, мы создали IForm интерфейс но при этом от куда нам брать тогда информацию для записи? То что они просто связаны на том что они одного интерфейса, но допустимо как его тогда сохранить если нету информации. Вообще не понял что происходит
Не понятно одно,почему Сергей во всех роликах про ооп использовал python,а в последнем перешёл на java ?А так все доступно и понятно разъяснил.
так он вначале говорит, что объяснить принципы солид легче на джаве, так как там есть интерфейсы. В питоне тоже вроде можно используя абстрактные классы.
@@shoislom2200 Про абстрактные классы я знаю,но все же
Получается принцип открытости и закрытости, как бы подталкивает для осуществления принципа единственной ответственности, так как нужно каждый раз создавать отдельный класс)
Самая основная проблема подобных видосов это чрезмерное упрощение примеров. Информация вроде подается хорошо. Но вот эти вот "Ну, я просто для примера, напишу вот такие методы, какая разница" или "Ну, назову класс SaveComputer, можно было бы поумнее, но какая разница" очень портят качество. Ну придумайте вы нормальные полноценные законченные примеры, близкие к реальным, без вот этих вот "допущений". Это сильно поднимет качество роликов.
по solid много видео и на русском, но это имхо лучшее
А можно, тоже самое, но на python?
К такому меня жизнь не готовила!
Жду разбор шаблонов проектирования GoF.))
Сергей, спасибо за видео. Скажите, получается второй принцип это использование абстрактных миксинов которые применять нужно при множественном наследовании?
как один из примеров да, подходит
букву S разве не модно было как - то подругому сделать например у класса SHAPE просто оставить метод DRAW и тогда получилось что в классах нужно было бы просто переопределить метод DRAW нежели создавать 3 лишних интерфейса которые наоборот нагружают память
Ура!!!!
Круто
нравится Java) думаю в качестве компилируемого языка начну изучать ее) у вас не планируется вводный курс по ней?
уже есть, см. плейлист на этом канале )
Джава компилируемый язык только наполовину (до создания байт кода). Далее после этого, во время чтения байт кода - это уже гибридный язык , так как работает одновременно и JIT компилятор и интерпретатор в паре чтобы транслировать файл класса (байт код) в исполняемый файл на машинном языке.
Чисто компилируемые языки это C, C++, Rust, Go и тд
@@skyx5691 да теперь уже знаю, спасиб
Может быть курс по Java сделаете?😅
посмотрим ))
Сергей, вы добавили это видео в плейлист по ооп питона?
да, пусть будет, это же принципы, которые универсальны для любого языка программирования
Заметил интересное(в java базовый класс может хранить ссылку на объект класса-наследника), а что касается методов и переменных класса-наследника?Можно ли их использовать через базовый класс?
нет, только после приведения типа к дочернему классу
Добрый день, планируются еще видео по чистой архитектуре? Спасибо!
Пока не думал об этом, я вообще планов таких не строю, как идет, так и делаю ))
касаемо Барбары Лисков, для себя запомнил так, что если в базовом классе метод записывал данные файл, нельзя его переопределить в дочернем, чтобы он этот файл удалял, то бишь логика метода менялась с ног на голову) как то так)
хотя все равно не очень понятна граница, какие изменения в переопределении метода, будут противоречить принципу
ничего не понятно, но очень интересно...
Есть что то подобное не для ООП, а для процедурного программирования?
там, в основном, все сводится к правильному набору функций, которые, опять же, должны решать строго ограниченную задачу, а более сложный функционал реализовывать через вызовы более простых функций
а почему не на Python как раз после курса ОПП
В Python не так хорошо все можно продемонстрировать, например, те же абстрактные классы или интерфейсы, полиморфизм, в питоне это скрыто и встроено в саму структуру языка, было бы не так очевидно
Здравствуйте. А что, планируются уроки по Java?
так они же есть?
@@selfedu_rus И правда. Проглядел))
Канал хороший смотрю плейлист по питону и по си. Вопрос аа почему принципы Solid по java? будите делать по этому языку плейлист как по си? Или эти принципы к другим языкам то же подходят?
Спасибо! Просто на Java было проще всего показать эти принципы, а так да, они едины для всех языков, где есть ООП.
@@selfedu_rus ясно спасибо)⚡⚡⚡
спасибо
Есть же к.с abstract для создания абстрактных классов, почему автор заостряет внимание именно на интерфейсах, что через них реализуются абстрактные классы?
да, в Java interface - это аналог абстрактных классов
@@selfedu_rus абстрактные классы и интерфейсы - различные понятия
@@danilaminecraftcity поэтому употребил слово "аналог"
@@selfedu_rus хорошо, я уж быть подумал, что вы умеете ввиду его полное соответствие.
Именно через интерфейсы и лучше реализовывать солид философию. В плюсах к примеру есть только чистые абстрактные классы, поэтому приходится реализовываться через них. Вообще, каждому языку свойственна своя идиоматическая концепция…
8:55 это реально применяется и делается например визитором но этот вариант тоже нарушает SRP потому что при изменении класса вам надо изменить и сам класс и его лоадер который будет брать его структуру, так что не факт что такое выделение чище по дизайну. А не вот на ходу придумалось решение что самым чистым был бы класс универсального лоадера, который через "что то типа рефлекции" если это про Жабу, смотрит структуру любого обьектаи сохраняет данные типа как JSON. Если надо сохранять не все поля то в классе прописывается какие поля надо сохранять.
Не надо в лекции по SOLID говорить белиберду. Отдельно класс который сохраняет специфический обьект специфическим образом непрактично потому что у вас будет n * m таких классов где n количество классов а m виды сохранения.
Solid - это только для ООП?
Если я программирую, например, в процедурном стиле?
4:05 услышал ответ.
Нет, философия солид - не только про ооп
👍🏻
Все же лучше называть класс не действием - это ведь сущность. Здесь, в примере с Computer, имхо достаточно рассмотреть навязшую в зубах mvc. Есть область хранилища, есть само представление сущности, и есть какой-то контроллер, обеспечивающий взаимодействие хранилища и представления. Имхо🥴
Лайк с вертухана
Первый принцип - фактически о том, насколько удачно вы декомпозицировали задачу…
Мне кажется, что автор не правильно объяснил принцип подстановки Лисков.
Прошу прощения, последний принцип тоже, мне кажется, объяснили не правильно.
08:11
Так может надо было на питоне и делать эту рубрику...
там не покажешь так явно интерфейсы как в Java
Интерфейс и абстрактный класс в джаве две совершенно разные сущности
Курс клёвый , но конец подкачал
Нету абстрактных методов..
Потчем тут ява к пайтону?
это не про Python, а про SOLID, а SOLID - про все ООП
@@selfedu_rus вот только это в плейлист
ООП python
он во всех плейлистах по ООП, не только в Python
Ну, проект из нескольких классов как бы надо уже на масштабирование закладывать…🥴
Ще б паттернів і побільше...
22:3
ну, в общем-то, типичные ошибки (странно, что человек, перед тем как учить кого-то, не может просто даже вики открыть - не то что, открыть книжку мартина, где всё это подробно расписано):
1) принцип единственной *ОТВЕТСТВЕННОСТИ* не про то, что класс или метод должен отвечать за одну вещь. даже на вики написано: "A class should have only one reason to change" R. Martin. и где тут что-то про работу класса? принцип о том (и на ютубе есть видео, где дядюшка это поясняет на примерах), что класс должен иметь ОДИН ИСТОЧНИК ДЛЯ ИЗМЕНЕНИЙ. т.е. если этот класс создан по заказу бухгалтерии, для их расчетов, то он не должен меняться по приказу отдела кадров. в противном случае, существует вероятность, что после изменений для кадров, у бухгалтерии отвалится жопа.
2) osp - самое простое. но даже тут чувак нарушает принцип наименования интерфейсов (как и в целом в видео). интерфейс - это прилагательное (или существительное, если это группа объектов). отвечает на вопрос: "какой?". отвечает ли SaveInterface на вопрос "какой?" - вопрос риторический. и ладно бы он придерживался такого написания везде - но нет: тут добавляет Interface, потом пишет интерфейс Shape, без добавления Interface, потом вообще пишет ICircle. чувак, определись уже.
3) принцип лисков не о том, что дочерний класс должен ПОЛНОСТЬЮ повторять ФУНКЦИОНАЛ. вон, в комментах у людей тоже вопрос - "нафига тогда есть переопределение метода?". принцип о том, что дочерний метод должен соответствовать той же БАЗОВОЙ СИГНАТУРЕ, что и родительский. т.е. если у тебя базовый метод принимает число, как аргумент, и возвращает число, то и дочерний метод должен делать то же самое: иметь ПЕРВЫМ аргументом число, и возвращать число. но это не значит, что я в дочерний метод не могу вторым аргументом добавить строку, например. и это не означает, что в теле метода я не могу реализовать другую работу, нежели в базовом. если у меня базовый класс возвращает число, путем возведения аргумента в квадрат, то я в дочернем классе могу вернуть число, путем умножения аргумента на самого себя. или умножить его на 2. или на 10. да, результат будет неправильным, но он будет соответствовать ожидаемому типу. но если ты переопределишь метод, но сделаешь возвращаемый тип строкой, то при подстановке, у тебя сломается программа, если ты захочешь использовать результат, как число, но получишь строку.
да, в видео правильно сказано, что изменение свойств класса в переопределенном методе тоже нарушает этот принцип. но это лишь его часть.
4) тут всё понятно, кроме нейминга интерфейсов
5) опять проблемы с наименованием. как язык программирования (sql) может быть типом базы данных? если ты делаешь абстракцию базы данных, то и называй ее DB. базой данных может быть и локальное хранилище - каким боком оно тогда относится к sql?