впервые встречаю того, кто четко объясняет этот принцип с использованием ковариантности и контрвариантности, а не как обычно невнятно чего-то там про "соблюдайте контракт" - а что оно такое даже и не говорят в итоге однозначно зачет
Да, хорошее замечание, надо было сделать какой-то вывод. Но конкретно проблема квадрат/прямоугольник решается отделением Square от Rectangle в силу того, что логика изменения размеров у них принципиально отличается.
Это не решает проблемы, так как чтобы определить ожидаемое поведение (в данном случае вычисление площади), нужно знать, с экземпляром какого конкретно класса взаимодействует код. В продемонстрированном коде теста эта проблема не совсем очевидна в силу того, что экземпляр тестируемого класса создаётся прямо в тестовом методе. А вот если бы экземпляр класса Rectangle получался от абстрактной фабрики или фабричного метода, то тогда пример был бы нагляднее: мы получаем прямоугольник, устанавливаем размеры 10х3, и ожидаем площадь 30, но получаем - 9. Да и в целом вынос метода в интерфейс или абстрактный класс не решит нарушение принципа, заключающееся в изменении свойств родительского класса в методе класса-наследника. Тут до кучи проявляется нарушение принципа открытости/закрытости.
Что он говорит в джава ковариантность аргументов методов не работает, это же не правда, короче он то сам хоть пересмотривает ролики свои? он напутал все то говорит про ковариантность то про контрвариантность и он сам себя запутал....
Возможно, я не совсем ясно выразился в ролике, отрицать не буду. Но ковариантность и контравариантность типов аргументов при переопределении методов в Java не работают. Да, можно в классе-наследнике объявить метод с сигнатурой, отличающейся только типом аргумента от сигнатуры метода из класса-родителя, проблем с точки зрения компилятора это не вызовет. Но это будет уже не переопределением метода (overriding), а перегрузкой (overloading). И это будет уже новый, а не наследуемый метод.
впервые встречаю того, кто четко объясняет этот принцип с использованием ковариантности и контрвариантности, а не как обычно невнятно чего-то там про "соблюдайте контракт" - а что оно такое даже и не говорят в итоге
однозначно зачет
После вашего объяснения все встало на места с этим принципом, спасибо
Лайк, коммент, следующий ролик!
Если рабоотает с классом, то должно работать и с подклассом этого класса. Нужно запомнить, что это именно L в солид, спасибо
Тему Ковариантности/Контрвариантности раскркрой более широко пожалуйста. Класно бы в сравнении с TypeScript.
поддерживаю. Не совсем понятно как мы от упрощеной трактовки принципа перешли к ограничениям на Ковариантности/Контрвариантности :)
Так в конце нужно было показать, как правильно орагнизовать логику класса
Да, хорошее замечание, надо было сделать какой-то вывод. Но конкретно проблема квадрат/прямоугольник решается отделением Square от Rectangle в силу того, что логика изменения размеров у них принципиально отличается.
@@shurik_codes в принципе можно вынести метод в интерфейс или абстрактной фигурой пользоваться.
Это не решает проблемы, так как чтобы определить ожидаемое поведение (в данном случае вычисление площади), нужно знать, с экземпляром какого конкретно класса взаимодействует код. В продемонстрированном коде теста эта проблема не совсем очевидна в силу того, что экземпляр тестируемого класса создаётся прямо в тестовом методе. А вот если бы экземпляр класса Rectangle получался от абстрактной фабрики или фабричного метода, то тогда пример был бы нагляднее: мы получаем прямоугольник, устанавливаем размеры 10х3, и ожидаем площадь 30, но получаем - 9.
Да и в целом вынос метода в интерфейс или абстрактный класс не решит нарушение принципа, заключающееся в изменении свойств родительского класса в методе класса-наследника. Тут до кучи проявляется нарушение принципа открытости/закрытости.
Спасибо!!!!!
Вступайте в официальный паблик в VK: vk.com/shurik_kodit
Подписывайтесь на канал в Telegram: t.me/rural_java
Записал вдогонку ролик с решением проблемы квадрата/прямоугольника: th-cam.com/video/AILeiAJY_78/w-d-xo.html
Что он говорит в джава ковариантность аргументов методов не работает, это же не правда, короче он то сам хоть пересмотривает ролики свои? он напутал все то говорит про ковариантность то про контрвариантность и он сам себя запутал....
Возможно, я не совсем ясно выразился в ролике, отрицать не буду. Но ковариантность и контравариантность типов аргументов при переопределении методов в Java не работают.
Да, можно в классе-наследнике объявить метод с сигнатурой, отличающейся только типом аргумента от сигнатуры метода из класса-родителя, проблем с точки зрения компилятора это не вызовет. Но это будет уже не переопределением метода (overriding), а перегрузкой (overloading). И это будет уже новый, а не наследуемый метод.
Автор нарушил прицип единственной ответственности и напихал в видео кучу всего кроме самой Барбары, чем только запутал зрителя.