Первый принцип solid был неправильно рассказан. "У класса должна быть одна причина для изменения" не значит, то что он должен иметь одну ответственность(хотя такой принцип тоже есть, но это не солид), первый принцип солид значит, что класс должен быть ответственен только за один актор, актор - это что то вроде сущности бизнес логики, например отдел по работе с персоналом, бухгатерия и т.д. Эти два актора могут использовать фичу расчета времени, они используют один и тот же метод в коде, потому что это кажется логичным и подходит к принципу dry, но это не соответствует solid, приходит заказ на то что алгоритм расчета меняется для бухгалтерии, программист не замечает что эту фичу использует оба актора, а может и больше, меняет ее, тестирует, отправляет бухгалтеру, они говорят что все ок и это заливают на прод. Дальше начинается ад, так как для других акторов этот алгоритм не подходит.
Что за бред? Какие другие принципы? "У класса должна быть одна причина для изменения" - это формулировка SRP от самого дяди Боба (автора SOLID). Да, Мартин не придумал эти принципы, он их, так сказать, каталогизировал, но когда говорят о SOLID в целом и SRP в частности, то как правило ссылаются на него, как на автора. Наличие нескольких акторов как раз и подразумевает наличие нескольких причин для изменения. Читайте Agile Software Development, Principles, Patterns, and Practices, там все написано.
51:00 вообще не понял примера с квадратом и прямоугольником. Видимо потому что не понял поставленной проблемы. Принцип гласит о том, что класс-наследник должен соблюдать первоначальный интерфейс родителя. Т.е. условно, если у нас в ресторан есть простой повар и мы хотим его заменить шеф-поваром, то если повар умеет варить борщ, его должен уметь варить и шеф-повар (помимо остальных всяких штук). В программировании самым простым и наглядным примером будет попробовать подставить класс-наследник в тесты для класса родителя. Если он будет проходить тесты родителя -- принцип соблюдается. А пример с квадратом, как по мне, какой-то притянутый за уши получился, потому что если написать тесты для прямоугольника, отнаследовать от него квадрат и прогнать тесты, то они скорее всего пройдут успешно (при условии что потомок не изменяет/перегружает родительские методы)
Простейший тест для родителя - прямоугольника. Посчитать площадь прямоугольника со сторонами 4 и 5. Для прямоугольника вернётся 20. Если передать квадрат, с теми же параметрами, то площадь вернётся 25 и тест не пройдёт. Значит принцип нарушен. Но вообще принцип очень мутный, сам до конца не понимаю.
Так это получается в Лисков принципе должна быть возможность заменять родителей на наследников в любой точке программы? А в каких ситуациях нам может потребоваться сделать данную замену? Насколько он юзабелен в PHP?
Материал очень нужный и интересный, но .... Ну очень много оговорок, ошибок мелких... Не сомневаюсь, что автор все это прекрасно знает и понимает, но правильно объяснить не может. А вообще за видео спасибо!
@@romanmatyushkin3974 на 49 минуте автор опечатался в методах setWidth и setHeight. Например setWidth принимает на вход width, но в parent.setHeight передает height, а следует передать width.Также автор при подсчете площади квадрата назвал цифру 20, хотя правильно 25. Еще он сказал "...поскольку мы отнаследовались от квадрата...", но по факту мы квадрат относледовали от прямоугольника. И тд. Но, несмотря на такие мелочи, материал годный, спасибо.
Вебинар не плохой, но........................................ ! Если Меня автор данного ролика спросит как проехать к определённой улице, Я РАССКАЖУ ЕМУ ВСЮ ИСТОРИЮ СВОЕГО ГОРОДА !
*опа какая-то, а не вебинар... "Надею Вам понятно... Здесь нужно додумать..." и т.д.. Представляю "кашу" в голове тех людей, которые о SOLID в первый раз услышали из этого видео.
чтобы понять хорошо солид недостаточно одного видео/статьи/примера. нужно посмотреть несколько источников, а еще лучше попробовать проверить свой код на соответствие этим паттернам
Материал очень нужный и интересный, но .... Ну очень много оговорок, ошибок мелких... Не сомневаюсь, что автор все это прекрасно знает и понимает, но правильно объяснить не может. А вообще за видео спасибо!
![Принципы программирования и антипаттерны [GeekBrains]](http://i.ytimg.com/vi/Z90DFL2Ndow/mqdefault.jpg)
![Принципы программирования и антипаттерны [GeekBrains]](/img/tr.png)
SRP - 9:29
OCP - 28:20
LSP -46:03
ISP - 1:07:07
DIP - 1:15:00
ЧЕЛОВЕЧИЩЕ !!!!!!!!!!!!!!!!!!!!!!
Мне нравятся когда вот так объясняют. Спокойно, без всяких заумностей. Спасибо докладчику.
Очень неплохой вебинар по SOLID принципам. Каждый раз когда смотрю лекции по SOLID - узнаю что-то новое
Самое понятное и подробное объяснение, которое видел! Огромное спасибо!
У автора талант сложные вещи объяснять простым языком
А можно ссылку на 3-ю лекцию по DI ?
Первый принцип solid был неправильно рассказан. "У класса должна быть одна причина для изменения" не значит, то что он должен иметь одну ответственность(хотя такой принцип тоже есть, но это не солид), первый принцип солид значит, что класс должен быть ответственен только за один актор, актор - это что то вроде сущности бизнес логики, например отдел по работе с персоналом, бухгатерия и т.д. Эти два актора могут использовать фичу расчета времени, они используют один и тот же метод в коде, потому что это кажется логичным и подходит к принципу dry, но это не соответствует solid, приходит заказ на то что алгоритм расчета меняется для бухгалтерии, программист не замечает что эту фичу использует оба актора, а может и больше, меняет ее, тестирует, отправляет бухгалтеру, они говорят что все ок и это заливают на прод. Дальше начинается ад, так как для других акторов этот алгоритм не подходит.
Что за бред? Какие другие принципы? "У класса должна быть одна причина для изменения" - это формулировка SRP от самого дяди Боба (автора SOLID). Да, Мартин не придумал эти принципы, он их, так сказать, каталогизировал, но когда говорят о SOLID в целом и SRP в частности, то как правило ссылаются на него, как на автора. Наличие нескольких акторов как раз и подразумевает наличие нескольких причин для изменения. Читайте Agile Software Development, Principles, Patterns, and Practices, там все написано.
51:00 вообще не понял примера с квадратом и прямоугольником. Видимо потому что не понял поставленной проблемы. Принцип гласит о том, что класс-наследник должен соблюдать первоначальный интерфейс родителя. Т.е. условно, если у нас в ресторан есть простой повар и мы хотим его заменить шеф-поваром, то если повар умеет варить борщ, его должен уметь варить и шеф-повар (помимо остальных всяких штук). В программировании самым простым и наглядным примером будет попробовать подставить класс-наследник в тесты для класса родителя. Если он будет проходить тесты родителя -- принцип соблюдается. А пример с квадратом, как по мне, какой-то притянутый за уши получился, потому что если написать тесты для прямоугольника, отнаследовать от него квадрат и прогнать тесты, то они скорее всего пройдут успешно (при условии что потомок не изменяет/перегружает родительские методы)
Простейший тест для родителя - прямоугольника. Посчитать площадь прямоугольника со сторонами 4 и 5. Для прямоугольника вернётся 20. Если передать квадрат, с теми же параметрами, то площадь вернётся 25 и тест не пройдёт. Значит принцип нарушен. Но вообще принцип очень мутный, сам до конца не понимаю.
Спасибо за лекцию. Очень хорошее и понятное объяснение. 10)
Спасибо, очень хорошо и доступно объяснили
а как можно сделать класс закрытым для модификации, если редактировать можно любой файл проекта?
Оценка по 10 бальной - 100 :-) спасибо!
Спасибо за знания.
А третье видео есть ?
Очень хорошее объяснение. Благодарю.
Все понятно, спасибо, SOLID
10 лет использую принцип Барбары Лисков - не наследую вообще, так как нарушаю этот принцип))
Так это получается в Лисков принципе должна быть возможность заменять родителей на наследников в любой точке программы? А в каких ситуациях нам может потребоваться сделать данную замену? Насколько он юзабелен в PHP?
крепанулся на полный просмотр, понял только про принцип единоответственности)
th-cam.com/video/Z90DFL2Ndow/w-d-xo.html Первая лекция
Т.Е фактически DIP - это паттерн стратегия?)
*Нормально ли учить Apache Maven после Java Core?*
Наверное предыдущую лекцию, которая была когда в прошлом - нужно искать самим на сайте GB в разделе выбинары.
Предыдущая лекций которая? Можно ссылку.
th-cam.com/video/Z90DFL2Ndow/w-d-xo.html
Материал очень нужный и интересный, но .... Ну очень много оговорок, ошибок мелких... Не сомневаюсь, что автор все это прекрасно знает и понимает, но правильно объяснить не может. А вообще за видео спасибо!
а я очень сомневаюсь, есть ряд грубых оговорок
@@Todortodorov62 , ваш комментарий имел бы гораздо больше ценности, если бы вы указали конкретные проблемы.
@@romanmatyushkin3974 на 49 минуте автор опечатался в методах setWidth и setHeight. Например setWidth принимает на вход width, но в parent.setHeight передает height, а следует передать width.Также автор при подсчете площади квадрата назвал цифру 20, хотя правильно 25. Еще он сказал "...поскольку мы отнаследовались от квадрата...", но по факту мы квадрат относледовали от прямоугольника. И тд. Но, несмотря на такие мелочи, материал годный, спасибо.
Очень познавательно и интересно слушать в таком формате, но альпари все равно лохотрон)
Спасибо
thank for really detail information.
Помню на собеседовании был в альпари) там этот препод меня собеседовал.
Я тоже был, в итоге я спрашивал про код и оказалось они сами нифига не применяют эти принципы в своей разработке, говнокод одним словом
@@getanduse ну меня взяли, но я отказался)
А где третья лекция?
третья не появилась?
первая тут: th-cam.com/video/Z90DFL2Ndow/w-d-xo.html
Принципы программирования и антипаттерны [GeekBrains]
Val Firstмн
Вебинар не плохой, но........................................ !
Если Меня автор данного ролика спросит как проехать к определённой улице, Я РАССКАЖУ ЕМУ ВСЮ ИСТОРИЮ СВОЕГО ГОРОДА !
Пишущимися :)
*опа какая-то, а не вебинар... "Надею Вам понятно... Здесь нужно додумать..." и т.д..
Представляю "кашу" в голове тех людей, которые о SOLID в первый раз услышали из этого видео.
Чувак, это просто краткий обзор. Без предварительного опыта, логично, что ты не сможешь освоить такой объемный принцип построения программ.
чтобы понять хорошо солид недостаточно одного видео/статьи/примера. нужно посмотреть несколько источников, а еще лучше попробовать проверить свой код на соответствие этим паттернам
Ну уж 5 минут тишины-то могли бы и вырезать
Спасибо!
Материал может и полезен, но он очень сухо и скучно подан, примерно как на типичных лекциях в универе
Спасибо за обратную связь. Передадим коллегам!
все-таки ооп и все эти принципы худшее что случалось с программированием
почему?
ахах, как методы трехмерного мира так и дохуенного. мне одному послышалось?
Материал очень нужный и интересный, но .... Ну очень много оговорок, ошибок мелких... Не сомневаюсь, что автор все это прекрасно знает и понимает, но правильно объяснить не может. А вообще за видео спасибо!