Красивая концепция, оторванная от реальности. Приводит ко кратному увеличению числа объектов на ровном месте. Когда их число исчисляется сотнями тысяч это даёт заметную просадку из-за GC. Да и пользоваться без фасадов за фасадами не удобно.
OCP
Фактически говорит "никогда не делай рефакторинг". Ну да, пусть кодовая база тухнет под гнётом десятков реализаций одного и того же, но чуть по другому. Зато у нас ничего не сломается. Не тесты же писать в конце-то концов!
Такая себе структурная типизация для бедных. Каждой комбинации имя+сигнатура метода даётся уникальное название и потом из этих названий собираются уникальные комбинации.
Впрочем, протягивать очередную сигнатуру через слои абстракций в любом случае ад.
DIP
Чудесный способ всех запутать. Вот у вас использование зависимости. Казалось бы рукой подать. Но нет, это только начало увлекательного квеста по определению, что же у тебя сюда приходит на самом деле. Затрудняет навигацию по коду, усложняет API объекта, приводит к излишнему бойлерплейту.
DRY
Источник многих звездолётов. Но есть с ним и менее известная проблема - независимые части системы, случайно имеющие похожий код, вдруг начинают реально быть связанными через общий код. Правишь для одного - ломаешь всех.
YAGNI
Известное прикрытие для архитектурных раздолбаев. Ща побырому сделаем, а после нас хоть потоп. Потоп начинается через 2 итерации с дикими костылями и криками "Ну мы же не знаааали, что оно понадобится!".
TDD
Предполагает написание красного теста до изменений в коде. Что приводит либо к недопокрытию, из-за невозможности написать красный тест. Либо к нарушению TDD с написанием изначально зелёного теста, что говорит о том, что он пишется после имплементации тестируемой им функциональности.
Замедляет и усложняет RnD, требуя фиксации интерфейса до полного понимания какой он должен быть и реализуем ли вообще.
KISS
Внезапно, единственный принцип, которым стоит руководствоваться. Потому, что всё гениальное - просто. И потому, что довести его до абсурда вам никто не даст - усложнять всё равно придётся, но вы будете искать максимально простое решение.
SRP
Красивая концепция, оторванная от реальности. Приводит ко кратному увеличению числа объектов на ровном месте. Когда их число исчисляется сотнями тысяч это даёт заметную просадку из-за GC. Да и пользоваться без фасадов за фасадами не удобно.
OCP
Фактически говорит "никогда не делай рефакторинг". Ну да, пусть кодовая база тухнет под гнётом десятков реализаций одного и того же, но чуть по другому. Зато у нас ничего не сломается. Не тесты же писать в конце-то концов!
LSP
Говорит лишь про ковариантность типов, однако в ряде случаев типы должны быть контравариантны, а в ряде инвариантны. https://habr.com/ru/post/477448/#princip-podstanovki--barbary-liskov-lsp
ISP
Такая себе структурная типизация для бедных. Каждой комбинации имя+сигнатура метода даётся уникальное название и потом из этих названий собираются уникальные комбинации.
Впрочем, протягивать очередную сигнатуру через слои абстракций в любом случае ад.
DIP
Чудесный способ всех запутать. Вот у вас использование зависимости. Казалось бы рукой подать. Но нет, это только начало увлекательного квеста по определению, что же у тебя сюда приходит на самом деле. Затрудняет навигацию по коду, усложняет API объекта, приводит к излишнему бойлерплейту.
DRY
Источник многих звездолётов. Но есть с ним и менее известная проблема - независимые части системы, случайно имеющие похожий код, вдруг начинают реально быть связанными через общий код. Правишь для одного - ломаешь всех.
YAGNI
Известное прикрытие для архитектурных раздолбаев. Ща побырому сделаем, а после нас хоть потоп. Потоп начинается через 2 итерации с дикими костылями и криками "Ну мы же не знаааали, что оно понадобится!".
TDD
Предполагает написание красного теста до изменений в коде. Что приводит либо к недопокрытию, из-за невозможности написать красный тест. Либо к нарушению TDD с написанием изначально зелёного теста, что говорит о том, что он пишется после имплементации тестируемой им функциональности.
Замедляет и усложняет RnD, требуя фиксации интерфейса до полного понимания какой он должен быть и реализуем ли вообще.
KISS
Внезапно, единственный принцип, которым стоит руководствоваться. Потому, что всё гениальное - просто. И потому, что довести его до абсурда вам никто не даст - усложнять всё равно придётся, но вы будете искать максимально простое решение.