Problemas de nomeação: "ISomething" deve ser renomeado para "Something"? [fechadas]

O capítulo do tio Bob sobre nomes no Código Limpo recomenda que você evite codificações em nomes, principalmente em relação à notação húngara. Ele também menciona especificamente a remoção do Iprefixo das interfaces, mas não mostra exemplos disso.

Vamos assumir o seguinte:

• O uso da interface é principalmente para obter testabilidade através da injeção de dependência
• Em muitos casos, isso leva a ter uma única interface com um único implementador

Então, por exemplo, como devem ser nomeados esses dois? Parsere ConcreteParser? Parsere ParserImplementation?

public interface IParser {
    string Parse(string content);
    string Parse(FileInfo path);
}

public class Parser : IParser {
     // Implementations
}

Ou devo ignorar essa sugestão em casos de implementação única como essa?

Enquanto muitos, incluindo o "tio Bob", recomendam não usar Icomo prefixo para interfaces, isso é uma tradição bem estabelecida com o C #. Em termos gerais, deve ser evitado. Mas se você estiver escrevendo C #, realmente deve seguir as convenções desse idioma e usá-las. Não fazer isso causará grande confusão com qualquer pessoa familiarizada com C # que tente ler seu código.

A interface é o conceito lógico importante, portanto, a interface deve conter o nome genérico. Então, eu prefiro ter

interface Something
class DefaultSomething : Something
class MockSomething : Something

do que

interface ISomething
class Something : ISomething
class MockSomething : ISomething

Este último tem vários problemas:

1. Algo é apenas uma implementação do ISomething, mas é aquele com o nome genérico, como se fosse algo especial.
2. MockSomething parece derivar de Something, mas implementa ISomething. Talvez devesse se chamar MockISomething, mas nunca vi isso na natureza.
3. Refatorar é mais difícil. Se Something for uma classe agora, e você descobrir mais tarde que precisa introduzir uma interface, essa interface deverá ter o mesmo nome, porque deve ser transparente para os clientes se o tipo é uma classe concreta, uma classe abstrata ou uma interface . Alguma coisa quebra isso.

Não se trata apenas de convenções de nomenclatura. O C # não suporta herança múltipla, portanto, esse uso herdado da notação húngara tem um pequeno benefício, embora útil, em que você está herdando de uma classe base e implementando uma ou mais interfaces. Então, é isso...

class Foo : BarB, IBarA
{
    // Better...
}

... é preferível a isso ...

class Foo : BarB, BarA
{
    // Dafuq?
}

IMO

Não não não.

As convenções de nomenclatura não são uma função dos seus fãs do tio Bob. Eles não são uma função da linguagem, c # ou de outra forma.

Eles são uma função da sua base de código. Em uma extensão muito menor de sua loja. Em outras palavras, o primeiro na base de código define o padrão.

Só então você decide. Depois disso, apenas seja consistente. Se alguém começar a ser inconsistente, tire sua arma nerf e faça com que atualizem a documentação até que se arrependam.

Ao ler uma nova base de código, se eu nunca Ivir um prefixo, estou bem, independentemente do idioma. Se eu vejo um em cada interface, estou bem. Se às vezes vejo uma, alguém vai pagar.

Se você se encontra no contexto rarefeito de definir esse precedente para sua base de código, recomendo que você considere isso:

Como classe cliente, reservo-me o direito de não dar a mínima para o que estou falando. Tudo o que preciso é de um nome e uma lista de coisas que eu possa chamar contra esse nome. Isso pode não mudar, a menos que eu diga. Eu possuo essa parte. O que estou falando, interface ou não, não é meu departamento.

Se você esgueirar-se Icom esse nome, o cliente não se importará. Se não houver I, o cliente não se importa. O que está falando pode ser concreto. Talvez não. Como não o chama newde qualquer maneira, não faz diferença. Como cliente, eu não sei. Eu não quero saber

