Шаблон проектирования для улучшения существующей структуры данных в Java с помощью дополнительной информации во время выполнения

Question

Начну с небольшого примера:

Представьте себе приложение с несколькими объектами.

EntityA -1 --- n-> EntityB -1 --- n-> EntityC

Допустим, у нас есть сервисный метод, который возвращает список экземпляров EnityC. В пользовательском интерфейсе мы хотим отобразить EntityC, но также добавить к объекту некоторую дополнительную информацию, которая имеет отношение только к пользовательскому интерфейсу (может быть, класс css или около того). Распространенным способом решения этой проблемы является создание оболочки EntityC, которая также может содержать дополнительную информацию.

public class EntityCWrapper implements EntityC, AdditionalInfo { ...}

или, возможно, использовать объект переноса в качестве простой структуры данных:

public EntityTO {
  public EntityC entity;
  public AdditionalInfo info;
}

Но что, если служба возвращает список экземпляров EnitityA и нам нужно присоединить AdditionalInfo ко всем сущностям в графе экземпляров (включая экземпляры сущностей, на которые ссылаются EntityB и EntityC)?

Кто-нибудь имеет идею или может указать мне шаблон дизайна, подходящий в этой ситуации?

Answer 1

Взгляните на образец объекта роли .

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

Answer 2

Таким образом, ваша модель данных, по сути, от 1 до n, использует следующий объект в качестве примера (может быть, надуманный)

class Thing  
{  
   Collection<DooDad> dooDads;
}    

class DooDad  
{  
   Collection<DooDadDetail> details;  
}  

class DooDadDetail  
{  
   ... 
}  

Так что я бы отнесся к этому как к своей модели с точки зрения n-уровневой архитектуры, и поэтому он должен точно отображаться в моей базе данных. В результате вы хотите, чтобы ваша модель что-то делала, что бы это ни было. Поэтому вы должны создать объект, состоящий из Thing, который может взаимодействовать с бизнес-логикой или внешними сервисами. Создание объекта переноса в этом случае будет правильным, так как оно гарантирует, что ваша модель остается действительной и что интерфейсы между вами и внешним сервисом не зависят от вашей модели. Это своего рода шаблон Фасада и Объект Передачи Данных.

Answer 3

Предполагая, что AdditionalInfo является специфичным для экземпляра (то есть каждый экземпляр EntityC имеет уникальное отношение 121 к экземпляру AdditionalInfo), лучшим вариантом будет расширение определения EntityC для включения в него AdditionalInfo как члена / ..., который не является обязательным и заполнен вами.

Если у вас нет контроля над EntityC, то между двумя опциями, которые вы указали, я бы сказал, что TransferObject выглядит лучше. Вам не нужно будет создавать новые объекты (из EntityC) таким образом.