Какие плюсы и минусы композиции?

Композиция: Плюсы и Минусы

Композиция (composition) — один из ключевых принципов объектно-ориентированного дизайна. Это связь "has-a" между объектами, когда один объект содержит другой как часть своего состояния, в отличие от наследования ("is-a"). Композиция часто рекомендуется вместо наследования как более гибкий подход.

Что такое композиция?

// Наследование ("is-a")
public class Car extends Vehicle {
    // Car IS-A Vehicle
}

// Композиция ("has-a")
public class Car {
    private Engine engine;      // Car HAS-A Engine
    private Transmission transmission; // Car HAS-A Transmission
    private Wheels wheels;      // Car HAS-A Wheels
    
    public void start() {
        engine.start();
    }
}

Плюсы композиции

1. Гибкость и динамизм

Можно менять поведение объекта во время выполнения программы:

public class DataProcessor {
    private Logger logger;
    
    public DataProcessor(Logger logger) {
        this.logger = logger; // можно подставить любую реализацию
    }
    
    public void process(String data) {
        logger.log("Processing: " + data);
        // обработка
    }
}

// Использование
DataProcessor processor1 = new DataProcessor(new ConsoleLogger());
DataProcessor processor2 = new DataProcessor(new FileLogger());
DataProcessor processor3 = new DataProcessor(new DatabaseLogger());

С наследованием пришлось бы создавать разные классы для каждого типа логирования.

2. Избегание хрупкого базового класса

Изменения в базовом классе не ломают производные классы:

// С наследованием — изменение базового класса может сломать всё
public class Animal {
    public void makeSound() { }
}

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

// С композицией — изменения локализованы
public class Dog {
    private SoundMaker soundMaker = new BarkingSoundMaker();
    
    public void makeSound() {
        soundMaker.make();
    }
}

3. Множественная композиция

Объект может комбинировать поведение множества других объектов (в Java нет множественного наследования):

public class Smartphone {
    private Camera camera;
    private Phone phone;
    private MusicPlayer musicPlayer;
    private Browser browser;
    
    public void takePhoto() {
        camera.capture();
    }
    
    public void callSomeone(String number) {
        phone.call(number);
    }
    
    public void listenMusic(String song) {
        musicPlayer.play(song);
    }
    
    public void browsWeb(String url) {
        browser.navigate(url);
    }
}

// Это невозможно сделать наследованием (множественное наследование в Java запрещено)

4. SOLID принципы

Композиция помогает соблюдать SOLID, особенно Dependency Inversion:

// Плохо: зависимость от конкретного класса
public class UserService {
    private MySQLDatabase db = new MySQLDatabase(); // привязка к БД
}

// Хорошо: зависимость от интерфейса
public class UserService {
    private Database db; // может быть любая реализация Database
    
    public UserService(Database db) {
        this.db = db;
    }
}

interface Database {
    void save(User user);
    User findById(Long id);
}

class MySQLDatabase implements Database { ... }
class PostgreSQLDatabase implements Database { ... }
class MongoDatabase implements Database { ... }

5. Облегчённое тестирование

Легко подставить mock объекты:

public class OrderService {
    private PaymentGateway paymentGateway;
    private NotificationService notificationService;
    
    public OrderService(PaymentGateway gateway, NotificationService notification) {
        this.paymentGateway = gateway;
        this.notificationService = notification;
    }
    
    public void processOrder(Order order) {
        paymentGateway.charge(order.getAmount());
        notificationService.sendConfirmation(order.getCustomerId());
    }
}

// В тестах подставляем mock'и
public class OrderServiceTest {
    @Test
    public void testOrderProcessing() {
        PaymentGateway mockGateway = mock(PaymentGateway.class);
        NotificationService mockNotification = mock(NotificationService.class);
        
        OrderService service = new OrderService(mockGateway, mockNotification);
        service.processOrder(new Order());
        
        verify(mockGateway).charge(anyDouble());
        verify(mockNotification).sendConfirmation(anyLong());
    }
}

6. Переиспользование кода

Один компонент можно использовать в разных контекстах:

public class Logger {
    public void log(String message) {
        System.out.println("[LOG] " + message);
    }
}

// Logger можно использовать везде
public class UserService {
    private Logger logger;
    // ...
}

public class OrderService {
    private Logger logger;
    // ...
}

public class PaymentService {
    private Logger logger;
    // ...
}

Минусы композиции

1. Дополнительная сложность

Нужно больше кода и деталей:

// Наследование — просто
public class ProgrammingLanguage {
    public void compile() { }
}

public class Java extends ProgrammingLanguage {
    @Override
    public void compile() {
        System.out.println("Compiling Java code...");
    }
}

// Композиция — больше файлов
public interface Compiler {
    void compile();
}

public class JavaCompiler implements Compiler {
    public void compile() { ... }
}

public class ProgrammingLanguage {
    private Compiler compiler;
    
    public ProgrammingLanguage(Compiler compiler) {
        this.compiler = compiler;
    }
    
    public void compile() {
        compiler.compile();
    }
}

2. Больше памяти

Экземпляры содержат другие экземпляры:

public class Car {
    private Engine engine;           // отдельный объект в памяти
    private Transmission transmission; // отдельный объект в памяти
    private Wheels wheels;           // отдельный объект в памяти
    // ... каждый компонент — это отдельный объект
}

3. Делегирование методов

Нужно писать методы-обёртки:

public class Guitar {
    private String strings;
    
    // Делегирование
    public void tune() {
        strings.tune();
    }
    
    public void play(String note) {
        strings.play(note);
    }
    
    public String getCondition() {
        return strings.getCondition();
    }
    // ... много однообразного кода
}

4. Глубокие цепи делегирования

Может появиться train wreck (паттерн, который считается плохым):

car.getEngine().getValves().getHeadValve().close();
// Сложная цепь, сложно тестировать, слабая инкапсуляция

Когда использовать композицию vs наследование?

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

// Хорошо спроектированная система с композицией
public class NotificationService {
    private EmailSender emailSender;
    private SmsSender smsSender;
    private PushNotificationSender pushSender;
    
    public NotificationService(
        EmailSender emailSender,
        SmsSender smsSender,
        PushNotificationSender pushSender) {
        this.emailSender = emailSender;
        this.smsSender = smsSender;
        this.pushSender = pushSender;
    }
    
    public void notifyUser(User user, String message) {
        if (user.prefersEmail()) {
            emailSender.send(user.getEmail(), message);
        }
        if (user.prefersSms()) {
            smsSender.send(user.getPhone(), message);
        }
        if (user.prefersPush()) {
            pushSender.send(user.getPushToken(), message);
        }
    }
}

Вывод

Композиция обычно предпочтительнее наследования для большинства случаев благодаря гибкости и снижению связанности. Однако, если есть чёткое отношение "is-a" и стабильная иерархия, наследование может быть уместно. Лучший подход — начинать с композиции и использовать наследование только когда это действительно имеет смысл.