Как правильно разработать архитектуру объекта и обслуживающих его сервисов?

Question

[a_halala]

Всем привет. Вопрос к опытным знатокам ООП дизайна. Представим простую систему, где есть клиент и сервис, обслуживающий его.

public interface ClientService {
    void disableClient(String id);

    void sendEmailToClientWithId(String id);
}

public class Client {
    private String id;
    private String username;
    private String email;
    private Boolean isActive = true; // конструктор и куча других полей
}

Надо продумать способ взаимодействия объекта и его сервиса. Допустим мы получаем все необходимые данные в контроллере и собираем через фабрику объект Client. Вот и вопрос: что лучше?
1. Сделать агрегацию сервиса и объекта и предоставить апи для изменения состояния этого объекта, например

public class Client {
    private String id;
    private String username;
    private String email;
    private Boolean isActive = true; 

    @Autowired
    private ClientService clientService;

    public void printWelcomeMessage() {
        System.out.println(String.format("Hello, %s!", username));
    }

    public void disableClient() {
        clientService.disableClient(this.id);
        this.isActive = false;
    }

    public void printClientStatus() {
        System.out.println(this.isActive? "Active" : "Inactive");
    }

    public void sendEmail() {
        clientService.sendEmailToClientWithId(this.email);
    }
}

2. Сделать сервис, с такими же методами, но в качестве параметра будет приходить сам Client (в котором, соответственно, будут геттеры/сеттеры)

Т.е. вопрос даже вот в чем: Правильно ли с точки зрения ооп и дизайна делегировать управление состоянием объекта внешним сервисам через геттеры/сеттеры? И какие подводные камни могут быть у каждого из мною предложенных вариантов?
Надеюсь, что мой вопрос ясен. Надеюсь на ответы, спасибо!

Answer 1

[Александр Косарев]

Второй вариант с точки зрения ООП однозначно правильнее. Ответ на вопрос: да, правильно.

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

Comments

[a_halala]

Спасибо за ответ! А как насчет мнения, что getters/setters это зло и их нужно избегать, ибо никто не должен быть ответственен за состояние объекта, кроме самого объекта?

[Александр Косарев]

a_halala: надо же, отголоски холиваров 2003 года) На самом деле тема "ущербность get/set" стара как этот мир (и неактуальна). Да и "факты" об ущербности весьма сомнительны. Как было где-то написано:
1. Худший вариант - свойства с открытым доступом
2. Вариант получше - get/set методы
3. Лучший вариант - get-методы для всех свойств, set-методы там, где это надо

Оригинальный пост: www.javaworld.com/article/2073723/core-java/why-ge...

Хороший ответ на эту тему: stackoverflow.com/questions/1568091/why-use-getter...