¿Deben los nombres de interfaz comenzar con un prefijo "I"?

Con suerte, he estado leyendo " Clean Code " de Robert Martin para convertirme en un mejor programador. Si bien nada de esto hasta ahora ha sido realmente innovador, me ha hecho pensar de manera diferente sobre la forma en que diseño aplicaciones y escribo código.

Hay una parte del libro con la que no solo no estoy de acuerdo, sino que no tiene sentido para mí, específicamente en lo que respecta a las convenciones de nombres de interfaz. Aquí está el texto, tomado directamente del libro. He resaltado el aspecto de esto que encuentro confuso y quisiera aclaraciones.

Prefiero dejar las interfaces sin adornos. El I anterior, tan común en los tacos heredados de hoy, es una distracción en el mejor de los casos y demasiada información en el peor. No quiero que mis usuarios sepan que les estoy entregando una interfaz .

Tal vez sea porque solo soy un estudiante, o tal vez porque nunca he hecho ninguna programación profesional o en equipo, pero me gustaría que el usuario supiera que es una interfaz. Hay una gran diferencia entre implementar una interfaz y extender una clase.

Entonces, mi pregunta se reduce a: "¿Por qué debemos ocultar el hecho de que alguna parte del código espera una interfaz?"

Editar

En respuesta a una respuesta:

Si su tipo es una interfaz o una clase es su negocio, no el negocio de alguien que usa su código. Por lo tanto, no debe filtrar detalles de su código en este código de terceros.

¿Por qué no debería "filtrar" los detalles de si un tipo dado es una interfaz o una clase de código de terceros? ¿No es importante que el desarrollador externo use mi código para saber si implementarán una interfaz o extenderán una clase? ¿Las diferencias simplemente no son tan importantes como las imagino?

Si te detienes a pensarlo, verás que una interfaz realmente no es semánticamente muy diferente de una clase abstracta:

• Ambos tienen métodos y / o propiedades (comportamiento);
• Ninguno de los dos debe tener campos no privados (datos);
• Ninguno de los dos puede ser instanciado directamente;
• Derivar de uno significa implementar cualquier método abstracto que tenga, a menos que el tipo derivado también sea abstracto.

De hecho, las distinciones más importantes entre clases e interfaces son:

• Las interfaces no pueden tener datos privados;
• Los miembros de la interfaz no pueden tener modificadores de acceso (todos los miembros son "públicos");
• Una clase puede implementar múltiples interfaces (en lugar de poder heredar generalmente de una sola clase base).

Dado que las únicas distinciones particularmente significativas entre clases e interfaces giran en torno a (a) datos privados y (b) jerarquía de tipos, ninguno de los cuales hace la menor diferencia para una persona que llama, generalmente no es necesario saber si un tipo es una interfaz o una clase. Ciertamente no necesitas la indicación visual .

Sin embargo, hay ciertos casos de esquina a tener en cuenta. En particular, si está usando reflexión, intercepción, proxies / mixins dinámicos, tejido de bytecode, generación de código o cualquier cosa que implique meterse directamente con el sistema de mecanografía o el código del entorno, entonces es muy útil y, a veces, es necesario saberlo de inmediato. Bate si estás tratando con una interfaz o una clase. Claramente, no desea que su código falle misteriosamente porque trató de agregar una clase, en lugar de una interfaz, como un mixin.

Sin embargo, para el código de lógica de negocios típico, común y corriente, las distinciones entre clases abstractas e interfaces no necesitan anunciarse porque nunca entrarán en juego.

Dicho todo esto, tiendo a prefijar mis interfaces C # de Itodos modos porque esa es la convención .NET utilizada y defendida por Microsoft. Y cuando estoy explicando las convenciones de codificación a un nuevo desarrollador, es mucho menos complicado usar las reglas de Microsoft que explicar por qué tenemos nuestras propias reglas "especiales".

En muchos sentidos, la coherencia es más importante que la convención. Mientras sea coherente en sus esquemas de nombres, no será difícil trabajar con ellos. Prefije las interfaces con un yo si lo desea, o simplemente deje el nombre sin adornos, ¡no me importa siempre que elija un estilo y se quede con él!

