multiple getters for some fields

Question

I have 2 DTO which have equivalent fields so what I did is I make them implement one interface to treat them same way as a type of interface (avoid duplication) so I put in the interface some Getters and Setters that I need to do the business logic.

However, as the fields have differents names but their content is the same

(eg. requestAmount in first Class is loanAmount in the second)

what I did is just to override the interface getters with a new getter that call the other one just to adapt it to the interface So my POJO end up with multiple getters for some fields.

This way :

public void setRequestAmount(BigDecimal amount)
{
    setLoanAmount(amount);
}

@Override
public BigDecimal getRequestAmount()
{
    return getLoanAmount();
}

Is this a bad practice ? is there any other solution ?

Answer 1

It's not bad practice in and of itself. There are sometimes reasons to do this. But it is an indicator that your classes may not be as related as they seem.

Just because both classes have a field of the same type does not mean that they should implement the same interface. The question is, are they both specific cases of a common, meaningful concept? (By which I mean other than the "object with a BigDecimal field concept").

If there is no such concept, there should be no such interface. Note that it can be a business domain concept or a technical concept (such as Serializable), but based on the name I'll assume it's not a technical concept.

Think about the method name, and see if you can find one that makes sense for both classes. If you can't, that's a first hint that there may be no such concept. Exception: it's a known fact of the business domain that there are different terms for the same thing.

Do you have algorithms that work with both classes (i.e. that only use the interface but don't know which class it is)? Do you actually use these algorithms for both classes? If not, that's another sign that they are not related.

Is RequestAmountHolder (or whatever you interface is called) a concept in your business domain? In other words, would a user see the two classes as special cases of things that have an amount? Or would your user consider this a strange way to speak about a loan application (for example)?

As for alternatives, it depends a lot on the rest of your application. But if you find that there is no common concept for the classes, yet you have a bunch of algorithms that work with the get/set methods, without knowing anything else about the classes, it's possible that these operations really should be methods of an Amount class.

Answer 2

I think that your need may be covered by the Adapter design pattern.

For example, this may help to expose the same interface to the rest of your program by writing adapters of your two base classes.