SOLID: Принцип подстановки Барбары Лисков/ LSP (The Liskov Substitution Principle)

SOLID принцип LSP: Принцип подстановки Барбары Лисков (The Liskov Substitution Principle) объекты в программе должны быть заменяемыми на экземпляры их подтипов без изменения правильности выполнения программы.
Курсы для новичков:
JAVA - bit.ly/2CeYIhM
JAVA Start - bit.ly/2DU0IMJ
Инструментарий JAVA - bit.ly/33MKksj
Automation QA (Java) - bit.ly/2F1EQj9
ANDROID - bit.ly/30KeMSf
C#/.NET - bit.ly/2FeBPMN
C# START - bit.ly/3in99PC
PYTHON - bit.ly/2DU0HbD
FRONT-END - bit.ly/3ackHCB
WORDPRESS Developer - bit.ly/3aeE8e2
SALESFORCE Developer - bit.ly/2DU0Onz
UI/UX дизайн - bit.ly/30KvTmJ
Project management - bit.ly/3ah1RdI
Обучение на проекте - bit.ly/3iqfsSG
Продвинутые курсы для состоявшихся девелоперов:
GRASP and GoF Design patterns - bit.ly/2DuKo5z
Enterprise patterns - bit.ly/3fOPre2
Сайт Foxminded: bit.ly/30HAAxO
Foxminded в ФБ: / foxmindedco
FoxmindEd в Instagram: / foxminded.ua
Foxminded в VK: foxminded
Мой Telegram: t.me/nemchinskiyOnBusiness
Мой блог: www.nemchinsky.me
1. На основе работы Роберта Мартина (дяди Боба). Акроним SOLID предложен Michael Feathers
2. SOLID (сокр. от англ. single responsibility, open-closed, Liskov substitution, interface segregation и dependency inversion)
1. SRP Принцип единственной ответственности (The Single Responsibility Principle) - Каждый класс должен иметь одну и только одну причину для изменений.
2. OCP Принцип открытости/закрытости (The Open Closed Principle) - программные сущности … должны быть открыты для расширения, но закрыты для модификации
3. LSP Принцип подстановки Барбары Лисков (The Liskov Substitution Principle) объекты в программе должны быть заменяемыми на экземпляры их подтипов без изменения правильности выполнения программы
4. ISP Принцип разделения интерфейса (The Interface Segregation Principle) много интерфейсов, специально предназначенных для клиентов, лучше, чем один интерфейс общего назначения
5. DIP Принцип инверсии зависимостей (The Dependency Inversion Principle) Зависимость на Абстракциях. Нет зависимости на что-то конкретное
0:00 вступление Сергея Немчинского
0:22 формулировка LSP Робертом Мартином и Барбарой Лисков
2:53 принцип подстновки Барбары Лисков на примерах
5:40 LSP в формулировке Герба Саттера и Андрея Александреску
8:25 еще пример на картинке
11:35 про соблюдение LSP

[@-ebaka]

Роберт что-то непонятное сказал, то ли дело Барбара

[@6598335]

XDXDXD

[@user-pl9hn7mg1q]

Математически чёткое описание всегда более точное, чем словесное описание. Например, Правила Ассоциативноти и Дистрибутивности и звучат лучше...

[@vadimsokhatsky2748]

Сергей, спасибо! С вашими видео обучение программированию становится сплошным кайфом!

[@masterbedroom594]

Сергей, выражаю вам искреннюю благодарность

[@user-wq4yh7bl7g]

Классное видео, спасибо за детальное и простое объяснение, хотелось бы еще послушать про паттерн pipeline.

[@stakhovskiy]

Август месяц на дворе, а его все еще зовут Сергей Немчинский. Хосспаде! Спасибо за видео 😄Лайк.

[@z1zzz]

А в чём прикол?

[@igorost795]

Попрошу! Сергей "тутромбик" Немчинский!

[@TheHosuwisp]

Математический вариант Барбары все разложил по полочкам, а то так много воды и ничего не понятно.

[@SergeyNemchinskiy]

ахаха. Ну, рад за вас :)

[@ffconsole3467]

Попався, математiк

[@fakerliar6599]

Тоже объяснение Барбары показалось более простым и понятным, хотя не математик. Может это потому что я женщина?:D

[@murationametisation4347]

Чувак, и мне показалось вариант Барбары намного ясный и простой. Но задело то, что автор видео так обобщает, "всем непонятно". Бро, как раз таки и понятно. Это может для гуманитариев проблема понять из-за боязни математики.

