Простые объекты - каков правильный дизайн по принципам единой ответственности и инкапсуляции - PullRequest
Новая
       23

Простые объекты - каков правильный дизайн по принципам единой ответственности и инкапсуляции

0 голосов
/ 05 октября 2011

Я планирую простое приложение и хочу следовать принципам единой ответственности и инкапсуляции.

Основные игроки:

Класс API - который предоставляет возможность сохранения пользователя: 

class API{
    ....
    public void saveUser(id, name, address){
        //save the received user in the DB
    }
    ....
}

Класс DBConnector - предоставляет возможность сохранять пользовательские данные в БД.

Класс пользователя - который представляет пользователя.

По старинке метод saveUser будет выглядеть так: 

IDBConnector connector = DBConnectorFactory.getDBConnector();
User user = new User(id, name, address);
connector.saveUser(user);

По новым принципам кажется, что правильный путь будет: 

User user = new User(id, name, address, DBConnectorFactory.getDBConnector());
user.save();

Это правильно?

Должен ли пользователь обрабатывать сохранение БД?

Если нет, можете ли вы предложить лучший способ?

1 Ответ

0 голосов
/ 15 ноября 2011

Если ваш класс содержит данные (пользователя) и знает, как их сохранить, то он делает больше, чем одну вещь.Перефразируй.У этого есть больше чем одна причина измениться.Если база данных изменится, пользователь должен будет изменить (и все другие ваши постоянные бизнес-объекты)

Одно решение: 

public interface Persister {
    void persist(User user);
}

Часть базы данных вашего приложения будет реализовывать интерфейс какты набросал.Создание, если пользователь выполняется в части приложения.Этот пост также содержит интерфейс.Таким образом, ваше основное приложение отделено от постоянного уровня.Он ничего не знает об этом.Вместо этого ваша база данных «подключена».

(я знаю, что интерфейс, который мы назвали довольно глупо. Однако основная идея - разделение задач для выполнения единой ответственности)

...