Non è una cattiva pratica in sé e per sé. A volte ci sono dei motivi per farlo. Ma è un indicatore che le tue classi potrebbero non essere correlate come sembrano.
Solo perché entrambe le classi hanno un campo dello stesso tipo non significa che dovrebbero implementare la stessa interfaccia. La domanda è: sono entrambi casi specifici di un concetto comune e significativo? (Con il quale intendo diverso da "l'oggetto con un concetto di campo BigDecimal ").
Se non esiste un concetto del genere, non dovrebbe esserci un'interfaccia di questo tipo. Tieni presente che può trattarsi di un concetto di dominio aziendale o di un concetto tecnico (come Serializable ), ma in base al nome presumo che non sia un concetto tecnico.
Pensa al nome del metodo e vedi se riesci a trovarne uno che abbia senso per entrambe le classi. Se non puoi, è un primo suggerimento che potrebbe non esserci un concetto del genere. Eccezione: è un fatto noto del dominio aziendale che ci sono termini diversi per la stessa cosa.
Hai algoritmi che funzionano con entrambe le classi (cioè che usi solo l'interfaccia ma non sai quale classe sia)? Utilizzi effettivamente questi algoritmi per entrambe le classi? In caso contrario, questo è un altro segno che non sono correlati.
È RequestAmountHolder (o qualsiasi altra cosa che viene chiamata l'interfaccia) un concetto nel tuo dominio aziendale? In altre parole, un utente vedrebbe le due classi come casi speciali di cose che hanno un importo? O il tuo utente lo considererebbe uno strano modo di parlare di una richiesta di prestito (per esempio)?
Per quanto riguarda le alternative, dipende molto dal resto della tua applicazione. Ma se scopri che non esiste un concetto comune per le classi, eppure hai un sacco di algoritmi che funzionano con i metodi get / set, senza sapere nient'altro sulle classi, è possibile che queste operazioni siano davvero metodi di una Amount class.