H SOLID принципы проектирования и внедрения в C# в черновиках Перевод

Всем привет!

Мы тут пополняем нашу копилочку курсов — решили попробовать запустить новый курс "Разработчик C#" с достаточно (вроде как) плотной программой. Сегодня проводим первый открытый урок ещё, ну и вот делимся небольшим интересным переводиком статьи, которая попала нам в лапы.

Поехали

Введение

Основные концепции Объектно-Ориентированного Программирования (ООП) заключаются в низкой связанности, высокой сцепляемости и сильной инкапсуляции. SOLID принципы ООП помогают разработчикам достигнуть масштабируемости и улучшить качество и надежность кода благодаря одновременному применению этих принципов. Системы, созданные таким образом, просто обслуживать, использовать повторно и расширять с течением времени. 5 SOLID принципов были введены Майклом Фезерсом (Michael Feathers).

Что такое SOLID принцип?



SOLID принципы легко запомнить благодаря английскому слову SOLID (переводится как “надежный”, “прочный”). Каждая буква в этой аббревиатуре имеет значение:

• S означает SRP (Single responsibility principle) — Принцип единственной ответственности;
• O означает OCP (Open closed principle) — Принцип открытости/закрытости;
• L означает LSP (Liskov substitution principle) — Принцип подстановки Барбары Лисков;
• I означает ISP (Interface segregation principle) — Принцип разделения интерфейса;
• D означает DIP (Dependency Inversion principle) — Принцип инверсии зависимостей.

Принцип единственной ответственности (SRP)

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

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

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

Принцип подстановки Барбары Лисков (LSP)

Принцип подстановки Барбары Лисков говорит о полиморфизме. Он утверждает что производный класс не должен влиять на поведение родительского класса. В соответствии с LSP, вместо родительского класса вы можете использовать любой производный, который будет вести себя таким же образом без модификаций. LSP — расширение Принципа открытости/закрытости и означает, что мы должны убедиться, что наш новый производный класс расширяет базовые классы без изменения их поведения.

Принцип разделения интерфейса (ISP)

По принципу разделения интерфейса, клиенты не должны зависеть от методов, которые они не используют. Вместо одного “толстого” интерфейса, лучше использовать группы методов. Интерфейс должен быть более плотно связан с кодом, в котором он используется, чтобы методы интерфейса определялись методами, необходимыми клиентскому коду. Чем больше интерфейс, тем больше вероятность, что он включает в себя методы, которые могут выполнить не все исполнители. И в этом вся суть Принципа разделения интерфейса.
Интерфейсы нужны для достижения низкой связанности. Именно клиенты используют интерфейсы, а не классы.

Принцип инверсии зависимостей (DIP)

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

Dry и Wet Кодинг

Don’t Repeat Yourself (Не Повторяйся), сокращенно DRY, принцип разработки ПО, который говорит, что гораздо проще управлять единственным, непротиворечивым и авторитетным представителем в рамках системы. С другой стороны, Write Everything Twice (Пиши Все Дважды), сокращенно WET — прямая противоположность DRY принципа. Всегда стоит следовать DRY принципам, а любое их нарушение считается WET решением.

THE END

Как всегда ждём комментарии тут или можете помучать нашего преподавателя на открытом уроке.

Спасибо!