Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Observação
Esse conteúdo é reimpresso por permissão da Pearson Education, Inc. das Diretrizes de Design da Estrutura: Convenções, Idiomas e Padrões para Bibliotecas .NET Reutilizáveis, 2ª Edição. Essa edição foi publicada em 2008, e desde então o livro foi totalmente revisado na terceira edição. Algumas das informações nesta página podem estar desatualizadas.
Embora as propriedades sejam tecnicamente muito semelhantes aos métodos, elas são bastante diferentes em termos de seus cenários de uso. Eles devem ser vistos como campos inteligentes. Eles têm a sintaxe de chamada dos campos e a flexibilidade dos métodos.
✔️ Crie propriedades de acesso apenas para leitura se o chamador não puder alterar o valor da propriedade.
Tenha em mente que, se o tipo da propriedade for um tipo de referência mutável, o valor da propriedade poderá ser alterado mesmo se a propriedade for somente obtenção.
❌ NÃO forneça propriedades que só podem ser definidas ou propriedades em que o setter tem acessibilidade mais ampla do que o getter.
Por exemplo, não use propriedades com um método setter público e um método getter protegido.
Se o getter de propriedade não puder ser fornecido, implemente a funcionalidade como um método em vez disso. Considere começar o nome do método com Set e depois seguir com o nome que você daria à propriedade. Por exemplo, AppDomain tem um método chamado SetCachePath em vez de ter uma propriedade somente conjunto chamada CachePath.
✔️ O DO fornece valores padrão sensatos para todas as propriedades, garantindo que os padrões não resultem em uma falha de segurança ou código terrivelmente ineficiente.
✔️ DO permite que as propriedades sejam definidas em qualquer ordem, mesmo que isso resulte em um estado temporário inválido do objeto.
É comum que duas ou mais propriedades sejam inter-relacionadas a um ponto em que alguns valores de uma propriedade podem ser inválidos, considerando os valores de outras propriedades no mesmo objeto. Nesses casos, exceções resultantes do estado inválido devem ser adiadas até que as propriedades interrelacionadas sejam realmente usadas juntas pelo objeto.
✔️ DO preservará o valor anterior se um setter de propriedade gerar uma exceção.
❌ EVITE lançar exceções em getters de propriedade.
Os métodos de acesso de propriedade devem ser operações simples e não devem ter pré-condições. Se um getter puder gerar uma exceção, ele provavelmente deverá ser redesenhado para ser um método. Observe que essa regra não se aplica aos indexadores, em que esperamos exceções como resultado da validação dos argumentos.
Design de propriedades indexadas
Uma propriedade indexada é uma propriedade especial que pode ter parâmetros e pode ser chamada com sintaxe especial semelhante à indexação de matriz.
As propriedades indexadas são comumente conhecidas como indexadores. Os indexadores devem ser usados somente em APIs que fornecem acesso a itens em uma coleção lógica. Por exemplo, uma cadeia de caracteres é uma coleção de caracteres e o indexador System.String foi adicionado para acessar seus caracteres.
✔️ CONSIDERE o uso de indexadores para fornecer acesso aos dados armazenados em uma matriz interna.
✔️ CONSIDERE fornecer indexadores em tipos que representam coleções de itens.
❌ EVITE usar propriedades indexadas com mais de um parâmetro.
Se o design exigir vários parâmetros, reconsidere se a propriedade realmente representa um acessor para uma coleção lógica. Se não funcionar, use métodos. Considere iniciar o nome do método com Get ou Set.
❌ Evite indexadores com tipos de parâmetro diferentes de System.Int32, System.Int64, System.String, System.Object ou uma enumeração.
Se o design exigir outros tipos de parâmetros, avalie fortemente se a API realmente representa um acessador para uma coleção lógica. Se não funcionar, use um método. Considere iniciar o nome do método com Get ou Set.
✔️ USE o nome Item para propriedades indexadas, a menos que haja um nome obviamente melhor (por exemplo, consulte a Chars[] propriedade em System.String).
Em C#, os indexadores são, por padrão, chamados Item. Pode IndexerNameAttribute ser usado para personalizar esse nome.
❌ NÃO forneça um indexador e métodos semanticamente equivalentes.
❌ NÃO forneça mais de uma família de indexadores sobrecarregados dentro de um tipo.
Isso é imposto pelo compilador C#.
❌ NÃO use propriedades indexadas não padrão.
Isso é imposto pelo compilador C#.
Eventos de notificação de alteração de propriedade
Às vezes, é útil fornecer um evento notificando o usuário de alterações em um valor de propriedade. Por exemplo, System.Windows.Forms.Control gera um TextChanged evento depois que o valor de sua Text propriedade é alterado.
✔️ CONSIDERE disparar eventos de notificação de alteração quando os valores de propriedades em APIs de alto nível (normalmente componentes de designer) forem modificados.
Se houver um bom cenário para um usuário saber quando uma propriedade de um objeto está mudando, o objeto deverá gerar um evento de notificação de alteração para a propriedade.
No entanto, é improvável que valha a pena aumentar esses eventos para APIs de baixo nível, como tipos base ou coleções. Por exemplo, List<T> não geraria esses eventos quando um novo item é adicionado à lista e a Count propriedade é alterada.
✔️ CONSIDERE a geração de eventos de notificação de alteração quando o valor de uma propriedade é alterado por meio de forças externas.
Se um valor de propriedade for alterado por meio de alguma força externa (de uma forma diferente dos métodos de chamada no objeto), os eventos gerados indicarão ao desenvolvedor que o valor está mudando e foi alterado. Um bom exemplo é a Text propriedade de um controle de caixa de texto. Quando o usuário digita texto em um TextBox, o valor da propriedade é alterado automaticamente.
Partes © 2005, 2009 Microsoft Corporation. Todos os direitos reservados.
Reimpresso por permissão da Pearson Education, Inc. da Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition por Krzysztof Cwalina e Brad Abrams, publicado em 22 de outubro de 2008 pela Addison-Wesley Professional como parte da Microsoft Windows Development Series.