solid php простое объяснение
SOLID принципы часть 1
В интернете можно найти много статей описывающий принципы SOLID. Но большинство из них сложны для понимая, а некоторые даже не содержать примеров кода, а те в которых есть примеры используют свойственные выбранному языку абстракции, такие как интерфейсы или абстрактные классы. Поэтому я постарался создать статью описывающие эти принципы простым языком и содержащие примеры не использующие особенности какого либо языка. Это статья создана на основе вот этой очень хорошей презентации и дополнена описанием и примерами.
И так в этой статье я расскажу про пять архитектурных принципов программирования, которые помогут сделать ваш код гибким, понятным и легко поддерживаемым. Все о чем будет рассказано далее находится в книги Роберт К. Мартин Гибкая разработка программ. Принципы, примеры, практика (Agile Software Development Principles, Patterns and Practices )
Что такое Solid принципы?
Solid — переводится с английского как твердый, крепкий прочный, но с другой стороны SOLID это акроним, где каждая буква этого слова это отдельный принцип:
S — Single Responsible Principle (SRP)
O — Open Closed Principle (OCP)
L — Liskov Substitution Principle (LSP)
I — Interface Segregation Principle (ISP)
D — Dependency Inversion Principle (DIP)
Каждый принцип сам по себе является целой идеологией и все они не зависят друг от друга. Но вместе они позволяют делать код более понимаемым, лучше описаным и поддерживаемым. Говоря о эти принципах, вначале нужно сказать, а почему вообще эти принципы так важны и для чего они вообще нужны и какой смысл, в том что бы их изучать и что такое плохой код.
Самая большая проблема в написание программ заключается в том что всегда происходят изменения. В реальной жизни почти никогда не бывает что бы вы один раз написали код и больше к нему не возвращались. Как правило всегда нужно вносить какие либо изменения, для добавление нового функционала, исправления старых ошибок и т.п. Поэтому нужно писать код так что бы эти изменения не создавали новых проблем, а процесс внесения изменений был естественной часть технологического процесса и вам приходилось бы тратить больше времени не на поддержку старого кода, а на написания нового.
В книги Роберта Мартина описано 7 признаков плохого кода:
И так начнем описание принципов.
Принцип персональной ответственности (SRP Single Responsibility Principle)
Каноническое определение принципа:
«Существует лишь одна причина, приводящая к изменению класса»
Том Де-Марко (1979) и Мейлер Пейдж-Джонсан (1988)
То есть этот принцип говорит, что каждый класс должен иметь лишь одну ответственность, то есть он должен отвечать только за одну вещь.
Хотя концепция, лежащая в основе SRP, достаточно проста для понимания, но реализация этого принципа на практике требует определенных навыков, поскольку ответственность класса не всегда сразу очевидна.
Мартин рассматривает ответственность как причину изменения и приходит к выводу, что у класса и модуля должна быть единственная причина для изменения. Объединение двух сущностей, которые меняются по разным причинам в разное время, — является плохим дизайном. Чем больше обязанностей у класса, тем больше запросов на изменение он получит, и тем сложнее будет реализовать эти изменения. Цель принципа SRP — бороться со сложностью, которая возникает в процессе разработки логики приложения.
Рассмотрим пример. Пусть у нас есть один класс Product, в котором определены все необходимые методы для работы с сущностью продукта, с базой и методы отображения продукта.
В данном случае мы явно нарушаем принцип так как наш класс содержит множество ответственностей. Перепишем его, так что бы выделить методы в отдельные классы.
Как мы можем видеть код стал намного более понятным.
Рассмотрим еще один пример, класс User:
При такой архитектуре все будет хорошо работать если проект будет небольшим. Но с ростом проекта увеличением количества требуемых методов, будет расти и сложность архитектуры, все очень быстро может стать запутанным, поэтому лучше это переделать. Разделить на сущность пользователя класс UserEntity и класс для работы с базой данных UserRepository
Еще один пример. Пусть у нас есть класс, который отвечает как за генерацию отчета и за его отправку определенному пользователю
Класс FinancialReportMailer, показанный выше, выполняет две задачи: генерация отчета (метод «generate_report!») И отправка отчета (метод «send_report»). Класс выглядит довольно простым. Однако расширение этого класса в будущем может быть проблематичным, поскольку нам, вероятно, придется изменить логику класса. Принцип SRP говорит нам, что класс должен реализовывать одну единственную задачу, и поэтому в соответствии с этим принципом мы должны разделить класс FinancialReportMailer на два класса.
Давайте посмотрим, как выглядит этот код после того, как мы реорганизовали его для соответствия требованиям SRP:
После рефакторинга у нас есть два класса, каждый из которых выполняет определенную задачу. Класс FinancialReportMailer отправляет электронные письма, содержащие тексты, созданные классом FinancialReportGenerator. Если бы мы хотели расширить класс, отвечающий за генерацию отчетов в будущем, мы могли бы просто внести необходимые изменения, не касаясь класса FinancialReportMailer.
Этот принцип применяется, когда:
Не используйте этот принцип когда:
Пример когда следовать этому принципу не нужно.
Допустим нам нужно написать класс Modem, о котором мы точно знаем что в будущем мы не будем вносить в него изменения.
Если мы будем придерживаться принципа SRP, то нам нужно будет разделить этот класс на два класса DataChannel для организации соединения и Connection для передачи данных.
Но так как мы заранее знаем, что мы никогда не будем менять класс Modem, то в данном случае все таки выгоднее оставить все как есть, иначе в будущем наш код будет иметь избыточную сложность
На каждый объект должна быть возложена одна единственная обязанность
Принцип открытости / закрытости (OCP Open Closed Principle)
Каноническое определение принципа:
Программные объекты (классы, модули, функции и т.п.) должны быть открыты для расширения, но в то же время закрыты для модификации.
Бертран Майер (1988)
Как что-то может быть открытым и закрытым одновременно?!
Класс следует OCP, если он удовлетворяет этим двум критериям:
Открыт для расширения
То есть класс должен быть создан таким образом, что бы поведение класса можно было бы дополнить в любой момент. По мере изменения требований мы должны иметь возможность дополнить класс новым функционалом.
Закрыт для модификации
При добавление нового функционала нельзя вносить изменения в исходный код такого класса. То есть весь новый код не должен затрагивать старый.
Цель принципа
Разработчики всегда должны писать новый код, а не переписывает старый. Тестирование кода должно происходит единожды. И разработчики не должны тратить время на частый рефакторинг
Рассмотрим простой пример. Пусть у нас есть класс Order и метод getTotalPrice, которые вначале получает все позиции корзины потом получает возможные скидки, а потом рассчитывает итоговую сумму.
В начале перепишем его, так что бы он удовлетворял принципу единой обязанности SIP
Далее перепишем его так что бы он удовлетворил принципу OCP. У нас будет два возможных решения. Первой очень простое, второе чуть интереснее.
Первое решение для соответствия принципу OCP. Мы можем просто унаследовать дочерний класс MainOrderAlgorithm от BaseOrderAlgorithm и переопределить внутренние методы расчета getProducts и getDiscount. Таким образом мы сохраним старый код и добавим новый.
Второе решение для соответствия принципу OCP.
Через конструктор класса передаем отдельные классы product и discount И таким образом мы написали один раз класс Order и можем написать множество классов для обработки.
Применяйте принцип в местах подтвержденных частым изменениям.
Так же наличие условных операторов (if, case) при ветвление бизнес логики может сигнализировать о потенциальных точках изменения логики.
Возможная проблемы с принципом OCP
Пусть у нас есть некая фабрика которая на основе неких параметров создает новый класс
Тут проблема в том что когда вам надо добавить новую фигуру вам каждый раз надо будет вставлять/редактировать текущий код то есть каждый раз переписывать этот класс.
Возможное решение
Полностью избавиться от подобных классов/методов почти невозможно поэтому:
Максимальное использование абстракций может показаться идеальным способом приведения любых классов в соответствие с принципом OCP. Но тут есть определенные проблемы о которых заранее лучше знать:
Только большой опыт разработки позволит делать точные предположение, о том как следует делать код не изменяемым.
Пример с большим количеством if/case:
В приведенном ниже коде класс Logger форматирует и отправляет журналы логов. Но принцип OCP не соблюдается, поскольку нам придется изменять регистратор каждый раз, когда нам нужно добавить дополнительных типы отправлений или типы форматов:
После того, как мы проведем рефакторинг этого кода, он может быть расширен. В приведенном ниже примере мы создали отдельные классы для отправителей и для форматирования и сделали возможным подключение новых отправителей и средств форматирования без необходимости изменения базового кода:
Суть принципа
Изменения в программе должны происходить при написание нового кода, а не модификации старого.
Далее в следующей статье я продолжу описание принципов.
Принципы SOLID состоят из 5 ключевых идей по написанию и проектированию объектно-ориентированных приложений. Принцип SOLID, сама его идея появилась в 2000 году Робертом Мартином (однако, само официальное название этому принципу были утверждено только спустя несколько лет). Принципы, именуемые, как SOLID были настолько хороши, что спустя лишь небольшое время они захватили внимание сообщества программистов.
Так же, совутую, после изучения материала этой статьи (или даже во время), ознакомиться с принципами SOLID в картинках.
Принцип единственной ответственности
Этот принцип является базовым, и одним из ключевых. Мне кажется, что многие программисты при написании кода интуитивно следуют этому принципу, не задумываясь об этом, и даже не зная о его сущестовавании. Однако, если вы поймёте идею этого принципа сейчас, и начнете разработку, держа её в голове, это, вероятно избавит вас от рефакторинга кода в будущем.
Главная идея, проходит нитью по названию этого принципа, она состоит в том, что каждый класс должен выполнять только одну задачу, и только одну.
Каждый класс должен получать информацию из системы ровно столько, сколько достаточно для работы логики этого класса. А так же, класс не должен быть мастером на все руки, выполняя множество разноплановых задач. Он должен выполнять только одну конкретную задачу. Класс может содержать много методов, но все они должны быть направлены на решение одной и только одной задачи.
Посмотрите на пример плохо спреэктированного класса:
А в контроллере этот класс вызывается как-то так:
Вместо этого, любой из классов должен иметь только по одной обязанности
Потому, сейчас перепишем этот класс с учётом новых требований.
Другое изменение было применено к проверке аутентификации пользователя. Эта обязанность была вынесена в контроллер, где ему и место.
Новая версия выглядит на порядок чище, проще для тестирования, и обновления.
Принцип Открытости/Закрытости
Этот принцип гласит, что классы должны быть открыты к расширению, и закрыты к модификации. Это значит, что ваш код должен быть написан так, чтобы другие разработчики (а, возможно, и вы, в будущем) могли изменить поведение существующего кода, при этом, не изменяя основной код. То есть, ваши классы должны быть такими, чтобы каждый мог дописать что-то своё, не меняя при этом содержимого исходного кода.
Например, если вы когда-то использовали шаблонизатор Twig, то вы наверняка писали плагины и расширения для него (добавляя собственные функции или фильтры в шаблонизатор). И как раз, из-за следования этому принципу, вы, написав собственное расширение (по соответствующему интерфейсу), добавили новую функциональность без изменения кода самого шаблонизатора.
Когда мы говорим о написании класса, открытого к расширению, обязательным условием его реализации является наследование и следование интерфейсам.
Код интерфейсов не должнен изменяться (закрыты для модификации), в то время, как классам-реализациям должно быть достаточно текущего интерфейса без нужды его изменения. То есть, вы должны писать интерфейсы таким образом, чтобы в будущем любой программист мог создать свою реализацию вашего интерфейса, без нужды внесения в него изменений. Это и является ключом к написанию кода, соответствующему этому принципу.
А, чтобы более чётко понимать, как работать с интерфейсами и абстрактыми классами, советую почитать мою предыдущую статью на эту тему.
Принцип подстановки Барбары Лисков
Принцип подстановки Барбары Лисков (именуемый как LISP) это важная концепция, придуманная ещё в далёком 1987-м. Я опишу этот принцип на основу определений, условного описания кода, вместо реализации большого примера с кодом (чтобы сделать этот пример легче для понимания, я буду использова определение, как «Клиентский класс»).
Клиентский класс должен иметь возможность использовать базовый класс или любой подкласс, производный от базового, при этом не изменяя собственный код или логику работы, независимо от реализации. То есть, родительский класс должен быть полностью взаимозаменяемым любыми его подклассами, при этом, клиентский код даже не должен знать о том, что мы работаем с каким-то подклассом, ему не должно быть разницы.
По-другому: если вы имеете базовый класс, и вы имеете 5 разных классов со своей реализацией, унаследовавших этот базовый класс. И ваш код, использующий этот базовый класс, при его замене на любой из его «наследников», по-прежнему должен продолжать работать, как и ранее.
Для соблюдения этого принципа, при наследовании базового класса, в подклассах вы должны поддерживать соответствие входных параметров и выходных (иметь одинаковые типы и соответствие сигнатур методов), как это было в базовом классе.
Принцип разделения интерфейса
Принцип инверсии зависимостей
Это мой самый любимый принцип, которы помогает поддерживать бОльшую чистоту кода, который легче тестировать и изменять в будущем.
После чего, вы можете иметь несколько реализаций на основе этого интерфейса, легко переключаемых между собой. При этом, замена реализаций иключает изменение основного клиентского кода. Для соблюдения этого принципа достаточно следовать правилу: программируйте на основу интерфейсов а не их реализации, о чем я и писал, в ранее упомянутой статье.
Резюме
В этой статье я попытался лайтово, не особо нагромождая ваше внимание большими кусками кода описать принципы SOLID в PHP, сделать его описание и привести полной объяснения его сути. Для того, чтобы научиться писать по SOLID-у, вам нужно просто практиковаться писать всё больше и больше, постоянно держа в голове эти принципы и стараясь их внедрять в нужные места. После чего, полное понимание и умение их применять придёт само собой.
Subscribe to Блог php программиста: статьи по PHP, JavaScript, MySql
Get the latest posts delivered right to your inbox
Шпаргалка по SOLID-принципам с примерами на PHP
Тема SOLID-принципов и в целом чистоты кода не раз поднималась на Хабре и, возможно, уже порядком изъезженная. Но тем не менее, не так давно мне приходилось проходить собеседования в одну интересную IT-компанию, где меня попросили рассказать о принципах SOLID с примерами и ситуациями, когда я не соблюл эти принципы и к чему это привело. И в тот момент я понял, что на каком-то подсознательном уровне я понимаю эти принципы и даже могут назвать их все, но привести лаконичные и понятные примеры для меня стало проблемой. Поэтому я и решил для себя самого и для сообщества обобщить информацию по SOLID-принципам для ещё лучшего её понимания. Статья должна быть полезной, для людей только знакомящихся с SOLID-принципами, также, как и для людей «съевших собаку» на SOLID-принципах.
Для тех, кто знаком с принципами и хочет только освежить память о них и их использовании, можно обратиться сразу к шпаргалке в конце статьи.
Что же такое SOLID-принципы? Если верить определению Wikipedia, это:
аббревиатура пяти основных принципов дизайна классов в объектно-ориентированном проектировании — Single responsibility, Open-closed, Liskov substitution, Interface segregation и Dependency inversion.
Принцип единственной ответственности (Single responsibility)
Итак, в качества примера возьмём довольно популярный и широкоиспользуемый пример — интернет-магазин с заказами, товарами и покупателями.
Принцип единственной ответственности гласит — «На каждый объект должна быть возложена одна единственная обязанность». Т.е. другими словами — конкретный класс должен решать конкретную задачу — ни больше, ни меньше.
Рассмотрим следующее описание класса для представления заказа в интернет-магазине:
Как можно увидеть, данный класс выполняет операций для 3 различный типов задач: работа с самим заказом( calculateTotalSum, getItems, getItemsCount, addItem, deleteItem ), отображение заказа( printOrder, showOrder ) и работа с хранилищем данных( load, save, update, delete ).
К чему это может привести?
Приводит это к тому, что в случае, если мы хотим внести изменения в методы печати или работы хранилища, мы изменяем сам класс заказа, что может привести к его неработоспособности.
Решить эту проблему стоит разделением данного класса на 3 отдельных класса, каждый из которых будет заниматься своей задачей
Теперь каждый класс занимается своей конкретной задачей и для каждого класса есть только 1 причина для его изменения.
Принцип открытости/закрытости (Open-closed)
Принцип подстановки Барбары Лисков (Liskov substitution)
Пожалуй, принцип, который вызывает самые большие затруднения в понимании.
Принцип гласит — «Объекты в программе могут быть заменены их наследниками без изменения свойств программы». Своими словами я бы это сказал так — при использовании наследника класса результат выполнения кода должен быть предсказуем и не изменять свойств метод.
К сожалению, придумать доступного примера для это принципа в рамках задачи интернет-магазина я не смог, но есть классический пример с иерархией геометрических фигур и вычисления площади. Код примера ниже.
Очевидно, что такой код явно выполняется не так, как от него этого ждут.
Но в чём проблема? Разве «квадрат» не является «прямоугольником»? Является, но в геометрических понятиях. В понятиях же объектов, квадрат не есть прямоугольник, поскольку поведение объекта «квадрат» не согласуется с поведением объекта «прямоугольник».
«Что ещё за пред- и постусловия?» — можете спросите Вы.
Ответ: предусловия – это то, что должно быть выполнено вызывающей стороной перед вызовом метода, постусловия – это то, что, гарантируется вызываемым методом.
Поэтому, лучше в рамках ООП и задачи расчёта площади фигуры не делать иерархию «квадрат» наследует «прямоугольник», а сделать их как 2 отдельные сущности:
Хороший реальный пример несоблюдения принципа Лискоу и решения, принятого в связи с этим, рассмотрен в книге Роберта Мартина «Быстрая разработка программ» в разделе «Принцип подстановки Лискоу. Реальный пример».
Принцип разделения интерфейса (Interface segregation)
Данный принцип гласит, что «Много специализированных интерфейсов лучше, чем один универсальный»
Соблюдение этого принципа необходимо для того, чтобы классы-клиенты использующий/реализующий интерфейс знали только о тех методах, которые они используют, что ведёт к уменьшению количества неиспользуемого кода.
Вернёмся к примеру с интернет-магазином.
Предположим наши товары могут иметь промокод, скидку, у них есть какая-то цена, состояние и т.д. Если это одежда то для неё устанавливается из какого материала сделана, цвет и размер.
Опишем следующий интерфейс
Данный интефейс плох тем, что он включает слишком много методов. А что, если наш класс товаров не может иметь скидок или промокодов, либо для него нет смысла устанавливать материал из которого сделан (например, для книг). Таким образом, чтобы не реализовывать в каждом классе неиспользуемые в нём методы, лучше разбить интерфейс на несколько мелких и каждым конкретным классом реализовывать нужные интерфейсы.
Принцип инверсии зависимостей (Dependency Invertion)
Принцип гласит — «Зависимости внутри системы строятся на основе абстракций. Модули верхнего уровня не зависят от модулей нижнего уровня. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций». Данное определение можно сократить — «зависимости должны строится относительно абстракций, а не деталей».
Для примера рассмотрим оплату заказа покупателем.
Таким образом, класс Customer теперь зависит только от абстракции, а конкретную реализацию, т.е. детали, ему не так важны.
Шпаргалка
Надеюсь, моя «шпаргалка» поможет кому-нибудь в понимании принципов SOLID и даст толчок к их использованию в своих проектах.
Спасибо за внимание.
SOLID
SOLID критикует тот, кто думает, что действительно понимает ООП
© Куряшкин Виктор
Я знаком с принципами SOLID уже 6 лет, но только в последний год осознал, что они означают. В этой статье я дам простое объяснение этим принципам. Расскажу о минимальных требованиях к языку программирования для их реализации. Дам ссылки на материалы, которые помогли мне разобраться.
Первоисточники
Придумал принципы SOLID Роберт Мартин (Uncle Bob). Естественно, что в своих работах он освещает эту тему.
Книга “Принципы, паттерны и методики гибкой разработки на языке C#” 2011 года. Большинство статей, которые я видел, основываются именно на этой книге. К сожалению, она дает расплывчатое описание принципов, что сильно ударило по их популярности.
Видео сайта cleancoders.com. Дядюшка Боб в шутливой форме на пальцах рассказывает, что же именно означают принципы и как их применять.
Книга “Clean Architecture” 2017 года. Описывает архитектуру, построенную из кирпичиков, удовлетворяющих SOLID принципам. Дает определение структурному, объектно-ориентированному, функциональному программированию. Содержит лучшее описание SOLID принципов, которое я когда-либо видел.
Требования
SOLID всегда упоминают в контексте ООП. Так получилось, что именно в ООП языках появилась удобная и безопасная поддержка динамического полиморфизма. Фактически, в контексте SOLID под ООП понимается именно динамический полиморфизм.
Полиморфизм дает возможность для разных типов использовать один код.
Полиморфизм можно грубо разделить на динамический и статический.
Кроме привычных языков вроде Java, C#, Ruby, JavaScript, динамический полиморфизм реализован, например в
Принципы
SOLID принципы советуют, как проектировать модули, т.е. кирпичики, из которых строится приложение. Цель принципов — проектировать модули, которые:
SRP: The Single Responsibility Principle
A module should be responsible to one, and only one, actor.
Старая формулировка: A module should have one, and only one, reason to change.
Часто ее трактовали следующим образом: Модуль должен иметь только одну обязанность. И это главное заблуждение при знакомстве с принципами. Все несколько хитрее.
На каждом проекте люди играют разные роли (actor): Аналитик, Проектировщик интерфейсов, Администратор баз данных. Естественно, один человек может играть сразу несколько ролей. В этом принципе речь идет о том, что изменения в модуле может запрашивать одна и только одна роль. Например, есть модуль, реализующий некую бизнес-логику, запросить изменения в этом модуле может только Аналитик, но никак не DBA или UX.
OCP: The Open Closed Principle
A software artifact should be open for extension but closed for modification.
Старая формулировка: You should be able to extend a classes behavior, without modifying it.
Это определенно может ввести в ступор. Как можно расширить поведение класса без его модификации? В текущей формулировке Роберт Мартин оперирует понятием артефакт, т.е. jar, dll, gem, npm package. Чтобы расширить поведение, нужно воспользоваться динамическим полиморфизмом.
Например, наше приложение должно отправлять уведомления. Используя dependency inversion, наш модуль объявляет только интерфейс отправки уведомлений, но не реализацию. Таким образом, логика нашего приложения содержится в одном dll файле, а класс отправки уведомлений, реализующий интерфейс — в другом. Таким образом, мы можем без изменения (перекомпиляции) модуля с логикой использовать различные способы отправки уведомлений.
Этот принцип тесно связан с LSP и DIP, которые мы рассмотрим далее.
LSP: The Liskov Substitution Principle
Имеет сложное математическое определение, которое можно заменить на: Функции, которые используют базовый тип, должны иметь возможность использовать подтипы базового типа, не зная об этом.
Классический пример нарушения. Есть базовый класс Stack, реализующий следующий интерфейс: length, push, pop. И есть потомок DoubleStack, который дублирует добавляемые элементы. Естественно, класс DoubleStack нельзя использовать вместо Stack.
У этого принципа есть забавное следствие: Объекты, моделирующие сущности, не обязаны реализовывать отношения этих сущностей. Например, у нас есть целые и вещественные числа, причем целые числа — подмножество вещественных. Однако, double состоит из двух int: мантисы и экспоненты. Если бы int наследовал от double, то получилась бы забавная картина: родитель содержит 2-х своих детей.
ISP: The Interface Segregation Principle
Make fine grained interfaces that are client specific.
Под интерфейсом здесь понимается именно Java, C# интерфейс. Разделение интерфейса облегчает использование и тестирование модулей.
DIP: The Dependency Inversion Principle
Depend on abstractions, not on concretions.
Что такое модули верхних уровней? Как определить этот уровень? Как оказалось, все очень просто. Чем ближе модуль к вводу/выводу, тем ниже уровень модуля. Т.е. модули, работающие с BD, интерфейсом пользователя, низкого уровня. А модули, реализующие бизнес-логику — высокого уровня.
Что такое зависимость модулей? Это ссылка на модуль в исходном коде, т.е. import, require и т.п. С помощью динамического полиморфизма в runtime можно обратить эту зависимость.
Есть модуль Logic, реализующий логику, который должен отсылать уведомления. В этом же пакете объявляется интерфейс ISender, который используется Logic. Уровнем ниже, в другом пакете объявляется ConcreteSender, реализующий ISender. Получается, что в момент компиляции Logic не зависит от ConcreteSender. В runtime, например, через конструктор в Logic устанавливается экземпляр ConcreteSender.
Отдельно стоит отметить частый вопрос “Зачем плодить абстракции, если мы не собираемся заменять базу данных?”.
Логика тут следующая. На старте проекта, мы знаем, что будем использовать реляционную базу данных, и это точно будет Postgresql, а для поиска — ElasticSearch. Мы даже не планируем их менять в будущем. Но мы хотим отложить принятие решений о том, какая будет схема таблиц, какие будут индексы, и т.п. до момента, пока это не станет проблемой. И на этот момент мы будем обладать достаточной информацией, чтобы принять правильное решение. Также мы можем раньше отладить логику нашего приложения, реализовать интерфейс, собрать обратную связь от заказчика, и минимизировать последующие изменения, ведь многое реализовано только в виде заглушек.
Принципы SOLID подходят для проектов, разрабатываемых по гибким методологиям, ведь Роберт Мартин — один из авторов Agile Manifesto.
Принципы SOLID стремятся свести изменение модулей к их добавлению и удалению.
Принципы SOLID способствуют откладыванию принятия технических решений и разделению труда программистов.