Problemas de nomenclatura: ¿Se debe cambiar el nombre de "ISomething" a "Something"? [cerrado]

El capítulo del tío Bob sobre nombres en Clean Code recomienda evitar las codificaciones en los nombres, principalmente en relación con la notación húngara. También menciona específicamente la eliminación del Iprefijo de las interfaces, pero no muestra ejemplos de esto.

Asumamos lo siguiente:

• El uso de la interfaz es principalmente para lograr la capacidad de prueba a través de la inyección de dependencia
• En muchos casos, esto lleva a tener una única interfaz con un único implementador

Entonces, por ejemplo, ¿cómo deberían llamarse estos dos? Parsery ConcreteParser? Parsery ParserImplementation?

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

public class Parser : IParser {
     // Implementations
}

¿O debería ignorar esta sugerencia en casos de implementación única como este?

Mientras que muchos, incluido el "Tío Bob", aconsejan no usar Icomo prefijo para las interfaces, hacerlo es una tradición bien establecida con C #. En términos generales, debe evitarse. Pero si está escribiendo C #, realmente debe seguir las convenciones de ese lenguaje y usarlo. No hacerlo causará una gran confusión con cualquier otra persona familiarizada con C # que intente leer su código.

La interfaz es el concepto lógico importante, por lo tanto, la interfaz debe llevar el nombre genérico. Entonces, prefiero tener

interface Something
class DefaultSomething : Something
class MockSomething : Something

que

interface ISomething
class Something : ISomething
class MockSomething : ISomething

Este último tiene varias cuestiones:

1. Algo es solo una implementación de ISomething, pero es la que tiene el nombre genérico, como si fuera de alguna manera especial.
2. MockSomething parece derivar de Something, pero implementa ISomething. Tal vez debería llamarse MockISomething, pero nunca lo he visto en la naturaleza.
3. Refactorizar es más difícil. Si Something es una clase ahora, y luego descubre que tiene que introducir una interfaz, esa interfaz debe tener el mismo nombre, porque debe ser transparente para los clientes si el tipo es una clase concreta, una clase abstracta o una interfaz . Algo rompe eso.

Esto no se trata solo de nombrar convenciones. C # no admite la herencia múltiple, por lo que este uso heredado de la notación húngara tiene un pequeño beneficio, aunque útil, cuando hereda de una clase base e implementa una o más interfaces. Así que esto...

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

... es preferible a esto ...

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

OMI

No no no.

Las convenciones de nomenclatura no son una función de tu tío Bob fandom. No son una función del lenguaje, c # o de otra manera.

Son una función de su base de código. En mucho menor medida de su tienda. En otras palabras, el primero en la base del código establece el estándar.

Solo entonces puedes decidir. Después de eso, solo sé consistente. Si alguien comienza a ser inconsistente, quíteles su arma nerf y haga que actualicen la documentación hasta que se arrepientan.

Cuando leo una nueva base de código si nunca veo un Iprefijo, estoy bien, independientemente del idioma. Si veo uno en cada interfaz, estoy bien. Si a veces veo uno, alguien va a pagar.

Si se encuentra en el contexto enrarecido de establecer este precedente para su base de código, le insto a que considere esto:

Como clase de cliente, me reservo el derecho de no importarme lo que esté hablando. Todo lo que necesito es un nombre y una lista de cosas a las que pueda llamar contra ese nombre. Esos no pueden cambiar a menos que yo lo diga. Soy dueño de esa parte. Lo que estoy hablando, interfaz o no, no es mi departamento.

Si se cuela Icon ese nombre, al cliente no le importa. Si no hay I, al cliente no le importa. Con lo que está hablando podría ser concreto. Puede que no. Como no lo llama newde ninguna manera, no hay diferencia. Como cliente, no lo sé. No quiero saber

Ahora, como un mono de código que mira ese código, incluso en Java, esto podría ser importante. Después de todo, si tengo que cambiar una implementación a una interfaz, puedo hacerlo sin decirle al cliente. Si no hay Itradición, ni siquiera podría cambiarle el nombre. Lo que podría ser un problema porque ahora tenemos que volver a compilar el cliente porque, aunque a la fuente no le importa, el binario sí lo hace. Algo fácil de perder si nunca cambiaste el nombre.

Tal vez eso no sea un problema para ti. Tal vez no. Si es así, esa es una buena razón para preocuparse. Pero por amor a los juguetes de escritorio, no digamos que deberíamos hacer esto a ciegas porque es la forma en que se hace en algún idioma. O tienes una muy buena razón o no te importa.

No se trata de vivir con eso para siempre. Se trata de no darme una mierda sobre la base del código que no se ajusta a su mentalidad particular a menos que esté preparado para solucionar el 'problema' en todas partes. A menos que tenga una buena razón por la que no debería tomar el camino de menor resistencia a la uniformidad, no venga a predicar conformidad. Tengo mejores cosas que hacer.

Hay una pequeña diferencia entre Java y C # que es relevante aquí. En Java, cada miembro es virtual por defecto. En C #, cada miembro está sellado de manera predeterminada, excepto los miembros de la interfaz.

Los supuestos que acompañan a esto influyen en la directriz: en Java, cada tipo público debe considerarse no final, de acuerdo con el Principio de sustitución de Liskov [1]. Si solo tiene una implementación, nombrará la clase Parser; si encuentra que necesita implementaciones múltiples, simplemente cambiará la clase a una interfaz con el mismo nombre y cambiará el nombre de la implementación concreta a algo descriptivo.

