Nombres de interfaz en Java [cerrado]

¿Hay realmente una diferencia entre:

class User implements IUser

Y

class UserImpl implements User

¿Si todo lo que estamos hablando son convenciones de nombres?

Personalmente prefiero NO preceder la interfaz con Iya que quiero codificar la interfaz y considero que sea más importante en términos de la convención de nomenclatura. Si llamas a la interfaz IUser entonces cada consumidor de esa clase necesita saber que es un IUser. Si llama a la clase UserImpl entonces solo la clase y su DI contenedor saber acerca de la parte Impl y los consumidores solo saben que están trabajando con un User.

Por otra parte, las veces que me he visto obligado a usar Impl porque un mejor nombre no se presenta han sido pocos y distantes entre sí porque la implementación se nombra de acuerdo a la implementación porque ahí es donde es importante, por ejemplo,

class DbBasedAccountDAO implements AccountDAO
class InMemoryAccountDAO implements AccountDAO

Puede haber varias razones por las que Java no utiliza generalmente la convención IUser.

1. Parte del enfoque orientado a objetos es que no debe tener que saber si el cliente está utilizando una interfaz o una clase de implementación. Por lo tanto, incluso List es una interfaz y String es una clase real, un método puede pasarse a ambos - no tiene sentido distinguir visualmente las interfaces.

2. En general, preferiremos el uso de interfaces en código de cliente (prefiera List a ArrayList, por ejemplo). Por lo tanto, no tiene sentido hacer que las interfaces se destaquen como excepciones.

3. La convención de nomenclatura de Java prefiere nombres más largos con significados reales a los prefijos de estilo húngaro. Para que el código sea lo más legible posible: una Lista representa una lista, y un Usuario representa un usuario-no un IUser.

También hay otra convención, utilizada por muchos proyectos de código abierto, incluyendo Spring.

interface User {
}

class DefaultUser implements User {
}

class AnotherClassOfUser implements User {
}

Personalmente no me gusta el prefijo "I" por la simple razón de que es una convención opcional. Así que si adopto esto ¿IIOPConnection significa una interfaz para IOPConnection? ¿Qué pasa si la clase no tiene el prefijo "I", entonces sé que no es una interfaz..la respuesta aquí es no, porque las convenciones no siempre se siguen, y vigilarlas creará más trabajo que la convención se salva.

Como dijo otro poster, normalmente es preferible que las interfaces definan capacidades y no tipos. Yo tendería a no "implementar" algo como un "Usuario", y esta es la razón por la que" IUser " a menudo no es realmente necesario en la forma descrita aquí. A menudo veo las clases como sustantivos e interfaces como adjetivos:

class Number implements Comparable{...}  
class MyThread implements Runnable{...}
class SessionData implements Serializable{....}

A veces un Adjetivo no tiene sentido, pero todavía estaría generalmente usando interfaces para modelar el comportamiento, acciones, capacidades, propiedades, etc... no tipos.

Además, si realmente solo vas a hacer un Usuario y llamarlo Usuario, ¿cuál es el punto de tener también una interfaz IUser? Y si vas a tener algunos tipos diferentes de usuarios que necesitan implementar una interfaz común, ¿qué es lo que le ahorra agregar una "I" a la interfaz al elegir los nombres de las implementaciones?

Creo que un ejemplo más realista sería que algunos tipos de usuarios necesitan poder iniciar sesión en una API en particular. Podríamos definir una interfaz de inicio de sesión, y luego tener una clase padre "Usuario" con Superusuario, DefaultUser, AdminUser, AdministrativeContact, etc suclasses, algunos de los cuales implementarán o no el Inicio de sesión (Loginable?) según sea necesario.

Bob Lee dijo una vez en una presentación:

¿Cuál es el punto de una interfaz si tener una sola implementación.

Entonces, comienza con una implementación, es decir, sin una interfaz. más tarde usted decide, bueno, hay una necesidad de una interfaz aquí, por lo que convertir su clase a una interfaz.

