Когда не нужно использовать наследование?

Когда НЕ использовать наследование в Java

Наследование (inheritance) — один из трёх столпов ООП, но часто его используют неправильно. Существует множество сценариев, где композиция, делегирование или интерфейсы являются лучшим выбором.

Проблема классического наследования

Наследование создаёт тесную связанность между классом-родителем и классом-наследником:

// ❌ ПЛОХО: строгое наследование
public class Vehicle {
    protected String color;
    protected int speed;
    
    public void startEngine() { /* ... */ }
}

public class Car extends Vehicle {
    // наследует методы, не нужные Car
    // например, startEngine может быть не применим
}

Класс-наследник полностью зависит от внутренней реализации родителя. При изменении родителя ломается наследник.

1. Когда родитель содержит специфичную логику

НЕ наследуй, если родитель имеет конкретную бизнес-логику:

// ❌ НЕПРАВИЛЬНО
public class DatabaseConnection {
    private String url;
    public void connect() { /* SQL логика */ }
}

public class UserRepository extends DatabaseConnection {
    // наследуем специфичную для БД логику
    public User findById(Long id) { /* ... */ }
}

✅ ПРАВИЛЬНО: Используй композицию

public class UserRepository {
    private final DatabaseConnection connection;
    
    public UserRepository(DatabaseConnection connection) {
        this.connection = connection;
    }
    
    public User findById(Long id) {
        connection.connect();
        // запрос
        return null;
    }
}

Композиция позволяет:

• Менять реализацию DatabaseConnection без изменения UserRepository
• Использовать разные типы подключений (MySQL, PostgreSQL)
• Тестировать с mock-объектами

2. Наследование для переиспользования кода

НЕ наследуй только для того, чтобы переиспользовать методы:

// ❌ ПЛОХО
public class Employee {
    protected void logError(String msg) { /* ... */ }
}

public class Manager extends Employee {
    // нужна только функция логирования
}

✅ ПРАВИЛЬНО: Выноси в утилиту

public class Logger {
    public static void logError(String msg) { /* ... */ }
}

public class Manager {
    public void performTask() {
        Logger.logError("Something wrong");
    }
}

Ор используй композицию:

public class Manager {
    private final Logger logger;
    
    public Manager(Logger logger) {
        this.logger = logger;
    }
    
    public void performTask() {
        logger.logError("Something wrong");
    }
}

3. Когда нарушается принцип Liskov Substitution (LSP)

НЕ наследуй, если подкласс не может заменить родителя везде, где он используется:

// ❌ ПЛОХО: нарушает LSP
public class Bird {
    public void fly() { /* летаем */ }
}

public class Penguin extends Bird {
    @Override
    public void fly() {
        throw new UnsupportedOperationException("Пингвины не летают!");
    }
}

Пингвин нарушает контракт Bird. Код, работающий с Bird, сломается на Penguin.

✅ ПРАВИЛЬНО: Используй интерфейсы

public interface Flyable {
    void fly();
}

public interface Swimmer {
    void swim();
}

public class Bird implements Flyable {
    @Override
    public void fly() { /* летаем */ }
}

public class Penguin implements Swimmer {
    @Override
    public void swim() { /* плывём */ }
}

4. Иерархии, которые растут в глубину

НЕ наследуй многоуровнево, если создаёшь сложную иерархию:

// ❌ ПЛОХО: излишняя глубина
Animal → Vehicle → Car → SportsCar → TeslaSportsCar → ...

Такие иерархии:

• Сложны в понимании
• Хрупкие (изменение на 1 уровне ломает всё внизу)
• Не расширяемы (сложно добавить новые комбинации)

✅ ПРАВИЛЬНО: Используй композицию и интерфейсы

public class Car {
    private final Engine engine;        // Composition
    private final Transmission transmission;
    private final Interior interior;
    
    public Car(Engine e, Transmission t, Interior i) {
        this.engine = e;
        this.transmission = t;
        this.interior = i;
    }
}

5. Когда подкласс не является "типом" родителя

НЕ наследуй, если отношение — это не "является" (is-a), а "имеет" (has-a):

// ❌ ПЛОХО
public class Person {
    private String name;
}

public class Address extends Person {
    // Address не является Person!
}

✅ ПРАВИЛЬНО

public class Person {
    private String name;
    private Address address;  // Composition
}

public class Address {
    private String street;
    private String city;
}

6. Множественное наследование (в Java частично)

НЕ наследуй от нескольких классов, потому что Java это не позволяет:

// ❌ НЕВОЗМОЖНО в Java
public class ElectricCar extends Car, ElectricVehicle { }

✅ ПРАВИЛЬНО: Используй интерфейсы

public class ElectricCar extends Car implements ElectricVehicle {
    // наследуем от Car (класс)
    // реализуем ElectricVehicle (интерфейс)
}

7. Недостаточная абстракция

НЕ наследуй, если родитель не определён как абстрактный концепт:

// ❌ ПЛОХО
public class Administrator extends User {
    // Administrator это специальный User? Не совсем.
    // Это role/privilege, не подтип User
}

✅ ПРАВИЛЬНО

public class User {
    private String name;
    private Role role;  // Enum или отдельный класс
}

public enum Role {
    ADMIN, USER, MODERATOR
}

Правило: Предпочитай композицию наследованию

Это "Composition over Inheritance" — один из принципов SOLID и Clean Code:

// ❌ НАСЛЕДОВАНИЕ (тугая связь)
public class LoggingService extends DatabaseService { }

// ✅ КОМПОЗИЦИЯ (слабая связь)
public class LoggingService {
    private final DatabaseService database;
    private final Logger logger;
    
    public LoggingService(DatabaseService db, Logger log) {
        this.database = db;
        this.logger = log;
    }
}

Когда наследование ВСЁ ЖЕ хорошо

Наследование используй когда:

• Истинная иерархия типов: Animal → Dog → Labrador (is-a отношение)
• Абстрактные базовые классы: AbstractProcessor, BaseService
• Стратегия полиморфизма: переопределение методов в подклассах
• Глубина максимум 2-3 уровня: иначе усложнение

Пример хорошего наследования:

public abstract class PaymentProcessor {
    public abstract void process(Payment payment);
    public abstract void rollback(Payment payment);
}

public class StripeProcessor extends PaymentProcessor {
    @Override
    public void process(Payment payment) { /* Stripe логика */ }
    
    @Override
    public void rollback(Payment payment) { /* Stripe откат */ }
}

public class PayPalProcessor extends PaymentProcessor {
    @Override
    public void process(Payment payment) { /* PayPal логика */ }
    
    @Override
    public void rollback(Payment payment) { /* PayPal откат */ }
}

Заключение

Ключевая идея: Наследование создаёт тугую связь и может быть хрупким. Используй его только для моделирования истинной иерархии типов. В остальных случаях предпочитай композицию, интерфейсы и делегирование — они дают больше гибкости и следуют SOLID принципам.