Como você evita semelhanças de nomes entre suas classes e as nativas? [fechadas]

9

Acabei de encontrar um "problema interessante", sobre o qual gostaria de sua opinião:

Estou desenvolvendo um sistema e, por muitas razões (significando: abstração, independência tecnológica etc.), criamos nossos próprios tipos para a troca de informações.

Por exemplo: se existe um método chamado SendEmail e é invocado pela lógica de negócios, ele possui um parâmetro do tipo OurCompany.EMailMessage, que é um objeto totalmente independente da tecnologia e contém apenas "dados relevantes para os negócios" (por exemplo, nenhuma informação sobre a codificação principal).

Dentro da função SendEmail, obtemos essas informações do nosso objeto EMailMEssage e criamos um objeto MailMessage (este é específico da tecnologia) para que possa ser enviado pela rede.

Como você já pode perceber, nossa classe tem um nome muito semelhante à classe de idioma "nativo". O problema é: isso é exatamente o que são, mensagens de email, por isso é difícil encontrar outro nome significativo para eles.

Você tem esse problema com frequência? Como você administra isso?

Edit: @mgkrebbs acabou de comentar sobre o uso de nomes totalmente qualificados. Esta é a nossa abordagem atual, mas um pouco detalhada demais, IMHO. Eu gostaria de algo mais limpo, se possível.

naming coding-standards variables

— JSBach
fonte

2

Sempre usar a qualificação parece uma solução viável, se um pouco detalhada. Use OurCompany.EMailMessage para um tipo e SendEmailClass.EMailMessage (ou qualquer outro) para o outro. Existe algum problema com essa abordagem?

— mgkrebbs

Sim, eu pensei sobre isso, mas fica detalhado. Gostaria de algo "mais limpo", mas a solução que você propôs é a minha atual. Vou acrescentar esta a explicação

— JSBach

3

Os nomes vêm em um contexto. Geralmente um espaço para nome ou algo assim. Portanto, não deve ser um problema.

— deadalnix

+1, gosto desta pergunta. Uma vez eu fiz esta pergunta a um instrutor cerca de 7 anos atrás, e ele pensou que eu sou um completo "...." :)

— NoChance

Que linguagem você está usando? A resposta é específica do idioma. Em geral, a resposta é 'use um espaço para nome'. Em um único aplicativo Java, é bastante comum ter o mesmo nome de classe usado por meia dúzia de bibliotecas.

— kevin Cline

3

Esse é um problema sobre o espaço para nome que você usará para o seu projeto.

Basicamente, um espaço para nome é a coleção das palavras-chave fornecidas por todas as suas classes e / ou todas as classes que você deseja usar em seu projeto (incluindo as classes padrão normalmente fornecidas com o idioma / compilador / IDE).

Como um espaço para nome é uma coleção, algumas regras são basicamente aplicadas para impedir a confusão de termos sem nenhum comportamento relacionado, e algumas linguagens como o C # também permitem definir seu próprio espaço para nome normalmente e também usá-lo em outras classes.

Não confunda o espaço para nome com a palavra-chave básica do idioma, eles são uma coleção de palavras-chave, mas com uma grande diferença entre os dois: você pode modificar um espaço para nome, mas geralmente não pode modificar as palavras-chave básicas de um idioma. A soma entre o espaço para nome que você usou no seu projeto e as palavras-chave básicas do idioma que você usa fornece a quantidade total de palavras-chave.

O tópico é muito discutido na rede. Posso sugerir uma pesquisa básica com os termos "namespace [seu idioma]" ou algo assim. Não estou respondendo diretamente à sua pergunta simplesmente porque você pode ter uma abordagem diferente para diferentes idiomas.

— Micro
fonte

3

Bem, minha antiga equipe de desenvolvimento usa para acrescentar o acrônimo do aplicativo em cada classe personalizada. Tivemos, por exemplo, a classe ABCEmail .

Eu acho que é mais direto do que depender do espaço para nome, mas também pode ser uma solução complementar para o uso do espaço para nome.

Por último, mas não menos importante, como você está criando um novo objeto, significa que o objeto nativo não atende às suas necessidades, portanto o nome do seu arquivo de email pode ser CustomizedEmail , AdvancedEmail ... etc.

— Amina
fonte

11

Concordou com o seu ponto final, mas por que OAEmailseria melhor que OurApplication.Email? OAEMailtem impacto em todas as partes do software, enquanto a notação de espaço para nome afeta apenas onde a conversão ocorre e as duas classes são usadas no mesmo arquivo de origem.

— precisa

11

