Design de Imóveis
Nota
Este conteúdo é reimpresso com permissão da Pearson Education, Inc., a partir de Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition. Essa edição foi publicada em 2008 e, desde então, o livro foi totalmente revisto 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. Devem ser vistos como campos inteligentes. Eles têm a sintaxe de chamada de campos, e a flexibilidade de métodos.
✔️ CRIE propriedades get-only se o chamador não puder alterar o valor da propriedade.
Lembre-se de 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 get-only.
❌ NÃO forneça propriedades somente de conjunto ou propriedades com o setter tendo uma acessibilidade mais ampla do que o getter.
Por exemplo, não use propriedades com um setter público e um getter protegido.
Se o getter de propriedade não puder ser fornecido, implemente a funcionalidade como um método. Considere iniciar o nome do método com Set e seguir com o que você teria chamado a propriedade. Por exemplo, AppDomain tem um método chamado SetCachePath em vez de ter uma propriedade set-only chamada CachePath.
✔️ 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 temporariamente inválido do objeto.
É comum que duas ou mais propriedades estejam inter-relacionadas a um ponto em que alguns valores de uma propriedade podem ser inválidos dados os valores de outras propriedades no mesmo objeto. Nesses casos, as exceções resultantes do estado inválido devem ser adiadas até que as propriedades inter-relacionadas sejam realmente usadas juntas pelo objeto.
✔️ PRESERVA o valor anterior se um setter de propriedade lançar uma exceção.
❌ EVITE lançar exceções de compradores de propriedades.
Os compradores de propriedades devem ser operações simples e não devem ter quaisquer pré-condições. Se um getter pode lançar uma exceção, provavelmente deve ser redesenhado para ser um método. Observe que essa regra não se aplica a indexadores, onde esperamos exceções como resultado da validação dos argumentos.
Design de propriedade indexada
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 chamadas de 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 em System.String foi adicionado para acessar seus caracteres.
✔️ CONSIDERE o uso de indexadores para fornecer acesso a 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 acessador a uma coleção lógica. Se isso não acontecer, use métodos em vez disso. Considere iniciar o nome do método com Get ou Set.
❌ EVITE indexadores com tipos de parâmetros diferentes de System.Int32, System.Int64, System.String, System.Object, ou um enum.
Se o design exigir outros tipos de parâmetros, reavalie fortemente se a API realmente representa um acessador a uma coleção lógica. Se isso não acontecer, 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. O IndexerNameAttribute pode ser usado para personalizar este nome.
❌ NÃO forneça um indexador e métodos que sejam semanticamente equivalentes.
❌ NÃO forneça mais de uma família de indexadores sobrecarregados em 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 sobre 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 foi alterado.
✔️ CONSIDERE gerar eventos de notificação de alteração quando os valores de propriedade em APIs de alto nível (geralmente 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 deve gerar um evento de notificação de alteração para a propriedade.
No entanto, é improvável que valha a pena a sobrecarga para aumentar esses eventos para APIs de baixo nível, como tipos básicos ou coleções. Por exemplo, List<T> não geraria tais eventos quando um novo item é adicionado à lista e a Count propriedade é alterada.
✔️ CONSIDERE levantar eventos de notificação de alteração quando o valor de uma propriedade muda por força externa.
Se um valor de propriedade for alterado por meio de alguma força externa (de uma forma diferente de chamar métodos no objeto), os eventos raise 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 muda automaticamente.
© Partes 2005, 2009 Microsoft Corporation. Todos os direitos reservados.
Reimpresso com permissão da Pearson Education, Inc., de 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 por Addison-Wesley Professional como parte da Microsoft Windows Development Series.