Devo fornire la funzione di accesso a metodi Getter e Setter per public/protected componenti di un modulo?

Question

Se ho .Forma netta con un componente/oggetto, ad esempio una casella di testo che ho bisogno di accesso da parte di un genitore o di altra forma ovviamente ho bisogno di "aggiornare" il modificatore di questo componente Interno o Pubblico di livello variabile.

Ora, se io fossi un pubblico variabile di tipo int o di tipo stringa, etc.nella mia classe del form non vorrei pensare due volte prima di usare metodi Getter e (forse) Setter di tutto questo, anche se essi non fanno altro che fornire un accesso diretto alla variabile.

Tuttavia, il VS designer non sembra per l'attuazione di tali metodi Getter/Setter per quelli pubblici oggetti che sono componenti di un modulo (e quindi non è conforme con la buona pratica di programmazione).

Quindi, la domanda è;Per fare la "cosa giusta" dovrebbe avvolgere tali VS componenti di progettazione o di oggetti in un Getter e/o Setter?

Answer 1

"Tuttavia, il VS designer non sembra per l'attuazione di tali metodi Getter/Setter per quelli pubblici oggetti che sono componenti di un modulo (e quindi non è conforme con la buona pratica di programmazione)."

Se vuoi dire che i controlli si sta trascinando sul modulo, queste sono contrassegnati come privati membri di istanza e vengono aggiunti per i Controlli del form di raccolta.Perché dovrebbero essere altrimenti?Un modulo può avere quaranta o cinquanta controlli, sarebbe un po ' inutile e ingombrante per fornire un getter/setter per ogni controllo del modulo.Il design lascia a voi per fornire l'accesso delegato di specifici controlli tramite i getter/setter.

Il progettista fa la cosa giusta qui.

Answer 2

Il motivo per cui non l'implementazione dei metodi Getter e Setter per i componenti di una maschera, io credo, la causa non sarebbe "Thread-Safe" .Net oggetti sono supponiamo di essere modificato solo dalla forma thread che li ha creati, Se si mette su getter e i setter sono potenzialmente di apertura per i thread.Invece il tuo supponiamo di implementare un delegato di sistema in cui le modifiche di questi oggetti sono delegate al thread che li ha creati e corse c'.

Answer 3

Questo è un classico esempio di incapsulamento in progettazione object-oriented.

Una Maschera è un oggetto la cui responsabilità è presente interfaccia utente e di accettare in ingresso.L'interfaccia tra il Modulo di oggetto e di altre aree del codice dovrebbe essere una data-oriented, non un'interfaccia che espone l'interno i dettagli di implementazione del Modulo.Il funzionamento interno di una Forma (vale a dire, i controlli) deve rimanere nascosto da qualsiasi consumo di codice.

Una soluzione matura sarebbe probabilmente coinvolgono i seguenti punti:

• Pubblica metodi o proprietà di comportamento (di mostrare, nascondere, posizione) o data-oriented (set di dati, dati, dati di aggiornamento).
• Tutti i gestori di eventi attuato dal Modulo sono avvolti nel thread appropriato delegazione di codice per far rispettare la Forma del filo-le regole di esecuzione.
• Controlli stessi sarebbe associato ai dati la struttura di dati sottostante (ove appropriato) per ridurre il codice.

E non parlare di meta-sviluppo le cose come test di unità.

Answer 4

Faccio sempre così, e se si sta seguendo un MVP di progettazione la creazione di metodi getter e setter per la visualizzazione componenti di un requisito di progettazione.

Non capisco cosa vuoi dire con "non è conforme con la buona pratica di programmazione".Microsoft viola un sacco di buone pratiche di programmazione per rendere più facile per creare roba su Visual Studio (per il bene del rapido sviluppo delle app) e non vedo la mancanza di getter e setter per i controlli come prova della violazione di tali best practices.