Состав объектов

Question

У меня есть класс, который действует как менеджер и выполняет некоторую работу. Сервлет, который запускается при запуске сервера приложений, создает экземпляр этого менеджера. Мне нужно добавить еще один класс, который будет выполнять другую работу, и должен координировать свои действия с менеджером. Я думал о добавлении класса к менеджеру в качестве переменной экземпляра. Должен ли я сделать, чтобы менеджер создал новый класс (как в конструкторе), или чтобы сервлет создал новый класс и вызвал manager.setNewClass () после того, как был создан менеджер?

Answer 1

Ну, как грубое обобщение, вы должны создать его экземпляр в сервлете и передать его в менеджер (либо с помощью параметра конструктора, либо с помощью setNewClass()) ... Внедрить зависимости, а не жесткий код их.

Однако, в зависимости от вашего конкретного случая использования, даже это может быть неправильным ответом. Возможно, вам лучше использовать Builder для создания класса менеджера. Таким образом, компоновщик управляет построением всего менеджера (включая любые зависимости), а не жестко программирует его в сервлете. Это переместит зависимость из сервлета в компоновщик (с которым вы можете лучше справиться в тестах и ​​другом коде).

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

Answer 2

Это напоминает мне шаблон FFF .

Неважно, где вы создаете экземпляр. Просто создайте там, где вам больше нравится, и, если вам это нужно, где-то еще, просто примените базовый рефакторинг.

Если вам действительно нужна развязка, попробуйте использовать какой-нибудь инструмент, например Guice , но только если он вам действительно нужен.

Answer 3

Вы должны сделать последнее - это отделяет менеджера от его делегата. Чтобы сделать разделение правильно, вы должны создать интерфейс, который определяет поведение, которое ожидает менеджер, а затем предоставить реализацию посредством инверсии управления / внедрения зависимостей. Это позволит вам протестировать менеджер и его рабочий класс (я назвал его делегатом, но это может быть не так) в изоляции.

РЕДАКТИРОВАТЬ - этот ответ предполагает Java, потому что вы упомянули сервлет.

У вас есть класс менеджера, в нем вы ожидаете интерфейс

class Manager {
    Worker worker;

    Manager(Worker worker) {
        this.worker = workder
    }
}

Рабочий - это интерфейс. Он определяет поведение, но не реализацию

interface Worker {
    public void doesSomething(); //method definition but  no implementation
}

Теперь вам нужно создать реализацию

class WorkerImpl implements Worker {
    // must define a doesSomething() implementation
}

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