Основы ООП: абстракция, интерфейсы, абстрактные классы, композиция и Open Closed Principle

Эта статья даёт определение абстракции в объектно-ориентированном программировании с примерами экзаменационных вопросов и ключевыми терминами.

In a Nutshell

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

Компактное определение

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

Ключевые моменты для экзамена

• Фокус на релевантные свойства, сокращение видимой поверхности
• Средства: интерфейсы, абстрактные классы, композиция, генерики
• Разделение контракта и реализации, слабая связанность и высокая связность
• Важно для IHK, точное разграничение от инкапсуляции и наследования
• На практике используйте маленькие, ролевые интерфейсы, Interface Segregation Principle
• Безопасность: чёткие контракты ограничивают поверхность атак и предотвращают несанкционированное изменение состояния
• Экономия: стабильные контракты снижают затраты на поддержку и изменения
• Документирование обязательно: предусловия, постусловия, исключения, побочные эффекты должны быть описаны явно

Ключевые компоненты

1. Модель предметной области, повсеместный язык, термины и взаимосвязи
2. Контрактный интерфейс, сигнатуры, семантика, обработка ошибок
3. Абстрактные базовые классы, общая фундаментальная логика без полной реализации
4. Роли, несколько маленьких интерфейсов вместо одного гигантского
5. Композиция, отношения “имеет” для структурирования поведения
6. Параметрические типы, параметрическая абстракция через типы
7. Паттерны проектирования: Strategy, Template Method, Adapter, Port и Adapter
8. Границы архитектуры, Ports, Adapters, Bounded Contexts
9. Правила качества, высокая связность, низкая связанность, соответствие LSP
10. Тестирование, договорные тесты, тесты замещения, Property Based Tests

Практический пример

// Цель: абстрагировать экспорт файлов
interface Exporter {
byte[] export(Report r)
}

class PdfExporter implements Exporter {
public byte[] export(Report r) { /* PDF Rendering, Validierung, Byte Stream */ }
}

class CsvExporter implements Exporter {
public byte[] export(Report r) { /* CSV Serialisierung, Trennung, Encoding */ }
}

class ReportService {
private Exporter exporter
public ReportService(Exporter exporter) { this.exporter = exporter }
public byte[] exportReport(Report r) {
if (r == null) throw new IllegalArgumentException("Report erforderlich")
return exporter.export(r)
}
}

Объяснение: интерфейс Exporter определяет абстракцию экспорта, конкретные форматы взаимозаменяемы, ReportService остаётся неизменным.

Преимущества и недостатки

Преимущества

• Низкая связанность, высокая связность
• Лучшая тестируемость, ясные области ответственности
• Простое расширение, стабильные API

Недостатки

• Начальные затраты на моделирование
• Риск переабстрагирования контрактов
• Дополнительная косвенность при неправильном объёме

Типичные экзаменационные вопросы (с кратким ответом)

1. Абстракция и инкапсуляция, в чём различие? Абстракция определяет, какие релевантные аспекты видны, инкапсуляция скрывает их реализацию за поверхностью.

2. Интерфейс или абстрактный класс? Интерфейс для чистых контрактов и множественных ролей, абстрактный класс когда нужна общая базовая логика или состояние.

3. Поддерживает ли Open Closed Principle? Контракты остаются стабильны, новые варианты появляются как новые реализации, существующий код не меняется.

4. Критерии хорошей абстракции? Минимальна но полна, согласованно названа, ортогональна, стабильна при внутренних изменениях, однозначно задокументирована.

5. Как оценить качество абстракции? Метрики: число методов в интерфейсе, частота изменений, переиспользование, покрытие тестами, число реализаций.

6. Пример плохой абстракции? God Interface с множеством несвязанных методов, нарушает ISP, затрудняет взаимозаменяемость и тестирование.

7. Роль генериков в абстракции? Параметрическая абстракция, один алгоритм для многих типов без приведения типов, безопасность типов через компилятор.

8. Как полиморфизм и абстракция работают вместе? Абстракция определяет контракт, полиморфизм предоставляет взаимозаменяемые реализации, динамическая диспетчеризация связывает их при выполнении.

Основные источники

1. https://docs.oracle.com/javase/tutorial/java/IandI/abstract.html
2. https://de.wikipedia.org/wiki/Abstraktion_(Informatik)
3. https://martinfowler.com/bliki/RoleInterface.html