Entonces se vuelve obvio: su clase original se llamaba User. su interfaz ahora se llama Usuario. tal vez tengas un UserProdImpl y un UserTestImpl. si diseñado su aplicación bien, cada clase (excepto los que instancian Usuario) será sin cambios y no se dará cuenta de que de repente se les pasa una interfaz.

Para que quede claro -> Implementación de usuario de interfaz UserImpl.

En C # es

public class AdminForumUser : UserBase, IUser

Java diría

public class AdminForumUser extends User implements ForumUserInterface

Debido a eso, no creo que las convenciones sean tan importantes en Java para las interfaces, ya que hay una diferencia explícita entre la herencia y la implementación de la interfaz. Yo diría que simplemente elija cualquier convención de nomenclatura que desee, siempre y cuando sea consistente y use algo para mostrar a la gente que estas son interfaces. No he hecho Java en unos pocos años, pero todas las interfaces solo estarían en su propio directorio, y esa fue la convención. Nunca tuve ningún problema con él.

En mi experiencia, la convención "I" se aplica a las interfaces que están destinadas a proporcionar un contrato a una clase, particularmente cuando la interfaz en sí no es una noción abstracta de la clase.

Por ejemplo, en tu caso, solo esperaría ver IUser si el único usuario que pretendes tener es User. Si planea tener diferentes tipos de usuarios - NoviceUser, ExpertUser, etc. - Yo esperaría ver una interfaz User (y, tal vez, una clase AbstractUser que implementa algunos funcionalidad, como get/setName()).

También esperaría interfaces que definan capacidades - Comparable, Iterable, etc. - ser nombrado así, y no como IComparable o IIterable.

Siguiendo buenos principios de OO, su código debería (en la medida de lo práctico/posible) depender de abstracciones en lugar de clases concretas. Por ejemplo, generalmente es mejor escribir un método como este:

public void doSomething(Collection someStuff) {
    ...
}

Que esto:

public void doSomething(Vector someStuff) {
    ...
}

Si sigues esta idea, entonces mantengo que tu código será más legible si le das nombres a las interfaces como "Usuario" y "BankAccount" (por ejemplo), en lugar de "IUser", "UserInterface" u otras variaciones.

Los únicos bits de código que debe preocuparse por las clases de hormigón reales son los lugares donde se construyen las clases de hormigón. Todo lo demás debe escribirse usando las interfaces.

Si haces esto, entonces los nombres de clase concretos "feos" como "UserImpl" deberían ocultarse de forma segura del resto del código, que puede continuar alegremente usando los nombres de interfaz "agradables".

=v= El prefijo "I" también se usa en el marco de Wicket, donde me acostumbré rápidamente. En general, doy la bienvenida a cualquier convención que acorta los nombres de clase de Java engorrosos. Es una molestia, sin embargo, que todo está alfabetizado bajo "I" en los directorios y en el Javadoc.

La práctica de codificación Wicket es similar a Swing, ya que muchas instancias de control/widget se construyen como clases internas anónimas con declaraciones de métodos en línea. Molesto, difiere 180° de Swing en que Swing usa un prefijo ("J") para las clases implementadoras.

El sufijo "Impl" es una abreviatura irregular y no se internacionaliza bien. Si al menos nos hubiéramos ido con "Imp" sería más lindo (y más corto). "Impl" se usa para el COI, especialmente para la primavera, así que estamos atascados con él por ahora. Se pone un poco esquizo siguiendo 3 convenciones diferentes en tres partes diferentes de una base de código, sin embargo.

¿Es esta una convención de nomenclatura más amplia en algún sentido real? Estoy más en el lado de C++, y no realmente en Java y descendientes. ¿Cuántas comunidades lingüísticas utilizan la I convención?

Si tiene aquí una convención de nomenclatura estándar de la tienda independiente del idioma, úsela. Si no, vaya con la convención de nomenclatura del idioma.