Доступно о SOLID

Не так давно, около месяца назад, я сделал небольшой доклад, посвященный SOLID, для своих коллег. Объяснить, что это такое оказалось не совсем тривиальным делом. Поэтому, я думаю, многим моя публикация окажется полезной. В этом посте я попытался собрать самые простые и понятные объяснения по каждому принципу.
Как известно, SOLID - это аббревиатура от пяти принципов проектирования, названия которых так удачно зашифровал в этом слове Роберт Мартин.
Собственно вот эти принципы:
1. Принцип единственности ответственности
2. Принцип открытости/закрытости
3. Принцип подстановки Лисков
4. Принцип разделения интерфейса
5. Принцип инверсии зависимостей

Обо всем по порядку.

Принцип единственности ответственности
Как показывает практика, самое сложное в этом принципе - запомнить его определение:

"Не должно быть более одной причины для изменения класса"

Нарушение этого принципа хорошо демонстрирует следующий пример:

1. class Email
2. {
3.   public String Theme { get; set; }
4.   public String From { get; set; }
5.   public String To { get; set; }
6. }
7.  
8. class EmailSender
9. {
10.   public void Send(Email email)
11.   {
12.     // ... sending...
13.     Console.WriteLine("Email from '" + email.From + "' to '" + email.To + "' was send");
14.   }
15. }
16.  
17. class Program
18. {
19.   static void Main(string[] args)
20.   {
21.     Email e1 = new Email() { From = "Me", To = "Vasya", Theme = "Who are you?" };
22.     Email e2 = new Email() { From = "Vasya", To = "Me", Theme = "vacuum cleaners!" };
23.     Email e3 = new Email() { From = "Kolya", To = "Vasya", Theme = "No! Thanks!" };
24.     Email e4 = new Email() { From = "Vasya", To = "Me", Theme = "washing machines!" };
25.     Email e5 = new Email() { From = "Me", To = "Vasya", Theme = "Yes" };
26.     Email e6 = new Email() { From = "Vasya", To = "Petya", Theme = "+2" };
27.  
28.     EmailSender es = new EmailSender();
29.     es.Send(e1);
30.     es.Send(e2);
31.     es.Send(e3);
32.     es.Send(e4);
33.     es.Send(e5);
34.     es.Send(e6);
35.  
36.     Console.ReadKey();
37.   }
38. }

* This source code was highlighted with Source Code Highlighter.

Обратите внимание на класс EmailSender. Кроме того, что при помощи метода Send, он отправляет сообщения, он еще и решает как будет вестись лог. В данном примере лог ведется через консоль.
Если случится так, что нам придется менять способ логирования, то мы будем вынуждены внести правки в класс EmailSender. Хотя, казалось бы, эти правки не касаются отправки сообщений. Очевидно, EmailSender выполняет несколько обязанностей и, чтобы класс не был привязан только к одному способу вести лог, нужно вынести выбор лога из этого класса.

1. class EmailSender
2. {
3.   public EmailSender(ILog log)
4.   {
5.     _log = log;
6.   }
7.   public void Send(Email email)
8.   {
9.     // ... sending...
10.     _log.Write("Email from '" + email.From + "' to '" + email.To + "' was send");
11.   }
12.  
13.   private ILog _log;
14. }
15.  
16. class Program
17. {
18.   static void Main(string[] args)
19.   {
20.     Email e1 = new Email() { From = "Me", To = "Vasya", Theme = "Who are you?" };
21.     Email e2 = new Email() { From = "Vasya", To = "Me", Theme = "vacuum cleaners!" };
22.     Email e3 = new Email() { From = "Kolya", To = "Vasya", Theme = "No! Thanks!" };
23.     Email e4 = new Email() { From = "Vasya", To = "Me", Theme = "washing machines!" };
24.     Email e5 = new Email() { From = "Me", To = "Vasya", Theme = "Yes" };
25.     Email e6 = new Email() { From = "Vasya", To = "Petya", Theme = "+2" };
26.  
27.     EmailSender es = new EmailSender(new ConsoleLog());
28.     es.Send(e1);
29.     es.Send(e2);
30.     es.Send(e3);
31.     es.Send(e4);
32.     es.Send(e5);
33.     es.Send(e6);
34.  
35.     Console.ReadKey();
36.   }
37. }
38.  
39. public interface ILog
40. {
41.   void Write(String str);
42. }
43.  
44. public class ConsoleLog: ILog
45. {
46.   public void Write(string str)
47.   {
48.     Console.WriteLine(str);
49.   }
50. }

