Гетери й сетери: коли вони потрібні, а коли шкодять дизайну

1. Вступ

Якщо ви вже бачили код у стилі getName()/setName() для кожного поля, легко подумати: «Гаразд, так заведено». Але потім трапляється C++‑код, де замість getX() пишуть просто x(), а замість setX() — метод на кшталт moveTo(...), і тоді вже не так легко зрозуміти, чому саме так.

Ключова думка тут проста: гетери й сетери — не магія і не «обовʼязковий ритуал дорослого програміста», а звичайні методи. Вони цінні тоді, коли допомагають підтримувати інваріанти й передавати зміст операцій. Якщо ж вони лише дублюють доступ до полів, ви отримуєте шумний інтерфейс, який створює ілюзію «інкапсуляції», але насправді нічого не захищає й часто заважає безболісно розвивати клас.

Щоб розмова не лишилася абстрактною, продовжимо наш навчальний консольний застосунок TaskTracker (міні‑трекер завдань). Раніше, на етапі struct, завдання могло мати такий вигляд: id, title, done. Тепер хочемо зробити крок до «розумного обʼєкта», який не дає зламати себе ззовні.

2. Гетери: «дати прочитати» — теж відповідальність

Коли ми чуємо «гетер», зазвичай уявляємо його як просто спосіб отримати значення поля. Але в дизайні класу гетер відповідає не лише за читання, а й за те, у якому вигляді зовнішній код побачить дані.

Це важливо більше, ніж здається: той самий факт можна «віддати» безпечно чи небезпечно, дешево чи дорого, зручно чи незручно. У C++ є кілька варіантів: повернути за значенням, повернути const T&, а іноді — дуже обережно — повернути T&. Саме на гетерах часто зʼявляються перші серйозні тріщини в інкапсуляції, тому що фраза «я просто хотів, щоб було зручніше» легко перетворюється на «я випадково віддав назовні важіль керування нутрощами».

Простий безпечний гетер для невеликих типів

Для невеликих типів на кшталт int і bool майже завжди зручно й безпечно повертати значення:

class Task {
public:
    int id() const { return id_; }
    bool is_done() const { return done_; }

private:
    int id_ = 0;
    bool done_ = false;
};

Тут майже немає підводних каменів: int і bool копіюються швидко, назовні ви не віддаєте прямий доступ до внутрішніх полів, а інваріанти не страждають.

Гетер для std::string: значення або const&

Із рядками стає цікавіше. Якщо в завданні є заголовок, можна зробити так:

#include <string>

class Task {
public:
    std::string title() const { return title_; } // копія

private:
    std::string title_ = "untitled";
};

Це безпечно, але копіювання може бути зайво дорогим. Іноді це нормально: рядки короткі, а викликів мало. Але якщо читати рядок потрібно часто, зручніше повертати його за const‑посиланням:

#include <string>

class Task {
public:
    const std::string& title() const { return title_; } // без копії

private:
    std::string title_ = "untitled";
};

Це все ще безпечно для інкапсуляції, оскільки const std::string& не дає зовнішньому коду змінювати рядок напряму. Але тут зʼявляється важливий нюанс: посилання «привʼязане» до обʼєкта. Якщо обʼєкт знищити, воно стане висячим.

Правило просте: не можна зберігати результат const&-гетера довше, ніж живе сам обʼєкт. Якщо ви використовуєте його одразу, усе гаразд.

Чому T&-гетер часто ламає клас

Ось гетер, який виглядає «дуже зручним»:

#include <string>

class Task {
public:
    std::string& title() { return title_; } // небезпечно

private:
    std::string title_ = "untitled";
};

Тепер зовнішній код може зробити майже що завгодно:

Task t;
// Зовнішній код отримав змінюване посилання й обійшов будь-які перевірки.
t.title().clear();

Якщо інваріант формулювався як «у завдання заголовок не порожній», його щойно зламано. Формально клас «інкапсульований» (поле private), але фактично ви віддали назовні прямий дріт до нутрощів. Це і називають «протіканням інкапсуляції».

Мінітаблиця: як обирати тип повернення в гетері

Коли ви лише починаєте писати класи, корисно мати простий орієнтир. Не як «закон», а як підказку здорового глузду, щоб не зависати над кожним методом.

Зверніть увагу: у C++ гетер — це частина API. Якщо ви одного разу віддали T&, то фактично пообіцяли користувачу класу, що цей стан завжди можна змінювати напряму. А коли згодом захочете додати перевірку, зʼясується, що її вже обходять через T&.

3. Сетери й операції: як змінювати стан без втрати інваріантів

Сетер здається простим: «присвоїти значення полю». Але в нормальному класі сетер — це точка контролю: саме тут ви вирішуєте, чи допустима зміна, чи потрібно нормалізувати дані, чи варто відмовити і як зберегти інваріанти.

Головний критерій такий: сетер виправданий тоді, коли він виражає правила і зміст. Якщо він просто робить field_ = value; без перевірок, то часто перетворюється на «public поле, але через два зайві екрани коду».

Сетер без правил: формально є, фактично нічого не захищає