El libro está lleno de cosas buenas, pero aún agregaría "I" al nombre de la interfaz.

Imagina que tienes public interface ILoguna implementación predeterminada public class Log.

Ahora, si decides tenerlo public interface Log, de repente tienes que cambiar la clase de Log a public class LogDefaultalgo en esas líneas. Pasaste de tener un personaje extra a siete, seguramente eso es un desperdicio.

A menudo hay una delgada línea entre la teoría y la práctica. En teoría esta es una muy buena idea, pero en la práctica no es tan buena.

Bueno, esto no se trata de implementar la interfaz o extender una clase. En estos casos, usted sabe de todos modos lo que está haciendo.

Sin embargo, cuando el código de un tercero (otro módulo de la aplicación, por ejemplo) manipula sus datos, este código no debería importarle si presenta una interfaz o una clase.

Este es todo el punto de abstracción. Está presentando a este código de terceros un objeto de un tipo dado. Este tipo dado tiene alguna función miembro a la que puede llamar. Eso es suficiente.

Si su tipo es una interfaz o una clase es su negocio, no el negocio de alguien que usa su código. Por lo tanto, no debe filtrar detalles de su código a este código de terceros.

Por cierto, las interfaces y las clases son tipos de referencia al final. Y esto es lo que importa. Entonces, esto es lo que su convención de nomenclatura debe enfatizar.

La mayoría de las respuestas parecen suponer que el lenguaje de programación es Java o C #, donde hay un concepto (o palabra clave) para interfaces / clases abstractas. En estos casos, en un IDE decente, es inmediatamente visible con qué tipo de clase uno trata y la escritura public interface IMyClasses una duplicación innecesaria. Es como si no escribiera public final FinalMyClass: imagine poner cada palabra clave en el nombre de la clase.

Sin embargo, en mi opinión en C ++, la situación es un poco diferente, ya que uno tiene que sumergirse en el archivo de encabezado y ver si la clase tiene algún método virtual para averiguar si es una clase abstracta. En ese caso, puedo ver claramente un argumento para escribir class AbstractMyClass.

Entonces mi respuesta sería: depende del lenguaje de programación.

Actualizado 2016: 2 años de experiencia en C ++ más adelante Probablemente ahora consideraría una mala práctica prefijar los nombres de clase Abstract, aunque diría que probablemente hay bases de código que son tan complejas que podría tener sentido.

Sigue los modismos del idioma que estás utilizando.

Cada idioma tiene sus propios modismos y pautas de codificación. Por ejemplo, en C #, es idiomático prefijar interfaces con I. En Go, no lo es.

En mi código (Java), tiendo a tener esta convención en las API que expongo a las personas que llaman:

• La funcionalidad se proporciona a través de interfaces, y nunca por clases.
• Las partes no funcionales son clases.

Por no funcional, me refiero a cosas como estructuras de datos puros (como clases que actúan como puentes para la serialización XML o el ORM), enumeraciones y excepciones, todas las cuales no pueden ser interfaces (bueno, puede hacerlo para las clases de datos puros , pero es mucho trabajo para muy poca ganancia ya que no hay nada que hagan esas clases excepto mantener datos).

En términos de convenciones de nomenclatura, las interfaces tienden a correlacionarse con nombres de actores (por ejemplo, FooBarWatcher) o adjetivos (por ejemplo, FooBarWatchable) y tanto las clases de datos puros como las enumeraciones se asignan a nombres no activos (por ejemplo, FooBarStatus); El IDE puede guiar al consumidor de API sin convenciones de nomenclatura especiales. Excepciones siguen las convenciones habituales (Java FooBarException, FooBarError, FooBarFault), por supuesto.

A menudo también pongo las interfaces en su propio paquete o incluso en su propia biblioteca, solo para asegurarme de que no tengo la tentación de romper mis propias reglas. (Esto también me ayuda a administrar la compilación cuando obtengo el código de fuentes externas como documentos WSDL).