Agora, como um macaco de código olhando para esse código, mesmo em java, isso pode ser importante. Afinal, se eu tiver que alterar uma implementação para uma interface, posso fazer isso sem informar o cliente. Se não houver Itradição, talvez nem o renomeie. O que pode ser um problema, porque agora precisamos recompilar o cliente, porque, embora a fonte não se importe com o binário, Algo fácil de perder se você nunca mudou o nome.

Talvez isso não seja um problema para você. Talvez não. Se for, é uma boa razão para se importar. Mas, pelo amor aos brinquedos de mesa, não afirme que devemos fazer isso cegamente, porque é assim que é feito em algum idioma. Ou tem uma razão muito boa ou não se importa.

Não se trata de viver com isso para sempre. É sobre não me dar a mínima para a base de código não estar de acordo com sua mentalidade em particular, a menos que você esteja preparado para corrigir o 'problema' em todos os lugares. A menos que você tenha uma boa razão para não seguir o caminho de menor resistência à uniformidade, não venha a mim pregando a conformidade. Eu tenho coisas melhores para fazer.

Há uma pequena diferença entre Java e C # que é relevante aqui. Em Java, cada membro é virtual por padrão. Em C #, todos os membros são selados por padrão - exceto os membros da interface.

As suposições que acompanham isso influenciam a diretriz - em Java, todo tipo público deve ser considerado não final, de acordo com o Princípio de Substituição de Liskov [1]. Se você tiver apenas uma implementação, nomeará a classe Parser; se você achar que precisa de várias implementações, altere a classe para uma interface com o mesmo nome e renomeie a implementação concreta para algo descritivo.

Em C #, a principal suposição é que, quando você obtém uma classe (o nome não começa com I), essa é a classe que você deseja. Lembre-se, isso não chega nem perto de 100% de precisão - um contra-exemplo típico seria de classes como Stream(que realmente deveriam ter sido uma interface ou algumas interfaces), e todo mundo tem suas próprias diretrizes e experiências de outros idiomas. Há também outras exceções, como o Basesufixo bastante usado para denotar uma classe abstrata - assim como em uma interface, você sabe que o tipo deve ser polimórfico.

