Меню
Что нового?

задачки по SOLID, встречали?

ivanov77

Новичок
Привет.
По математике когда мы изучаем геометрию или алгебру есть куча задачек, их решений, проверок правильного ответа.
Есть что нибудь такое, но только по SOLID? И вики и много всего на хабре прочел, но как бы закрепить теперь на практике?
 
Absinthe

Absinthe

жожо
Задачки существуют только для базового уровня навыков.
Понимание SOLID - это уровень мидла.
 
Hello

Hello

Новичок
@ivanov77, в математике для конкретной задачи есть конкретное решение, SOLID это абстрактное понятие и проверять реализацию компьютер пока не умеет.
Найди преподавателя.
 

ivanov77

Новичок
Hello написал(а):
@ivanov77, в математике для конкретной задачи есть конкретное решение, SOLID это абстрактное понятие и проверять реализацию компьютер пока не умеет.
Найди преподавателя.
Нажмите для раскрытия...
Не такое уж и абстрактное.
Да и причем тут проверка компьютером?
Многие агитируют за использование SOLID, а чтобы подготовить уроки с описанием предметной области и как они ее разрешили по правилам SOLID, не так уж густо.
Чаще просто приводится теория и надуманные примеры под каждый отдельный принцип.
 

ivanov77

Новичок
Не могу понять, вот тут автор пробует объяснять Liskovs Substitution Principle.
Пример с уткой.
Сначала он утверждает что т.к. электрическая утка может и не поплыть (т.к. нет батареек) то это нарушение, т.к. должна поплыть.
Потом походу в комментах с ним спорили и он зачеркнул это утверждение.
Т.е. то что электрическая утка не поплывет без батареек - это не нарушение LSP?
Что тогда нарушение, раз для LSP вон ту картинку с уткой все вставляют?
 
fixxxer

fixxxer

К.О.
Партнер клуба
Нарушение LSP - это когда контракт наследника не соответствует контракту базового класса или интерфейса.
Так что тут зависит от того, какой контракт у Duck.
Если Duck::swim():void, но ElectricDuck::swim():bool - это нарушение.
Если Duck::swim() не объявляет throws, но ElectricDuck()::swim throws CannotSwimException - это нарушение.
Если ElectricDuck::swim() в случае, если не включена, просто ничего не делает - формально никакого нарушения LSP нет (точно так же, как test stubs с пустыми методами-заглушками ничего не нарушают). Проблема тут, конечно, есть, но не на уровне нарушения LSP электроуткой.

В данном случае я бы ввел throws CannotSwimException в контракт swim. Обычная утка тоже ведь не всегда может плыть. Например, она стоит на земле.
 
Breeze

Breeze

goshogun
Команда форума
Партнер клуба
ivanov77 написал(а):
электрическая утка может и не поплыть
Нажмите для раскрытия...
Бензиновая утка может не поплыть, деревянная утка может не поплыть, даже живая может не поплыть ибо сил нет ибо не пожрала -- это всё внутреннее состояние объекта типа Утка, который требует питание для движения.
 
Breeze

Breeze

goshogun
Команда форума
Партнер клуба
Т.е. у него проверка IsTurnedOn должна быть в каждой реализации в виде isOnPower.
В этом случае даже деревянная утка сможет плыть, если ей дали кинетическую энергию.
 

ivanov77

Новичок
fixxxer написал(а):
Если ElectricDuck::swim() в случае, если не включена, просто ничего не делает - формально никакого нарушения
Нажмите для раскрытия...
вот я ж об этом и подумал, ну не поплыла, ее дело.

В примере там без наследования, но если LSP не нарушен, то тогда электрич утку можн сделать наследником живой.
Но тогда о чем это выражение, ассоциированное с LSP:
If it looks like a duck and quacks like a duck but it needs batteries, you probably have the wrong abstraction.

О том что электрич. утка от вызывающего кода потребует включения перед плаванием и нарушит предусловия?
 
fixxxer

fixxxer

К.О.
Партнер клуба
ivanov77 написал(а):
то тогда электрич утку можн сделать наследником живой
Нажмите для раскрытия...
Так себе идея. :) Только если какой-то хак.
Даже если в данный момент вроде все нормально, у живой утки может быть причина для ее изменения, и такое изменение при таком наследовании сломает электрическую.
AbstractDuck, от которой наследуются живая и электрическая, - норм.

Я там имел ввиду DuckInterface/AbstractDuck, конечно, одновременно подразумевая, что контракты Duck и DuckInterface/AbstractDuck одинаковы и нет нарушения LSP.

Тут не так давно @Вурдалак продвигал принцип abstract or final. Проанализировав код одного из своих проектов, я согласился с этим: нашел только два места, где я наследовался не от абстрактного класса, и оба случая - хаки. Хаки удобные и позволяющие быстро срезать углы, но такие, опасные очень.
 
Последнее редактирование:
WMix

WMix

герр M:)ller
Партнер клуба
ivanov77 написал(а):
электрич утку можн сделать наследником живой.
Нажмите для раскрытия...
Забавное событие, связанное с багами, произошло в австралийских воздушных войсках. Командование ВВС Австралии велело программистам смоделировать на компьютере поведение кенгуру при появлении в воздухе боевых вертолетов. Для начала, надо сказать, что сейчас в армиях всего мира используются компьютерные игры — имитаторы военной техники для обучения будущих пилотов боевых машин. Главное в таких программах — создание обстановки, максимально приближенной к боевой. Ландшафт, техника, «враги» — все должно быть «как настоящее».

В австралийской армии подобные программы — с солдатами, танками вертолетами и прочим, уже имелись, вот только кенгуру в них не фигурировали. Программисты принялись за дело. Чтобы не выполнять лишнюю работу, они взяли уже готовый программный объект — пехоту, и просто заменили солдат на кенгуру…

Демонстрация проводилась в присутствии высших военных чинов армии США. Все началось прекрасно: вертолеты «взлетели», стада мирно пасущихся кенгуру в ужасе разбежались в разные стороны. Но тут случилось странное: кенгуру, первоначально попрятавшись за холмами, внезапно сгруппировались и предприняли атаку на вертолеты невесть откуда взявшимися зенитно-ракетными комплексами. Они даже успели «сбить» пару боевых машин, пока вконец расстроенные австралийцы не прервали демонстрацию программы. Американцы пребывали в шоке, в конце концов, это же министерство обороны и подобные шутки здесь просто неуместны. А может и в самом деле кенгуру способны воевать?

Все объяснялось маленькой ошибкой программистов. «Поменяв» солдат на кенгуру, они забыли «отобрать» у тех амуницию. В результате кенгуру атаковали…
 

AnrDaemon

Продвинутый новичок
Не, я про кенгуру и вертолёты. Точно помню, что читал. Но дату не скажу.
Вообще, хорошо иллюстрирует проблему наследования.
 

ivanov77

Новичок
А насчет инверсии зависимости.
Видел примеры по ServiceLocator и DI, но вот например я раньше так часто делал (пример для Yii2):
PHP: 
// модуль
class Module {
    public $loginFormClass = '...'; // устанавливаемый через конфиг конкретный класс для формы логина
}
// экшен у контроллера этого модуля
public function actionLogin(){
   $class = $this->module->loginFormClass;
   $model = new $class; // для примера опустим возможность создать через DI, используя Yii::createObject
   //...
}
Тут же тоже нет у меня жесткой зависимости, есть название такому паттерну?
Ведь тут по сути даже нет требования совпадения типов форм логина, что хочешь то и ставь.
 
Войдите или зарегистрируйтесь для ответа.
Сверху