Nomeando Classes - Como evitar chamar tudo de um "Gerenciador de <Qualquer>"? [fechadas]

Há muito tempo, li um artigo (acredito que seja uma entrada de blog) que me colocou no caminho "certo" para nomear objetos: Seja muito cuidadoso ao nomear coisas em seu programa.

Por exemplo, se meu aplicativo fosse (como um aplicativo comercial típico) manipulando usuários, empresas e endereços, eu teria uma classe a User, a Companye Addressdomain - e provavelmente em algum lugar a UserManager, a CompanyManagere a AddressManagerapareceriam e tratariam dessas coisas.

Então você pode dizer que aqueles UserManager, CompanyManagere AddressManagerfazer? 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 o uso de nomes muito específicos. Se fosse um aplicativo C ++ e o UserManagertrabalho do usuário estivesse alocando e liberando usuários da pilha, ele não gerenciaria os usuários, mas protegeria seu nascimento e morte. Hmm, talvez possamos chamar isso de UserShepherd.

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

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

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

Por fim, gostaria de ter algo como um catálogo de padrões em minha mente (freqüentemente os padrões de design fornecem facilmente os nomes dos objetos, por exemplo, uma fábrica )

• Fábrica - Cria outros objetos (nomeação tirada do padrão de design)
• Pastor - Um pastor lida com a vida útil dos objetos, sua criação e desligamento
• Sincronizador - copia dados entre dois ou mais objetos (ou hierarquias de objetos)

• Babá - Ajuda os objetos a atingir o estado "utilizável" após a criação - por exemplo, conectando outros objetos

• etc etc.

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

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

Atualização: Resumo das respostas

Aqui está um pequeno resumo do que aprendi com essa pergunta enquanto isso.

• Tente não criar novas metáforas (babá)
• Veja o que outras estruturas fazem

Mais artigos / livros sobre este tópico:

• Que nomes você se encontra anexando / anexando regularmente às aulas?
• Qual é a melhor abordagem para nomear classes?
• Livro: Padrões de Design: Elementos de Software Orientado a Objetos Reutilizáveis ​​(Capa Dura)
• Livro: Padrões de arquitetura de aplicativos corporativos (capa dura)
• Livro: Padrões de Implementação (Brochura)

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

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

E uma boa dica para a estrada:

Não fique com paralisia de nomes. 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 conseguir encontrar um bom nome em 10 minutos, siga em frente.

Fiz uma pergunta semelhante , mas sempre que possível, tento copiar os nomes que já estão na estrutura .NET e procuro idéias nas estruturas Java e Android .

Parece Helper, Managere Utilsão os substantivos inevitáveis anexados pela coordenação classes que contêm nenhum estado e são geralmente processual e estático. Uma alternativa é Coordinator.

Você poderia começar prosey particularmente roxo com os nomes e ir para coisas como Minder, Overseer, Supervisor, Administrator, e Master, mas como eu disse eu prefiro mantê-lo como os nomes quadro que você está acostumado.

Alguns outros sufixos comuns (se esse for o termo correto) que você também encontra na estrutura .NET são:

• Builder
• Writer
• Reader
• Handler
• Container

Você pode dar uma olhada em source-code-wordle.de , analisei lá os sufixos mais usados ​​dos nomes de classe do .NET framework e algumas outras bibliotecas.

Os 20 principais são:

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

Sou a favor de bons nomes e costumo escrever sobre a importância de tomar muito cuidado ao escolher nomes para as coisas. Por essa mesma razão, desconfio de metáforas ao nomear coisas. Na pergunta original, "fábrica" ​​e "sincronizador" parecem bons nomes para o que parecem significar. No entanto, "pastor" e "babá" não são, porque são baseados em metáforas . Uma classe no seu código não pode ser literalmente uma babá; você chama isso de babá porque cuida de outras coisas, da mesma forma que uma babá da vida real cuida de bebês ou crianças. Isso é bom no discurso informal, mas não é bom (na minha opinião) para nomear classes no código que terá que ser mantido por quem sabe quem sabe quando.

Por quê? Porque as metáforas são dependentes da cultura e muitas vezes dependem também do indivíduo. Para você, nomear uma classe como "babá" pode ser muito claro, mas talvez não seja tão claro para outra pessoa. Não devemos confiar nisso, a menos que você esteja escrevendo um código apenas para uso pessoal.

Em qualquer caso, a convenção pode criar ou quebrar uma metáfora. O uso de "factory" em si é baseado em uma metáfora, mas que existe há algum tempo e atualmente é bastante conhecida no mundo da programação, então eu diria que é seguro usá-lo. No entanto, "babá" e "pastor" são inaceitáveis.

