Comments 14
1) Роберт Мартин заостряет внимание читателя на различии между software design и software architecture. SOLID — имеет большее отношение к дизайну систем, а не архитектуре как заявлено в заголовке. Непонимание этого — очень большое упущение.
2) Чтение подобной литературы не в оригинале, не на английском так же ведет к не верной трактовке написанного.
Да, переводы вносят смысловые "потери". Изредка сталкивался с последствиями этих потерь в рабочем процессе, но написать и тем более опубликовать этот разбор заставила англоязычная книга русского автора, в которой эти потери для принципов SOLID закреплены переносом на язык оригинала. Слово "архитектура" появилось из названия русского перевода упоминаемой (фото обложки) книги Р. Мартина: "Чистая архитектура".
За долгие годы вокруг понятий «дизайн» и «архитектура» накопилось много путаницы. Что такое дизайн? Что такое архитектура? Чем они различаются?
<...> Прежде всего, я утверждаю, что между этими понятиями нет никакой разницы. Вообще никакой.
Р. Мартин, «Чистая архитектура»
Мне кажется, такие статьи только усложняют [задачу].
Знаки препинания конечно же в данном случае не несут ни малейшей сколь бы то ни было заметной пользы.
На мой взгляд, статья не облегчает и не упорядочивает восприятие принципов SOLID. Только ещё больше запутывает.
Зачем это мудрёное усложнение? Там же всё просто. Из всех 5 принципов, только LSP сложен для восприятия, и то вы как-то коряво его объяснили.
Проблема не в том, что квадрат как то не так наследуется от прямоугольника. Проблема в том, что квадрат, прямоугольник, ромб и параллелограммом является абсолютно разными фигурами не смотря на ряд сходст. И ни кто из них не является подтипом другого о чем и говорит LSP.
И зачем вы объединили ISP и DIP? Это разные принципы. У них из общего только то, что они входят в SOLID. К слову, SOLID это про зависимости.
Рекомендую к прочтению https://github.com/jupeter/clean-code-php или форк на русском https://github.com/peter-gribanov/clean-code-php
Эти мысли понятны, это все помогает справиться со сложностью и работает одинаково и в общей архитектуре и в деталях, хоть при объектном, хоть при функциональном, хоть при процедурном подходе.
Обычно когда пишут о подобных вопросах, приводят всякие странные тривиальные примеры, из которых вообще не ясно как предлагается решать главную проблему — как справиться со сложностью.
Спасибо. Второй причиной этой публикации был поиск собеседников, имеющих близкий к моему способ излагать и воспринимать мысль. Да, считаю большим недостатком использовать перегруженные зависимостями предложения, но это следствие моего способа удержать мысль. Планирую выложить цикл статей. Там количество "полочек-терминов" хватит на небольшой шкаф. Тренируюсь и примеряюсь. Рад знакомству.
Допустим условно, что некто, не обладающий мощью и авторитетом великих пытается объяснить как пользоваться некой теорией из математики, физики или программирования в контексте указанных вопросов (почему работает и что все это значит). Тогда реакция читателей будет примерно следующей:
1. Вы слишком много на себя берете, вы думаете, что понимаете эти теории лучше чем их авторы? Что это вообще все за муть? (потому что даже авторы теорий таких широких обобщений не делали).
2. Вы невежественны в терминологии и понимании канонических истин, искажаете все, несете ересь и еще беретесь нас учить. (потому, что автор концентрируется на общих принципах и забил на ловлю блох и каноническую схоластику, которой все ждут).
3. Вы слишком все усложняете, на самом деле все можно объяснить проще (потому что автор берет на себя более амбициозную задачу, чем просто объяснить как пользоваться принципами, а большинство его читателей сталкиваются только с очень тривиальными задачами, в которых они скрупулезно применяют разные принципы не понимая зачем и получая больше проблем чем пользы).
4. Вы изобретаете какую-то свою теорию (потому что отчасти это правда).
5. Вы не понимаете истинного значения этих принципов (потому что автор не работал с теми же задачами и в той же корпоративной среде что большинство читателей).
В итоге автор получит кучу негатива и пару положительных отзывов от философски настроенных невежд, вроде меня.
Да, у меня те же опасения. Для объяснения любых теоритических построений необходимо найти доступную форму (заняться публицистикой и упрощением). При этом потеряешь краткость и точность. Но что делать, если найденная аксиоматика красива, позволяет многое объяснить и, уверен, будет полезна. Где и как её засветить? Начать с терминов или примеров использования? Даже примеры использования теории (вывод правил эффективного развития архитектуры из статьи) нуждаются в приведении к легкому в применении виду. В выборе между процессом созидания и внедрения, пока побеждает творчество.
Как не понимать принципы развития архитектуры SOLID