Motivazione
Lascia un progetto in cui ...
... esiste un comportamento molto diverso. Per ogni comportamento, c'è un'interfaccia che ha le sue possibili azioni. Un oggetto potrebbe comportarsi in modo molto diverso.
Normalmente, un collaboratore "A" si preoccupa solo dell'interfaccia "I" di un oggetto specifico.
Quindi, come evitare che un oggetto implementi molti ruoli.
Esempio:
public class MyComplexObject implements Closeable, Reliable, Trustable, Treable, Moveable { ...}
Perché preoccuparsi?
Composition risolve il problema. Ma solo parzialmente. In Java, l'oggetto di destinazione dovrà ancora delegare le chiamate ai problemi per l'implementazione di destinazione. Sebbene sia un'implementazione senza cervello, non è comodo quando l'elenco dei ruoli è superiore a 5.
L'ereditarietà (oltre le interfacce) non migliorerà le cose.
Supponiamo 6 diverse interfacce (ogni interfaccia con 5 metodi). Per ora, semplificiamo e immaginiamo un'implementazione predefinita per queste interfacce. Ora, supponiamo che un insieme di oggetti più complessi possa implementare da una a sei di queste interfacce. Significa 2 ^ 6 = 64 diverse combinazioni possibili. Inoltre, una lunga lista di interfacce significa una lunga lista di metodi interni.
È chiaro che l'ereditarietà, utilizzando una BaseImplementation, non ha senso in questo caso.
Esempi:
public class MyComplexObject1 implements Closeable, Reliable, Trustable, Treable, Moveable { ...}
public class MyComplexObject2 implements Reliable, Treable, Moveable { ...}
public class MyComplexObject3 implements Reliable, Trustable, Moveable { ...}
public class MyComplexObject4 implements Closeable, Trustable, Treable { ...}
Non sto chiedendo un proiettile d'argento
"Essere scettici", "evitare la complessità", naturalmente, quelle cose vanno bene. Tuttavia, troppo generale. Questo problema si verifica quando una lunga lista di ruoli fa male. Quindi questo è uno scenario d'angolo e non un problema mainstream.
Cosa non significa scenario non realistico. C'è un progetto che usa un'idea che potrebbe essere usata per risolvere quel problema.
Netbeans, che ha il concetto di cookie
EditorCookie ec = activatedNodes[0].getLookup().lookup(EditorCookie.class);
A cookie is a capability and cookies are a powerful feature of NetBeans. With a Java interface, your object's capabilities are fixed at compile time, while NetBeans cookies allow your object to behave dynamically because your object can expose capabilities, or not, based on its state.
Come implementare i cookie
public class MyComplexObject {
private Map<Class<?>, ?> adapters;
public <T> T getAdapterIfApplicable(Class<T> t){
return (T) adapters.get(t);
}
public MyComplexObject add(Class<T> aClass, T t){
adapters(aClass, t);
t.setTarget(this);
}
...
}
...
public CloseableAdapter implements Adapter{
void setTarget(Object target){
this.target = target;
}
}
...
new MyComplexObject().add(CloseableAdapter.class, aCloseAdapter);