SOLID - это принципы ООП. Важно понимать, что это рекомендации, но никак не догмы. Применять НЕ обязательно. Так же нужно понимать, что иногда следование одному из принципов может нарушать другой принцип.
Следствие применения принципов:
- Больше кода
- Но зато этот код будет легче дорабатывать и тестировать(если правильно применить)
Есть еще принцип YAGNI - You Aint Gonna Need It (Тебе это не нужно). Идея в том, что если у тебя на данную секунду нету обьективных причин применять какой-то принцип или паттерн здесь, то его применять не нужно вообще. На примере SOLID: если тебе не нужно дорабатывать и развивать код в будущем(проэкт на 1 вечер, например) -- пиши код проще и без применения SOLID. Попытка создать гибкое решение на ранних стадиях разработки очень часто является созданием переусложненного решения.
Вернемся к нашим овцам:
SOLID - это аббревиатура:
- SRP : Single responsibility principle - "У класса должна быть только одна причина для изменения"
- OCP : Open/Closed principle - Программные сущности(классы, модули, функции и т.п.) должны быть открытыми для расширения, но закрытыми для модификации.
- LSP : Liskov substitution principle - возможность вместо базового типа подставить любой его подтип.
- ISP : Interface segregation principle - Принцип разделения интерфейсов
- DIP : Dependency inversion principle - Инверсия зависимостей (Зависеть нужно от абстракций)
Постараемся выяснить и понять их на примерах языка c#.
Я буду идти НЕ ПО ПОРЯДКУ.
Single responsibility. - "У класса должна быть только одна причина для изменения". Звучит очень расплывчасто, да?
PS: "Принцип единой обязанности/ответственности" совсем звучит неинтуитивно, поэтому советую так не запоминать.
Причины для изменения логики работы класса:
- Изменение отношений между классами
- Введение новых требований или отмена старых.
Суть этого принципа заключается в том, что функционал класса должен быть целостным, обладать высокой логической связностью. Если у класса много ответвенности(много функций "из разных сфер"), то и меняться он будет очень часто. Таким образом, если класс имеет больше одной ответственности, то это ведет к хрупкости дизайна и ошибкам в неожиданных местах при изменениях кода. Любой сложный класс должен быть разбит на несколько простых составляющих, отвечающих за определенный аспект поведения.
Возьмем за пример Bird. Есть птицы, которые умеют летать, а есть те, которые НЕ летают. Будет странным, если мы создадим экземпляр Страуса или Киви, которые смогут летать. То есть вместо класса
public class Bird
{
public void Fly() { }
}
У нас должны быть 3 класса:
public class Bird
{
public void Jump() { }
}
public class BirdFlying: Bird
{
public void Fly() { }
}
public class BirdNonFlying: Bird
{
public void Run() {}
}
Нюансы применения:
- Объединение ответственностей является общепринятой практикой и в этом нет ничего плохого, до тех пор пока это легко обслуживать. То есть не нужно фанатично дробить классы -- это усложняет работу с проэктом точно так же, как и НЕ применение этого принципа.
- Если у вы делаете игру и у вас только летающие птицы, то, конечно же, не имеет смысла делать подобное дробление как в примере.
- Если размер вашего класса начинает разбухать, то стоит подумать а не нужно ли разделить этот класс на несколько классов.
- класс решает задачи разных уровней абстракции (например разбирает json-объект и анализирует его содержимое) - явный признак что это идет не по принципу.
- интерфейс класса слишком разнороден и содержит методы, отвечающие за слабосвязанные логически операции.
- класс или интерфейс содержит несколько методов со схожей семантикой, которые используются разными клиентами
Interface segregation - это предоставление каждому клиенту минимального (в идеале - отдельного!) интерфейса.
Рассмотрим код:
interface IMachine
{
public bool print(List<Item> item);
public bool staple(List<Item> item);
public bool fax(List<Item> item);
public bool scan(List<Item> item);
public bool photoCopy(List<Item> item);
}
class Machine : IMachine
{
public bool print(List<Item> item){} //Печатает все документы
public bool staple(List<Item> item){} //Скрепляет степлером
public bool fax(List<Item> item) {} //Отправляет факсом документы
public bool scan(List<Item> item) {} //Сканирует документы
public bool photoCopy(List<Item> item) //Делает копии документов
}
Проблемы кода:
- Перекомпилирование всего кода, даже, при маленьком изменении.
- Клиент получит доступ ко многим "левым" методам, даже, если он заинтересован только в печати(например)
По принципу ISP нам нужно разделить один интерфейс на несколько: IPrinter , IStaple , IFax , IScan , IPhotoCopy
И, раз уж, у нас есть универсальная машина которая имплементирует все перечисленные, то создать под нее интерфейс, который унаследуется от них.
interface IMachine : IPrinter, IFax, IScan, IPhotoCopy,IStaple
{
public bool print(List<Item> item);
public bool staple(List<Item> item);
public bool fax(List<Item> item);
public bool scan(List<Item> item);
public bool photoCopy(List<Item> item);
}
А так же добавить конструктор класса в Machine
public Machine(IPrinter printer, IFax fax, IScan scan, IPhotoCopy photoCopy, IStaple staple)
{
this.Printer = printer;
this.fax = fax;
this.scan = scan;
this.photoCopy = photocopy;
this.staple = staple;
}
Тогда создание такой универсальной машины будет таким:
var allOneClient = new Machine(
new Printer(),
new Fax(),
new Scanner(),
new PhotoCopy(),
new Staple() );
Реализуя так, мы получаем следующие преимущества:
- Клиент имеет доступ исключительно к тем методам, которые нужны клиенту. Про другие он не знает.
- При повторном компилировании проэкта будут перекомпилированы лишь те блоки, в которых были изменения.
Open/Closed - Программные сущности должны быть открытыми для расширения, но закрытыми для модификации.
Что это значит?
Закрытыми для модификации означает: единственная причина, по которой вы можете менять код класса\функции\модуля - это непосредственно изменение заложенной в него функции или фикс ошибок работы этой функции. Других причин быть не может.
Открыты для расширения означает: если вам надо, чтобы ваш класс\функция\модуль могли выполнять заложенные функции в новом окружении - они должны это поддерживать без изменения их кода.
Допустим, у нас есть класс для сортировки массива
public class BubbleSorter
{
public void Sort(int[] data)
{
int n = data.Length;
for (int i = 0; i < n - 1; i++)
for (int j = 0; j < n - i - 1; j++)
if (data[j] > data[j + 1])
{
int temp = data[j];
data[j] = data[j + 1];
data[j + 1] = temp;
}
}
}
Этот метод умеет сортировать только целые числа.
Если наша программа уже сейчас нуждается в таком же методе но не только для целых чисел(или будет нуждатся в будущем наверняка) -- это и есть наша точка расширения.
Мы используем существующие в дотнете интерфейсы и перепишем немного код:
public class BubbleSorter<T>
{
IComparer<T> _comparer;
public BubbleSorter(IComparer<T> comparer)
{
_comparer = comparer;
}
public void Sort(T[] data)
{
int n = data.Length;
for (int i = 0; i < n - 1; i++)
for (int j = 0; j < n - i - 1; j++)
if (_comparer.Compare(data[j], data[j + 1]) > 0)
{
var temp = data[j];
data[j] = data[j + 1];
data[j + 1] = temp;
}
}
}
Этими изменениями мы добились многого, а именно:
- Все что можно сортировать мы можем сортировать через наш метод: целые числа, числа с плавающей точкой, строки.
- если нужно сортировать по убыванию, а не возрастанию, нам не нужно менять код сортировщика или создавать такую же функцию для обратной сортировки.
Нюансы применения:
- Слишком усердное применение принципа так же плохо сказывается на результате как и не применение принципа. Слишком абстрактный и универсальный код будет слишком плохим для разбора вами или другими людьми и создает слишком большое число уровней абстракции, в котором сложно разобраться.
- Даный пример написан из предположения, что не нужно будет сортировать другие данные окроме массивов в даном проэкте.
- Даный пример написан умышленно для изменения оригинального массива данных. То есть все изменения делаются в оригинальном обьекте массива. Не нужно реализовать то, что нам лишь теоретически может потребоваться.
Второй пример применения принципа: Через наследование.
Есть у нас класс, который обрабатывает CSV (Comma Separated Value). То есть пишет таблицу в текстовый файл где кома - это разделитель ячеек в строке, а переход на новую строку это новая строка таблицы [вообще там все сложнее, но это для простоты понимания]
Если вдруг нам понадобится такой же класс, но который еще и заголовки столбцов пишет, то нам нужно будет просто унаследоваться от этого класса, а не изменять базовый.
public class Csv
{
//Some methods
}
public class CsvWithHeader: Csv
{
//header realization
}
Этот кусок написан на основе ответа Что такое принцип открытости и закрытости?
Если интересно, там есть еще третий пример применения даного принципа через применение Декоратора.
Liskov substitution - идея реализации "ПРАВИЛЬНОГО" полиморфизма. То есть нужно реализовать наследование подтипов так, что бы была возможность вместо базового типа подставить любой его подтип.
Иногда это сложно сделать. Рассмотрим сложность реализации подобного на примере:
public interface IDuck
{
void Swim();
// contract says that IsSwimming should be true if Swim has been called.
bool IsSwimming { get; }
}
public class OrganicDuck : IDuck
{
public void Swim() { }
bool IsSwimming { get{}}
}
public class ElectricDuck : IDuck
{
bool _isSwimming;
public void Swim()
{
if (!IsTurnedOn)
return;
_isSwimming = true;
//swim logic
}
bool IsSwimming { get { return _isSwimming; } }
}
Допустим у нас есть некий метод, который должен что-то делать с утками. Не важно что. public void DoSomethingWithDuck(IDuck: duck) {}.
Здесь сложность применения принципа лежит в том, что электрическая утка может поплыть только в том случае, если она включена. То есть, если мы в этот метод засунем ВЫКЛЮЧЕННУЮ электрическую утку и вызовем duck.Swim(); то она не сможет поплыть. То есть в даном случае LSP соблюдается только при первом взгляде, но на практике этот принцип не соблюдается.
Конечно, это можно пофиксить костылем внутри этого метода в виде:
if (duck is ElectricDuck)
{
((ElectricDuck)duck).TurnOn();
}
duck.Swim();
Но это будет именно костылем.
Правильное решение при котором будет слюблюдаться принцип - изменить электрическую утку таким образом, что бы она включалась автоматически при вызове метода .Swim();.
Второй способ - не делать электрическую утку "родственником" органической вовсе.
Dependency inversion. Всюду этот принцип обьясняется как "Модули верхнего уровня не должны зависеть от модулей нижнего уровня. И те и другие должны зависеть от абстракций". Как по мне, то эту фразу понять довольно сложно. Что же это означает на практике?
Обратимся к автору принципа (Боб Мартин), и коротко он говорит "Зависеть нужно от абстракций, а не от чего-то конкретного". Применяя этот принцип, одни модули можно легко заменять другими, всего лишь меняя модуль зависимости, и тогда никакие перемены в низкоуровневом модуле не повлияют на высокоуровневый.
- Не должно быть переменных, в которых хранятся ссылки на конкретные классы.
- Не должно быть классов, производных от конкретных классов.
- Не должно быть методов, переопределяющих метод, реализованный в одном из базовых классов.
- Но при этом вполне нормальная зависимость от "родных" классов языка. То есть зависимость от String вполне нормальное явление. Если же мы пишем классы сами, то они могут быть изменчивыми. Именно от таких классов мы и не хотим зависеть напрямую.
На примере это может выглядеть следующим образом:
public class MySQLConnection
{
public bool Connect()
{
//Коннектимся к MYSQL бд
}
}
public class PasswordReminder
{
private MySQLConnection _dbConnection;
public void PasswordReminder (MySQLConnection dbConnection)
{
_dbConnection = dbConnection;
}
}
Класс PasswordReminder зависит от MySQLConnection. Но более высокуровневый PasswordReminder не должен зависеть от более низкуровневого модуля MySQLConnection.
Если нам нужно изменить подключение с MySQLConnection на MongoDBConnection, то придётся менять прописанное в коде внедрение конструктора в класс PasswordReminder.
Класс PasswordReminder должен зависеть от абстракций, а не от чего-то конкретного. Но как это сделать?
public interface IDbConnection
{
public Connect();
}
public class DbConnection: IDbConnection
{
public bool Connect()
{
//Коннектимся к MYSQL бд
}
}
public class PasswordReminder
{
private IDbConnection _dbConnection;
public void PasswordReminder (IDbConnection dbConnection)
{
_dbConnection = dbConnection;
}
}
Как следствие этих изменений PasswordReminder() зависит только от абстракции. Мы можем приконектится к MongoDB вместо MYSQL изменением всего одного метода -- Connect() Или же создать MongoDBConnection и унаследовать от IDbConnection;
