design-patterns - style - sun java naming conventions




Naming Classes-Como evitar chamar tudo de um “<WhatEver> Manager”? (9)

Acho que o mais importante a ter em mente é: o nome é descritivo o suficiente? Você pode dizer, olhando para o nome, o que a classe deve fazer? Usar palavras como "Gerente", "Serviço" ou "Manipulador" nos nomes das classes pode ser considerado genérico demais, mas como muitos programadores os usam, também ajuda a entender para que serve a classe.

Eu mesmo tenho usado muito o padrão de fachada (pelo menos, acho que é assim que é chamado). Eu poderia ter uma classe de User que descreve apenas um usuário e uma classe de Users que controla minha "coleção de usuários". Eu não chamo a classe de um UserManager porque eu não gosto de gerentes na vida real e não quero ser lembrado deles :) Simplesmente usando o formulário plural me ajuda a entender o que a classe faz.

Há muito tempo eu li um artigo (acredito em uma entrada de blog) que me colocou na faixa "certa" de nomeação de objetos: seja muito escrupuloso em nomear coisas em seu programa.

Por exemplo, se meu aplicativo fosse (como um aplicativo de negócios típico) manipulando usuários, empresas e endereços, eu teria uma classe de domínio User , Company e Address - e provavelmente em algum lugar um UserManager , um CompanyManager e um AddressManager seriam AddressManager aquelas coisas.

Então você pode dizer o que esses UserManager , CompanyManager e AddressManager fazem? Não, porque Manager é um termo muito genérico que se ajusta a qualquer coisa que você possa fazer com seus objetos de domínio.

O artigo que li recomendou usando nomes muito específicos. Se fosse um aplicativo C ++ e o UserManager do UserManager estivesse alocando e liberando usuários do heap, ele não gerenciaria os usuários, mas protegeria seu nascimento e morte. Hmm, talvez pudéssemos chamar isso de UserShepherd .

Ou talvez o UserManager do UserManager seja examinar os dados de cada objeto do usuário e assinar os dados criptograficamente. Então nós teríamos um UserRecordsClerk .

Agora que esta ideia ficou comigo, tento aplicá-la. E ache esta ideia simples incrivelmente difícil.

Eu posso descrever o que as classes fazem e (contanto que eu não escorregue na codificação rápida e suja) as aulas que escrevo fazem exatamente uma coisa. O que eu sinto falta de ir dessa descrição para os nomes é um tipo de catálogo de nomes, um vocabulário que mapeia os conceitos para os nomes.

Em última análise, eu gostaria de ter algo como um catálogo de padrões em mente (freqüentemente os padrões de projeto fornecem facilmente os nomes dos objetos, por exemplo, uma fábrica )

  • Fábrica - Cria outros objetos (nomenclatura tirada do padrão de design)
  • Pastor - Um pastor lida com o tempo de vida dos objetos, sua criação e desligamento
  • Sincronizador - Copia dados entre dois ou mais objetos (ou hierarquias de objeto)
  • Babá - Ajuda os objetos a alcançar o estado "utilizável" após a criação - por exemplo, conectando-se a outros objetos

  • etc etc.

Então, como você lida com esse problema? Você tem um vocabulário fixo, você inventa novos nomes na hora ou considera nomear coisas não tão importantes ou erradas?

PS: Também estou interessado em links para artigos e blogs discutindo o assunto. Para começar, aqui está o artigo original que me fez pensar sobre isso: Nomeando Classes Java sem um 'Gerenciador'

Atualização: Resumo das respostas

Aqui está um pequeno resumo do que eu aprendi com esta questão nesse meio tempo.

  • Tente não criar novas metáforas (babá)
  • Dê uma olhada no que outros frameworks fazem

Outros artigos / livros sobre este tema:

E uma lista atual de prefixos / sufixos de nomes que eu coletei (subjetivamente!) Das respostas:

  • Coordenador
  • Construtor
  • Escritor
  • Leitor
  • Manipulador
  • Recipiente
  • Protocolo
  • Alvo
  • Conversor
  • Controlador
  • Visão
  • Fábrica
  • Entidade
  • Balde

E uma boa dica para a estrada:

Não fique com paralisia. Sim, os nomes são muito importantes, mas não são importantes o suficiente para desperdiçar grandes quantidades de tempo. Se você não consegue pensar em um bom nome em 10 minutos, siga em frente.



Eu acredito que o ponto crítico aqui é ser consistente dentro da esfera de visibilidade do seu código, ou seja, contanto que todos que precisam olhar / trabalhar em seu código entendam sua convenção de nomenclatura, então isso deve ser bom, mesmo se você decidir chamá-los 'CompanyThingamabob' e 'UserDoohickey'. A primeira parada, se você trabalha para uma empresa, é ver se existe uma convenção da empresa para nomear. Se não houver ou você não trabalhar para uma empresa, crie os seus próprios usando termos que façam sentido para você, passe para alguns colegas / amigos de confiança que pelo menos codifiquem casualmente e incorpore qualquer feedback que faça sentido.

