Rimozione di un oggetto dal relativo supporto

Question

Rimozione di un oggetto dal relativo supporto

#1 da (1 voti)

0

Supponiamo di avere tre classi, come follwing:

class A {
  Array<B> bs;
  createB() { b = new B(); this.bs.insert(b); return b; }
}

class B {
  Array<C> cs;
  createC() { c = new C(); this.cs.insert(c); return c; }
}

class C {
  delete() { ... }
}

A tiene Bs e B tiene Cs. C ha un metodo di cancellazione su cui per una data C, c, voglio cancellare la sua B dalla A che alla fine tiene c.

Un modo semplice per farlo è di mantenere un riferimento all'indietro sull'oggetto titolare. In questo modo, il metodo di cancellazione di C può essere scritto come:

delete() { this.b.a.bs.remove(this.b); }

Ma mi trovo con una dipendenza circolare in cui ogni classe è a conoscenza degli altri. Voglio che qualsiasi classe inferiore non sia a conoscenza della sua classe di proprietari.

Qualche idea su come risolvere questo più elegantemente? Gradirei anche una soluzione che possa essere applicata su una gerarchia più grande di solo tre classi.

Modifica: Potrei non essere stato abbastanza chiaro, ma il mio punto è che la classe C è un "ricevitore azione", come un pulsante sullo schermo con molte opzioni su cui fare clic. A e B sono più di un elemento logico che non ha la rappresentazione dello schermo ma i dati di gruppo insieme.

Supponiamo che B abbia un attributo shape e C abbia un attributo color.

Voglio poter fare clic su C e fornire questi metodi (solo alcuni esempi inventati):

Delete() { go to B, and delete this C from it array }
PaintAllRed() { go to B, for each C set color red }
ShapeSquare() { go to B, go to it's A, for each B of A set shape square }

In sostanza voglio sapere come può C informare B (e A) che un'azione è stata fatta dall'utente.

circular-dependency

posta Deer 13.12.2018 - 23:50

fonte

1 risposta

Leggi altre domande sui tag circular-dependency

Accodamento di e-mail in Laravel quando si utilizza un driver API come Mailgun? Troppo strong dell'accoppiamento tra radici aggregate?

score 1 · Answer 1

IMO, l'approccio migliore al problema della gerarchia è quello di garantire che un nodo non sia mai a conoscenza dei suoi genitori, come hai accennato. Credo che questo sia lo standard del settore, quindi la situazione che stai incontrando in cui un bambino ha bisogno di invocare comportamenti su un genitore di cui non dovrebbe essere a conoscenza è piuttosto comune (la composizione dell'interfaccia utente è da qualche parte che affiora molto). Ci sono tre approcci a cui posso pensare:

Fai in modo che il genitore passi l'accesso alla rimozione comportamento al bambino (passa al bambino una funzione che può chiamare per rimuovere se stesso). Questo è buono in JavaScript e Python, ma in lingue in cui le funzioni non sono facilmente trattate come variabili che fanno schifo.
Il genitore è responsabile della cancellazione dei suoi figli. Quindi per eliminare un C chiameresti un metodo removeC del suo parent B .
Gestisci l'avere i riferimenti posteriori. Il modo in cui questa struttura di dati viene propagata attraverso la tua applicazione può imporre di doverlo fare in questo modo senza importanti refactoring.