Принципы SOLID. Общие сведения

Итак, что же это за принципы? Что вообще имеется ввиду под понятием принцип? Всего этих принципов пять, обратите внимание на аббревиатуру SOLID, каждая буква в этом слове является первой буквой в названии одного из пяти принципов. Кстати, в английском языке есть такое слово «solid», которое переводится как «твердый или сплошной». Конечно же, это значение не имеет ничего общего с этими принципами. В нашем случае SOLID – это просто аббревиатура.

Первый принцип – Single responsibility principle, или по-русски – Принцип единственной обязанности.

Второй принцип – Open/Closed principle или Принцип открытости/закрытости.

Третий принцип – Liskov substitution principle или Принцип подстановки Лисков. Здесь Лисков – это фамилия.

Четвертый принцип – Interface segregation principle или Принцип разделения интерфейсов.

И, наконец, пятый принцип – Dependency inversion principle или Принцип инверсии зависимостей.

Вот эти пять принципов вместе и образуют аббревиатуру SOLID.

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

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

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

То есть, все эти пять принципов это не что-то такое секретное, их не изобретали специально, нет, это просто некоторые приемы, которые используют разработчики в своей практике.

Грамотное и своевременное использование этих принципов в своих программах делает код более простым, понятным, гибким и легко расширяемым.

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

Постепенно, в процессе создания, программа становится все сложнее, кода становится все больше. В результате мы наблюдаем следующее, у программы появляются следующие признаки:

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

Хрупкость. Это свойство программы повреждаться во многих местах при внесении единственного изменения. Оно тесно связано со свойством жесткость. Очень часто, при внесении очередного изменения, новые проблемы, новые повреждения возникают в тех частях программы, которые не имеют прямой связи с той, что была изменена.

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

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

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

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

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

То есть, применять принципы SOLID следует грамотно и только тогда, когда это необходимо.

Их можно использовать в объектно-ориентированном программировании и проектировании в целом. Конечно же, их можно использовать не только в языке C#, но и на любом другом объектно-ориентированном языке. Более того, эти принципы можно использовать еще на стадии проектирования приложения, не приступая к кодированию.