En C #, la suposición principal es que cuando obtienes una clase (el nombre no comienza con I), esa es la clase que deseas. Eso sí, esto no está cerca del 100% de precisión: un contraejemplo típico sería clases como Stream(que realmente deberían haber sido una interfaz, o un par de interfaces), y todos tienen sus propias pautas y antecedentes de otros idiomas. También hay otras excepciones, como el Basesufijo bastante utilizado para denotar una clase abstracta: al igual que con una interfaz, sabes que se supone que el tipo es polimórfico.

También hay una buena característica de usabilidad al dejar el nombre sin prefijo I para la funcionalidad que se relaciona con esa interfaz sin tener que recurrir a hacer de la interfaz una clase abstracta (lo que perjudicaría debido a la falta de herencia de clase múltiple en C #). Esto fue popularizado por LINQ, que utiliza IEnumerable<T>como interfaz y Enumerablecomo depósito de métodos que se aplican a esa interfaz. Esto es innecesario en Java, donde las interfaces también pueden contener implementaciones de métodos.

En última instancia, el Iprefijo se usa ampliamente en el mundo de C # y, por extensión, en el mundo de .NET (dado que la mayoría del código de .NET está escrito en C #, tiene sentido seguir las pautas de C # para la mayoría de las interfaces públicas). Esto significa que seguramente trabajará con bibliotecas y códigos que siguen esta notación, y tiene sentido adoptar la tradición para evitar confusiones innecesarias; no es como omitir el prefijo mejorará su código :)

Supongo que el razonamiento del tío Bob fue algo como esto:

IBananaEs la noción abstracta de plátano. Si puede haber una clase de implementación que no tenga un nombre mejor que el Banana, la abstracción no tiene ningún sentido, y debe abandonar la interfaz y simplemente usar una clase. Si hay un nombre mejor (digamos, LongBananao AppleBanana), no hay razón para no usarlo Bananacomo nombre de la interfaz. Por lo tanto, usar el Iprefijo significa que tiene una abstracción inútil, lo que hace que el código sea más difícil de entender sin ningún beneficio. Y dado que la OOP estricta siempre tendrá que codificar contra interfaces, el único lugar donde no vería el Iprefijo de un tipo sería en un constructor, un ruido bastante inútil.

Si aplica esto a su IParserinterfaz de muestra , puede ver claramente que la abstracción está completamente en el territorio "sin sentido". O bien hay algo específico acerca de una aplicación concreta de un programa de análisis (por ejemplo JsonParser, XmlParser, ...), o que sólo debe utilizar una clase. No existe tal cosa como "implementación predeterminada" (aunque en algunos entornos, esto tiene sentido, especialmente COM), ya sea que haya una implementación específica o que desee una clase abstracta o métodos de extensión para los "valores predeterminados". Sin embargo, en C #, a menos que su base de código ya omita el Iprefijo, guárdelo. Solo toma una nota mental cada vez que veas un código class Something: ISomething, significa que alguien no es muy bueno siguiendo a YAGNI y construyendo abstracciones razonables.

[1] - Técnicamente, esto no se menciona específicamente en el documento de Liskov, pero es uno de los fundamentos del documento original de OOP y en mi lectura de Liskov, ella no cuestionó esto. En una interpretación menos estricta (la que toman la mayoría de los lenguajes OOP), esto significa que cualquier código que use un tipo público destinado a la sustitución (es decir, no final / sellado) debe funcionar con cualquier implementación conforme de ese tipo.

Entonces, por ejemplo, ¿cómo deberían llamarse estos dos? Analizador y Concreto Parser y ParserImplementation?

En un mundo ideal, no debe anteponer su nombre con una abreviatura ("I ...") sino simplemente dejar que el nombre exprese un concepto.

Leí en alguna parte (y no puedo encontrarlo) la opinión de que esta convención ISomething lo lleva a definir un concepto "IDollar" cuando necesita una clase "Dólar", pero la solución correcta sería un concepto llamado simplemente "Moneda".

En otras palabras, la convención facilita la dificultad de nombrar cosas y la salida es sutilmente incorrecta .

En el mundo real, los clientes de su código (que puede ser "usted del futuro") deben poder leerlo más tarde y familiarizarse con él lo más rápido (o con el menor esfuerzo) posible (entregue a los clientes de su código lo que esperan obtener).

La convención ISomething, introduce cruft / bad names. Dicho esto, el cruft no es real cruft *), a menos que las convenciones y prácticas utilizadas para escribir el código ya no sean reales; si la convención dice "use ISomething", entonces es mejor usarlo, conformarse (y funcionar mejor) con otros desarrolladores.

*) Me salgo con la suya porque "cruft" no es un concepto exacto de todos modos :)

Como mencionan las otras respuestas, el prefijo de los nombres de su interfaz Ies parte de las pautas de codificación para el marco .NET. Debido a que las clases concretas se interactúan con más frecuencia que las interfaces genéricas en C # y VB.NET, son de primera clase en esquemas de nomenclatura y, por lo tanto, deben tener los nombres más simples, IParserpor lo tanto, para la interfaz y Parserla implementación predeterminada.

Pero en el caso de Java y lenguajes similares, donde se prefieren las interfaces en lugar de las clases concretas, el tío Bob tiene razón en que Ideben eliminarse y las interfaces deben tener los nombres más simples Parser, por ejemplo, para su interfaz de analizador. Pero en lugar de un nombre basado en roles como ParserDefault, la clase debería tener un nombre que describa cómo se implementa el analizador :

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 es, por ejemplo, cómo Set<T>, HashSet<T>y TreeSet<T>se nombran.

Tienes razón en que esta convención de interfaz I = rompe las reglas (nuevas)

En los viejos tiempos, prefijaste todo con su tipo intCounter boolFlag, etc.

Si desea nombrar cosas sin el prefijo, pero también evitar 'ConcreteParser', puede usar espacios de nombres

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


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