Зв'язки між об'єктами: композиція та агрегація

Чому самодостатні класи не вистачає

На попередніх етапах ми познайомилися з фундаментальними механізмами об'єктно-орієнтованого програмування: інкапсуляцією даних, конструкторами та деструкторами, перевантаженням операторів. Ми навчилися створювати автономні класи, які зберігають стан і надають методи для його модифікації. Проте реальні програмні системи рідко складаються з ізольованих класів-одинаків.

Уявіть собі завдання моделювання автомобіля в симуляційній програмі. Ви могли б створити монолітний клас Car, який містить сотні полів: параметри двигуна (enginePower, fuelType, cylinderCount), характеристики коробки передач (gearCount, transmissionType), властивості кожного колеса (tirePressure, wheelDiameter) і навіть дані про систему гальмування. Результатом стане клас-велетень на тисячі рядків, у якому важко орієнтуватися, тестувати окремі підсистеми та повторно використовувати код в інших проєктах.

Архітектурна проблема полягає не в тому, що ми можемо вмістити всю логіку в один клас, а в тому, що не повинні цього робити. Компілятор C++ не заборонить вам написати Car::calculateEngineTorque(), Car::simulateTransmissionShift() та Car::applyBrakingForce() у одному файлі, але така структура порушує фундаментальний принцип декомпозиції: один клас має виконувати одну добре визначену роль.

Саме для розв'язання цієї проблеми індустрія програмування виробила набір структурних шаблонів взаємодії між об'єктами. У реальному світі складні сутності природно розкладаються на дрібніші компоненти: автомобіль складається з двигуна, кузова та коліс; університет володіє факультетами; підприємство наймає працівників. Кожен із цих зв'язків має власну семантику життєвого циклу та відповідальності за керування ресурсами. Наша задача — навчитися точно відображати ці відносини в коді C++.

Ієрархія взаємодій між об'єктами

Перед тим, як заглибитися в технічну реалізацію, важливо усвідомити загальну карту типів зв'язків. У теорії об'єктно-орієнтованого проєктування прийнято виділяти чотири основних типи відносин між класами, кожен із яких відображає різну силу зв'язку та різну відповідальність за життєвий цикл об'єктів.

Композиція (Composition)

Це найсильніший тип зв'язку, що моделює відношення «ціле-частина» (part-of). Частина не може існувати без цілого, створюється разом із ним і знищується у момент знищення контейнера. Класичний приклад: серце є частиною тіла людини. Якщо тіло перестає існувати, серце теж припиняє функціонування. У програмуванні такі відносини часто реалізуються через зберігання об'єктів-частин за значенням як полів класу-контейнера.

Приклади непротирічних взаємозв'язків композиції:

• Будинок ↔ Кімната (House ↔ Room): Кімната є фізичним внутрішнім об'ємом будівлі та не може існувати «сама по собі у просторі». Знесення будинку безумовно знищує всі його кімнати, а одна конкретна кімната не може належати двом різним спорудам одночасно.
• Шахова дошка ↔ Клітинка (ChessBoard ↔ Square): Клітинка (наприклад, E4) має зміст лише як координатна частина шахівниці. Вона не може існувати поза дошкою чи бути перенесена на іншу дошку як автономний об'єкт.
• Замовлення ↔ Рядок замовлення (Order ↔ OrderItem): Позиція в чеку («3 × кава по 60 грн») має сенс виключно всередині конкретного замовлення. Вона не може належати іншому чеку та ліквідується разом із видаленням замовлення.
• Текстовий документ ↔ Розділ або абзац (Document ↔ Paragraph): Абзац як структурна складова тексту створюється всередині документа, належить виключно йому і вивантажується з оперативної пам'яті при знищенні документа.
• Математичний дріб ↔ Чисельник і знаменник (Fraction ↔ numerator, denominator): Числові поля безпосередньо утворюють сутність дробу та не мають власного незалежного життєвого циклу.

Агрегація (Aggregation)

