I have a model call Drug

class Drug{

String drugId;
String name;
String strength;

this interface takes a drugId and returns the Drug Model

interface IProcessor{
getDrug(String drugId)

// easy flow

class ProcessorA extends IProcessor{
protected Drug getDrug(String drugId){
  //get Drug from source A
  return Drug

// From source B, I will be getting additional fields. Am not sure how i can append the new fields to the drug Model

class ProcessorB extends IProcessor{
protected Drug getDrug(String drugId){
//get Drug from source B
// Add few more fields specific to B 
  return Drug

1) Extend the Drug model (class DrugB extends Drug) for ProcessorB and add the new fields. In this case, I might be ending up typecasting the DrugB. Is this ok?

2) Add the common fields to Drug Class and use it. This is fine, but number of fields for each type of processor could be increasing.

Is there any patterns I should be thinking of. Please advice.

  • 2
    You tagged the Visitor Pattern. Why don't you just use it? – JeffO Mar 29 '17 at 12:46
  • is that the only option. could you please post a code snippet for the above sample. I see lot of samples online, but i think i will understand better for the problem i face. Thank you – Prabhu shanmughapriyan Mar 29 '17 at 16:16
  • 1
    Patterns should be applied relative to your understanding and not used because many see them as a best practice. Experiment with a side project. – JeffO Mar 29 '17 at 22:37

If I understand right you are trying to append the fields to the Drug model object so this logically rules out the subclassing. If you would like to give a structure to the values returned by a processor then you can create a new structure DrugB and DrugC and make these structures as part of the original Drug object. This kind of segregation will make the ProcessorA to return a DrugA kind of object and ProcessorB to...and so on and so forth. So Drug class will have DrugB and DrugC as objects within it. This is one way of looking at it.

| improve this answer | |
  • That is a good option. But if I need to add new fields say DrugD,DrugE etc.. each time I have to change the Drug class to add the setters DrugD and DrugE. – Prabhu shanmughapriyan Mar 31 '17 at 12:02
  • DrugD and DrugE are not fields they are separate class structures that would come into existence when you have new processors returning a new section of information pertaining to the Drug schema – acearch Mar 31 '17 at 14:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.