Pro / Contro per getter e setter di collezioni

Question

Pro / Contro per getter e setter di collezioni

#1 da (1 voti)
#2 da (0 voti)

1

Sto creando un modello in cui un elemento può contenere altri elementi. Attualmente sto scrivendo l'interfaccia per il modello e non sono sicuro di quale sia la migliore delle due opzioni:

Opzione 1

interface Container {
  List<Element> getElements(); // returns an unmodifiable list.
  void addElement(Element e);
  void removeElement(Element e);
}

Opzione 2

interface Container {
  List<Element> getElements(); // returns an unmodifiable list.
  void setElements(List<Element> elements);
}

Quali sono i pro / contro di ciascuna opzione? Inoltre, ci sono convenzioni di denominazione "accettate" in questi casi, come usare children invece di elements ?

design naming-standards

posta vainolo 24.03.2013 - 22:21

fonte

2 risposte

0

Generalmente preferisco Opzione 3 :

interface Container {
  MutableList<Element> getElements();
}

Questo è il pattern utilizzato dalla maggior parte delle API scritte nel framework .NET. Mantiene l'API il più semplice possibile, in particolare in .NET, dove sono presenti getter di proprietà come in myContainer.Elements.Add(new Element()) .

risposta data 24.03.2013 - 22:39

fonte

Leggi altre domande sui tag design naming-standards

codici JavaScript complessità e manutenibilità [chiuso] In che modo lo sviluppo di app per Windows Phone 8 è diverso da Windows Phone 7.x?

score 1 · Accepted Answer

In realtà si tratta di "Chi gestisce l'elenco".

Nell'opzione 1, fornisci al contenitore gli elementi e mantieni la sua responsabilità di gestirli: l'ordine, forse rifiuta alcuni elementi, ecc.

Con l'opzione 2, il contenitore è un contenitore stupido. Ottiene la lista da qualcun altro, e non ha voce in capitolo su cosa ci sia dentro o su quale sia l'ordine.

L'opzione 1 ti consentirebbe (se lasci getElements ()) per nascondere il contenuto del contenitore (o parte del contenuto) da altri flussi di lavoro nel tuo codice. Può persino consentire una sorta di multi-threading, fornendo la gestione della sicurezza dei thread all'interno del codice contenitore (anche se sembra eccessivo).

Per quanto riguarda la denominazione - per me, "elementi" significa "Non mi importa cosa ci sia dentro" - quindi un contenitore generico contiene Elementi. "Bambini" implica una relazione di dipendenza: per gestire un genitore, devi gestire tutti i suoi figli (come in un albero).