[@lindx2533]

странно что ты за этим вариантом полез на ютьюб к немчинскому

[@sergekim5499]

Спасибо большое, Сергей!)

[@samuro2ua]

Сергей, тема разработки через тестирование очень интересна! Как и SOLID. Спасибо.

[@Snake19S]

Сергей, вы такой живчик в этом видео. Отлично получилось!

[@demidovmaxim1008]

Большое спасибо за выпуск!!!

[@wandos777]

Супер, Сергей) Спасибо большое за видео, однозначно лайк!)

[@user-vv5vt3di5l]

Дуже вам дякую за пояснення. Все просто і зрозуміло )

[@user-us5uf9tt8i]

надо! про тест фёст надо про нуль из методов и ДОСКУ МАРКЕРНУЮ! НАДО!

[@Asmaers]

и про красную футболку!

[@VitaliyZlobin]

доску особенно, уши режет

[@kspshnik]

дададад! и про TDD и про null надонадонадо!

[@user-it1qb3oi9b]

Доска как раз под бумагой. Приглядись)

[@dmitriykozyrev8835]

Сразу лайк, спасибо тебе большое!

[@andrey7829]

Очень понятно объясняете - супер, спасибо

[@sfoxer]

Лучший препод =) Что бы мы без вас делали)

[@andrew_golubev]

Качество стало на порядок лучше, так держать!

[@user-uf9kn1lg2s]

Спасибо большое за видео!

[@YuretsUA]

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

[@BukasovMaxim]

Я бы еще добавил, что при оверрайде неабстрактных методов, новый метод должен уметь принимать параметры в таком же диапазоне или шире (но ни в коем случае не уже), а при возвращении значений - в таком же диапазоне или уже (но ни в коем случае не шире). Например в каком-то классе есть метод, который умеет принимать число от 1 до 100 и возвращать от 1 до 10. Если его заоверрайдить так, что новый будет уметь принимать 0..200, а возвращать 3..5 - существующий клиентский код будет доволен. А вот если переписать так, что новый метод умеет принимать только 1..50 или вдруг возвращает 0..20 - то существующий клиентский код может быть неприятно удивлён. Также можно было бы еще сказать, что список выбрасываемых исключений можно сокращать, а исключения - конкретизировать, а вот наоборот - добавлять новые или расширять существующие - нельзя. Но с контролируемыми исключениями компилятор Джавы в этом плане сам подскажет, что можно, а что нет, а неконтролируемые... на то они и неконтролируемые :)

[@vladzaiko5012]

что то я не уверен что вы правильно написалали, если базовый класс возвращал от 1 до 10, а наследник будет возвращать от 3 до 5 а это ведь нарушение принципов о которых говорит Сергей - наследник не может возвращать меньше чем базовый класс. Базовый класс будет ожидать что при определенных параметрах вернется 10, а наследник вернет максимум 5 и все сломается.

[@BukasovMaxim]

@@vladzaiko5012 Представьте, что есть клиентский код, который умеет разговаривать на английском, французском и немецком. Есть базовый компонент, который иногда выдаёт клиенту что-то на английском, а иногда - на немецком. Клиент понимает эти сообщения от компонента. Если заменим этот компонент на новый, который будет выдавать сообщения только на английском (т.е. сузим диапазон возвращаемых значений), то клиентский код всё еще будет понимать эти сообщения. А вот если новый компонент вдруг заговорит на японском (т.е. расширим диапазон возвращаемых значений), то клиентский код сломается - потому что клиентский код не знает, что делать с сообщениями на японском.

[@vladzaiko5012]

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

[@BukasovMaxim]

@@vladzaiko5012 Речь не о новых методах. Речь о старых методах, которые в новых компонентах вдруг начали выдавать на выход то, что старые компоненты не выдавали. Пример: батарейка (как компонент). Допустим у нас есть электрическая схема (клиент), которой нужно питание +5В +/-10% (т.е. от 4.5 до 5.5 - будет работать). Если у нас есть батарейка, которая выдаёт +5В +/- 5% (т.е. от 4.75 до 5.25), то все ОК, схема будет работать и не сгорит (потому что при замене компонентов выходные диапазоны можно сужать без проблем). Но если мы вставим батарейку +5В +/-20%, то она может дать или слишком мало (и схема не заработает) или слишком много (и схема сгорит). Поэтому, при подмене компонентов, расширять возвращаемый диапазон - нельзя (можно только сужать). Входной диапазон - наоборот: сужать нельзя (чтобы клиент не послал в компонент что-то такое, что он не поймёт), а расширять - можно (чтобы компонент был не глупее, чем его предок).

