Комментарии 7
Не могли бы Вы привести обратные примеры — недостатки? Например, когда SOLID создает проблемы? или сколько «стоит» SOLID по сравнению с другими рекомендациями или подходами? не абстрактно «хорошо» или «плохо», а объективными измеримыми метриками.
Ведь архитектура влияет на цену решения, может стоит сравнить на всем жизненом цикле решения, начиная от стадии дизайна, продолжая стадией ввода и заканчивая вывода из эксплуатации.
За чужой счет можно много чего делать :)

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


За зарплатой он предпочитал ходить к неидеальному бизнесу...

В любых правилах, принципах и т.п. решающим является не знание принципа а понимание границ его применения. Невежда вооруженный аббревиатурами стршнее полного невежды. Недавно я напр по порекомендовал одному разработчику создать индекс в таблице по которой идет селект по миллиону записей таблицы. Что грузит любое обращение к api на 4 секунды. На что получил ответ что так делать нельзя ибо каждый индекс замедляет вставку в таблицу новых строк. Ведь и не поспоришь.

На что получил ответ что так делать нельзя ибо каждый индекс замедляет вставку в таблицу новых строк. Ведь и не поспоришь.

Старики рассказывали, что есть такие мудрые книги которые называются «руководство разработчика», «руководство по оптимизации баз данных» и прочая «ересь».
Изустные предания которые передаются за распитием кофе и раскуриванием вейпа мира куда надежнее… И зачем верить этим безумным старикам про какие-то магические полумифические «мануалы»? Они же порождают споры и они же их и прекращают…

p.s. Если что, это глубокий сарказм. Когда такое слышу хочется сделать непотребное или мало приемлимое социумом с таким индивидом.
Я помню первое восторженное ощущение после прочтения книги Мартина, но некоторое время спустя мне в руки попала книга Бертрана Мейера (та, что про основы ООП) и после этого труда я взглянул на то, что изложил Мартин в некоторых местах, «другими глазами».
Что будем делать с классом "AccessManager", когда у нас изменится количество подписок? Вот добавится подписка VIP, которая ну самая-самая круче PREMIUM? Сколько и каких несоответствий SOLID всплывёт?
И почему этот класс уже нарушает тот принцип, примером которого он показан?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.