Наследование Inheritance в ооп - проблемы которые могут возникнуть
HTML-код
- Опубликовано: 22 окт 2019
- В этом видео описаны проблемы которые появляются при использовании наследования в объектно ориентированном (ооп) программировании.
Видео о преимуществах использования композиции - • Композиция Composition...
Наследование скорее вредит чем помогаем в написание нашего кода.
matthiasnoback.nl/2018/09/fin... в этой статье на английском автор обьясняет почему он принял решение не использовать наследование вообще.
Почему так мало подписчиков, такой канал топовый, автор объясняет все ну максимально понятно, большим каналам стоит поучиться. Автору второй раз за день респект:)
В примере с корзиной, будет ошибка Deprecated: Creation of dynamic property FastBasket::$items is deprecated in ... т.к св-во приватное, что бы ее не было нужно сделать protected
Спасибо
на ноль делить нельзя - это не проблема инкапсуляции, а проблема в самом методе подсчёта
Насколько это всё относится и к имплементации?
Не уверен что понял в чем вопрос, имплементации это какое то решение в коде которое мы реализует. Можете вы имели ввиду инкапсуляция ?
@@livecodingschool8906 Я хотела узнать насколько, по-вашему, тема относится не только к наследованию (использованию родительских классов), но и использованию интерфейсов.
... и заодно к множественному наследованию, трейтам?
@Victoria M тема данного видео относится только в наследованию интерфейсы и трейты оно не затрагивает.
Больше не согласен с автором чем согласен, если это как в примерах php то на скорость не ВЛИЯЕТ (ну не критически), если только в конструкторе базы нет тяжёлых запросов итп что уже неверно.
1. Должна быть продумана архитектура приложения так чтобы не было проблем
2. В пункте с деливери и скидками можно использовать трейт
3. SOLID
4. Пример с setItem возможен если у людей кривые руки или неправильная архитектура которая этот айтем размывает между классами, наименования по SOLID.
Ну т.е. проблема конечно есть, но зависит от программиста.
спасибо за комментарий. 1 - как правило требования меняются/добавляются уже посте того как что-то сделано так что заранее что-то придумать нет возможности. 2 использование traits это уже не наследование не понятно почему вы здесь со мной не согласны ). 3 наследование нарушает ( потенциально нарушает) первые три условия S O L. 4. Вопрос вы будете уверены что ни чего не сломаете если относледуете дочерний класс скорее всего да но вот если наследование продолжится на 100% быть уверенным быть нельзя, а вдруг вам нужно поменять в родительском классе - (у вас 4 потомка и 3 подпотомка ) вы все еще так же уверенные в том что ничего не сломается ? какие бы примые руки небыли с наследованием потенциально вероятность ошибки возрастает . Оно вам надо ? Если говорить о простом скрипте то здесь все можно в одном файле уместить а вот если в проекте сотни тыс строк кода здесь нужно бы задуматься
Наследование применять когда оно уместно, а функционал классов контролировать интерфейсами.
А решение какое? Через композицию?
да решение в следуюдщем видео
@@livecodingschool8906 Уточняйте пожалуйста, какое видео. У меня например отображается следующее видео "Неудержимые 3". А в целом видео понравилось.
Лучьше 2-3 дубляжа, чем один швейцарский нож с надписью на рукоятке "Костыль"
Можно вообще обойтись без наследования. Вот язык Go вообще обходится без него. Да, там есть any, композиция. Но как-то можно. И это вообще антипатерн, как оказалось после использования C++, Java
На мой взгляд это не проблема наследования, а проблема проектирования класса. Если у вас возникли проблемы, значит вы неверно спроектировали класс.
@@sardaucar да, всегда надо планировать разработку