Há também um bom recurso de usabilidade ao deixar o nome sem prefixo I para a funcionalidade relacionada a essa interface sem ter que recorrer a transformar a interface em uma classe abstrata (o que prejudicaria devido à falta de herança múltipla de classe em C #). Isso foi popularizado pelo LINQ, que usa IEnumerable<T>como interface e Enumerablecomo repositório de métodos que se aplicam a essa interface. Isso é desnecessário em Java, onde as interfaces também podem conter implementações de métodos.

Por fim, o Iprefixo é amplamente usado no mundo C # e, por extensão, no mundo .NET (como a maioria do código .NET é escrita em C #, faz sentido seguir as diretrizes C # para a maioria das interfaces públicas). Isso significa que você quase certamente estará trabalhando com bibliotecas e códigos que seguem essa notação, e faz sentido adotar a tradição para evitar confusões desnecessárias - não é como omitir o prefixo que tornará seu código melhor :)

Suponho que o raciocínio do tio Bob fosse algo assim:

IBananaé a noção abstrata de banana. Se pode haver qualquer classe de implementação que não teria um nome melhor do que isso Banana, a abstração é totalmente sem sentido e você deve descartar a interface e usar apenas uma classe. Se houver um nome melhor (digamos, LongBananaou AppleBanana), não há razão para não usar Bananacomo o nome da interface. Portanto, o uso do Iprefixo significa que você possui uma abstração inútil, o que dificulta a compreensão do código sem nenhum benefício. E como o OOP estrito fará com que você sempre codifique contra interfaces, o único lugar onde você não veria o Iprefixo em um tipo seria em um construtor - ruído bastante inútil.

Se você aplicar isso à sua IParserinterface de amostra , poderá ver claramente que a abstração está inteiramente no território "sem sentido". Ou há algo específico sobre a implementação concreta de um analisador (por exemplo JsonParser, XmlParser...), ou você deve usar apenas uma classe. Não existe "implementação padrão" (embora em alguns ambientes isso realmente faça sentido - principalmente COM), existe uma implementação específica ou você deseja uma classe abstrata ou métodos de extensão para os "padrões". No entanto, em C #, a menos que sua base de código já omita o Iprefixo-, mantenha-o. Faça uma anotação mental sempre que vir código class Something: ISomething- isso significa que alguém não é muito bom em seguir o YAGNI e criar abstrações razoáveis.

[1] - Tecnicamente, isso não é mencionado especificamente no artigo de Liskov, mas é um dos fundamentos do artigo original da POO e, na minha leitura de Liskov, ela não contestou isso. Em uma interpretação menos rigorosa (a adotada pela maioria das linguagens OOP), isso significa que qualquer código que utilize um tipo público destinado a substituição (por exemplo, não final / selado) deve funcionar com qualquer implementação em conformidade desse tipo.

Então, por exemplo, como devem ser nomeados esses dois? Analisador e ConcreteParser? Parser e ParserImplementation?

Em um mundo ideal, você não deve prefixar seu nome com uma mão curta ("I ..."), mas simplesmente deixar o nome expressar um conceito.

Eu li em algum lugar (e não posso obtê-lo) a opinião de que esta convenção ISomething leva você a definir um conceito "IDollar" quando você precisa de uma classe "Dollar", mas a solução correta seria um conceito chamado simplesmente "Moeda".

Em outras palavras, a convenção dá uma saída fácil à dificuldade de nomear as coisas e a saída fácil está sutilmente errada .

No mundo real, os clientes do seu código (que podem ser apenas "você do futuro") precisam ser capazes de lê-lo mais tarde e familiarizá-lo o mais rápido (ou com o mínimo de esforço) possível (fornecer aos clientes do seu código o que eles esperam obter).

A convenção ISomething apresenta nomes de cruft / bad. Dito isto, o cruft não é real *), a menos que as convenções e práticas usadas na escrita do código não sejam mais reais; se a convenção diz "use ISomething", é melhor usá-lo, em conformidade (e funcionar melhor) com outros desenvolvedores.

*) Posso dizer que isso porque "cruft" não é um conceito exato de qualquer maneira :)

Como as outras respostas mencionam, prefixar seus nomes de interface Ifaz parte das diretrizes de codificação da estrutura .NET. Como as classes concretas são mais frequentemente interagidas do que as interfaces genéricas em C # e VB.NET, elas são de primeira classe em esquemas de nomenclatura e, portanto, devem ter os nomes mais simples - portanto, IParserpara a interface e Parsera implementação padrão.

Porém, no caso de Java e linguagens similares, onde as interfaces são preferidas em vez de classes concretas, o Tio Bob está certo em que Ideve ser removido e as interfaces devem ter os nomes mais simples - Parserpara a interface do analisador, por exemplo. Mas, em vez de um nome baseado em função ParserDefault, a classe deve ter um nome que descreva como o analisador é implementado :

public interface Parser{
}

public class RegexParser implements Parser {
    // parses using regular expressions
}

public class RecursiveParser implements Parser {
    // parses using a recursive call structure
}

public class MockParser implements Parser {
    // BSes the parsing methods so you can get your tests working
}

Este é, por exemplo, como Set<T>, HashSet<T>, e TreeSet<T>são nomeados.

Você está certo de que esta convenção I = interface quebra as (novas) regras

Antigamente, você prefixava tudo com seu tipo intCounter boolFlag etc.

Se você quiser nomear coisas sem o prefixo, mas também evitar 'ConcreteParser', poderá usar namespaces

namespace myapp.Interfaces
{
    public interface Parser {...
}


namespace myapp.Parsers
{
    public class Parser : myapp.Interfaces.Parser {...
}