Size: a a a

Software Design/Architecture/Zen

2021 May 21

SP

Sergey Protko in Software Design/Architecture/Zen
Надо с позиции клиентского кода смотреть. Тут кому-то диф делать придется
источник

s

s4b0t in Software Design/Architecture/Zen
Наверное профдиформация сказывается.
Для примера можно взять ноут или комп. Где в принципе уже всё сгуппировано. Моник соеденён маленьким интерфейсом с видюхой.
Клава соединяется не кучеё проводковс системным блоком, а куча проводков проходят по плате  внутри выделенного блока клавиатуры и тужаже вынесен контроллер клавиатуры в результате осталось питание и шина данных.
источник

МФ

Максим Федоров... in Software Design/Architecture/Zen
А можно наоборот, как Сергей неоднократно и говорил

Посмотреть на конкретную функцию управления тв  и при необходимости в пульт влепить,

появилась новая функциональность — сделал, а куда-либо завязать всегда найдётся
источник

МФ

Максим Федоров... in Software Design/Architecture/Zen
Проектировать комп и по пути искать, куда блок и ответственность вынести — так себе решение
источник

SP

Sergey Protko in Software Design/Architecture/Zen
А потом открываем какой МакБук где все компоненты на одном чипе
источник

SP

Sergey Protko in Software Design/Architecture/Zen
Главная проблема любителей солид в том что упускается главное - зачем все эти связи и как влияют друг на друга.

Шина pci хороший конечно пример open close но... Раз людям сложно аналогию через плагины к ide то явно не в недостатке метафор проблема
источник

SP

Sergey Protko in Software Design/Architecture/Zen
С электроникой можно ещё в примеры приводить m2 который вроде одинаковый но есть нюансы (sata/pcie)
источник

SP

Sergey Protko in Software Design/Architecture/Zen
А эти коварные "физически совместимо а электрически нет"
источник

s

s4b0t in Software Design/Architecture/Zen
Чем больше примеров тем лучше. Не претендую на объективность. Просто хотел поделится своим видением.
источник

SP

Sergey Protko in Software Design/Architecture/Zen
А так тот же lsp из солида это тот же robustness principle при проектировании протоколов
источник

s

s4b0t in Software Design/Architecture/Zen
В любом случае спасибо за обстоятельные разъяснения.
источник

SP

Sergey Protko in Software Design/Architecture/Zen
вообще в SOLID главное не связи эти а "потоки изменений требований". Кто влияет на поведение контракты и как эти контракты меняются. Потому вот эти аналогии с "посмотрите на то как комп собран" или там "разрежте панель посмотрите на проводки" не работают. Солид нельзя пощупать в статике, оно все работает при изменении требований
источник

s

s4b0t in Software Design/Architecture/Zen
Тогда как его применять с ходу? На опыте и интуиции?
источник

SP

Sergey Protko in Software Design/Architecture/Zen
Солид нужен для рефакторинга а не для проектирования, можно так объяснять )
источник

SP

Sergey Protko in Software Design/Architecture/Zen
До солида есть другие штуки которые ты должен понимать что бы эффективно солиды юзать
источник

SP

Sergey Protko in Software Design/Architecture/Zen
удобно думать что есть набор из 5-ти принципов (всеравно никто дальше SRP не читает судя по всему) и ты архитектор
источник

SP

Sergey Protko in Software Design/Architecture/Zen
даже если "до" этого этих же принципов было 11
источник

SP

Sergey Protko in Software Design/Architecture/Zen
источник

SP

Sergey Protko in Software Design/Architecture/Zen
и даже если "до" этого SOLID был только про то как пакеты/библиотеки компановать.
источник

SP

Sergey Protko in Software Design/Architecture/Zen
или там никто не понимает в чем прикол с Open/Close - ведь смотрят не на C++ с DLL/SO.
источник