Це слабша форма зв'язку, що моделює відношення «володіє/містить» (has-a), але без жорсткого контролю життєвого циклу. Об'єкт-контейнер знає про свої частини та може з ними взаємодіяти, але не відповідає за їх створення чи знищення. Приклад: університетський факультет має викладачів. Викладачі можуть існувати до створення факультету, можуть переходити на інші факультети, а після розформування факультету продовжують працювати в університеті. У C++ агрегація часто реалізується через покажчики або посилання на зовнішні об'єкти.

Приклади непротирічних взаємозв'язків агрегації:

• Музичний плейлист ↔ Аудіотрек (Playlist ↔ Song): Аудіофайл пісні автономно зберігається на накопичувачі або у спільній медіатеці, а плейлист лише посилається на нього. Один трек може одночасно належати десяткам плейлистів, а видалення списку відтворення не видаляє сам аудіофайл.
• Спортивна команда ↔ Гравець (Team ↔ Player): Спортсмен існує як автономна особистість до укладання контракту з клубом. Він може виступати за національну збірну або перейти в інший клуб, а розформування команди не припиняє життя чи кар'єри гравця.
• Університетська кафедра ↔ Викладач (Department ↔ Teacher): Викладач приймається на роботу ззовні, може суміщати ставки на кількох кафедрах, а реорганізація чи закриття кафедри не призводить до його фізичного знищення.
• Аеропорт ↔ Літак (Airport ↔ Airplane): Літак прибуває до аеропорту, тимчасово обслуговується і відлітає за іншим маршрутом. Аеропорт не конструює літак і не знищує його під час закриття термінала на ремонт.
• Текстовий редактор ↔ Файл на диску (TextEditor ↔ File): Програма-редактор лише відкриває зовнішній файл в ОС та утримує його дескриптор. Закриття вікна програми не призводить до видалення файлу з файлової системи.

Асоціація (Association)

Відношення «використовує» (uses-a) між об'єктами, які взаємодіють як рівноправні партнери без концепції володіння. Наприклад, пацієнт відвідує лікаря: обидва існують незалежно, можуть мати багато партнерів одночасно. Асоціація може бути односпрямованою (клас А знає про B, але B не знає про А) або двоспрямованою (bidirectional).

Залежність (Dependency)

Найслабший тип зв'язку: об'єкт тимчасово використовує інший об'єкт для виконання конкретної операції, але не зберігає на нього посилання. Типовий приклад: метод приймає аргумент або створює локальну змінну іншого класу. Залежність не впливає на життєвий цикл і не створює постійного зв'язку в пам'яті.

У цій статті ми детально розглянемо перші два типи зв'язків — композицію та агрегацію, оскільки саме вони визначають структуру класів із вкладеними об'єктами та правила керування ресурсами. Асоціацію та залежність ми вивчимо в наступних лекціях, коли перейдемо до проєктування складніших систем взаємодії.

Композиція: нерозривний життєвий цикл частин і цілого

Композиція (composition) — це структурний шаблон, у якому складний об'єкт-контейнер (ціле, whole) повністю відповідає за існування своїх складових частин (parts). Частина створюється у момент конструювання цілого і знищується у момент його деструкції. Між двома об'єктами встановлюється відношення суворого володіння: частина належить рівно одному контейнеру і не може існувати поза його межами.

Формальні ознаки композиції

Для того, щоб відношення між класами кваліфікувалося як композиція, необхідно дотримання чотирьох умов:

1. Частина є невід'ємною складовою цілого: Поле-член класу безпосередньо представляє сутність, без якої ціле втрачає сенс. Наприклад, дріб (Fraction) не може існувати без чисельника і знаменника.
2. Частина може належати лише одному об'єкту за раз: Якщо m_numerator є полем об'єкта fraction1, то цей самий екземпляр m_numerator не може одночасно бути частиною fraction2. Кожен об'єкт класу володіє власними копіями своїх полів.
3. Існування частини керується об'єктом: Контейнер має повний контроль над життєвим циклом частини. Якщо частина створюється динамічно (через new), контейнер зобов'язаний звільнити пам'ять у своєму деструкторі.
4. Частина не знає про існування цілого: Поле m_numerator є звичайним цілим числом (int) і не має жодної інформації про клас Fraction, до якого воно належить. Це односпрямовані відносини: клас знає про свої поля, але поля не знають про клас.

