Devo fornecer métodos de acesso/Setters Getter para componentes públicos/protegidos em um formulário?

Question

Se eu tiver um formulário .Net com um componente/objeto, como uma caixa de texto que preciso acessar de um pai ou outro formulário, obviamente preciso "atualizar" o modificador deste componente para uma variável de nível interno ou público.

Agora, se eu estivesse fornecendo uma variável pública do tipo int ou string, etc.na minha classe de formulário, eu não pensaria duas vezes antes de usar Getters e (talvez) Setters para resolver isso, mesmo que eles não fizessem nada além de fornecer acesso direto à variável.

No entanto, o designer do VS não parece implementar esses Getters/Setters para os objetos públicos que são componentes de um formulário (e, portanto, não está em conformidade com as boas práticas de programação).

Então, a questão é;Para fazer a "coisa certa", devo agrupar esses componentes ou objetos do designer VS em um Getter e/ou Setter?

Answer 1

"No entanto, o designer do VS não parece implementar esses Getters/Setters para os objetos públicos que são componentes de um formulário (e, portanto, não está em conformidade com as boas práticas de programação)."

Se você se refere aos controles que está arrastando e soltando no formulário, eles são marcados como membros de instância privada e adicionados à coleção Controls do formulário.Por que seriam de outra forma?Um formulário pode ter quarenta ou cinquenta controles, seria um tanto desnecessário e complicado fornecer um getter/setter para cada controle no formulário.O designer deixa para você fornecer acesso delegado a controles específicos por meio de getter/setters públicos.

O designer faz a coisa certa aqui.

Answer 2

A razão para não implementar Getters e Setters para componentes em um formulário, acredito, é porque eles não seriam "Thread Safe". Os objetos .Net devem ser modificados apenas pelo thread do formulário que os criou, se você colocar getter e setters você está potencialmente abrindo-o para qualquer tópico.Em vez disso, suponha que você implemente um sistema delegado onde as alterações nesses objetos sejam delegadas ao thread que os criou e foi executado lá.

Answer 3

Este é um exemplo clássico de encapsulamento em design orientado a objetos.

Um Form é um objeto cuja responsabilidade é apresentar a UI ao usuário e aceitar entradas.A interface entre o objeto Form e outras áreas do código deve ser uma interface orientada a dados, não uma interface que exponha os detalhes internos de implementação do Form.O funcionamento interno do Form (ou seja, os controles) deve permanecer oculto de qualquer código consumidor.

Uma solução madura provavelmente envolveria os seguintes pontos de design:

• Métodos ou propriedades públicas são comportamentais (mostrar, ocultar, posicionar) ou orientados a dados (definir dados, obter dados, atualizar dados).
• Todos os manipuladores de eventos implementados pelo Form são agrupados em código de delegação de thread apropriado para impor regras de execução de thread do Form.
• Os próprios controles seriam vinculados aos dados da estrutura de dados subjacente (quando apropriado) para reduzir o código.

E isso sem mencionar coisas de metadesenvolvimento, como testes unitários.

Answer 4

Eu sempre faço isso, e se você ESTÁ seguindo um design MVP, criar getters/setters para seus componentes de visualização seria um requisito de design.

Não entendo o que você quer dizer com "não cumpre as boas práticas de programação".Microsoft viola bastante de boas práticas de programação para facilitar a criação de coisas no Visual Studio (para o rápido desenvolvimento de aplicativos) e não vejo a falta de getters/setters para controles como evidência de violação de tais práticas recomendadas.