Агрегировать объект с вложенностью - PullRequest
Новая
       4

Агрегировать объект с вложенностью

2 голосов
/ 18 февраля 2012

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

Теперь, когда я хочу добавить запись вождения, я говорю addRecord(Double distance, ...) на объекте DrivingLog.Однако является ли DrivingRecord агрегатом для классов Condition и Environment или они являются только ссылками?Состояние и окружающая среда не имеют значения вне одного DrivingRecord.

Состояние и среда - это статические данные: пользователь будет выбирать среди предопределенных значений в раскрывающемся списке в представлении JSF.Но если DrivingRecord является агрегатом, он должен иметь метод с именем addEnviroment().Должно ли это принимать класс Enviroment в качестве аргумента?

Если в этом случае DrivingLog будет иметь метод с именем addRecord(Double distance, Environment environment...)?

И, наконец, разве среда и условия не должны быть «скрыты» совокупным корнем и никогда не должны быть доступны извне.Это заставляет меня задуматься о том, действительно ли DrivingRecord также является агрегированным корнем.

Допускается ли даже вложение агрегатов, что в некоторых случаях является плохой практикой?

enter image description here

1 Ответ

1 голос
/ 18 февраля 2012

когда я хочу добавить запись вождения, я говорю addRecord (Двойное расстояние, ...)

Вместо этого я бы предложил addRecord(DrivingRecord record) в качестве API для вашего сервиса.

является ли DrivingRecord агрегатом для класса Condition и Environment или они являются только ссылками? Условие и окружающая среда не имеют значения вне одного DrivingRecord.

Я не уверен, что следую терминологии, как вы могли бы сказать, но я думаю, что оба ответа верны - DrivingRecord является агрегатом (я полагаю, «указывающим на группу объектов»), но также и ссылкой (как любой объект "Гендель" в Java считается ссылкой). Суть в том, что он передается не как двоичный объект, а как 4-байтовые ссылки на кучную память, если вы создали его с помощью «нового XYZ» (или стека, если это примитив, который передается в качестве аргумента методу). И он не будет собирать мусор, если на него ссылается живой объект.

Состояние и среда - это статические данные: пользователь будет выбирать среди предопределенных значений в раскрывающемся списке в представлении JSF. Но если DrivingRecord является агрегатом, он должен иметь метод с именем addEnviroment (). Должно ли это принимать класс Enviroment в качестве аргумента?

после создания экземпляра DrivingRecord вам нужно разрешить вставку ссылок на List.

Если бы в этом случае у DrivingLog был метод с именем addRecord (Double distance, Environment environment ...)?

Я не знаю, связаны ли параметры друг с другом, но если они могут быть добавлены отдельно, я бы предложил что-то вроде этого: 

class DrivingRecord {
   private ArrayList<Enviroment> env;
   private ArrayList<Condition> cond;
   private Double distance;
   addEnvironment(Enviroment e) { env.add(e); }
   addCondition(Condition c) { cond.add(c); }
   setDistance(Double d) { distance=d;}
}

И, наконец, разве среда и условия не должны быть "скрыты" совокупным корнем и никогда не должны быть доступны извне. Это заставляет меня задуматься о том, действительно ли DrivingRecord является агрегированным корнем.

уверен

Разрешено ли вложение агрегатов, плохая практика, хорошо в некоторых случаях?

Зная очень мало о целях вашего проекта, я не могу сказать, есть ли лучшая архитектура. Но это, конечно, неплохая практика.

...