YouIT

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

564   0   3   0 | Добавлено 187 дней назад  

Любой современный язык программирования, будь то JavaScript, Python или C# является достаточно комплексным инструментом, который состоит из длинного списка простых и сложных составляющих. Даже небольшая задача может быть решена несколькими разными способами за счет вариаций комбинирования программных конструкций.

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

Техники борьбы со сложностью

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

На вышеперечисленных принципах построен длинный ряд шаблонов проектирования, к которым относятся GoF шаблоны (Декоратор, Медиатор, Посетитель и так до 23х), не GoF шаблоны (Null Object, Rules, Event Aggregator), шаблоны доступа к данным (Репозиторий, Единица работы, Спецификация, Активная запись…), шаблоны предметно-ориентированного проектирования (Сущность, Объект-значение, Доменный сервис, Агрегат, Репозиторий, Доменное событие) и прочие категории шаблонов.

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

Все производное от Принципа Единой Ответственности

Если проанализировать различные принципы, шаблоны и анти-шаблоны проектирования, то немалую их часть объединяет лишь один принцип, а именно Принцип Единой Ответственности (Single Responsibility Principle). Наверное, не зря он стоит на первом месте в списке SOLID. Этот принцип говорит о том, что программный компонент (метод, класс, интерфейс, сборка, микросервис) должен реализовывать только одну задачу и иметь только одну причину для внесения в него изменения.

На принципе единой ответственности базируются например Принцип Открыт/Закрыт (Open/Closed Principle) или Принцип Разделения Интерфейсов (Interface Segregation Principle), так как следование им является следованием принципу единой ответственности в чистом виде.

На принципе единой ответственности базируется большая часть шаблонов проектирования, которые созданы именно для его соблюдения, а именно Строитель/Фабричный метод, Декоратор, Прокси, Цепочка обязанностей, Итератор, Медиатор, Состояние, Стратегия/Шаблонный метод, Правила (Rules), MVC и другие. Все перечисленные шаблоны инкапсулируют логику определенного вида. Например, шаблон Медиатор инкапсулирует логику взаимодействия нескольких объектов. Если не использовать Медиатор, то логика взаимодействия располагалась бы непосредственно во взаимодействующих между собой объектах в добавок к их основной логике, что и нарушало бы принцип единой ответственности.

Ну и наконец различные анти-шаблоны, как например God-object, слезно кричат лишь об одном: “Не нарушайте принцип единой ответственности!”.

Как следовать Принципу Единой Ответственности

Следовать Принципу Единой Ответственности совсем не сложно с технической точки зрения, ведь как упоминалось ранее, вы, как разработчик, должны наделять свои программные компоненты (методы, классы и т. д.) единственной обязанностью. Например, метод не должен выполнять валидацию данных и сохранять их в базу, а класс не должен вычислять значения по некоторым формулам и генерировать pdf-документы.

В следовании принципу единой ответственности главную роль играет выбор вами четкого именования методов, классов и т. д. Имя должно четко описывать выполняемую обязанность, должно описываться одним-тремя словами и не содержать союзов ‘И’ или ‘Или’ (например, OrderPriceCalculator а не OrderPriceCalculatorAndXmlParser). Имя должно быть неким сдерживающим фактором для программиста, чтобы не впихнуть новые обязанности, которые будут выходить за рамки выбранного имени. Если, например, называть свои классы Helper, Manager, Doer, то в конечном счете в них окажется самая разнообразная логика и принцип единой ответственности будет нарушен. Но если класс будет называться например XmlFileValidator, то вряд ли у кого-то поднимется рука разместить там логику расчета налогов или стоимости заказа.

Заключение

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


Похожие статьи

Комментарии (0)

Авторизируйтесь для участия в дискуссии

Google Facebook ВКонтакте
работа программиста качество кода IT-компания обучение программированию карьера собеседование C# сертификация джуниор алгоритмы ООП энтерпрайз .NET тестирование javascript программирование эстимейты roadmaps информатика фан быстродействие базы данных