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

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

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

Проблема с наследованием

Наследование — это один из самых неправильно используемых механизмов в Java. Оно создаёт жёсткую связанность между классами и часто приводит к хрупкому коду.

// ПЛОХО — наследование создаёт проблемы
public class Animal {
    public void eat() {
        System.out.println("Animal is eating");
    }
}

public class Dog extends Animal {
    public void bark() {
        System.out.println("Woof!");
    }
}

public class Robot extends Animal {  // ???
    // Robot not an animal!
    // Это нарушает логику
    @Override
    public void eat() {
        // Robot не ест!
        throw new UnsupportedOperationException();
    }
}

Это нарушает принцип Liskov Substitution Principle (LSP) из SOLID: подкласс должен быть заменяем на базовый класс.

КОГДА использовать наследование?

1. Отношение "является" (IS-A), а не "имеет" (HAS-A)

Если между классами отношение "является" — тогда наследование уместно.

// ПРАВИЛЬНО — собака ЯВЛЯЕТСЯ животным
public abstract class Animal {
    public abstract void makeSound();
    public abstract void eat();
}

public class Dog extends Animal {
    @Override
    public void makeSound() {
        System.out.println("Woof!");
    }
    
    @Override
    public void eat() {
        System.out.println("Dog eats meat");
    }
}

public class Bird extends Animal {
    @Override
    public void makeSound() {
        System.out.println("Tweet!");
    }
    
    @Override
    public void eat() {
        System.out.println("Bird eats seeds");
    }
}

// Правильное использование
Animal dog = new Dog();
Animal bird = new Bird();
dog.makeSound();  // Woof!
bird.makeSound(); // Tweet!

Тут Dog действительно ЯВЛЯЕТСЯ Animal, а не просто имеет анимальные свойства.

2. Общее поведение в базовом классе

// ПРАВИЛЬНО — общее поведение для всех животных
public abstract class Vehicle {
    protected String name;
    protected double speed;
    
    // Общее поведение
    public void accelerate(double amount) {
        speed += amount;
    }
    
    public void brake(double amount) {
        speed = Math.max(0, speed - amount);
    }
    
    // Абстрактное поведение — для переопределения
    abstract void start();
    abstract void stop();
}

public class Car extends Vehicle {
    @Override
    void start() {
        System.out.println("Car engine starts");
    }
    
    @Override
    void stop() {
        System.out.println("Car engine stops");
    }
}

public class Truck extends Vehicle {
    @Override
    void start() {
        System.out.println("Truck engine starts (loud!)");
    }
    
    @Override
    void stop() {
        System.out.println("Truck engine stops");
    }
}

// Общее поведение (accelerate, brake) используется для обоих
Vehicle car = new Car();
car.accelerate(10);  // Работает для Car и Truck
car.start();         // Переопределено в Car

3. Создание иерархии типов (Type Hierarchy)

// ПРАВИЛЬНО — иерархия типов исключений
public class CustomException extends Exception {
    // Кастомное исключение
}

public class ValidationException extends CustomException {
    // Специфичное исключение валидации
}

public class DatabaseException extends CustomException {
    // Специфичное исключение БД
}

// Использование:
try {
    validateUser(user);
    saveToDatabase(user);
} catch (ValidationException e) {
    // Обработка ошибок валидации
} catch (DatabaseException e) {
    // Обработка ошибок БД
} catch (CustomException e) {
    // Общая обработка кастомных исключений
}

4. Полиморфизм для обработки разных типов одинаково

// ПРАВИЛЬНО — полиморфизм через наследование
public abstract class PaymentProcessor {
    abstract void processPayment(BigDecimal amount);
}

public class CreditCardProcessor extends PaymentProcessor {
    @Override
    void processPayment(BigDecimal amount) {
        // Обработка кредитной карты
    }
}

public class PayPalProcessor extends PaymentProcessor {
    @Override
    void processPayment(BigDecimal amount) {
        // Обработка PayPal
    }
}

public class BitcoinProcessor extends PaymentProcessor {
    @Override
    void processPayment(BigDecimal amount) {
        // Обработка Bitcoin
    }
}

// Использование — один код работает со всеми типами
public class CheckoutService {
    private PaymentProcessor processor;
    
    public void checkout(BigDecimal total) {
        processor.processPayment(total);  // Работает для любого процессора
    }
}

КОГДА НЕ использовать наследование?

1. Когда есть отношение "имеет" (HAS-A), а не "является" (IS-A)

// ПЛОХО — неправильное наследование
public class Car extends Engine {
    // Car НЕ является Engine!
    // Car ИМЕЕТ Engine
}