Реалізація композиції: об'єкти за значенням

Найпростіший і найбезпечніший спосіб реалізації композиції в C++ — це оголошення полів класу за значенням, а не через покажчики. Розглянемо класичний приклад класу Fraction, який складається з двох цілочисельних частин:

class Fraction
{
private:
    int numerator;
    int denominator;

public:
    Fraction(int num = 0, int den = 1)
        : numerator(num), denominator(den)
    {
        if (denominator == 0) {
            denominator = 1; // Захист від ділення на нуль
        }
    }

    void print() const
    {
        std::cout << numerator << "/" << denominator;
    }
};

Проаналізуємо, як цей клас задовольняє всім критеріям композиції:

• Невід'ємність: Дріб Fraction не може існувати без чисельника і знаменника. Ці два поля визначають сутність об'єкта.
• Унікальне володіння: Кожен об'єкт Fraction f(3, 5); створює власну пару {numerator=3, denominator=5}. Якщо ми створюємо другий об'єкт Fraction g(1, 2);, він отримує власні, незалежні поля.
• Керований життєвий цикл: Поля numerator і denominator автоматично конструюються разом із об'єктом Fraction (через список ініціалізації) і автоматично знищуються, коли об'єкт виходить із області видимості.
• Односпрямованість: Ціле число numerator не має інформації про те, що воно є частиною дробу. Це просто примітивне значення типу int.

Композиція користувацьких класів: зв'язок «Людина — Серце»

Приклад із дробом Fraction ілюструє композицію з примітивними числовими типами (int). Проте в об'єктно-орієнтованому програмуванні композиція найчастіше застосовується для поєднання повноцінних користувацьких класів.

Класичний приклад із реального світу — Людина та її Серце (Human ↔ Heart). Біологічне серце формується разом із організмом, б'ється впродовж усього життя людини та не може функціонувати як автономна сутність поза тілом.

Зверніть особливу увагу на архітектурне правило, якого часто не дотримуються новачки: контейнер зобов'язаний сам конструювати свої складові. Якщо в конструктор класу Human передавати вже готовий об'єкт Heart ззовні, це спотворює семантику композиції, адже створюється хибне враження, що серце існувало автономно до появи людини. При істинній композиції конструктор приймає лише параметри конфігурації (наприклад, базовий пульс), а сам екземпляр Heart конструюється безпосередньо у списку ініціалізації:

#include <iostream>
#include <string>

class Heart
{
private:
    int beatsPerMinute;

public:
    Heart(int bpm = 70)
        : beatsPerMinute(bpm)
    {
        std::cout << "Серце сформовано (пульс: " << beatsPerMinute << " уд/хв)\n";
    }

    ~Heart()
    {
        std::cout << "Серце зупинилося\n";
    }

    void beat() const
    {
        std::cout << "Серце б'ється з частотою " << beatsPerMinute << " уд/хв\n";
    }
};

class Human
{
private:
    std::string name;
    Heart heart; // Композиція за значенням: серце фізично вбудоване в об'єкт Human

public:
    // Конструктор приймає примітивні характеристики, а НЕ готовий об'єкт Heart!
    // Human САМ відповідає за створення свого підоб'єкта:
    Human(const std::string& personName, int normalBpm = 72)
        : name(personName), heart(normalBpm)
    {
        std::cout << "Людина " << name << " народилася\n";
    }

    ~Human()
    {
        std::cout << "Людина " << name << " завершила життєвий шлях\n";
    }

    void live() const
    {
        std::cout << name << " живе активним життям: ";
        heart.beat(); // Делегування виконання підоб'єкту
    }
};

Використання в програмі наочно демонструє нерозривність життєвих циклів:

int main()
{
    {
        Human ivan("Іван", 75);
        ivan.live();
    } // При виході зі scope ivan знищується, автоматично знищуючи і своє серце

    return 0;
}

Черговість подій підкреслює семантику володіння:

1. Спочатку конструюється підоб'єкт heart (поля завжди ініціалізуються до початку виконання тіла конструктора Human).
2. Потім виконується конструктор Human.
3. При виході зі scope порядок суворо протилежний: спершу викликається деструктор Human, а після нього автоматично запускається деструктор поля heart. Жоден зовнішній код не має можливості втрутитися в цей процес або викликати витік пам'яті.