[@catmother8368]

@@BukasovMaxim спасибо за отличное объяснение! А что, если у нас есть класс User и класс Admin, который является наследником от User? Допустим, в User есть метод, вохвращающий все права пользователей. User будет возвращать стандартные разрешения типа редактировать аккаунт и проч. Но у Admin нужно будет расширять этот список. Верно ли я понимаю, что в данном случае произойдёт нарушение принципа LSP? Как этого избежать? Не лучше ли выделить отдельный класс с правами, чтобы не нарушать SRP?

[@jossefal1957]

Хорошее объяснение, как обычно лайк

[@user-is4ji8mr7j]

Давно ждал!

[@yuriyfedoryshyn5206]

looking forward to a TDD video))

[@LeoMrakobes]

@Sergey Nemchinskiy уже раньше обещал про "почему нельзя возвращать null"

[@newprim1]

Это самое лучшее объяснение принципа Лисков, что я встречал! Подписка однозначно

[@user-hv8rh8nk9d]

Отлично. Про тесты видео нужно

[@user-wt1tp2ff3h]

TDD - ДА! Про return null - ДА! Спасибо за видео!

[@alexeydeyev4970]

Очень интересно про Test First!!! В топ!!

[@ntvisigoth]

@Sergey Nemchinskiy: Мужик, здоровья тебе! Отличное пояснение! ;)

[@gomer3894]

спасибо за видео!

[@whoiam6395]

Спасибо огромное!!! В 3х словах рассказал то что я не смог понять ни в одном видео до этого.

[@whoiam6395]

А я их пересмотрел штук 10

[@user-ns7uz5dt4h]

TDD интересно. С удовольствием послушаю.

[@kotanhp3115]

Хорошее видео, жду такое же про Оксимирона

[@xdef42]

Я не использую наследование, я имплементирую интерфейсы, и занимаюсь агрегацией и композицией

[@nanvlad]

Ты сраный рукожоп по версии Немчинского)) Я тоже агрегирую и композирую с интерфейсами + ещё дженерики

[@alexeydeyev4970]

Имплементирование можно с натяжкой отнести к наследованию.

[@grommaks]

аналогично

[@makaroningable]

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

[@woodzimierz9621]

@@makaroningable есть товарищи, которые отрицают любую форму наследования

[@bumer7721]

Об ACID интересно послушать. А за SOLID благодарю)

[@maxlich9139]

было, Владимир Кузнецов рассказывал.

[@bumer7721]

@@maxlich9139 Дякую! Шукатиму.

[@siclbear]

Наконец-то я понял этот принцип)

[@alokym86]

Я знаю чому для Вас формулювання Барбари Лісков складне і заплутане! Все тому, що для Вас і квадрат - це не прямокутник!) Дякую за відео. Приклад з квадратом підірвав мій мозок.

[@Madeniath]

Про TDD интересно было бы посмотреть.

[@Oleksii_Leshchenko]

про то, как оно в жизни

[@sofiatopalidi9403]

Я вас обожаю. Вы один из самых интересных и умных людей, которых я знаю) спасибо за знания и ваш юмор ☺️

[@user-wd7mz4ys5o]

Або це просто вже 100те відео про Лісков і я нарешті зрозумів, або це найкраще з тих відео що я бачив і я зрозумів =))

[@SergeyNemchinskiy]

я просто умею объяснять :)

[@NikolayMishin]

Самый сложный принцип, я вечно сыплюсь на нем))) но объяснение с прямоугольником и квадратом просто огонь! Спасибо 🙏

[@yuriytheone]

Ты сыпишься, потому что Solid ложны. Каждый принцип ложен! Давай про Srp. Когда ты создаёшь дочерний класс, ты его создаёшь именно таким, какой нужен именно в твоём коде. И именно с таким интерфейсом, который нужен твоему софту. Далее Ocp - ты не только можешь менять код метода, но и должен если это нужно для оптимизации. Да, представь себе Ocp тоже ложен. Далее Lsp - зачем тебе порождать наследников и закидывать в какой либо метод работающий с классом родителем. Ну, вот ты и не можешь объяснить... У немчи6ского яйц нет признать, Solid - фуфло.

[@nataliia9346]

Хотелось бы с таким классным объяснением и примерами послушать о Паттернах Программирования :)

[@SergeyNemchinskiy]

