Dovremmo "preferire la composizione su più interfacce"?

Question

Dovremmo "preferire la composizione su più interfacce"?

#1 da (10 voti)

1

Dovremmo evitare l'interfaccia multipla se possibile? Poiché penso che nella maggior parte dei casi una classe con più interfacce possa essere sostituita con un'altra versione con composizione e unica interfaccia, ad esempio:

interfaccia multipla:

public class C implements A,B{
    @Override
    public void a(){
    }
    public void b(){
    }
}

composizione e singola interfaccia:

public class ConcreteA implements A{
    @Override
    public void a(){
    }
}

public class ConcreteB implements B{
    @Override
    public void b(){
    }
}

public class C{
    ConcreteA a;
    ConcreteB b;
}

e se 2 interfacce hanno parti comuni, posso separare le parti comuni dalla classe originale:

interfaccia multipla:

public class C implements A,B{
    @Override
    public void a(){
    }

    @Override
    public void b(){
        a();
    }
}

composizione e singola interfaccia:

public class ConcreteA implements A{
    @Override
    public void a(){
    }
}
public class C implements B{
   ConcreteA a;
   @Override
   public void b(){
       a.a();
   }
}

E persino implementare serializzabile:

public class C implements A,Serializable{
    String name;
    int userId;
    @Override
    public void a(){
    }
}

In realtà posso racchiudere la parte Serializable in una nuova classe:

public class CData implements Serializable{
    public String name;
    public int userId;
} 

public class C{
    public CData;
    public ConcreteA a;
}

Quindi la mia domanda è, dovremmo preferire la composizione su un'interfaccia multipla, vale a dire: limitare la classe per implementare al massimo una sola interfaccia, proprio come preferisce la composizione sull'ereditarietà, se possibile?

object-oriented interfaces composition

posta ggrr 13.07.2016 - 08:49

fonte

1 risposta

Leggi altre domande sui tag object-oriented interfaces composition

C'è qualche situazione in cui vi è una buona ragione per usare un ancoraggio un elemento senza un attributo href? node.js Addons C ++ per fare tutti i principali calcoli [chiuso]

score 10 · Accepted Answer

Non è davvero una questione su quale sia il preferito. Sono diverse soluzioni a diversi problemi.

Lo faresti se un C è un A e un B :

public class C implements A, B { ... }

Lo faresti se un C condivide parte del comportamento di A e B , ma non è un A o a B :

public class C {
    private A a;
    private B b;
}

Questa decisione dovrebbe essere basata su ciò che le classi rappresentano concettualmente, non sulla nozione di quale approccio sia "migliore".

Tuttavia, l'implementazione di molte interfacce suggerisce con forza l' interfaccia bloat anti-pattern, che è una violazione di principio di responsabilità singola . Una buona regola è che se non puoi descrivere cosa fa la classe senza usare la parola "e", stai violando lo SRP.