Будинок та Кімнати: фіксована композиція кількох складових

Ще один непротирічний приклад — Будинок та Кімнати (House ↔ Room). Будинок не існує без своїх приміщень, а кімната є невіддільною просторовою частиною будівлі. Будинок самостійно конструює кімнати у власному списку ініціалізації:

class Room
{
private:
    std::string title;
    double areaSquareMeters;

public:
    Room(const std::string& name, double area)
        : title(name), areaSquareMeters(area)
    {
    }

    void printInfo() const
    {
        std::cout << "  - " << title << " (" << areaSquareMeters << " м²)\n";
    }
};

class House
{
private:
    std::string streetAddress;
    Room livingRoom; // Перша обов'язкова частина
    Room bedroom;    // Друга обов'язкова частина

public:
    // Конструктор будинку приймає площі, а самі кімнати конструює самостійно
    House(const std::string& address, double livingArea, double bedArea)
        : streetAddress(address),
          livingRoom("Вітальня", livingArea),
          bedroom("Спальня", bedArea)
    {
    }

    void showPlan() const
    {
        std::cout << "План будинку за адресою: " << streetAddress << "\n";
        livingRoom.printInfo();
        bedroom.printInfo();
    }
};

Цей приклад ілюструє, що ціле може складатись одночасно з кількох підоб'єктів одного типу (Room), кожним із яких воно одноосібно володіє.

Замовлення та Рядки замовлення: композиція з динамічною кількістю частин

Що робити, коли кількість складових заздалегідь невідома? Наприклад, Замовлення в інтернет-магазині (Order) може містити довільну кількість позицій (OrderItem).

Навіть при використанні динамічного контейнера std::vector композиція зберігається за умови, що замовлення самостійно створює свої рядки через метод addItem, який приймає примітивні дані товару й конструює об'єкт безпосередньо у внутрішньому буфері вектора за допомогою emplace_back:

#include <vector>

class OrderItem
{
private:
    std::string itemName;
    int quantity;
    double unitPrice;

public:
    OrderItem(const std::string& name, int qty, double price)
        : itemName(name), quantity(qty), unitPrice(price)
    {
    }

    double getTotalCost() const { return quantity * unitPrice; }

    void print() const
    {
        std::cout << "  • " << itemName << " x" << quantity 
                  << " = " << getTotalCost() << " грн\n";
    }
};

class Order
{
private:
    int orderNumber;
    std::vector<OrderItem> items; // Композиція: вектор володіє екземплярами OrderItem

public:
    Order(int id) : orderNumber(id) {}

    // Метод додавання приймає характеристики товару, а НЕ готовий об'єкт!
    // Замовлення САМО створює рядок OrderItem всередині свого вектора:
    void addItem(const std::string& name, int qty, double price)
    {
        items.emplace_back(name, qty, price);
    }

    void printReceipt() const
    {
        std::cout << "Замовлення #" << orderNumber << ":\n";
        double total = 0.0;
        for (const auto& item : items) {
            item.print();
            total += item.getTotalCost();
        }
        std::cout << "Загальна сума: " << total << " грн\n";
    }
};

Знищення об'єкта Order автоматично очищує вектор items, викликаючи деструктори для кожного OrderItem. Жоден рядок замовлення не може залишитися в пам'яті чи бути переданим іншому замовленню.

Композиція із динамічною пам'яттю: відповідальність класу

У деяких випадках частини об'єкта необхідно створювати динамічно — наприклад, коли розмір даних невідомий на момент компіляції або коли частина є великим об'єктом, передача якого за значенням неефективна. У таких ситуаціях композиція все одно зберігає повний контроль над життєвим циклом, але реалізується через покажчики-члени класу із ручним керуванням пам'яттю.

Розглянемо клас IntArray, який інкапсулює динамічний масив цілих чисел. Масив є невід'ємною частиною об'єкта і не може існувати без контейнера:

class IntArray
{
private:
    int* data;      // Покажчик на динамічний масив (частина об'єкта)
    int length;     // Розмір масиву

public:
    // Конструктор виділяє пам'ять для масиву (створює частину)
    IntArray(int size)
        : length(size)
    {
        data = new int[length]{};  // Ініціалізація нулями
    }

