A melhor prática para subclasses de nomeação

Question

Estou muitas vezes em uma situação onde eu tenho um conceito representado por uma interface ou classe, e então eu tenho uma série de subclasses / subinterfaces que se estendem-lo.

Por exemplo: A "DoiGraphNode" genérico A "DoiGraphNode", representando um recurso A "DoiGraphNode", representando um recurso Java A "DoiGraphNode" com um caminho associado, etc., etc.

Eu posso pensar de três convenções de nomenclatura, e gostaria de receber comentários sobre como escolher.

---

Opção 1:. Sempre comece com o nome do conceito

Assim:. DoiGraphNode, DoiGraphNodeResource, DoiGraphNodeJavaResource, DoiGraphNodeWithPath, etc

Pro: É muito claro o que estou lidando, é fácil de ver todas as opções que eu tenho

Con: Não muito natural? Tudo parece o mesmo?

---

Opção 2:. Coloque o material especial no início

Assim: DoiGraphNode, ResourceDoiGraphNode, JavaResourceDoiGraphNode, PathBaseDoiGraphNode, etc., etc.

Pro: É muito claro quando eu vê-lo no código

Con: Encontrar poderia ser difícil, especialmente se eu não me lembro o nome, a falta de consistência visual

---

Opção 3: Coloque o material especial e remover parte do texto redundante

Assim: DoiGraphNode, ResourceNode, JavaResourceNode, GraphNodeWithPath

Pro: Não muito de escrever e ler Con: Parece que cr * p, muito inconsistente, o conflito pode com outros nomes

Answer 1

Nome-los por aquilo que são.

Se nomeá-los é difícil ou ambígua, muitas vezes é um sinal de que a classe está fazendo demais (Responsabilidade Individual Princípio).

Para evitar conflitos de nomes, escolha seus namespaces de forma adequada.

Personnally, eu usaria 3

Answer 2

Use o que quiser, é uma coisa subjetiva. O importante é deixar claro o que cada classe representa, e os nomes devem ser tais que as relações de herança faz sentido. Eu realmente não acho que é tão importante para codificar as relações nos nomes, embora; Isso é o que documentação é para (e se os seus nomes são apropriados para os objetos, as pessoas devem ser capazes de fazer bons palpites sobre o que herda a partir do que).

Por que vale a pena, eu costumo usar a opção 3, e da minha experiência olhando para opção de código de outras pessoas 2 é provavelmente mais prevalente do que a opção 1.

Answer 3

Você pode encontrar algumas orientações em um documento de padrões de codificação, por exemplo, há o documento IDesign para C # aqui .

Pessoalmente, eu prefiro a opção 2. Esta é geralmente a forma como os nomes do .NET Framework seus objetos. Por exemplo olhar para classes de atributos. Todos eles terminam em Atributo (TestMethodAttribute). O mesmo vale para EventHandlers:. OnClickEventHandler é um nome recomendado para um manipulador de eventos que manipula o evento Click

Normalmente, eu tento seguir esta em projetar meu próprio código e interfaces. Assim, um IUnitWriter produz um StringUnitWriter e um DataTableUnitWriter. Desta forma eu sempre sei o que sua classe base é e lê mais naturalmente. Auto-documentar código é o objetivo final para todos os desenvolvedores ágeis para que ele parece funcionar bem para mim!

Answer 4

Eu costumo citar semelhante à opção 1, especialmente quando as aulas serão usadas polymophically. Meu raciocínio é que o bit de informação mais importante é listado primeiro. (Ou seja, o fato de que a subclasse é basicamente o que o ancestral é, com (geralmente) ampliações 'acrescentado'). Eu gosto desta opção também porque quando ordenar listas de nomes de classe, as classes relacionadas serão listados juntos. Ou seja, Eu costumo citar a unidade de tradução (nome do arquivo) o mesmo que O nome da classe arquivos de classe tão relacionados será, naturalmente, listados juntos. Da mesma forma isso é útil com pesquisa incremental.

Embora eu tendem a usar a opção 2 no início da minha carreira de programação, eu evitá-lo agora, porque como você diz que é 'inconsistente' e não parecem muito ortogonal.

Costumo usar a opção 3, quando a subclasse fornece extensão ou especificação substancial, ou se os nomes seria muito longa. Por exemplo, minhas aulas de nomes sistema de arquivos são derivados de Cordas mas eles estender a classe String e ter um significativamente diferente uso / significado:

Directory_entry_name derivado de Cordas adiciona funcionalidade extensa. File_name derivado de Directory_entry_name tem funções bastante especializado. Directory_name derivado de Directory_entry_name funções também tem bastante especializado.

Além disso, juntamente com a opção 1, eu costumo usar um nome não qualificado para uma classe de interface. Por exemplo, eu poderia ter uma cadeia de classe interence:

• Texto (uma interface)
• Text_abstract (abstract (base) classe generalização)
• Text_ASCII (específico classe concreta para ASCII codificação)
• Text_unicode (específico classe concreta para unicode codificação)

eu gosto bastante de que a interface e a classe base abstrata automaticamente aparecem em primeiro lugar na lista ordenada.

Answer 5

Opção mais três logicamente decorre do conceito de herança. Desde que você está especializada na interface ou classe, o nome deve mostrar que ele não está usando a implementação base (se existir).

Há uma infinidade de ferramentas para ver o que uma classe herda, por isso, um nome conciso indicando a função real da classe vai mais longe do que tentar embalar informações de tipo em demasia o nome.