La sintassi per la composizione sarebbe un'utile aggiunta a Java? [chiuso]

Question

Prima di tutto, non so quasi nulla della teoria delle lingue e conosco a malapena altre lingue tranne Java, ma ho avuto un'idea che penso che sarebbe bello, ma ho bisogno che voi ragazzi mi dica:
a: perché fa schifo
b: come la lingua x lo usa da anni
c: come fa schifo la mia mente
d: tutto quanto sopra

L'idea darebbe alla composizione la stessa facilità di riutilizzo del codice che estende .

Quindi se hai avuto una lezione come questa:

public interface A {  
    public void methodInA();  
}

E poi hai avuto una lezione come questa:

public class B {  
    private composed A;
    public B() {
        // construct A within constructor
    }
}

Saresti quindi in grado di farlo:

B myB = new B();
myB.methodInA();

Senza dover aggiungere la delega nella classe B. Ma potresti anche fare lo stesso dell'ereditarietà, ovvero:

@Overrides
public void methodInA(){
    // B's own delegation method
}

Gli svantaggi includono:

• i metodi sono nascosti nel codice sorgente, rendendo meno ovvio da dove proviene la chiamata, ma questo è anche il caso di extends
• se i campi composti condividono la stessa firma del metodo, è necessario risolvere un conflitto (come possono risolverlo le interfacce in conflitto?)
• se si volessero avere più campi composti dello stesso tipo, ci sarebbe un evidente conflitto per il campo a cui delegare
• probabilmente altre 100 cose a cui non ho pensato

Come ho detto, ovviamente non sono un teorico del linguaggio, e non ho passato secoli a pensarci, l'idea mi è venuta in mente e volevo sapere quanto mi sbaglio. Penso solo che sarebbe bello.

Answer 1

Penso che se la limitassi in modo tale che una classe possa usare questa funzione solo per comporre una singola classe, sarebbe in qualche modo utile ed eviterebbe molti dei mal di testa che vengono discussi.

Personalmente odio l'eredità di classi concrete. Sono un grande sostenitore dell'articolo 14 di Java efficace , Favorisci composizione su eredità

Onestamente, se davvero sapessi cosa stavi facendo, scommetto che potresti scrivere un'annotazione del compilatore in grado di gestirlo. Quindi supponendo che tu avessi una barra di classe che implementasse l'interfaccia IBar, la tua classe sarebbe simile a questa:

public class Foo {

  @Delegate(IBar.class)
  private Bar bar;

  // initialize bar via constructor or setter
}

Quindi durante la compilazione Foo potrebbe essere realizzato per implementare IBar e uno qualsiasi dei metodi su quell'interfaccia che non erano già stati implementati da Foo sarebbe stato generato per assomigliare a questo:

public Baz method1(Qux val) {
  return bar.method1(val);
}

Come accennato in precedenza, si desidera limitare la possibilità che solo un campo per classe possa utilizzare questa annotazione. Se questa annotazione contiene più campi, probabilmente si vorrebbe generare un errore di compilazione. In alternativa, potresti trovare un modo per codificare una sorta di modello di precedenza nei parametri passati ad esso.

Ora che l'ho scritto sembra un po 'figo. Forse ci giocherò la settimana prossima. Lo aggiornerò se riesco a capire qualcosa.

Answer 2

Sembra bello, ma penso che crei alcuni orribili costrutti linguistici. Ovviamente c'è un problema se si dichiara più di una 'composizione' della stessa classe, ma anche se si proibisce che per quanto riguarda il caso in cui una chiamata corrisponde a un metodo in più di una delle (diverse) classi composte? Dovresti specificare quale è stato chiamato nella classe principale e per questo avrai bisogno di una sintassi aggiuntiva. La situazione peggiora ulteriormente se ci sono membri pubblici nelle classi.

La composizione viene utilizzata per prevenire problemi con l'ereditarietà multipla. Consentire una composizione come questa è effettivamente consentire l'ereditarietà multipla, almeno in termini di risoluzione del metodo da chiamare. Poiché una decisione chiave di progettazione con Java è stata quella di vietare l'ereditarietà multipla (per buoni motivi), ritengo improbabile che questo venga mai introdotto in Java.

Answer 3

Non sono sicuro di vedere comunque un chiaro vantaggio nel farlo. Capisco il punto che stai sollevando. Al momento per chiamare un metodo su A devi myB.getAInstance (). MethodInA (), ma vuoi renderlo myB.methodInA ().

Ma cosa succede se hai più istanze di A? Come verrebbe risolta la chiamata al metodo? Molte volte la composizione implica un'associazione da una a molte, quindi B ha molte istanze A. Cosa succede allora?

Sono d'accordo con i tuoi svantaggi elencati. Potrebbe semplicemente causare troppa confusione di quanto valga la pena.

Answer 4

Scopri ciò che viene chiamato " Mixins " in alcune lingue e " Ruoli " nel sistema Perl 5 Moose OO.

Answer 5

C'è anche la differenza tra composizione e aggregazione da considerare. Come fa il compilatore a sapere se intendi relazioni "is-a" o "has-a"?

• L'intero grafico a oggetti diventa idoneo per la garbage collection o solo la testa del grafico?

Un paio di strumenti e framework di mappatura ORM al di sopra / attorno a essi forniscono appartieneTo o ha molti tra oggetti persistenti e alcuni prevedono anche l'eliminazione a cascata ( per composizione). Non conosco una mano che fornisce il semplice zucchero sintattico che stai cercando.

In realtà, ripensandoci, il linguaggio (i) MetaClass e MetaProgramming di Groovy possono fornire qualcosa di molto simile, con una delega "auto-magica".

Answer 6

L'ereditarietà multipla è consentita in C ++, lo so diverso ma è lungo lo stesso processo di pensiero. Java è stato progettato per non consentire l'ereditarietà multipla in modo da creare meno confusione, quindi bug e exploit.

Quello che hai suggerito è in diretto conflitto con i principi di Java.

Detto questo, sarebbe bello (non necessariamente utile). Sono un programmatore Java che è passato dal C ++. Mi piace poter commettere i miei errori.