04.12.2024 04:32
badcasedaily1 0 886 Источник

Привет, Хабр!

Однажды передо мной вырос, как снежный ком, чудовищный God Object — класс, который хотел быть всем сразу. У него была и бизнес‑логика, и данные, и контроллеры, и, кажется, даже немного души. Вдохновленный этой катастрофой, решил поделиться несколькими способами, как избежать этого монстра.

Что такое God Object?

Это такой класс в Java (да и в других языках тоже), который «знает все» и «умеет все». Но в реальности это антипаттерн, который убивает читаемость кода, затрудняет рефакторинг и превращает архитектуру в ад.

Пример:

public class GodObject {
    private Map<String, Object> data = new HashMap<>();
    
    public void addData(String key, Object value) {
        data.put(key, value);
    }
    
    public Object getData(String key) {
        return data.get(key);
    }
    
    public void processBusinessLogic() {
        // Сложная логика здесь...
        System.out.println("Processing...");
    }
    
    public void renderUI() {
        // Генерация UI
        System.out.println("Rendering UI...");
    }
    
    public void handleRequests() {
        // Контроллер
        System.out.println("Handling requests...");
    }
}

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

Как избежать создания God Object?

Во первых God Object сам по себе часто появляется из‑за стремления сделать все «на скорую руку» на ранних этапах разработки, когда кажется, что такой подход ускорит процесс. Отсутствие проектирования архитектуры и четких границ ответственности между классами только усугубляет ситуацию, превращая центральный класс в монстра, который берет на себя все подряд. Желание централизовать логику, чтобы якобы упростить понимание кода, на деле приводит к хаосу и неподдерживаемому нагромождению функциональности. Лень или страх рефакторинга закрепляют проблему: ведь разбираться в большом куске кода, который «и так работает», кажется более сложной задачей, чем оставить все как есть.

Поэтому рассмотрим пару способов, которые помогут на раннем этапе избежать таких проблем.

Принцип единственной ответственности

Старая, как мир, мантра из SOLID: «Класс должен иметь только одну причину для изменения». Если в одном классе у вас и данные, и бизнес‑логика, и представление — вы нарушаете этот принцип.

Разделите ответственность:

public class UserData {
    private String name;
    private int age;
    
    // Геттеры и сеттеры
}

public class UserService {
    public void processBusinessLogic(UserData user) {
        // Логика работы с данными пользователя
        System.out.println("Processing user data...");
    }
}

public class UserController {
    private final UserService userService;

    public UserController(UserService userService) {
        this.userService = userService;
    }

    public void handleRequest() {
        UserData user = new UserData();
        user.setName("Ivan");
        user.setAge(30);
        
        userService.processBusinessLogic(user);
    }
}

Вот так гораздо лучше: данные в UserData, бизнес‑логика в UserService, управление запросами в UserController. Каждый класс четко знает своё место в жизни.

Интерфейсы и абстракции

Пусть каждый класс взаимодействует с другими через интерфейсы. Это позволит легко изменять реализацию, не боясь нарушить что‑то в другом месте.

Пример:

public interface Storage {
    void saveData(String key, String value);
    String getData(String key);
}

public class DatabaseStorage implements Storage {
    private final Map<String, String> database = new HashMap<>();
    
    @Override
    public void saveData(String key, String value) {
        database.put(key, value);
    }

    @Override
    public String getData(String key) {
        return database.get(key);
    }
}

Теперь можно легко подменить DatabaseStorage на, скажем, FileStorage, не трогая остальной код.

Слой сервисов и DTO

Если ваш класс начинает раздуваться из‑за передачи данных между слоями, используйте Data Transfer Objects. Это простые объекты, которые содержат только данные и ничего больше.

Пример:

public class UserDTO {
    private String name;
    private int age;
    
    // Геттеры и сеттеры
}

public class UserMapper {
    public static UserDTO toDTO(UserData userData) {
        UserDTO dto = new UserDTO();
        dto.setName(userData.getName());
        dto.setAge(userData.getAge());
        return dto;
    }
}

Так можно легко адаптировать данные к любому слою.

Модули и пакеты

Не пытайтесь запихнуть все классы в один пакет. Разделяйте их по модулям: data, service, controller и так далее. Это поможет лучше структурировать проект.

Domain-Driven Design

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

К примеру:

  • Aggregate Root: основной объект, который управляет связанными данными и правилами.

  • Value Objects: неприменяемые данные, которые неизменны.

  • Entities: объекты с уникальными идентификаторами.

Пример кода:

public class Order {
    private final String orderId;
    private final List<OrderItem> items = new ArrayList<>();

    public Order(String orderId) {
        this.orderId = orderId;
    }

    public void addItem(OrderItem item) {
        items.add(item);
    }

    public BigDecimal calculateTotal() {
        return items.stream()
                .map(OrderItem::getPrice)
                .reduce(BigDecimal.ZERO, BigDecimal::add);
    }
}

public class OrderItem {
    private final String productId;
    private final BigDecimal price;

    public OrderItem(String productId, BigDecimal price) {
        this.productId = productId;
        this.price = price;
    }

    public BigDecimal getPrice() {
        return price;
    }
}

А что, если God Object уже существует?

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

Постепенная декомпозиция. Разбейте монстра на небольшие классы. Начните с выделения самых очевидных модулей.

Тесты. Перед любым рефакторингом пишите тесты. God Object — это бомба замедленного действия, поэтому убедитесь, что ничего не сломается.

Старая добрая стратегия «Strangler Fig». Создайте новые классы, которые постепенно заменят функциональность God Object. Со временем наш «монстр» уменьшится до приемлемого состояния.

Заключение

Итак, если у вас в проекте завелся God Object, не ждите, пока он начнет разрушать вашу архитектуру. Разделяйте ответственность, используйте интерфейсы, вводите слои DTO и не забывайте про модули. Да, рефакторинг — это сложно и больно, но результат того стоит.

А как вы справлялись с такой проблемой? Делитесь в комментариях.

В завершение напомню, что в декабре по Java-разработке пройдут три открытых урока:

5 декабря: Разрабатываем Kafka-appender для логгера. Подробнее
10 декабря: Observability в Java-приложениях. Подробнее
19 декабря: Знакомство с Resilience4j. Подробнее

Комментарии (0)