Chi è responsabile del controllo delle proprietà dell'oggetto come Visibile / Abilitato?

Ogni elemento stesso

Tutto dovrebbe funzionare in modo molto simile a un sistema basato sugli eventi. L'entità padre dovrebbe dare ordini ai suoi articoli, e gli oggetti dovrebbero controllare con il loro stato per vedere se e come possono eseguire quell'azione.

Anche se è semplice leggere 1-2 proprietà pubbliche per il genitore, è ancora meglio per incapsulamento non farlo e lasciare che gli elementi controllino il loro stato (che a volte può essere molto più complicato di un singolo flag booleano).

Principio TDA (Tell-Dont-Ask) supporta questo:

Tell-Don't-Ask is a principle that helps people remember that object-orientation is about bundling data with the functions that operate on that data. It reminds us that rather than asking an object for data and acting on that data, we should instead tell an object what to do. This encourages to move behavior into an object to go with the data.

Almeno in interfacce basate su evento OO +:

• Gli oggetti GUI, incluso il pannello della finestra stesso, hanno listener di eventi che vengono attivati con azioni dell'utente. Questi listener di eventi chiamano un metodo che quindi invia messaggi ad altri elementi della GUI (o a se stessi).
• Ma ... una volta che un elemento della GUI riceve un messaggio (come myButton.setVisible(false); ) si esegue il rendering (ovviamente le chiamate di livello inferiore al sistema di finestre sono rese possibili).
• Quindi il "controlling / orchestrating" è per conto delle finestre principali e delegato ad altri controsl, ad esempio un listener di eventi radio cooner%% può inviare un messaggio a una casella di testo per renderlo invisibile.
• Il codice di rendering effettivo è all'interno di ogni elemento, essendo ciascuno un'istanza di una classe. Ovviamente stanno emettendo chiamate di basso livello a un sistema di windowing / motore di rendering.

La visibilità è spesso qualcosa che si desidera aggregare in modo da poter dire a un intero gruppo di oggetti di nascondersi o mostrarsi insieme. Anche così è meglio lasciare che ogni oggetto test e si dipingi da solo.

Sono un grande sostenitore di tell do not ask . Per me il mondo orientato agli oggetti è diviso in oggetti comportamentali che non ti dicono nulla del loro stato, e gli oggetti dati che riguardano tutti i getter.

Gli oggetti comportamentali non hanno getter. Sono incapsulati. Parlano al mondo dicendo ad altri oggetti di fare cose e di emettere.

Gli oggetti dati hanno getter. Devono esistere quando i comportamenti che dipendono da questi dati sono sparsi tra più oggetti e quei comportamenti non possono essere spostati in un unico oggetto.

Un oggetto che può dipingere su se stesso suona come un oggetto di comportamento. Quindi, come condividere la visibilità?

Gli oggetti di gruppo che devono condividere le modifiche di visibilità insieme in raccolte. Di 'loro di cambiare la visibilità insieme. Gli eventi sono un modo comune per farlo. Il pattern di osservatore può essere usato con le ipotesi che ho fatto qui, ma di solito viene raffigurato osservando i dati.