SOLID - набор из пяти принципов проектирования приложения. Single Responsibility - речь про то что конкретная ответственность закреплена за конкретной сущностью, будь то метод, или класс, или некая бизнес логика. То есть, если у нас есть например класс отвечающий за реализацию логики работы с данными, и реализован функционал который позволяет общаться с БД, то логики не связанной с общением с БД для данного примера, там не должно быть, не должно быть бизнес логики, логики контроллера, и т.д. Если реализуется какой то метод который отвечает за сортировку массива, то реализации логики связанной с чем то другим в методе не должно быть. Open Close - этот принцип говорит про то что если мы хотим в компонент добавить какую нибудь новую фишку, то мы должны дизайнить этот компонент так, что бы была возможность добавить фишку добавлением кода, а не изменением старого. Liskov's Subtitution - принцип подстановки, насколько я понял речь идет про то что, например, если есть компонент А, который зависит от интерфейса(B), есть реализация интерфейса Bimpl, то если заменить(подставить) другую реализацию, это не должно повлиять на компонент A. Если такое происходит, то можно создать новую реализацию для интерфейса B, но она уже не будет подходить под старые критерии, и тогда в коде начинается такая штука: if get class 1 то делай то то, else делай другое, в таком случае будет нарушение принципа. Если выразить идею принципа, то озвучил бы я ее так: создание и использование любой другой имплементации интерфейса не должна приводить к изменению в компоненте зависимом от этого интерфейса. Interface Segregation - разделение интерфейса, где несколько интерфейсов лучше чем один большой. Почему так, потому что если есть один большой интерфейс, то тот компонент который от него зависит, будет зависеть от кода который ему не нужен, чем больше будут изменяться, дописываться реализации интерфейса, тем больше вероятность что, что то изменится в компоненте зависимом от интерфейса, поэтому важно зависеть как можно сильнее от меньшего количества логики. Dependency Inversion - инверсия зависимостей, эта та вещь которую я описывал когда писал о полиморфизме, то есть возможность за счет полиморфизма развернуть зависимость compile time в другую сторону. Далее насчет DI, где зависеть должны от абстракции, а не от конкретной реализации, не всегда, но в определенных моментах, идея в чем, если конкретная реализация стабильная, то есть она не меняется постоянно, мы можем от нее зависеть, если она постоянно меняется, мы не можем от нее зависеть. Для реализации нормального дизайна, насколько мне известно, еще дополнительно нужно разобрать Абстрактную фабрику(паттерн), его я еще буду разбирать и потому много сказать об этом не могу.