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.