Interfaccia con più metodi predefiniti OR Interface + Class

Question

Interfaccia con più metodi predefiniti OR Interface + Class

#1 da (4 voti)

3

In una base di codice sono "a partire da" ci sono una manciata di interfacce con molti metodi predefiniti. Sembrano qualcosa del genere:

public interface HasXY {
   double getX();
   double getY();
   default double method1(double x, double y)  {...}
   default double method1(HasXY other)  {...}
   default double method2(double x, double y)  {...}
   default double method2(HasXY other)  {...}
   default double method3(double x, double y)  {...}
   default double method3(HasXY other)  {...}
   default double method4(double value)  {...}
   default double method5(double value)  {...}
}

In questo momento ho la possibilità di refactoring questo codice in un'interfaccia e una classe. Il risultato di questo refactor sarà simile a questo:

public interface HasXY {
    XYPosition getXY();
}

public class XYPosition {
   double method1(double x, double y)  {...}
   double method1(XYPosition other)  {...}
   double method2(double x, double y)  {...}
   double method2(XYPosition other)  {...}
   double method3(XYPosition other)  {...}
   double method4(double value)  {...}
   double method5(double value)  {...}
}

Devo notare che il code-base "source" ha diverse interfacce di questo tipo e molte classi implementano una manciata di queste interfacce (portando ad oggetti che hanno molti metodi). Sono anche in un momento unico nel tempo in cui fare questo refactoring sarà più semplice che mai.

Che cosa pensi di un simile refactoring? È una schiacciata "dovrebbe fare"? Pensi che sia una perdita di tempo? È effettivamente dannoso perché perde la sintassi di chiamare "myObject.methodFromOneOfSeveralDifferentInterfaces ()"

refactoring java interfaces single-responsibility

posta Ivan 13.09.2016 - 19:03

fonte

1 risposta

Leggi altre domande sui tag refactoring java interfaces single-responsibility

Funzione che funge da collegamento ai metodi dell'oggetto Dove si trova la logica per rispettare SRP qui?

score 4 · Accepted Answer

L'intenzione del refactoring è buona. Prende la verbosità dagli implementatori e raggruppa i metodi basati su XYPosition nella sua classe, in modo simile a ciò che facciamo con gli oggetti parametro per evitare funzioni con molti parametri. Ti stai attenendo al principio di segregazione dell'interfaccia che afferma che i clienti non dovrebbero conoscere i metodi che non hanno bisogno o che non usano.

Ma un'interfaccia (un'astrazione) non dovrebbe dipendere da una concrezione (una classe non astratta). Sia l'astrazione che le concrezioni dovrebbero dipendere dalle astrazioni. Questo è chiamato il principio di inversione delle dipendenze. Le cose che cambiano meno spesso (interfacce) non dovrebbero dipendere da cose che cambiano più spesso (implementazioni) ma viceversa. Quindi il mio suggerimento è di creare XYPosition un'interfaccia, quindi spostare l'implementazione su una classe concreta XYPosition (scegli un altro nome).