__init__, self, page та принципи ООП

self — явний параметр instance method, через який код звертається до конкретного екземпляра класу. self.card означає атрибут цього екземпляра, тоді як локальна змінна card живе лише у своїй функції або блоці видимості.

Однакові назви технічно можливі, але збільшують когнітивне навантаження. Префікс self. одночасно потрібен Python для правильного доступу до instance attribute і показує читачеві, де зберігається стан.

Через __init__ клас отримує залежності й початковий стан, без яких його методи не мають сенсу. Наприклад, компонент приймає кореневий locator, а Page Object — Playwright page; наступні методи перевикористовують ці значення через self.

У повсякденній мові __init__ часто називають constructor. Технічно екземпляр створює __new__, а __init__ ініціалізує вже створений об’єкт. Для звичайного Page Object достатньо реалізувати саме __init__.

class PageObject:
    def __init__(self, page: str):
        self.page = page

    def describe(self) -> str:
        return f"Page: {self.page}"


obj = PageObject("checkout")
assert obj.describe() == "Page: checkout"
print(obj.describe())

Playwright Page представляє окрему вкладку або сторінку в browser context. Переданий у Page Object екземпляр визначає, з яким саме браузерним контекстом працюватимуть locators, переходи й assertions.

Збереження page як self.page прибирає потребу передавати його в кожен метод. Залежність залишається явною в initializer, а всі дії конкретного Page Object використовують одну й ту саму вкладку.

Наявність __init__.py робить директорію звичайним Python package і може визначати його зручний публічний API через imports або __all__. Це допомагає IDE, імпортам і читачеві зрозуміти межу модуля.

Сучасний Python також підтримує namespace packages без __init__.py, тому файл не є абсолютною вимогою для кожної імпортованої директорії. У навчальному проєкті явний package зазвичай простіший і передбачуваніший.

Один underscore, наприклад _locator, — домовленість «внутрішня деталь, не використовуй без потреби». Інтерпретатор не забороняє доступ. Подвійний початковий underscore запускає name mangling, щоб зменшити випадкові конфлікти в нащадках, але теж не створює security boundary.

На відміну від private або protected у статично типізованих мовах, Python більше покладається на дисципліну автора й користувача класу. IDE може попередити про звернення до non-public member, але виконання зазвичай можливе.

Внутрішня функція корисна, коли складна бізнес-дія складається з кількох неочевидних технічних кроків або коли розрахунок потребує предметної назви. Вона зменшує деталі у публічному методі й показує, що не є частиною API класу.

Водночас Page Object має залишатися простим. Не варто ділити кожен рядок на helper: виділення виправдане, коли воно називає реальну дію або приховує поточну складність.

Інкапсуляція поєднує стан і поведінку та визначає дозволений спосіб взаємодії з об’єктом. Практичний акцент — не «сховати все», а відкрити невеликий зрозумілий інтерфейс, який не змушує зовнішній код знати внутрішню послідовність дій.

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

Java і C# формально перевіряють public, private та protected, тоді як Python використовує переважно conventions. Водночас суворіші мови скорочують boilerplate, а Python і JavaScript додають type hints та інструменти статичного аналізу.

Python annotations допомагають IDE й type checker, але самі по собі не перетворюють Python на статично типізовану мову та не гарантують runtime-перевірку. Їхня користь — ранній зворотний зв’язок і краща навігація по API.

Абстрактні принципи стають зрозумілішими після практики: спочатку помітити code smells, потім розібрати базові механізми ООП, далі — patterns і SOLID. KISS, DRY та YAGNI варто застосовувати паралельно як питання до конкретного коду, а не як привід будувати структуру наперед.

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

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