Nós poderíamos fazer sem qualquer xxxFactory, xxxManagerou xxxRepositoryaulas se modelou o mundo real corretamente:

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

;-)

Parece uma ladeira escorregadia para algo publicado em thedailywtf.com, "ManagerOfPeopleWhoHaveMortgages" etc.

Suponho que é certo que uma classe monolítica do Manager não seja 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 está representando uma 'coisa' do mundo real. 'AccountsClerk' - como devo saber se é uma classe que gerencia os dados do usuário ou representa alguém que é um funcionário de contabilidade para o seu trabalho?

Como você está interessado em artigos nesta área, você pode estar interessado no artigo de opinião de Steve Yegge "Execution in the Kingdom of Nouns":

http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html

Quando me pego pensando em usar Managerou Helperem 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 geralmente facilita muito a nomeação.

Mas mesmo as classes bem projetadas não (sempre) se autodenominam, e suas escolhas dependem em parte de você estar criando classes de modelo de negócios ou 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 Policypara classes de estratégia em um domínio (por exemplo, LateRentalPolicy), mas eles geralmente fluem da tentativa de criar uma " linguagem onipresente " que você pode compartilhar com os usuários de negócios, projetando e nomeando classes para que elas modelem real idéias, objetos, ações e eventos do mundo.

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

Estar em conformidade com os padrões definidos pelo (digamos) livro do GOF e nomear objetos depois deles me ajudam bastante a nomear classes, organizá-las e comunicar a intenção. A maioria das pessoas entenderá essa nomenclatura (ou pelo menos uma parte importante).

Se eu não conseguir criar um nome mais concreto para minha classe do que o XyzManager, seria um ponto para eu reconsiderar se essa é realmente uma funcionalidade que pertence à classe, ou seja, um 'cheiro de código' arquitetônico.

Penso 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? O uso de palavras como "Gerente", "Serviço" ou "Manipulador" em seus nomes de classe pode ser considerado muito genérico, mas, como muitos programadores as utilizam, isso 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 Userclasse que descreva apenas um usuário e uma Usersclasse que rastreie minha "coleção de usuários". Não chamo a turma de a UserManagerporque não gosto de gerentes na vida real e não quero ser lembrado deles :) O simples uso da forma plural me ajuda a entender o que a turma faz.

Específico ao C #, achei que "Diretrizes de design da estrutura: convenções, idiomas e padrões para bibliotecas .NET reutilizáveis" tinham muitas informações boas sobre a lógica da nomeação.

No entanto, quanto a encontrar essas palavras mais específicas, geralmente uso um dicionário de sinônimos e pulo as palavras relacionadas para tentar encontrar uma boa. No entanto, tento não passar muito tempo com ele, à medida que progrido no desenvolvimento, encontro nomes melhores, ou às vezes percebo que isso SuchAndSuchManagerrealmente deve ser dividido em várias classes, e então o nome dessa classe obsoleta se torna um problema. .

Acredito que o importante aqui é ser consistente dentro da esfera de visibilidade do seu código, ou seja, desde que todos que precisam olhar / trabalhar no seu código entendam sua convenção de nomenclatura, tudo bem, mesmo se você decidir chamá-lo 'CompanyThingamabob' e 'UserDoohickey'. A primeira parada, se você trabalha para uma empresa, é verificar se há uma convenção de empresa para nomear. Se não houver ou você não trabalha para uma empresa, crie seus próprios termos que fazem sentido para você, passe-o para alguns colegas / amigos de confiança que pelo menos codificam casualmente e incorpore qualquer comentário que faça sentido.

Aplicar a convenção de outra pessoa, mesmo que seja amplamente aceito, se ela não sair da página, é um erro no meu livro. Antes de tudo, preciso entender meu código sem fazer referência a outra documentação, mas ao mesmo tempo precisa ser genérico o suficiente para que não seja incompreensível para outra pessoa no mesmo campo 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 de tendem a ser definidas pelo padrão usado. Pessoalmente, apego a essas convenções de nomenclatura, pois elas são a maneira mais provável de outra pessoa conseguir pegar meu código e executá-lo.

Por exemplo, UserRecordsClerk pode ser melhor explicado como estendendo uma interface RecordsClerk genérica que UserRecordsClerk e CompanyRecordsClerk implementam e depois se especializam, o que significa que é possível olhar para os métodos na interface para ver para que geralmente são as subclasses.

Veja um livro como Design Patterns para obter informações, é um excelente livro e pode ajudá-lo a esclarecer onde você deseja estar com seu código - se você ainda não o estiver usando! ; o)

Acho que, desde que seu padrão seja bem escolhido e usado na medida do apropriado, nomes de classes simples e pouco convidativos devem ser suficientes!