* This source code was highlighted with Source Code Highlighter.

Теперь, чтобы сменить способ логирования, нужно отправить нужный экземпляр типа ILog в конструктор EmailSender.

Принцип открытости/закрытости

"Ваши классы должны быть отрытыми для расширения и закрыты для модификации"

Выгода от использования такой практики очевидна. Не нужно пересматривать уже существующий код, не нужно менять уже готовые для него тесты.
Если нужно ввести какую-то дополнительную функциональность, то это не должно коснуться уже существующих классов или как-либо иначе повредить уже существующую функциональность.
Рассмотрим на примере:

1. public class Report
2. {
3.   public uint Total;
4.   public String Name;
5.   public DateTime CreateDate;
6.   public override string ToString()
7.   {
8.     return "Name: " + Name + "\t" +
9.         "Created: " + CreateDate.ToLongDateString() + "\t" +
10.         "Total: " + Total;
11.   }
12. }
13.  
14. class ReportProcessor
15. {
16.   List<Report> _reports;
17.  
18.   public ReportProcessor()
19.   {
20.     _reports = new List<Report>
21.     {
22.       new Report { Total = 100, Name = "Average", CreateDate = DateTime.Now },
23.       new Report { Total = 120, Name = "Sum", CreateDate = DateTime.Now.AddDays(-1) },
24.       new Report { Total = 130, Name = "Average", CreateDate = DateTime.Now.AddDays(-2) },
25.       new Report { Total = 90, Name = "Average", CreateDate = DateTime.Now.AddDays(-3) },
26.       new Report { Total = 100, Name = "Sum", CreateDate = DateTime.Now.AddDays(-4) },
27.       new Report { Total = 110, Name = "Sum", CreateDate = DateTime.Now.AddDays(-2) },
28.       new Report { Total = 170, Name = "Average", CreateDate = DateTime.Now.AddDays(-1) },
29.       new Report { Total = 130, Name = "Sum", CreateDate = DateTime.Now.AddDays(-4) },
30.       new Report { Total = 120, Name = "Average", CreateDate = DateTime.Now.AddDays(-3) },
31.       new Report { Total = 180, Name = "Sum", CreateDate = DateTime.Now.AddDays(-7) }
32.     };
33.   }
34.  
35.   public List<Report> GetByName(String name)
36.   {
37.     List<Report> rs = new List<Report>();
38.     foreach (Report r in _reports)
39.       if (r.Name == name)
40.         rs.Add(r);
41.     return rs;
42.   }
43. }
44.  
45. class Program
46. {
47.   static void Main(string[] args)
48.   {
49.     ReportProcessor rp = new ReportProcessor();
50.  
51.     foreach (Report r in rp.GetByName("Sum"))
52.       Console.WriteLine(r);
53.  
54.     Console.ReadKey();
55.   }
56. }

* This source code was highlighted with Source Code Highlighter.

Есть какой-то набор отчетов, которые класс ReportProcessor может предоставить. В данном случае программа выведет на экран отчеты с названием Sum. Как вы поступите, если вам нужно будет выбирать отчеты еще и по итоговому полю? Наверняка первая мысль, это добавить такой вот метод в класс ReportProcessor

1. public List<Report> GetByTotal(uint total)
2. {
3.   List<Report> rs = new List<Report>();
4.   foreach (Report r in _reports)
5.     if (r.Total == total)
6.       rs.Add(r);
7.   return rs;
8. }

* This source code was highlighted with Source Code Highlighter.

И так при каждом добавлении новых требований? Если требований по фильтрации будет очень много, то нам придется добавить очень много новых методов в этот класс.
Кажется, что все-таки ничего плохого в этом все равно нет. Но добавление новых методов в класс это всегда потенциальная опасность. Ведь если класс уже реализует какую-то функциональность, то его исправление может нанести вред уже достигнутому.
Конкретно для нашего примера, чтобы избежать этих потенциальных ошибок, очень удобно использовать шаблон Спецификация.

1. class ReportProcessor
2. {
3.   /// ...
4.  
5.   public List<Report> GetReports(ISpecification spec)
6.   {
7.     List<Report> rs = new List<Report>();
8.     foreach (Report r in _reports)
9.       if (spec.IsSatisfied(r))
10.         rs.Add(r);
11.     return rs;
12.   }
13. }
14.  
15. class Program
16. {
17.   static void Main(string[] args)
18.   {
19.     ReportProcessor rp = new ReportProcessor();
20.  
21.     foreach (Report r in rp.GetReports(new NameSpecification("Sum")))
22.       Console.WriteLine(r);
23.  
24.     Console.ReadKey();
25.   }
26. }

