CODEWITHSUNDEEP
javaoopdesign-patterns
sprehn
sprehn

Reputation: 53

Design pattern to enhance an existing data structure in Java with additional information at runtime

I will start with a small example:

Imagine an application with a couple of entities.

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

Let's say we have a service method that returns a list of EnityC instances. In the UI we want to display EntityC but also add some additional information to the entity that is only relevant for the UI (maybe a css class or so). A common way to solve this would be to create a wrapper arround EntityC that can also carry the additional information.

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

or maybe use a transfer object as simple data structure:

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

But what if the service returns a list of EnitityA instances and we need to attach AdditionalInfo to all entities in the instance graph (including the referenced entity instances of EntityB and EntityC)?

Does anyone have an idea or can point me to a design pattern suitable in this situation?

Upvotes: 3

Views: 2032

Answers (3)

Ralph
Ralph

Reputation: 120831

Have a look at the Role Object Pattern.

It descripes how an object can be extended with different stuff (called Roles). The pattern is more about how to add Bussiness Logic (that is why it is called roles) but may the idea helps you.

Upvotes: 1

Woot4Moo
Woot4Moo

Reputation: 24336

So your data model is essentially 1 to n using the following object as an example (contrived as it may be) 

class Thing  
{  
   Collection<DooDad> dooDads;
}    

class DooDad  
{  
   Collection<DooDadDetail> details;  
}  

class DooDadDetail  
{  
   ... 
}

So I would treat this as my model, in terms of n-tier architecture and therefore this should map back to my database exactly. What comes up is you want your model to do something, whatever that may be. So you should create an object that is composed of Thing that can interact with business logic or outside services. Creating a transfer object would be correct in this case as it ensures your model remains valid and that the interfaces between both you and the outside service are not dependant on your model. It is sort of a Facade pattern and a Data Transfer Object.

Upvotes: 0

Kashyap
Kashyap

Reputation: 17476

Assuming AdditionalInfo is instance specific (i.e. each instance of EntityC has a unique 121 relation to an AdditionalInfo instance) best option would be to enhance EntityC definition to include AdditionalInfo inside it as member/..., which is optional and filled up by you.

If you don't have control over EntityC then between teh two options you have given, I would say TransferObject seems better. You won't have to create new objects (of EntityC) that way.

Upvotes: 0

Related Questions