эм.... Ну вот же оно: foxminded.com.ua/grasp-gof-design-patterns-advanced-on-line-course/

[@Brick87Game87]

супер, спасибо!

[@UnrealSPh]

Возможно, описание самой Барбары станет более понятным, если понимать когда она его предложила и как выглядели ассоциации типов в ЯП в то время, так как *спойлер* наследование не единственный способ ассоциации классов, а скорее частный случай. Насчёт использования наследования вы скорее всего заблуждаетесь, но причина заблуждения это легаси информация, которую из года в год перевыпускают в требованиях к коду. Если вы боретесь с копипастингом кода в проекте, то для этого больше подходит композиция кода. А если и методология разработки у вас не waterfall, то n-ступенчатая иерархия наследования превратит процесс изменения кода в ад (не забываем, что классы содержат ещё и стейты). Наследование сильный инструмент, но его главное назначение в продуктах, которые должны иметь жёсткую структуру иерархии, а так же максимально долгое время жизни самой иерархии. Напрмер фреймворки. Там наследование чувствует себя хорошо.

[@dmitrinikolaev6986]

Про TDD было бы очень интересно послушать!

[@alexeiceglei9841]

Юнит тесты интересны очень, особенно какие то хитрости, типо того же test first

[@TheDaslord]

Сергей, спасибо за видео! Пожалуйста, снимите видео про возврат null, очень интересно, сам постоянно так делаю.

[@woodzimierz9621]

Про TDD очень интересно.

[@victortamanov]

Про TDD интересно будет посмотреть.

[@dmytromarchuk3023]

Ставлю лайк відразу! "Виріс" на відосах Сергія про Design Patterns, Clean Code, etc

[@immortal-spirit-13]

Своеобразный парень :) Но мне очень нравится как он доносит, и он реально умный. Спасибо за видео. 👍

[@SergeyNemchinskiy]

спасибо :)

[@makskors5002]

TDD очень интересно!

[@mashinostroitel]

Спасибо :)

[@user-zu6hg3un6d]

Ах**нно) наконец то понял в чём фишка этого принципа

[@dmitry_shelemekh]

Крутотенюшка!

[@vanilla1006]

TDD, буду рад выслушать

[@AnnaIsHere]

Хотелось бы больший упор на "как надо" вместо "как не надо"

[@Gusto20000]

Просто берете как не надо и делаете не так и будет как надо

[@fractalzombie]

С опытом придёт.

[@user-dd1di2fv6i]

@@Gusto20000 и если это приходится объяснять, то, наверное, лучше никак не надо ;)

[@screamer8932]

@@Gusto20000 Часто бывает 101 способ как не надо и только парочку как надо. Кск би так убегая от плохого 98 способа не попасть в 86))

[@user-bd3fv1jp3i]

что касаемо lsp то что бы его не нарушать нужно просто придерживаться ооп. Надо постараться что бы его нарушить.

[@eligolin9947]

По моей оценке вся суть проблемы была не раскрыта. Наследование как "анти паттерн", основана на сложности соблюдение LSP принципа. Пройдёмся по примерам в этом ролике: 1. Здесь Сергей рассказывает как плохо нарушать LSP принцип и к чему это может привести. Но дело не в том что его нельзя явно нарушать (это и так понятно), а в том что его очень сложно соблюдать. 2. Сергей здесь спасибо вам за альтернативное определение LSP (оно добавляет глубины понимания!) хотя по моей оценке примеры всё равно слабы. 3. По моей оценке этот пример вообще не об этом. Здесь проблема не в соблюдении или несоблюдении LSP, а в отсутствии инкапсуляции. Это был хороший пример того что лучше писать иммутабильные классы а setters/getters могут раскрыть зачастую внутреннюю структуру класса. С точки зрения наследования - это как раз один из немногих примеров где наследование является корректным. Наследования квадрата от прямоугольника является математически правильным и хорошо обоснованным с точки зрения качеств квадрата по отношению к качествам прямоугольника.Если бы состояние этих классов задавалось только при помощи конструктора, то никакой проблемы не было бы.

[@olexkov4643]

Интересно все !!!!

[@romansharpe1131]

Есть 2 класса Pistol и Rifle. Оба должны стрелять и перезаряжаться, значит выносим эту логику в класс Weapon и наследуемся от него. Появлятся новое оружие Knife, которое тоже атакует (стреляет) и также наследуется от Weapon. Теперь нож и стреляет, и перезаряжается. Реализуем LSP: между классами Weapon -> Pistol/Rifle делаем прослойку Gun и выносим туда логику перезарядки, а в Weapon оставляем только атаку/стрельбу. В итоге получаем: Weapon -> Gun -> Pistol/Rifle и Weapon -> Knife

