Best way to write pojos that can have common fields

Question

I am currently making a service in which there are lots of public API's. And the response and request objects overlap a lot. So, I was thinking that is there a way by which we can generalise the pojo creation for the request/response objects. Sometimes the response object is identical to the request object with one or two extra fields.

Let me give you an example.

@Data
public class Request {
    private A objA;
    private B objB;
}

@Data
public class Response {
    private A objA;
    private B objB;
    private C objC;
}

@Data
public class A {
    private D objD;
}

@Data
public class B {
    private String sB; 
    private E obje;
}

@Data
public class C {
    private String sC;
}

---

Similary, D and E are pojos as well. The thing is that there is a lot of similarity(overlapping fields) in request/response objects.

Answer 1

Your solution is probably inheritance: Create a parent abstract object type with the overlapping fields and have the request and response objects extend it and specify any extra (unique) fields they need.

Inheritence

public abstract class Common {
  private String overlapfield1;
  private String overlapfield2
}

public class Request extends Common {
  private String requestField1;
  private String requestField2;
}

public class Response extends Common {
  private String responseField1;
  private String responseField2;
}

You could also approach this using composition: Create an object type with the overlapping fields and include this object as a sub-object of the Request/Response types:

Composition

public class Common {
  private String overlapfield1;
  private String overlapfield2
}

public class Request {
  private String requestField1;
  private String requestField2;
  private Common common;
}

public class Response {
  private String responseField1;
  private String responseField2;
  private Common common;
}

There are pros and cons to each approach which are widely discussed on this and other boards. These however, are the two standard approaches to dealing with such a problem.