lentinant, мое понимание SOLID:
S - один класс на одну задачу, сложные задачи разбиваются до подзадач и, соответственно, получаем один класс на большую задачу и по классу на подзадачу. Условно можно выразить так "если класс занимается выпеканием хлеба, то он не должен заниматься его доставкой". Важно не увлекаться дроблением сверх меры на этапе проектирования - если видишь что класс начинает разбухать и обростать группами не связанных методов, то самое время использовать этот принцип.
O - избегать изменения контрактов уже стабилизировавшегося кода. Применяется когда код уже может где-то использоваться как зависимость. По сути это требование обратной совместимости - расширять функционал можно и нужно, но старый код, зависящий от твоего, должен работать даже после превращения калькулятора в подводную лодку с вертикальным взлетом.
L - требование, согласно которому экземпляры родительских объектов должно быть можно заменить экземплярами дочерних объектов, не нарушая целостности программы. По сути это критерий, по которому можно определить и устранить избыточное или неправильное наследование, заменив его наследованием обоих объектов от общего родителя или агрегацией или хоть чертом лысым - сам принцип ничего не говорит о том, как именно его надо выпонять. Есть небольшой нюанс - применяется этот принцип только к экземплярам классов, а не к ссылкам или самому дереву наследования - если, например, где-то есть ссылка на A, который родительский класс для B, но по факту там используются только экземпляры классов B, C и D, то "nothing to do here".
I - аналог S для интерфейсов. Его главная идея в том, что не стоит перегружать класс, реализующий интерфейс, лишними методами.
D - суть в том, чтобы разорвать связи между объектами, находящимися на разных уровнях абстракции. Применяется в обоих направлениях - и для менее абстрактных объектов, включенных в более абстрактный и наоборот, более того - применяется не только при прямом включении, но и к любым другим ссылкам. Предположим нам нужно составить програмную модель кирпичной стены, класс стены не должен ничего знать о конкретных реализациях кирпичей и работать с любыми кирпичами, какие ему дадут, а кирпичи не должны напрямую зависеть от конкретных реализаций стены и быть пригодны к использованию в любой стене (или другой конструкции, если модель подразумевает не только стены).

Еще хочу сказать, что слепое следование всем принципам ни к чему хорошему не приводит - важно понимать грань, за которой начинается ад и содомия и вовремя остановиться.