    // Деструктор звільняє пам'ять (знищує частину)
    ~IntArray()
    {
        delete[] data;
        data = nullptr;
    }

    // Оператор індексації для доступу до елементів
    int& operator[](int index)
    {
        return data[index];
    }

    int getLength() const { return length; }
};

Аналіз реалізації з погляду композиції:

• Створення частини: Конструктор класу IntArray викликає new int[length] — це означає, що клас відповідає за створення масиву. Користувач класу лише передає розмір, але не бере участі у виділенні пам'яті.
• Знищення частини: Деструктор ~IntArray() викликає delete[] data — це гарантує, що пам'ять звільниться автоматично, коли об'єкт IntArray вийде зі scope або буде видалений через delete.
• Приховування деталей: Зовнішній код не має доступу до покажчика data (він приватний). Користувач взаємодіє з масивом виключно через публічний інтерфейс operator[] і getLength().

Приклад використання:

int main()
{
    IntArray numbers(5);  // Конструктор виділяє масив на 5 елементів

    numbers[0] = 10;
    numbers[1] = 20;

    std::cout << "First element: " << numbers[0] << "\n";

    // Деструктор IntArray автоматично викличе delete[] при виході зі scope
    return 0;
}

При виході з функції main() об'єкт numbers знищується, що автоматично запускає деструктор ~IntArray(), який звільняє динамічний масив data. Користувач класу не бачить цього процесу і не повинен турбуватися про ручне звільнення пам'яті — це є суттю ідіоми RAII (Resource Acquisition Is Initialization), яку ми вивчали раніше.

Моделювання реальних систем через композицію

Композиція особливо ефективна для моделювання складних об'єктів, що природно розкладаються на дрібніші підсистеми. Повернімося до прикладу симуляції істоти у грі, яка переміщується по двовимірній карті. Замість того, щоб зберігати координати x і y безпосередньо в класі Creature, ми можемо інкапсулювати концепцію «точка у просторі» в окремий клас Point2D і вбудувати його в Creature через композицію.

Клас Point2D — інкапсуляція координат

class Point2D
{
private:
    int x;
    int y;

public:
    // Конструктор за замовчуванням — початок координат (0, 0)
    Point2D()
        : x(0), y(0)
    {
    }

    // Параметризований конструктор для заданої точки
    Point2D(int xCoord, int yCoord)
        : x(xCoord), y(yCoord)
    {
    }

    // Метод для переміщення точки на нову позицію
    void setPoint(int newX, int newY)
    {
        x = newX;
        y = newY;
    }

    // Перевантаження оператора виводу для зручного друку
    friend std::ostream& operator<<(std::ostream& out, const Point2D& point)
    {
        out << "(" << point.x << ", " << point.y << ")";
        return out;
    }
};

Клас Point2D повністю автономний: він інкапсулює поведінку двовимірної точки, не знаючи нічого про те, хто його використовує. Це дозволяє повторно використовувати його в різних контекстах — для позицій істот, координат будівель, точок на карті тощо.

Клас Creature — композиція з Point2D

class Creature
{
private:
    std::string name;
    Point2D location;  // Композиція: location є частиною Creature

public:
    // Конструктор приймає координати, а НЕ готовий об'єкт Point2D!
    // Creature самостійно конструює свою точку location у списку ініціалізації:
    Creature(const std::string& creatureName, int startX = 0, int startY = 0)
        : name(creatureName), location(startX, startY)
    {
    }

    // Делегування переміщення підоб'єкту Point2D
    void moveTo(int x, int y)
    {
        location.setPoint(x, y);
    }

    // Вивід інформації про істоту разом із її координатами
    friend std::ostream& operator<<(std::ostream& out, const Creature& creature)
    {
        out << creature.name << " is at " << creature.location;
        return out;
    }
};

Проаналізуємо відносини:

• Створення частини всередині контейнера: Конструктор Creature приймає примітивні координати int startX, int startY, а не готовий об'єкт Point2D. Об'єкт Creature самостійно ініціалізує свою внутрішню точку у списку ініціалізації (location(startX, startY)). Це фундаментальне правило композиції: якщо конструктор вимагатиме готовий підоб'єкт ззовні (Creature(name, Point2D pos)), це виглядає як впровадження зовнішньої залежності. При істинній композиції зовнішній код навіть не зобов'язаний створювати екземпляри Point2D самостійно.
• Частина належить цілому: Поле location оголошено за значенням, а не через покажчик. Це означає, що об'єкт Point2D фізично вбудований у структуру пам'яті об'єкта Creature. Коли створюється Creature, одночасно конструюється і його location.
• Тривалість життя частини залежить від цілого: Коли об'єкт Creature знищується, автоматично викликається деструктор Point2D для поля location. Ніяка зовнішня логіка не потрібна.
• Делегування обов'язків: Метод moveTo() класу Creature не реалізує логіку переміщення самостійно — він делегує цю роботу методу setPoint() підоб'єкта Point2D. Це приклад композиційного підходу до розподілу відповідальності: кожен клас робить те, що він знає найкраще.

Використання у програмі

int main()
{
    std::cout << "Enter a name for your creature: ";
    std::string name;
    std::cin >> name;

    // Створюємо істоту на початковій позиції (5, 6)
    // Зверніть увагу: ми передаємо координати (5, 6), а не готовий об'єкт Point2D
    Creature creature(name, 5, 6);

    std::cout << creature << "\n";

    // Переміщуємо істоту на нову позицію (10, 15)
    creature.moveTo(10, 15);

    std::cout << "After moving: " << creature << "\n";

    return 0;
}

Архітектурні переваги композиції

Чому варто виділяти Point2D в окремий клас замість того, щоб просто додати поля int x, y безпосередньо в Creature? Це питання має фундаментальне значення для розуміння принципів проєктування:

Перевага №1: Модульність і спрощення розуміння
Кожен клас зосереджений на одній відповідальності (Single Responsibility Principle). Клас Point2D знає все про координати і операції з ними (відстань, зсув, обертання), а клас Creature зосереджений на високорівневій логіці істоти (здоров'я, інвентар, поведінка). Розробник, який хоче зрозуміти систему координат, може відкрити лише Point2D.h і побачити все необхідне в одному місці.

Перевага №2: Повторне використання коду (Reusability)
Якщо завтра ви захочете додати клас Building, який також має координати, ви просто використаєте той самий клас Point2D:

class Building
{
private:
    std::string type;
    Point2D position;  // Повторне використання вже готового класу

public:
    Building(const std::string& buildingType, int posX, int posY)
        : type(buildingType), position(posX, posY) {}
};

Без Point2D вам довелося б дублювати код роботи з координатами в кожному класі.

Перевага №3: Легкість розширення функціональності
Припустімо, ви вирішили додати обчислення відстані між двома точками або перевірку, чи лежить точка в певному прямокутнику. Ви просто додаєте ці методи в клас Point2D, і всі класи, що використовують його (і Creature, і Building), автоматично отримують доступ до нової функціональності без жодних змін у своєму коді.

UML-діаграма композиції: зафарбований ромб

Уніфікована мова моделювання (Unified Modeling Language, UML) використовує графічну нотацію для представлення відносин між класами. Композиція позначається зафарбованим (чорним) ромбом ◆ на стороні класу-контейнера, від якого веде суцільна лінія до класу-частини. Цей символ візуально підкреслює міцність зв'язку: ромб «прив'язує» частину до цілого, вказуючи на нерозривність життєвих циклів.

@startuml
skinparam style plain
skinparam backgroundColor #FFFFFF
skinparam classAttributeIconSize 0

class Creature {
  - name: std::string
  - location: Point2D
  + Creature(name: std::string, startX: int, startY: int)
  + moveTo(x: int, y: int): void
}

class Point2D {
  - x: int
  - y: int
  + Point2D()
  + Point2D(x, y)
  + setPoint(x: int, y: int): void
}

Creature *-- Point2D : містить як частину

note right of Creature
  Зафарбований ромб ◆ вказує на композицію:
  Creature самостійно створює та знищує
  свій екземпляр Point2D
end note

@enduml

Інтерпретація діаграми:

• Зафарбований ромб на стороні Creature: вказує, що Creature є «власником» частини Point2D.
• Множинність «1»: за замовчуванням одна істота має рівно одну точку локації. Якби істота мала список точок маршруту, ми б вказали 1..* або 0..*.
• Напрямок залежності: стрілка йде від цілого до частини, що відповідає односпрямованості відносин у коді (клас Creature знає про Point2D, але Point2D не знає про Creature).

Розташування об'єктів у пам'яті: монолітний блок

Одна з ключових характеристик композиції — це фізична близькість у пам'яті. Коли ви оголошуєте поле за значенням (Point2D location;), компілятор вбудовує байти під-об'єкта безпосередньо у структуру батьківського об'єкта. Це означає, що Creature і його location розміщені в єдиному неперервному блоці пам'яті.

class Worker
{
private:
    std::string name;

public:
    Worker(const std::string& workerName)
        : name(workerName)
    {
        std::cout << "Worker " << name << " hired\n";
    }

    ~Worker()
    {
        std::cout << "Worker " << name << " retired\n";
    }

    std::string getName() const { return name; }
};

class Department
{
private:
    std::string departmentName;
    Worker* manager;  // Агрегація: покажчик на зовнішній об'єкт Worker

public:
    // Конструктор приймає вже існуючий об'єкт Worker
    Department(const std::string& name, Worker* externalWorker = nullptr)
        : departmentName(name), manager(externalWorker)
    {
        std::cout << "Department " << departmentName << " created\n";
    }

    ~Department()
    {
        std::cout << "Department " << departmentName << " disbanded\n";
        // Увага: НЕ викликаємо delete manager!
        // Працівник існує незалежно від відділу
    }

    void assignManager(Worker* newManager)
    {
        manager = newManager;
    }

    void printInfo() const
    {
        std::cout << "Department: " << departmentName;
        if (manager != nullptr) {
            std::cout << ", Manager: " << manager->getName();
        } else {
            std::cout << ", Manager: [none]";
        }
        std::cout << "\n";
    }
};

int main()
{
    // Створюємо працівників незалежно від відділів
    Worker* alice = new Worker("Alice");
    Worker* bob = new Worker("Bob");

    {
        // Створюємо відділ і призначаємо менеджера
        Department engineering("Engineering", alice);
        engineering.printInfo();

        // Змінюємо менеджера відділу
        engineering.assignManager(bob);
        engineering.printInfo();

        // Відділ знищується при виході зі scope
    }

    // Працівники продовжують існувати після знищення відділу
    std::cout << "Workers still exist: " << alice->getName()
              << ", " << bob->getName() << "\n";

    // Звільняємо пам'ять працівників вручну
    delete alice;
    delete bob;

    return 0;
}

@startuml
skinparam style plain
skinparam backgroundColor #FFFFFF
skinparam classAttributeIconSize 0

class Department {
  - departmentName: std::string
  - manager: Worker*
  + Department(name, worker)
  + assignManager(worker: Worker*): void
  + printInfo(): void
}

class Worker {
  - name: std::string
  + Worker(name)
  + getName(): std::string
}

Department o-- Worker : має покажчик на

note right of Department
  Порожній ромб ◇ вказує на агрегацію:
  Worker існує незалежно від Department
  і не знищується разом із відділом
end note

@enduml

Creature dragon("Dragon", 10, 15);

Адреса       | Зміст              | Пояснення
-------------|--------------------|---------------------------------
0x7FFF1000   | [std::string data] | Поле name
0x7FFF1020   | 10                 | location.x (частина об'єкта)
0x7FFF1024   | 15                 | location.y (частина об'єкта)

Worker* alice = new Worker("Alice");
Department engineering("Engineering", alice);

Стек (об'єкт Department):
Адреса       | Зміст              | Пояснення
-------------|--------------------|---------------------------------
0x7FFF2000   | "Engineering"      | departmentName
0x7FFF2020   | 0x00A00100         | manager (покажчик на купу)

Купа (об'єкт Worker):
Адреса       | Зміст              | Пояснення
-------------|--------------------|---------------------------------
0x00A00100   | "Alice"            | name