[@JackFastGame]

Что делать, если к такому пришли только после написания кода? Например, нужно было сделать пистолет и ружьё, написали классы: Weapon -> Pistol, Weapon -> Rifle, а потом заказчик добавил в ТЗ нож. Что теперь делать?

[@romansharpe1131]

​@@JackFastGame по нормальному неплохо было бы продумать все это заранее. Здесь же я привел свой пример, как выглядит LSP на практике.

[@0imax]

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

[@denisbielishev]

Будет интересно услышать про GRASP и GoF

[@AndriySydorka]

Дядя Сережа, росскажи про Test first!

[@Lammax2012]

TDD - очень интересно!!!

[@chocolazerboom7389]

Чёт прямо больно, что такие листы бумаги тратятся на то, что можно нарисовать на доске и стереть

[@ESTechnonet]

А еще больно - звук маркера скрипучий.

[@Chat-Mayevskogo]

Я себе тоже такую футболочку взял, тока черную, чтоб прям в тему последних времен было) Это когда джаву в js тоже будут компилить, наверное)

[@MrLobash]

не ну тут лайк))

[@Zlobusz]

Программирую на php в Symfony. На самом деле крайне редко приходится использовать наследование. Чаще фреймворк предоставляют интерфейсы, чем абстрактные классы. А наследоваться от какой-то конкретной реализации - тоже не совсем приятно. Поэтому случаев наследования можно по пальцам одной руки пересчить. Но принцип постановки Лисковой зашёл. Спасибо! Теперь бы про инверсию зависимости послушать)

[@alexeyb5830]

потому, что ооп это не про наследование. В чистой архитектуре про это написано. Ооп это про полиморфизм. Старину Боба видимо не всего Немчинский читал, либо читал и не понял.

[@radikovichkz2470]

А как на счет предпочитайте композицию наследованию?

[@HaiIag]

Я таки дочекався )

[@dmitriimolchanov4971]

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

[@samirsalimkhanov3554]

Надо убрать бумагу между маркером и доской, потом писать. Я так думаю))) спаисбо за видос

[@YuretsUA]

Это нарушает 1-й принцип SLP, каждому объекту своя зона ответственности, доска для того, чтобы бумагу удерживать, и бумага не рвалась под фломастером. А бумага уже для отображения текстовой информации, так что тут все грамотно...

[@user-td1ny2mg8q]

Можно видео про TDD, и про кидание нулей в методах, плис))

[@igor_knv]

Понравился пример про квадрат и прямоугольник. Кто-кого расширяет.

[@zapplay]

Хотелось бы увидеть видео о том почему нельзя возвращать null

[@dmitrypichugin7449]

Спасибо за фразу о не использующих наследование. Добавил себе в цитаты :)

[@maxlich9139]

Клевое видео. Единственное что Сергей не рассказал: что тогда делать-то, если твоя реализация не поддерживает данный метод базового класса? Я такое видел и не только в тестах и моках (и там да, бросались эксепшены; и вроде бы это даже было в каких-то известных либах)

[@user-mr1ii2wn2w]

Про tdd очень интересно, расскажите)

[@user-hp5yw6gn6w]

ну круто я понял как делать не надо ,а как делать надо сам разберусь спасибо лайк щищ

[@halgerdka9287]

про пример с квадратом. что мешает переопределить только метод getSquare() return a*a ? и вообще не трогать b

[@r2d2925]

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

[@eb6006]

Про TDD интересно, запишите пож-ста

[@Telemahk]

По итогу - надо квадрат наследовать от прямоугольника или правильнее новый класс делать?

[@user-em8ns3nw7n]

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

[@danilakapitanov7044]

Проблема не столько с определением площади, сколько с установкой сторон в клиентском коде. Правильным решением является создание абстрактного класса Figure с методом вычисления площади, от которого наследуется отдельно Rect и отдельно Square и реализуют метод вычисления площади. При этом для клиентского кода логика работы по установке сторон Rect и Square становится разная. Т.е. прямоугольник и квадрат по сути это разные сущности, как ,например, прямоугольник и круг.

[@alexanderbelov6892]

@@danilakapitanov7044 Раз уж речь про клиентский код работы с фигурами, то характеристики фигур должны прописываться при создании, и отсутствовать методы их изменения, которые будут разными для разных фигур. К примеру для фигур могут быть методы get_square() для площади, и scale() для изменения размера. Но никак не изменения характеристик описывающих фигуру по отдельности. Для изменения фигуры с другими сторонами нужно создать новую фигуру, а предыдущую удалить.

