2014-07-25 5 views
5

Si supponga di aver definito l'interfaccia ISomeInterface con i metodi foo e bar.
E.g.Come gestite quando l'implementazione per un metodo di interfaccia è la stessa per alcune classi?

Diciamo che ho le classi A e B che per loro ha senso sia implementare l'interfaccia. Ma non ha senso avere un'implementazione diversa per foo().
Tenendo conto che derivare A da B o B da A è errato/strano c'è una pratica di codifica standard per questo progetto?
presumo ho potuto creare qualche classe utilità per implementare foo() e chiamarlo come delegato, ma mi chiedevo se tutta questa struttura può essere trattata in modo diverso

Aggiornamento:
Per dare una piena comprensione della mia domanda mi sono imbattuto in questo: http://perlbuzz.com/2010/07/why-roles-in-perl-are-awesome.html e stavo cercando di capire se questa funzione viene a mancare dai tradizionali concetti OO, come li usiamo in Java o no

+2

Perché non fai la tua interfaccia con una classe astratta e fornisci una implzione per foo()? – Seb

+0

Se sei in Java8, potresti fornire una [implementazione predefinita nell'interfaccia] (http://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html) o potresti sempre seguire il manifesto agile e optare per una relazione has-A creando un collaboratore in grado di eseguire la funzionalità. A e B avrebbero una relazione is-A con l'interfaccia e una relazione has-A con il collaboratore. –

+0

@Dan Temple: vedere l'aggiornamento – Jim

risposta

1

deciso di trasformare il mio commento in una risposta:

Si potrebbe utilizzare una classe astratta anziché un'interfaccia:

public abstract class FooBar { 
     public void foo(){ 
     //your implementation goes here 
     } 

     abstract void bar(); 
    } 

    public class A extends FooBar{ 

     @Override 
     public void bar(){ 

     } 
    } 
1

Perché non qualcosa di simile:

public class abstract SomeAbstractClass { 
    public void foo(){ 
     //implementation 
    } 
    public abstract void bar(); 
} 

class A extends SomeAbstractClass { 

} 

class B extends SomeAbstractClass { 

} 
1
public abstract class SomeClass implements ISomeInterface { 
    public void foo() { 
     // I do stuff.. 
    } 
} 

public class A extends SomeClass { 
    public void bar() { 
     // A specific impl. of bar.. 
    } 
} 

public class B extends SomeClass { 
    public void bar() { 
     // B specific impl. of bar.. 
    } 
} 
1

In alternativa, se non si vuole A e B per essere legato estendendo una classe astratta puoi semplicemente usare la composizione. Ciò fornisce anche la flessibilità di modificare il comportamento di IFoo in fase di esecuzione se si immette lo FooImpl come parte del costruttore. In questo esempio ho appena cablato il FooImpl per brevità.

public class B implements ISomeInterface { 

    private IFoo foo = new FooImpl(); 

    public void foo() { 
     foo.doSomethingFooey(); 
    } 

    public void bar() { 
     // B specific implementation   
    } 
} 

public class A implements ISomeInterface { 

    private IFoo foo = new FooImpl(); 

    public void foo() { 
     foo.doSomethingFooey(); 
    } 

    public void bar() { 
     // A specific implementation 
    } 
} 
+0

Vedere l'aggiornamento in OP – Jim

+0

Si implementeranno interfacce aggiuntive e forniremo classi di supporto simili a "IFoo + FooImpl' (mostrato sopra) che conterrà l'implementazione per il comportamento richiesto – Brad

+0

Ciò significa che questa funzione è necessaria e manca? Perché dal tuo suggerimento avrei bisogno di scrivere una nuova gerarchia di classi di helper – Jim

4

La modifica suggerisce che la vostra vera domanda è: "c'è un equivalente per i ruoli Perl in Java"

Poiché Java 8 ha introdotto i metodi default nelle interfacce, le interfacce con i metodi predefiniti sembrano un ottimo equivalente per i ruoli. In particolare, si può fare quello che vuoi nel tuo esempio: fornire un'implementazione di default per foo():

interface ISomeInterface { 
    public default void foo(){ /* your default impl goes here */} 
    public void bar(); // Abstract, must be implemented by subclasses 
} 

class A implements ISomeInterface { 
    // must only implement bar, can reuse foo's default impl 
} 

class B implements ISomeInterface { 
    // must only implement bar, can reuse foo's default impl 
} 

Se c'è una caratteristica di ruoli che mi manca per favore fatemelo sapere. Altrimenti, penso che le interfacce Java8 siano un surrogato abbastanza buono per i ruoli.

+0

Sei corretto. La mia preoccupazione principale è che ad essere onesti non vedo alcun bisogno di "ruoli". Quindi mi stavo chiedendo se questa è una mancanza di OO mentre la usiamo in Java – Jim

+0

@Jim: Per essere onesti, i ruoli sembrano molto simili ai soliti tratti (cioè interfacce con l'implementazione) per me. Gli autori che sostengono i ruoli come qualcosa di completamente diverso cercano semplicemente di dare loro un "look and feel" ma nel loro nucleo, non vedo alcuna differenza per il solito multi-eredità ... – gexicide