Чистый код: Данные

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

Значение предметности в этом участке имеют:

• Заказ (class Order),

• Счет (class Account),

• Клиент (class Client),

• Денежные средства (class Money).

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

Обозначают действия:

• Создание счета (interface CreatingAccount ),

• Направление клиенту (interface ReferralToTheClient ),

• Ожидание поступления (interface WaitingForReceipt).

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

Действия с интерфейсами выходят за рамки этой статьи, поэтому остановимся на работе с данными. Чтобы не ошибиться при проектировании, можно использовать прием реализованный в языке C# ключевым словом readonly. Описывайте классы с данными таким образом, чтобы поля нельзя было изменять после выхода из конструктора.

class Product {
private:
   std::string name; // Наименование товара
   double price;     // Цена
public:
   Product(std::string name, double price): name(name), price(price) {}
   std::string name() const { return name; }
   double price() const { return price; }
};

Спросите как это работает, если мы сами себя ограничили. Взгляните на диаграмму.

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

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

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

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

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

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

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

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

class Product {
private:
   std::string m_name; // Наименование товара
   double m_price;    // Цена
public:
   Product(std::string name, double price): m_name(name), m_price(price) {}
   std::string name() const { return m_name; }
   double price() const { return m_price; }
};

class Manufacturer {};

class ExpandProduct : public Product {
private:
   std::shared_ptr<Manufacturer> manufacturer;
public:
   ExpandProduct(std::string name, std::shared_ptr<Manufacturer> manufacturer, double price):
   Product(name, price) {
      this->manufacturer = manufacturer;
   }
   std::shared_ptr<Manufacturer> getManufacturer() const { return manufacturer; }
};

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

int main() {
   std::list<std::shared_ptr<Product>> products{
      std::make_shared<Product>("Product1", CEREALS, 500),
      std::make_shared<Product>("Product2", DRINKS, 400),
      std::make_shared<Product>("Product3", PACKS, 300)
   };

   std::list<std::shared_ptr<Product>> newproducts;
   std::ranges::for_each(products, [&newproducts](auto& elem) {
      auto temp = std::make_shared<ExpandProduct>(
         elem->getName(),
         elem->getClassifier(),
         std::make_shared<Manufacturer>(),
        elem->getPrice()
      );
      newproducts.push_back(temp);
   });

   for (auto& elem : newproducts) {
      std::cout << elem->getName() << std::endl;
   }

   return 0;
}

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

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

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

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

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

Следовательно и пирамида данных имеет примерно три уровня (5)(6). Именно так устроены сборщики мусора в таких языках как C# и Java. В C++ управлением памятью занимается компилятор и операционная система, а программист может влиять на эти процессы только через инструменты динамического управления памятью (7).

В современном C++ развиты инструменты управления динамической памятью в виде умных указателей. Однако семантика копирования и перемещения отдана на усмотрение программистов. Уровень подготовки различных программистов существенно различается, поэтому сложно отследить все копирования перемещения при написании кода. Приходятся переопределять соответствующие конструкторы и методы, а ведь мы еще используем подключаемые библиотеки.

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

Можно сделать вывод, что все объекты лучше использовать по ссылке. Собственно так все и выполняется в языках более высокого уровня C#, Java. В них есть всего два типа данных, базовый и ссылочный. Да и на языке С++ есть примеры использования такого подхода, например в Qt есть один класс QObject от которого происходят все остальные (8).

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

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

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

Обойти это ограничение помогает паттерн декоратор. Вот пример на его основе.

enum Classifier { NONE, CEREALS, DRINKS, PACKS };

/* Декоратор — это структурный паттерн проектирования,
* который позволяет динамически добавлять объектам новую
* функциональность, оборачивая их в полезные «обёртки». */
class Properties {};

class PropertiesCereals : public Properties {};
class PropertiesDrinks : public Properties {};
class PropertiesPacks : public Properties {};

class Product {
private:
   std::string name;    // Наименование товара
   double price;        // Цена
   Classifier category; // Классификатор товара
   std::shared_ptr<Properties> properties;
public:
   Product(std::string name, double price, Classifier classifier, std::shared_ptr<Properties> properties): name(name), price(price), category(classifier), properties(properties) {}
   std::string getName() const { return name; }
   double getPrice() const { return price; }
   Classifier getClassifier() const { return category; }
   const std::shared_ptr<Properties> getProperties() const { return properties; }
};