Aplicar a convenção de outra pessoa, mesmo quando ela é amplamente aceita, se ela não der um salto na página para você é um pequeno erro no meu livro. Primeiramente, preciso entender meu código sem referência a outra documentação, mas, ao mesmo tempo, ele precisa ser genérico o suficiente para que não seja incompreensível para outra pessoa no mesmo ramo do mesmo setor.


Eu consideraria os padrões que você está usando para o seu sistema, as convenções de nomenclatura / catalogação / agrupamento de classes tendem a ser definidas pelo padrão usado. Pessoalmente, eu mantenho essas convenções de nomenclatura como elas são a maneira mais provável para outra pessoa ser capaz de pegar meu código e correr com ele.

Por exemplo, UserRecordsClerk pode ser melhor explicado como estender uma interface RecordsClerk genérica que UserRecordsClerk e CompanyRecordsClerk implementam e, em seguida, especializam-se, o que significa que é possível examinar os métodos na interface para ver para que servem geralmente as subclasses.

Veja um livro como o Design Patterns for info, é um excelente livro e pode ajudá-lo a esclarecer onde você quer estar com o seu código - se você ainda não o estiver usando! o)

Acredito que, desde que o seu padrão seja bem escolhido e usado o mais adequado possível, então os nomes simples e desinteressantes da classe devem ser suficientes!


Nós poderíamos fazer sem nenhuma xxxFactory , xxxManager ou xxxRepository se xxxRepository o mundo real corretamente:

Universe.Instance.Galaxies["Milky Way"].SolarSystems["Sol"]
        .Planets["Earth"].Inhabitants.OfType<Human>().WorkingFor["Initech, USA"]
        .OfType<User>().CreateNew("John Doe");

;-)


Quando me pego pensando em usar o Manager ou o Helper em um nome de classe, considero um cheiro de código que significa que ainda não encontrei a abstração correta e / ou estou violando o princípio da responsabilidade única , refatorando e colocando mais esforço no design, muitas vezes torna a nomeação muito mais fácil.

Mas mesmo as classes bem projetadas não se nomeiam (sempre), e suas escolhas dependem, em parte, da criação de classes de modelo de negócio ou de classes de infraestrutura técnica.

As classes de modelo de negócios podem ser difíceis, porque são diferentes para cada domínio. Existem alguns termos que eu uso muito, como Policy para classes de estratégia dentro de um domínio (por exemplo, LateRentalPolicy ), mas estes geralmente fluem de tentar criar uma " linguagem onipresente " que você pode compartilhar com usuários de negócios, projetando e nomeando classes para que eles modelar idéias, objetos, ações e eventos do mundo real.

As aulas de infraestrutura técnica são um pouco mais fáceis, porque descrevem domínios que conhecemos muito bem. Eu prefiro incorporar nomes de padrões de design nos nomes de classes, como InsertUserCommand, CustomerRepository, ou SapAdapter. Eu entendo a preocupação em comunicar a implementação em vez da intenção, mas os padrões de projeto casam esses dois aspectos do design de classes - pelo menos quando você está lidando com infraestrutura, onde você quer que o design da implementação seja transparente mesmo quando você está escondendo os detalhes.


Sendo eu fait com padrões como definidos por (digamos) o livro GOF , e nomear objetos depois destes me faz um longo caminho na nomeação de classes, organizando-os e comunicando a intenção. A maioria das pessoas entenderá essa nomenclatura (ou pelo menos uma parte importante dela).


Soa como uma ladeira escorregadia para algo que seria postado no site www.edailywtf.com, "ManagerOfPeopleWhoHaveMortgages", etc.

Eu suponho que é certo que uma única classe Manager monolítica não é um bom design, mas usar 'Manager' não é ruim. Em vez do UserManager, podemos dividi-lo em UserAccountManager, UserProfileManager, UserSecurityManager, etc.

'Gerente' é uma boa palavra porque mostra claramente que uma classe não representa uma 'coisa' do mundo real. 'AccountsClerk' - como posso saber se essa é uma classe que gerencia dados de usuários ou representa alguém que é um Clerk de Contas para o seu trabalho?


Você pode dar uma olhada em source-code-wordle.de , eu analisei lá os sufixos usados ​​com mais freqüência de nomes de classes do .NET framework e algumas outras bibliotecas.

Os 20 melhores são:

  • atributo
  • tipo
  • ajudante
  • coleção
  • conversor
  • manipulador
  • informação
  • fornecedor
  • exceção
  • serviço
  • elemento
  • Gerente
  • opção
  • fábrica
  • contexto
  • item
  • desenhista
  • base
  • editor




naming