* This source code was highlighted with Source Code Highlighter.

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

1. public interface ISpecification
2. {
3.   bool IsSatisfied(Report r);
4. }
5.  
6. public abstract class CompositeSpecification: ISpecification
7. {
8.   public ISpecification And(ISpecification spec)
9.   {
10.     return new AndSpecification(this, spec);
11.   }
12.   public ISpecification Or(ISpecification spec)
13.   {
14.     return new OrSpecification(this, spec);
15.   }
16.   public ISpecification Not(ISpecification spec)
17.   {
18.     return new NotSpecification(this);
19.   }
20.  
21.   public abstract bool IsSatisfied(Report r);
22. }
23.  
24. public class AndSpecification: ISpecification
25. {
26.   private ISpecification _spec1;
27.   private ISpecification _spec2;
28.  
29.   public AndSpecification(ISpecification spec1, ISpecification spec2)
30.   {
31.     _spec1 = spec1;
32.     _spec2 = spec2;
33.   }
34.  
35.   public bool IsSatisfied(Report r)
36.   {
37.     return _spec1.IsSatisfied(r) && _spec2.IsSatisfied(r);
38.   }
39. }
40.  
41. public class OrSpecification: ISpecification
42. {
43.   private ISpecification _spec1;
44.   private ISpecification _spec2;
45.  
46.   public OrSpecification(ISpecification spec1, ISpecification spec2)
47.   {
48.     _spec1 = spec1;
49.     _spec2 = spec2;
50.   }
51.  
52.   public bool IsSatisfied(Report r)
53.   {
54.     return _spec1.IsSatisfied(r) || _spec2.IsSatisfied(r);
55.   }
56. }
57.  
58. public class NotSpecification: ISpecification
59. {
60.   private ISpecification _spec;
61.  
62.   public NotSpecification(ISpecification spec)
63.   {
64.     _spec = spec;
65.   }
66.  
67.   public bool IsSatisfied(Report r)
68.   {
69.     return !_spec.IsSatisfied(r);
70.   }
71. }
72.  
73. public class NameSpecification: CompositeSpecification
74. {
75.   private String _name;
76.  
77.   public NameSpecification(String name)
78.   {
79.     _name = name;
80.   }
81.  
82.   public override bool IsSatisfied(Report r)
83.   {
84.     return r.Name == _name;
85.   }
86. }
87.  
88. public class TotalGreaterSpecification : CompositeSpecification
89. {
90.   private double _total;
91.  
92.   public TotalGreaterSpecification(double total)
93.   {
94.     _total = total;
95.   }
96.  
97.   public override bool IsSatisfied(Report r)
98.   {
99.     return r.Total > _total;
100.   }
101. }

* This source code was highlighted with Source Code Highlighter.

Выберем все отчеты Sum, в которых значение поля итого более 100.

1. class Program
2. {
3.   static void Main(string[] args)
4.   {
5.     ReportProcessor rp = new ReportProcessor();
6.  
7.     foreach (var r in rp.GetReports(new NameSpecification("Sum")
8.       .And(new TotalGreaterSpecification(100))))
9.       Console.WriteLine(r);
10.  
11.     Console.ReadKey();
12.   }
13. }

* This source code was highlighted with Source Code Highlighter.

Таким образом, новые требования фильтрации не приводят к правкам в классе ReportProcessor.

Принцип замещения Лисков
Следовать этому принципу очень важно при проектировании новых типов с использованием наследования.

"Функции, которые используют ссылки на базовые классы, должны иметь возможность использовать объекты производных классов, не зная об этом"

Этот принцип предупреждает разработчика о том, что изменение унаследованного производным типом поведения очень рискованно.
Нарушение этого принципа очень наглядно демонстрирует следующий пример

1. class Rectangle
2. {
3.   public virtual int Width { get; set; }
4.   public virtual int Height { get; set; }
5.   public int GetRectangleArea()
6.   {
7.     return Width * Height;
8.   }
9. }
10.  
11. class Square: Rectangle
12. {
13.   public override int Width
14.   {
15.     get { return base.Width; }
16.     set
17.     {
18.       base.Height = value;
19.       base.Width = value;
20.     }
21.   }
22.   public override int Height
23.   {
24.     get { return base.Height; }
25.     set
26.     {
27.       base.Height = value;
28.       base.Width = value;
29.     }
30.   }
31. }

* This source code was highlighted with Source Code Highlighter.

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

