Разработчикам программного обеспечения постоянно подбрасывают множество передовых практик. Независимо от их опыта, всегда есть что-то новое, что должно исправить недостатки всех других паттернов, которые они усвоили. В сегодняшней статье мы рассмотрим объектно-ориентированное программирование и основную концепцию, называемую принципами SOLID.
Что означает SOLID?
SOLID - это мнемоническая аббревиатура - метод обучения, призванный упростить запоминание чего-либо (вот почему забавно, что они выбрали такое незабываемое имя для самого устройства). Каждая из пяти букв представляет собой единый принцип. Они перечислены в следующем порядке:
- S Принцип ответственности
- O принцип замкнутости пера
- Л Исков Принцип замещения
- I Принцип разделения интерфейса
- D принцип инверсии зависимости
Итак ... что это такое и как они помогут нам разрабатывать лучшее программное обеспечение? Давайте разберемся!
Принцип единой ответственности
Короче говоря, принцип единой ответственности (SRP) говорит нам, что объект должен делать что-то одно, и он должен делать это хорошо. По словам Джорджа К. Мартина, «у класса должна быть только одна причина для изменения». Когда я впервые это услышал, я был сбит с толку.
«Одна причина измениться? Но что, если один класс идеально подходит для одновременного отслеживания двух вещей? »
Что наконец заставило его щелкнуть, так это осознание того, что он говорил не о переменных состояниях, а о причинах их существования. Если класс предназначен для анализа документа и последующего отображения его пользователю, на самом деле у него есть две причины для существования, и, следовательно, у него есть две причины для изменения. Либо содержимое документа может измениться (а вместе с ним и процесс его анализа), либо формат документа может измениться (и, следовательно, изменить способ его отображения). Согласно SRP, эти две обязанности следует разделить на два разных класса, у каждого из которых есть одна причина для существования.
Принцип открытости закрыт
Принцип открытости-закрытости гласит, что программные объекты должны быть открыты для расширения, но закрыты для модификации.
Как правило, расширение программного объекта является хорошим и очень востребованным делом. Это облегчает другим работу над вашей работой, добавляя дополнительные функции к новому классу, используя ваш как родительский.
С другой стороны, вы обычно не хотите, чтобы ваш код был настолько открытым, чтобы другой разработчик мог переопределить какой-либо метод, предназначенный только для внутреннего использования, и, следовательно, изменить поведение всего вашего класса.
В целом этот принцип говорит о следующем:
Модификаторы доступа - это хорошо. Используйте их, чтобы контролировать, к каким частям вашего API другие должны иметь доступ, но не будучи настолько ограничительными, чтобы полностью лишить вас преимуществ использования вашего кода. Вам следует подумать о том, какая информация может оказаться полезной для других, и раскрыть ее, сохраняя при этом конфиденциальность внутренней работы.
Принцип замены Лискова
Эта идея была сформулирована Барбарой Лисков в 1987 году, и ее основная идея столь же элегантна, сколь и проста. Всякий раз, когда тип T имеет подкласс типа S, следует иметь возможность заменить T на S без изменения правильности программы.
Допустим, у вас есть класс Rectangle с методом, вычисляющим его площадь. Если вы добавите класс Square, унаследованный от Rectangle, Square фактически сможет заменить объект Rectangle, не влияя на наши результаты. Между ними существует связь, которая делает это возможным, поскольку Квадрат - это своего рода Прямоугольник.
Однако создание класса Circle и превращение его в подкласс Rectangle может быть не такой уж хорошей идеей. В основном потому, что они вычисляют свои площади совершенно по-разному, но также и потому, что у них разные отношения. Circle и Rectangle могут соответствовать протоколу Shape, но они не подходят для создания подклассов таким образом.
Принцип разделения интерфейса
Принцип разделения интерфейса - это тот принцип, который оказал на меня наибольшее влияние с тех пор, как я начал программировать. Идея заключается в том, что ни один клиент не должен зависеть от свойств или методов, которые они не используют или в которых не нуждаются.
Очень красивый и наглядный пример этого принципа - популярный протокол Swift Codable. Поскольку он определяет только два метода, один для инициализации нового объекта из декодера, а другой для кодирования объекта в кодировщик, инженеры Swift легко могли остановиться на этом.
Однако кто-то придумал, что кодирование и декодирование - это два очень разных процесса, хотя у них много общего. Решением было разделить метод на два разных протокола, Encodable и Decodable, и сделать Codable их композицией. Выбирая этот подход, разработчики, которые заинтересованы только в декодировании информации, не вынуждены реализовывать часть кодирования, и наоборот.
Принцип инверсии зависимостей
Принцип инверсии зависимостей гласит, что нужно полагаться на абстракции, а не на конкретность. Сначала все это предложение кажется очень абстрактным, поэтому я собираюсь конкретизировать его для вас (ах, я вижу, что вы там сделали). Для этого я собираюсь использовать стандартную библиотеку Java, потому что она хорошо поддается этому объяснению.
Представьте, что мы создаем класс, который будет хранить множество чисел. Мы могли бы создать переменную типа ArrayList и использовать ее для хранения наших чисел, но тогда мы заглянем в угол. Что, если позже мы поймем, что ArrayList был не лучшим выбором, и теперь мы зависим от конкретных методов этого конкретного класса, методов, которых может не быть в других классах?
Решение указанной выше проблемы - создать переменную типа List. Поскольку List - это интерфейс, а не конкретный класс, он действует только как договор о том, что определенный набор методов всегда будет доступен, независимо от того, какой класс выполняет работу. Поэтому заменить фактический класс позже будет так же просто, как просто изменить одну строку кода. Милая!
На этот раз все! Не стесняйтесь комментировать, если у вас есть вопросы, и подписывайтесь, чтобы получать уведомления о будущих статьях.
Чтобы узнать больше о разработке программного обеспечения, ознакомьтесь с моими предыдущими статьями:
