A melhor prática para subclasses de nomeação
Pergunta
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
Solução
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
Outras dicas
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.
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!
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.
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.