1. class Program
2. {
3.   static void Main(string[] args)
4.   {
5.     Rectangle rect = new Square();
6.     rect.Width = 3;
7.     rect.Height = 10;
8.  
9.     Console.WriteLine(rect.GetRectangleArea());
10.     Console.ReadKey();
11.   }
12. }

* This source code was highlighted with Source Code Highlighter.

Такой код как ни странно выведет в консоль 100 вместо 30. Ладно, здесь мы видим, что создан был все таки квадрат, а затем использован в качестве прямоугольника. А если использование объекта класса Rectangle будет совсем не в том месте, где объект был создан? Скажем, пропущенный через несколько вызовов нескольких классов?
Очевидно, что не стоило наследовать класс прямоугольника от класса квадрата. Выход из такой ситуации только один - отказаться от наследования. Варианта исправить ситуацию в целом два:
1. Rectange и Square будут совсем разными типами
2. Square агрегирует объект типа Rectangle.
Какой вариант выбрать, это на совести разработчика. Но ясно одно - с переопределением поведения базового типа нужно быть очень аккуратным. Иначе использование проектируемого типа в качестве базового принесет очень много бед.

Принцип разделения интерфейсов
Использование этого принципа рекомендуется очень многими заслуженными авторитетами по разработке ПО уже давно. Тот же Мейер в своей книге "50 советов по улучщению кода и архитектуры ваших систем" ревностно призывает пользоваться указанной практикой.

При проектировании типов нужно придерживаться минимализма в интерфейсах. Слишком толстые интерфейсы нужно разделять. Если не все методы необходимы для использования типа, то это первый звонок того, что данный принцип не выполняется.
Рассмотрим на примере

1. public interface ICustomList<T> : IEnumerable<T>
2. {
3.   void Insert(int index, T item);
4.  
5.   void RemoveAt(int index);
6.  
7.   T this[int index] { set; }
8.  
9.   void Add(T item);
10.  
11.   void Clear();
12.  
13.   bool Remove(T item);
14.  
15.   int IndexOf(T item);
16.   
17.   T this[int index] { get; }
18.   
19.   bool Contains(T item);
20.   
21.   int Count { get; }
22.   
23.   IEnumerator<T> GetEnumerator();
24. }

* This source code was highlighted with Source Code Highlighter.

Вы хотите сделать какой-то класс реализующий данный интерфейс. Класс будет представлять из себя список с возможностью добавления, удаления элементов и т.д.
Однако, при использовании объектов этого типа вы можете столкнуться с проблемой. Любой объект, который получит такой список может "редактировать" его. В определенных сценариях это может оказаться нежелательным. Для того, чтобы предостеречь подобное использование списка, следует разделить интерфейс ICustomList на два: полный и только для чтения.

1. public interface ICustomEnumerable<T>: IEnumerable<T>
2. {
3.   int IndexOf(T item);
4.  
5.   T this[int index] { get; }
6.  
7.   bool Contains(T item);
8.  
9.   int Count { get; }
10.  
11.   IEnumerator<T> GetEnumerator();
12. }
13.  
14. public interface ICustomList<T> : ICustomEnumerable<T>
15. {
16.   void Insert(int index, T item);
17.  
18.   void RemoveAt(int index);
19.  
20.   T this[int index] { set; }
21.  
22.   void Add(T item);
23.  
24.   void Clear();
25.  
26.   bool Remove(T item);
27. }

* This source code was highlighted with Source Code Highlighter.

Такой прием позволит ограничить использование списков. Если какому-либо классу нежелательно "редактировать" список, то вместо ICustomList следует передавать ICustomEnumerable.

Принцип инверсии зависимости
Этот принцип я описал в своем блоге ранее. Нет смысла повторяться. Чтобы ознакомиться с ним перейдите сюда.

Благодарности
Придумать что-то новое - не было целью моего доклада. В первую очередь я ориентировался на доступность и понятность материала. Поэтому при составлении доклада, я использовал много источников. Какие-то мысли были взяты из других блогов частично или полностью.
Я хочу выразить благодарность Александру Бындю за его серию постов о SOLID, а также автору вот этого блога за очень хорошие примеры кода.

PS По поводу Принципа подстановки Лисков недавно была очень интересная дискуссия. Ознакомиться с разными мнениями и позициями можно по следующим ссылкам
Блог Александра Бындю - Принцип замещения Лисков
Блог Александра Бындю - Дополнение к LSP
Блог Сергея Теплякова - Принцип замещения Лисков и контракты