// ПРАВИЛЬНО — композиция
public class Car {
    private Engine engine;  // Car ИМЕЕТ Engine
    
    public void start() {
        engine.start();
    }
}

public class Engine {
    public void start() {
        System.out.println("Engine started");
    }
}

2. Когда нужна гибкость и возможность менять поведение

// ПЛОХО — наследование минус: сложно менять
public class UserService extends DatabaseService {
    // Если захотим использовать другую БД, придётся менять иерархию
}

// ПРАВИЛЬНО — инъекция зависимостей (композиция)
public class UserService {
    private Database database;  // Можем использовать любую БД
    
    public UserService(Database database) {
        this.database = database;
    }
    
    public User getUser(Long id) {
        return database.findById(id);
    }
}

public interface Database {
    User findById(Long id);
}

public class PostgresDatabase implements Database {
    @Override
    public User findById(Long id) { ... }
}

public class MongoDatabase implements Database {
    @Override
    public User findById(Long id) { ... }
}

3. Когда нужно смешивать несколько свойств (Multiple Inheritance)

// ПЛОХО — Java не поддерживает множественное наследование
public class Bird extends Animal, Flyer {  // Ошибка!
}

// ПРАВИЛЬНО — используй интерфейсы (composition over inheritance)
public class Bird extends Animal implements Flyer {
    @Override
    public void fly() {
        System.out.println("Bird is flying");
    }
}

public interface Flyer {
    void fly();
}

4. Когда нужна одноразовая функциональность

// ПЛОХО — наследование ради одного метода
public class Logger extends Thread {
    // Наследуем Thread ради запуска в отдельном потоке
    @Override
    public void run() {
        log("message");
    }
}

// ПРАВИЛЬНО — композиция
public class Logger implements Runnable {
    @Override
    public void run() {
        log("message");
    }
}

// Использование
new Thread(new Logger()).start();
// Или с лямбдой в современной Java
new Thread(() -> logger.log("message")).start();

Правило 80/20 для наследования

// Используй наследование если:
// 1. Есть явное отношение IS-A
public class Manager extends Employee { ... }  // ✓ Manager IS-A Employee

// 2. Подклассы подменяют друг друга (LSP)
Animal animal = new Dog();  // ✓ Dog can be used as Animal

// 3. Общее поведение имеет смысл в базовом классе
public abstract class DataProcessor {
    public void process() {  // Общая логика
        validate();
        transform();
        save();
    }
}

// НЕ используй наследование если:
// 1. Нет явного IS-A отношения
class Circle extends Shape { ... }  // ✓ IS-A
class Car extends Engine { }        // ✗ HAS-A!

// 2. Код выглядит странно или требует пустых реализаций
class Robot extends Animal {
    @Override
    public void eat() {
        throw new UnsupportedOperationException();  // ✗ RED FLAG!
    }
}

// 3. Нужна гибкость или множественное поведение
// Используй интерфейсы и композицию вместо наследования

Лучшие практики

// 1. Предпочитай композицию наследованию
public class UserNotificationService {
    private EmailSender emailSender;      // Композиция
    private SmsSender smsSender;          // Композиция
    private NotificationLogger logger;    // Композиция
    
    public void notifyUser(User user, String message) {
        emailSender.send(user.getEmail(), message);
        smsSender.send(user.getPhone(), message);
        logger.log(user, message);
    }
}

// 2. Используй интерфейсы вместо базовых классов
public interface DataSource { ... }  // Вместо BaseDataSource
public class PostgresDataSource implements DataSource { ... }

// 3. Если всё же используешь наследование — делай базовый класс abstract
public abstract class Animal {  // abstract — сигнал для других разработчиков
    abstract void makeSound();
}

// 4. Используй @Override аннотацию
public class Dog extends Animal {
    @Override  // Явно указываем, что переопределяем
    void makeSound() { ... }
}

// 5. Не наследуй конкретные классы (concrete classes)
public class SpecialUser extends User { }  // ✗ Плохо
public class AdminUser implements UserRole { }  // ✓ Хорошо

Итог

• Наследование РЕДКО правильный выбор в современной Java
• Используй наследование только если:
  1. Есть явное отношение IS-A
  2. Подклассы действительно подменяют друг друга
  3. Базовый класс содержит общее поведение, которое имеет смысл для всех подклассов
• В остальных 90% случаев используй:
  • Композицию (HAS-A)
  • Интерфейсы (I)
  • Инъекцию зависимостей
• Девиз: Composition over Inheritance (Композиция вместо наследования)
• Золотое правило: Если понимаешь, что наследование — это неправильно, значит ты на правильном пути