#include <string>

class TaskBad {
public:
    void set_title(const std::string& title) {
        title_ = title; // без перевірок
    }

    const std::string& title() const { return title_; }

private:
    std::string title_ = "untitled";
};

Що тут не так? Ви ніби заявили: «я контролюю доступ», але насправді нічого не контролюєте. Зовнішній код може встановити порожній рядок, рядок, що складається лише з пробілів, надто довгий рядок — будь-що. Клас не захищає себе.

Сетер із перевірками: «сетер із характером»

Задаймо інваріант: заголовок завдання не повинен бути порожнім.

#include <string>

class Task {
public:
    bool set_title(const std::string& title) {
        if (title.empty()) return false;
        title_ = title;
        return true;
    }

    const std::string& title() const { return title_; }

private:
    std::string title_ = "untitled";
};

Тепер сетер справді корисний: він не просто присвоює, а не дає обʼєкту стати некоректним.

Зверніть увагу на стиль: ми повертаємо bool, щоб зовнішній код одразу бачив, чи вдалася операція. Винятки тут не використовуємо — це окрема велика тема, тож «акуратна відмова» цілком нормальна практика.

Чому «get/set на все» робить клас анемічним

Найпоширеніша помилка новачків звучить так: «Раз у нас є class і private, давайте для кожного поля зробимо get/set». Виглядає солідно, але якщо всередині set_* немає логіки й захисту інваріантів, клас стає просто шумною версією struct.

Такий клас не додає змісту, зате додає зобовʼязання: тепер зовнішній код залежить від десятка дрібних методів, і змінити внутрішнє подання стає складніше.

Уявіть, що завдання має пріоритет від 1 до 5. Якщо ви зробили set_priority(int p) без перевірки, то дозволили встановити -100 або 999. Далі в програмі почнуть зʼявлятися «милиці» на кшталт if (task.priority() < 1) ..., і ви програли: перевірки розповзлися по всьому коду, а клас перестав бути «господарем» власної коректності.

Методи-операції замість сетерів

Корисна звичка: коли ви хочете написати сетер, зупиніться на секунду й запитайте себе: «Це справді встановлення поля, чи все-таки операція?». У багатьох випадках читабельніше й безпечніше дати окремий метод-операцію.

Наприклад, замість set_done(true) часто краще:

• mark_done()
• reopen()

Це читається як команда, не змушує памʼятати, «яке значення що означає», а всередині методу можна підтримувати інваріанти.

4. Практичний приклад: поліпшуємо TaskTracker без зайвих get/set

Тепер зберімо реалістичніший приклад для нашого TaskTracker. Нехай завдання має:

• id (не змінюється після створення),
• title (не порожній),
• done (змінюється, але лише через методи-операції),
• priority (1..5).

Мінімальний «правильний» клас Task

#include <string>

class Task {
public:
    Task(int id, const std::string& title, int priority)
        : id_(id), title_(title), priority_(priority) {
        // У цій лекції не заглиблюємося в конструктори, але ідею ви вже бачили.
        // Перевірки можна робити й тут, але поки — тримаємо фокус на API.
        if (title_.empty()) title_ = "untitled";
        if (priority_ < 1) priority_ = 1;
        if (priority_ > 5) priority_ = 5;
    }

    int id() const { return id_; }
    const std::string& title() const { return title_; }
    int priority() const { return priority_; }
    bool is_done() const { return done_; }

    bool rename(const std::string& new_title) {
        if (new_title.empty()) return false;
        title_ = new_title;
        return true;
    }

    bool set_priority(int p) {
        if (p < 1 || p > 5) return false;
        priority_ = p;
        return true;
    }

    void mark_done() { done_ = true; }
    void reopen() { done_ = false; }

private:
    int id_ = 0;
    std::string title_ = "untitled";
    int priority_ = 1;   // інваріант: 1..5
    bool done_ = false;
};

Тут зверніть увагу на ідею: ми не зробили set_id, тому що id — це ідентичність завдання. Якщо зовнішній код зможе змінювати id, ви дуже швидко отримаєте хаос: завдання «вчора було #3, а сьогодні #17». Іноді це припустимо, але тоді це вже не id, а «номер у списку», тобто інша сутність.

Використаймо клас у маленькому main()

#include <iostream>
#include <string>

int main() {
    Task t(1, "Buy milk", 3);

    std::cout << t.id() << ": " << t.title() << "\n";  // 1: Buy milk

    t.mark_done();
    std::cout << t.is_done() << "\n";                  // 1

    if (!t.rename("")) {
        std::cout << "Bad title!\n";                   // Bad title!
    }
}

Так, це виглядає трохи довше, ніж прямий доступ до полів. Зате тепер правила коректності зосереджені всередині Task, а не розкидані по всій програмі.

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

Іноді хочеться «прискорити» й «спростити» дизайн: наприклад, дати доступ до заголовка завдання як до змінюваного посилання, щоб його можна було редагувати напряму. Покажемо, чому це небезпечно саме в контексті інваріантів.

Поганий варіант:

#include <string>

class TaskLeaky {
public:
    std::string& title() { return title_; } // назовні віддали керування
    const std::string& title() const { return title_; }

private:
    std::string title_ = "untitled"; // інваріант: не порожньо
};

Використання:

#include <iostream>

int main() {
    TaskLeaky t;
    t.title().clear();                       // інваріант зламано
    std::cout << "[" << t.title() << "]\n";  // []
}

Клас уже не може гарантувати своє правило «не порожньо», бо обхідний тунель ви побудували самі.

Правильний варіант — залишити лише читання та метод зміни:

#include <string>

class TaskSafe {
public:
    const std::string& title() const { return title_; }

    bool rename(const std::string& new_title) {
        if (new_title.empty()) return false;
        title_ = new_title;
        return true;
    }

private:
    std::string title_ = "untitled";
};

Тепер змінити значення можна, але лише через точку контролю rename, а отже — після перевірки.

6. Схема: як інтерфейс класу захищає стан

Іноді корисно побачити цю ідею наочно:

flowchart TD
    A[Зовнішній код] -->|викликає публічні методи| B[Публічний інтерфейс класу]
    B -->|перевірки та правила| C[Приватні поля]
    A -->|якщо назовні віддали T&| C

Суть проста: нормальний шлях зміни стану проходить через публічний інтерфейс, де живуть перевірки. Але якщо ви віддали назовні змінюване посилання (T&) на нутрощі, зовнішній код починає ходити напряму, і ваші правила лишаються осторонь.

7. Імена гетерів і сетерів: getTitle() vs title()

У різних кодових базах трапляються різні стилі. У навчальних прикладах ми часто використовуємо стиль title() / priority() / is_done() — він короткий і читається як «властивість», без зайвого шуму. У стилі getTitle() теж немає нічого поганого, особливо якщо команда або проєкт уже так домовилися.

Важливіше інше: імʼя методу має відображати зміст. Якщо ви робите метод set_title, а всередині він ще й «нормалізує» рядок (обрізає пробіли, замінює порожнє на "untitled"), можливо, логічніше назвати його rename або try_set_title, щоб поведінка була передбачуваною.

Називати метод «set», а потім усередині робити «додати, якщо немає» — теж поширене джерело непорозумінь.

Коли гетери й сетери справді доречні

Є сценарії, коли гетери й сетери — чудовий інструмент, і демонізувати їх не варто.

Гетер майже завжди виправданий, якщо поле private, але вам потрібно дати безпечне читання. Сетер виправданий, якщо значення справді потрібно встановлювати ззовні й водночас є правила коректності. У нашому Task це set_priority, тому що «пріоритет» — налаштовуване значення з чітким діапазоном. Водночас для done ми обрали операції mark_done/reopen, тому що так читається краще і менше шансів переплутати зміст.

8. Типові помилки

Помилка № 1: «для кожного поля — get і set, бо так заведено».
Такий підхід часто робить клас шумним і майже марним: інваріанти не захищені, логіки немає, а зовнішній код починає залежати від великої кількості дрібних методів. Якщо ви не додаєте правил і змісту, простіше залишити struct (і це буде чесно видно) або вже будувати «справжній» клас з операціями та перевірками.

Помилка № 2: сетери без перевірок, які пропускають некоректні значення.
Коли метод називається set_*, у читача виникає очікування, що після його виклику обʼєкт залишиться коректним. Якщо ви дозволили записати «що завгодно», далі перевірки починають плодитися по всьому проєкту, а клас втрачає роль охоронця інваріанта. Набагато краще відмовити (наприклад, повернути false), ніж «мовчки прийняти» сміття.

Помилка № 3: гетер, що повертає T&, бо «так зручніше».
Це класичне протікання інкапсуляції: зовнішній код отримує можливість змінювати нутрощі в обхід ваших правил. Особливо небезпечно віддавати std::string& або std::vector<T>&, тому що зовнішній код може очистити контейнер, додати дивні елементи, порушити взаємозвʼязок полів. Якщо потрібне читання без копії — повертайте const T&. Якщо потрібна зміна — робіть метод, який виражає операцію й містить перевірки.

Помилка № 4: сетери, які змінюють «ідентичність» обʼєкта.
Методи на кшталт set_id(...) часто здаються нормальними, доки ви не починаєте зберігати обʼєкти в контейнері, шукати їх за id, друкувати звіти й повʼязувати дані. Якщо id змінюється, ви дуже легко ламаєте узгодженість даних на рівні застосунку. Зазвичай ідентичність задається під час створення і потім не змінюється.

Помилка № 5: гетери, які повертають посилання, а клієнтський код зберігає його надто довго.
Повернення const std::string& зручне і швидке, але посилання живе лише доти, доки живе обʼєкт. Якщо десь зберегти це посилання, а потім обʼєкт знищити або замінити, ви отримаєте звернення до «даних, яких уже не існує». У навчальних прикладах простіше дотримуватися такого правила: посилання з гетера використовуємо одразу і не відкладаємо «на потім», а якщо його треба зберігати — беремо копію.