Что хотят услышать интервьюеры:

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

Определение:

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

Пример использования:

Например, в автотестах можно сделать абстрактный класс для страниц или API-клиентов, где общими будут логирование, ожидания, проверка статуса ответа и базовые методы работы с драйвером или HTTP-клиентом.

public abstract class BasePage {
    protected WebDriver driver;

    public BasePage(WebDriver driver) {
        this.driver = driver;
    }

    public void open(String url) {
        driver.get(url);
    }

    public abstract boolean isPageLoaded();
}

public class LoginPage extends BasePage {

    public LoginPage(WebDriver driver) {
        super(driver);
    }

    @Override
    public boolean isPageLoaded() {
        return driver.getTitle().contains("Login");
    }
}

Пояснение кода:

BasePage задаёт общий контракт для всех страниц: у всех есть driver, метод open() и обязательный метод isPageLoaded(). Метод open() уже реализован один раз в базовом классе, поэтому не дублируется в наследниках. LoginPage наследует общую логику и реализует только специфичную проверку загрузки страницы.

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

Ключевые моменты:

Абстрактный класс полезен, когда есть общий каркас и частично общая реализация.
Он помогает уменьшить дублирование в тестовом фреймворке.
Хорошо подходит для Page Object, базовых API-клиентов, общих компонентов тестов.
Если нужен только контракт без реализации, чаще подходит интерфейс.
Не стоит делать абстрактный класс слишком “толстым”, чтобы не жёстко связывать наследников.
Использовать его стоит тогда, когда действительно есть отношение “is-a” между базовым и дочерними классами.

Применяешь ли ты в своей практике абстрактные классы для архитектурных решений?