[@user-dd1di2fv6i]

Я вот чет не понял, что плохого в примере с квадратом ) Ну, перезаписал он сторону с 10 на 5, ну, посчитал он площадь 25. Так она такая и есть в его случае ) Одинаковый интерфейс родителя и наследника никак не означает одинакового результата. Если он одинаковый всегда, - нахрена наследовали-то? )

[@gromovoy1987]

Харизматичный

[@kyryloshamraiev6289]

Очень наглядное объяснение. Проще говоря, нужно наследовать большее от меньшего, а не наоборот. Все станет на свои места, если считать, что квадрат - это частный случай прямоугольника, а не его наследник. Именно такой подход применят учёные. Потому обьяснение Барбары и не понятно программистам с ООП профдеформацией. :)

[@RomanL321]

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

[@tislambek]

Можете расказать в следующем видео о проекты спринга

[@Mr43046721]

Про ТДД можно видео)) и про другие драйвен девелопмент

[@user-te1uc6fd9f]

Это вообще из другой оперы, но я бы послушал про DDD domain driven design, что такое bounded context и как его правильно определять

[@Leonardo-gd2iz]

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

[@vladyarets3596]

1:16 ну нафиг)) Как это прочитать получилось?!) 1:50 а не. вот тут нафиг, дяде Бобу спасибо огромнейшее!

[@FrolovDaniil]

Можно ещё про DRY, KISS, YAGNI

[@SergeyNemchinskiy]

уже в планах

[@FrolovDaniil]

@@SergeyNemchinskiy Смотрю Вас из интереса уже наверное больше года, когда ещё начинал знакомиться с Java, сейчас вообще Python разработчик. Так вот качество видосов стало на порядок выше, видно, что развиваетесь. Так держать! Пожалуйста, подумайте по поводу маркерной доски, а то эти шуршания маркера по бумаге некоторых приводят в ужас (меня например).

[@alexei3366]

можете записать видео почему метод не должен возвращать null?

[@woodzimierz9621]

Интересует на сколько сейчас актуально Eclipse RCP разработка? Сейчас вообще кто ни будь десктопы разрабатывает?

[@kosee4008]

класс

[@AAAnatoly]

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

[@YoungT18]

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

[@kisurov]

Ничего там нет страшного

[@pgriggs1299]

@@YoungT18 Mockito и JUnit обязательно нужно знать джуну, также будет в разы круче, если код, например, в пет-проектах будет протестирован, потому что не протестированный код = нерабочий код

[@r2d2925]

Что сложного, вызвал метод, передал тестов данные, и сравнял с заранее верным ответом. Это примитив, но смысл таков. Модульные тесты сложнее, но тоже эмалируешь роботу кода и сравниваешь с подготовленным ответом.

[@John_602nd]

Ничего страшного совершенно, с ними другая проблема, что их ленятся писать. В Java все юнит тесты: @Before, @Test, assert(Equals/That/...) Если прочитать как это работает, то... Это в целом всё. А прочитать можно в первой же статье в гугле по запросу "Java UnitTest"

[@dmytromarchuk3023]

Про TDD цікаво, запишіть відео

[@VoroninPavel]

Хе-хе, люблю этот пример с квадратом и прямоугольником. Только он еще веселее. Если ввести иммутабельность с втиле старого доброго ФП и после вызова любого "мутирующего" метода возвращать экземпляро нового объекта, то квадрат-таки можно сделать проямоугольником, не нарушая принципы ООП ;-)

[@kosatchev]

Принцип на примере семьи Хилтон: class Hilton { Money manageHotel(Hotel h) { Money m = makeCustomersHappy(c); return m; } } class Paris extends Hilton { @Override Money manageHotel(Hotel h){ Money m = sellHotel(h); return m; } }

[@torrvic1156]

Отличная шутка про ведение бизнеса 😂

[@homo-ergaster]

Вот что интересно, базовые классы Java нарушают LSP совершенно без стеснения. Попробуйте, например, сделать так: Map map = Map.of("a", 10, "b", 20); map.put("c", 30); и охренейте от того, что вам прилетит Exception в Runtime. При том что вся эта лабуда прекрасно скомпилируется. Когда-то налип с этим делом по незнанию, пришлось в довольно большом пакете искать где я делал Map.of и переделывать на new HashMap.