а использование FooChild вместо Foo разве не нарушение во входящих параметрах?

да, нарушение, не обратил внимания

Тут больше нарушения dip

Тут больше нарушения dip

в каком месте?))

A. High-level modules should not depend on low-level modules. Both should depend on abstractions. B. Abstractions should not depend on details. Details should depend on abstractions.

в каком месте?))

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

Both should depend on abstractions.

Ок

Both should depend on abstractions.

мне кажется ты не очень понимаешь суть этого

а если модули одного уровня, что мешает им зависеть напрямую?)

ну то есть тут вроде человек жаловался что пришел какой-то чел, сказал что у всего должен быть интерфейс а иначе не по солид и нарушает ДИП

а если модули одного уровня, что мешает им зависеть напрямую?)

вот именно

Ну судя по коду у нас не одного уровня

а если модули одного уровня, что мешает им зависеть напрямую?)

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

но вот тебе еще интересный вариант class SomeProvider implements Provider { public function supports(Data $data): bool { return $data instanceOf SomeData; } public function handle(Data $data) { if (!$data instanceof SomeData) { throw new \InvalidArgumentException(); } // .. do stuff } }

нарушает ли этот код LSP?

нарушает ocp

нарушает ocp

в каком месте?)

нарушает ли этот код LSP?

неистово, а что?

неистово, а что?

ну вот он не нарушает LSP

Объкты должны быть открыты для расширения закрыты от изменения

Объкты должны быть открыты для расширения закрыты от изменения

и что это значит?

Если у тебя появится SomeData2

потом 3

Будет вермешель из IF

Это косяк

неистово, а что?

LSP не нарушено потому что контракт подразумевает такое использование: foreach ($providers as $provider) { if ($provider->supports($data) { return $provider->handle($data); } }

это к слову так же говорит что OCP не нарушено потому что если вдруг появится SomeData2 то появится SomeProcessor2

Объкты должны быть открыты для расширения закрыты от изменения

модешь ли ты связано OCP и такое понятие как низкая связанность?

и второй вопрос - может ли связанность отсутствовать полностью а код только добавляться? ну то есть - возможно ли в принципе НЕ нарушать OCP?

Полностью естественно нет, в конце концов на что тобудет завязано например на front contoller

но с твоим примером я слегка не согласен

Хотя нет

Хотя хз)

Первое

ну вот он не нарушает LSP

Потому что он изначально в support указан? Если SomeData это наследник от Data - это всё тоже сужение входных параметров, просто менее явное, не?

LSP не нарушено потому что контракт подразумевает такое использование: foreach ($providers as $provider) { if ($provider->supports($data) { return $provider->handle($data); } }

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

Все таки нет не нарушает

тесты по солид?)))))

Орнул

Потому что он изначально в support указан? Если SomeData это наследник от Data - это всё тоже сужение входных параметров, просто менее явное, не?

потому что контракт подразумевает как именно им будут пользоваться

ну то есть для LSP и OCP важен не сам класс а именно контекст в котором оно используется

Ну только опять же интерфейсы не классы

так же как для SRP важен не сам класс а выявление ролей которые привязаны к поведению

Ну только опять же интерфейсы не классы

а в чем разница?

для контрактов разницы нет

Ну это детали

Все то же нужны абстракции

Все то же нужны абстракции

важный вопрос - зачем

кому они нужны и зачем

ну то есть для LSP и OCP важен не сам класс а именно контекст в котором оно используется

соглашусь, но ты читер и не показал использование сразу.

с этой точки зрения ISP очень важный принцип которым часто принебрегают

соглашусь, но ты читер и не показал использование сразу.

да)

кому они нужны и зачем

Все тот же dip

Без этого у нас связанность повышается

а мы ее стремимся снизить

разве нет?

Все тот же dip

зачем нужен DIP?

Без этого у нас связанность повышается

в пределах одного модуля - это более чем нормально

избежать связанности бизнесс логики с со слоем фреймворка

избежать связанности бизнесс логики с со слоем фреймворка

да, тут нужен DIP, но причем тут все остальное?

по DIP очень удобно ознакомиться с архитектурой портов и адаптеров

Ну если рассматривать твой код

LSP не нарушено потому что контракт подразумевает такое использование: foreach ($providers as $provider) { if ($provider->supports($data) { return $provider->handle($data); } }

То логичнее всего представить место где вызывается foreach более низким уровнем

Разве нет

Для DIP подразумевается использование не только на уровне библиотека\фреймворк -> бизнесс логика но и промежуточные уровни тоже

То логичнее всего представить место где вызывается foreach более низким уровнем

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

весь вопрос в том кто от кого зависит

ERROR: S client not available

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

короч в дополнение к принципам SOLID погугли Stable Dependency Principle от того же дяди боба (до того как он решил стричь бабло на брэнде SOLID)

а так же acyclic dependency principle, abstract dependency principle и еще пара штук каких-то

Всем добра! Скажите https://www.magephp.com/ актуален для 4-й версии симфони?

Всем добра! Скажите https://www.magephp.com/ актуален для 4-й версии симфони?

хз че это

это типа когда ты деплоишь архивчик и он потом такой изнутри разрывается чужим?

но не думаю что есть разница для него 3-я или 4-ая symfony

это типа когда ты деплоишь архивчик и он потом такой изнутри разрывается чужим?

Да, это для автоматизации поставки

но не думаю что есть разница для него 3-я или 4-ая symfony

Я тоже, но щупать буду уже завтра. На третьей версии работало как часы

ну... удачи)

))

http://symfony.com/blog/new-in-symfony-4-1-fastest-php-router

https://www.youtube.com/watch?v=kOa_llowQ1c

Вот вот просто взяли и в 77 раз ускорили роутер))

да, просто взяли и ускорили

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

Правильнее было бы написать up to 77. :))

и версию сменить на 77

Symfony 4.1 URL matching is 77 times faster than in previous Symfony versions. This also means that Symfony 4.1 router is now the fastest PHP router,

сщщд

cool

http://symfony.com/blog/new-in-symfony-4-1-fastest-php-router

это типа когда ты деплоишь архивчик и он потом такой изнутри разрывается чужим?

???

@fes0r призываю фесора!

@fes0r призываю фесора!

вы кто такие? я вас не знаю

ага

спам был?

знаем мы, проходили уже

дай мне, пожалуйста, ссылку на чат пхп, где ты админ

в котором 1100 + людей

мне помощь нужна по nginx

https://t.me/prophp7