Refactoring: comportamento delle classi di utilità in un'interfaccia comune

Question

Refactoring: comportamento delle classi di utilità in un'interfaccia comune

#1 da (2 voti)
#2 da (1 voti)
#3 da (1 voti)

1

Mi è stato suggerito di inserire la domanda qui, quindi sto facendo così;)

Ho bisogno di un'interfaccia comune che rappresenti un comportamento specifico:

public interface Contract(){
   public void methodA();
   public void methodB();
   // and so on...
}

Il problema è che, per soddisfare questo comportamento, l'implementazione può essere totalmente senza stato: può avere un costruttore privato ed esporre solo metodi statici:

public class MyUtilityClass /*implements Contract*/{
   private MyUtilityClass(){}
   public static void methodA(){
      // some implementation here...
   }
   public static void methodB(){
      // some implementation here...
   }
}

Ho molte di queste classi, con un comportamento diverso, quindi voglio refactoring e gestire sotto un'interfaccia comune.

Poiché non posso implementare Contract con metodi statici, è l'unica soluzione per convertire MyUtilityClass in un singleton che implementa l'interfaccia per raggiungere il mio obiettivo? O forse suggeriresti qualcos'altro? Ad esempio Metodo modello e Strategia che possono essere iniettati a seconda di una situazione specifica?

Che cosa proponesti?

refactoring interfaces static-methods polymorphism utilities

posta guitar_freak 29.01.2014 - 11:20

fonte

3 risposte

Leggi altre domande sui tag refactoring interfaces static-methods polymorphism utilities

Leggibilità vs benefici del polimorfismo Metodi di test unitari con dipendenze logiche su altre classi

score 2 · Answer 1

it can have a private constructor and expose only static methods

Sì, può , ma non c'è bisogno di per tecnici. Quindi (oltre ad altri buoni suggerimenti qui) dovresti considerare anche la soluzione più semplice per il tuo problema, solo per abbandonare la parola chiave "statica".

score 1 · Answer 2

Il singleton è uno schema creativo, ed è solo su quante istanze di una particolare classe esistono, non su come vengono utilizzate. Creando singleton risolvi il problema di eliminare i metodi statici e quindi puoi introdurre la tua interfaccia comune. Questa è la soluzione del tuo problema.

Nel momento in cui tutte le tue classi implementano un'interfaccia comune dovresti fare riferimento a loro usando l'astrazione. Quindi, potresti voler utilizzare un modello di strategia e scambiare a runtime la particolare implementazione da utilizzare. La strategia è un modello comportamentale, e secondo me non ha nulla a che fare con il tuo problema.

score 1 · Answer 3

All'interno della classe di utilità:

private static final Contract CONTRACT = new Contract() { // implement methods };

Ora puoi avvolgere i suoi metodi o restituire quell'istanza e usarne direttamente i metodi, dipende da te.

Modifica Un'altra idea mi è passata per la testa: anche i singleton possono essere creati usando le enumerazioni. E le enumerazioni possono implementare le interfacce!