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

Цикл статей о проектировании, призван показать один из возможных путей, достижения успеха, через проектирование программного обеспечения с использованием UML (англ. Unified Modeling Language — унифицированный язык моделирования).

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

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

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

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

Цикл статей о проектировании, призван показать один из возможных путей, достижения успеха, через проектирование программного обеспечения с использованием UML (англ. Unified Modeling Language — унифицированный язык моделирования).

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

-------------

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

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

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

Цикл статей о проектировании, призван показать один из возможных путей, достижения успеха, через проектирование программного обеспечения с использованием UML (англ. Unified Modeling Language — унифицированный язык моделирования).

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

Конечно, каждая программа начинается с идеи, однако путь от идеи до готового продукта достаточно долог. На пути будут поджидать множество сложных вопросов, неверные ответы на которые, могут значительно усложнить проект или вообще завести вас в тупик.

Цикл статей о проектировании, призван показать один из возможных путей, достижения успеха, через проектирование программного обеспечения с использованием UML (англ. Unified Modeling Language — унифицированный язык моделирования).

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

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

Цикл статей о проектировании, призван показать один из возможных путей, достижения успеха, через проектирование программного обеспечения с использованием UML (англ. Unified Modeling Language) — унифицированный язык моделирования.

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

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

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

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

Текущая же статья посвящена общим принципам написания кода, который легко читать, понимать и поддерживать (KISS если так больше нравится). Сразу хочу предупредить, что многие положение отраженные в этой статье могут вызвать сомнения в их корректности, но это личное мнение автора, опирающееся на опыт.

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

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

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

Разработку модуля начнем с определения цели, очень тривиально, но правильно поставленная цель, значительно упрощает реализацию. Основной целью модуля будет создание инструмента удобного для пользователя. Легко добавлять, изменять значения аргументов, легко перебирать значения.

Опишем функционал модуля.

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

Вот такое сложное определение. Где, «Проще говоря», только больше запутывает чем поясняет, хотя все передает верно. Этот принцип пожалуй самый сложный для объяснений, хотя его суть очевидна.

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

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

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

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

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

В чем суть принципа разделения интерфейсов. Если перефразировать простыми словами, не нужно делать два дела сразу. Сознание человека так и построено, вспомните детскую задачку, когда просят одновременной дотянуться пальцем до кончика носа и гладить живот по часовой стрелке.

Прежде чем создавать свой пример, давайте рассмотрим пару участков кода из интернета. Из кода удалены приватные части классов, а так же конструкторы и параметры методов. Исключительно для экономии места.

Первый пример, выдержка из огромного класса интерфейса API, весь класс содержит около 30 методов и не представляет интереса, но показанный участок, иллюстрирует проблемы которые возникли у автора кода при модификации.

Принцип подстановки Лисков гласит, что если метод использует базовый класс, то он должен иметь возможность использовать любой из его производных классов без необходимости иметь информацию о производном классе.

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

Рассмотрим тонкости соблюдения этого принципа, на довольно сложном примере. Начнем с класса хранения данных.

Принцип открытости/закрытости гласит, что программные объекты (классы, методы, функции и т. д.) должны быть открыты для расширения, но закрыты для модификации.

Идеальной реализацией данного принципа является интерфейс. Ничего лишнего, нечего модифицировать, можно только расширять.

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

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

Чистый код не набор внешних признаков, таких как наименование переменных и наличие или отсутствие комментариев, хотя они тоже важны. Чистый код — это архитектура программного продукта, которая позволяет легко читать и модифицировать программный код. Написание такого кода опирается на множество типовых шаблонов (SOLID, паттрерны проектирования и др.), выработанных в ходе практики программирования. Описание еще одного такого шаблона приведено в этой статье.

Неизменяемым называется объект (англ. immutable object), состояние которого не может быть изменено после создания⁽¹⁾. Это понятие не так широко используется в различной литературе, поэтому начну с более подробного разбора этого понятия и обоснования, почему стоит применять этот шаблон.

Классическое определение гласит - Объектно ориентированное программирование (ООП), парадигма программирования, в рамках которой программа представляется в виде совокупности объектов, а её выполнение состоит во взаимодействии между объектами. Объектом называется набор из данных и операций, которые можно выполнить над этими данными⁽²⁾.

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