Penso que o prefixo é uma boa ideia quando o seu idioma não suporta namespaces. Mas se o idioma suportar alguma forma no namespacing, use-o (este é o problema que os namespaces foram projetados para resolver!). `

— Martin York

@ Steven Jeuris: O nome da classe deve ser selecionado uma vez criada. Depois, acho uma prática ruim mudar isso ... por causa de todos os impactos desnecessários.

— Amine

@Loki Astari: Eu não sei qual IDE você está usando, mas acho que um nome de classe diferente é mais fácil de manusear ao pesquisar ou abrir uma determinada classe. Vi projetos com uma versão personalizada de "email" e cada vez que desejava abrir o arquivo, precisava navegar por vários namespace. Seu argumento ainda é válido. Acho que é subjetivo à organização do pacote quantas classes personalizadas serão criadas.

— Amine

11

@Amine: Eu não sabia que você estava realmente argumentando contra namespaces. Eu sugiro que você leia um pouco mais sobre espaços para nome para ver todas as vantagens de usá-los: encapsulamento, eliminação de ambiguidade, menos redundância, ... Ps: A maioria dos IDEs modernos possui recursos de pesquisa que permitem encontrar rapidamente um arquivo de origem sem precisar navegar através a hierarquia. Quanto ao seu comentário para mim: refatoração constante faz parte do desenvolvimento de software. Quando você conseguir um nome mais adequado, com grande impacto ou não, considere renomeá-lo. No entanto, é melhor discutir isso com os colegas primeiro.

— Steven Jeuris

3

Que linguagem você está usando? A resposta é específica do idioma. Em geral, a resposta é 'use namespaces'. Eu quase nunca manipularia o nome do tipo para evitar um conflito com algum espaço para nome externo.

Em um único aplicativo Java, é bastante comum ter o mesmo nome de classe (por exemplo, "Data") definido em meia dúzia de namespaces. Se uma classe precisar usar duas classes Date separadas, uma das classes Date deverá ser totalmente qualificada em todos os lugares em que aparecer, pois o Java não suporta aliases de tipo. Em C ++, a vida é mais fácil; você pode simplesmente renomear um deles com um typedef.

— Kevin Cline
fonte

Eu estava prestes a postar uma resposta semelhante, mas em vez do exemplo de alias em C ++, queria mencionar C # usando a diretiva de alias .

— 91111 Steven Jeuris

@ Steven: Eu ia mencionar C # em vez de C ++, mas já faz alguns anos desde que eu programei em C #, e não tinha certeza.

— Kevin cline

2

Você tem esse problema com frequência? Como você administra isso?

Realmente depende do idioma que você usa. Em c ++ e java, esse problema é resolvido usando espaços para nome. Eu estou usando c ++, e acontece que eu tenho classes diferentes com o mesmo nome. Não é um problema, pois eles estão em diferentes namespaces.

Em outros idiomas, não há como evitar nomes diferentes.

— BЈовић
fonte

Para o computador, não é um problema, mas pode ser para o desenvolvedor, já que você tem o EmailMessage e o MailMessage, por exemplo.

— JSBach

@ Oscar Obviamente. Para o computador, pode ser xyz123e ainda funciona da mesma maneira. Eu não vejo outra maneira, em seguida, ficar detalhada (você disse nos comentários que está tentando evitá-la).

— BЈовић

2

Sua pergunta é muito boa. Que tal se você prefixar seu método com um prefixo como U (ou u) ou cls (abreviação de classe)? Por exemplo:

clsEMailMEssage ou uEMailMEssage

Isso não requer muita digitação e você pode dizer imediatamente que o tipo é 'seu'.

Editar - em resposta aos 2 primeiros comentários:

Gostaria de chamar a atenção do leitor para o fato de que: nem todas as notações húngaras são iguais. Devemos distinguir entre sistema húngaro e aplicativos húngaro , presumo que a sugestão acima segue o tipo de aplicativos húngaro, o que não é prejudicial.

O dano associado à notação húngara do sistema, como nomear um ID e um intID, não está presente na sugestão acima.

Para saber mais, dê uma olhada em: Fazendo o código errado parecer errado - Joel On Software

— NoChance
fonte

3

Toda vez que alguém recomenda a notação húngara, Deus mata um gatinho.

— 28911 Konamiman

2

O BIgHUmpCAmelCAsing também não ajuda.

— Steven Jeuris

Os comentários acima são apreciados. Por favor, veja minhas edições, embora eu saiba que alguns de nós não vão mudar de idéia, afinal quem quer que um gatinho seja morto? :)

— NoChance

Eu removi a votação para baixo agora que você adicionou algum raciocínio válido. No entanto, não concordo que o Apps Hungarian seja mais apropriado que os namespaces nesse cenário. Quando o idioma suporta aliases, é uma solução muito mais adequada. Veja a resposta de Kevin Cline .

— Steven Jeuris

@ Steven Jeuris, obrigado pelo seu comentário. Os namespaces são perfeitos, exceto pelo tempo de digitação, vou verificar o link que você forneceu.

— NoChance