2010-02-23 11 views

Respuesta

12

No, esto no es convencional. Al menos no está dentro del JDK. Dicho esto, si su tienda tiene esto como una convención, aunque no sea una práctica en el exterior, le sugiero que haga lo mismo. Mantener la consistencia dentro de un equipo es más importante con respecto a las convenciones.

19

Eso no se hace típicamente en Java - es una cosa NET C# /..

Personalmente, me gusta ya que creo que la fuga de información que no debe ser filtrada. El código debe escribirse de manera independiente en cuanto a si un objeto se maneja a través de una interfaz o directamente a través de una API de clase.

+0

Es probable que los conferenciantes recogieran esa convención de un idioma que usaban anteriormente y simplemente asumieron que era una convención de Java también y lo enseñó como tal. – David

+6

Es curioso que Microsoft haya eliminado la notación húngara para casi todo, pero todavía siente que necesitan decírselo mirando el nombre de que es una interfaz. –

+7

Es bastante común en algunas bibliotecas de Java (por ejemplo, SDK de Eclipse) – Uri

-1

Esta es sin duda la convención .NET, y Microsoft lo hace con sus propias interfaces de la biblioteca de clases base de .NET. Era la convención de Java cuando hice Java, y no puedo imaginar que haya cambiado, aunque no estoy actualizado con Java.

En un aparte en C++ también siempre usa como prefijo con un 'yo' y de hecho siempre se utiliza para clases de prefijo con 'C'. No llevamos esta convención 'C' a .NET.

+6

Esto es incorrecto, nunca ha estado cerca de ser una convención general entre los programadores de Java ... quizás quiso decir "No fue la convención de Java ..." ?? –

+0

Entonces me corrijo. Supongo que fue algo que siempre hicimos y asumí que era una convención. – MrLane

1

Es una convención de programación familiar, pero su prevalencia depende de la API. Por ejemplo, en general no es seguido por la biblioteca estándar de Java, donde cosas como colecciones son interfaces, pero se nombran como sus conceptos matemáticos. Por otro lado, algunas API importantes como Eclipse lo usan de manera consistente.

Un argumento oí contra el uso del prefijo es que uno está poniendo en esencia un problema de idioma (es decir, la dicothomy de interfaces y clases) en el esquema de nombres. Otra es que "todo en una API pública debería ser una interfaz y no una clase de todos modos". Dado que muchas clases que implementan la interfaz se llaman "XImpl", se podría argumentar que puede ser superfluo. Sin embargo, usar el prefijo puede tener sentido si el tipo es simplemente un marcador.

+1

la API de eclipse? – Woot4Moo

+0

@ Woot4Moo: ¿Estás argumentando que no es importante o que no es una API? Ciertamente se refieren a ella como una API. – Uri

+0

Nunca escuché el eclipse llamado API. Lo he oído llamar un IDE e incluso un SDK (que es sospechoso en el mejor de los casos) – Woot4Moo

2

En Java, la convención es intentar finalizar sus interfaces en "able". Serializable, Clonable, y así sucesivamente. En .NET comienzan con "I".

me quedo con el criterio de que es estándar en su lenguaje (es decir, tratar extensión "poder"). No estoy de acuerdo con Software Monkey en que "filtra información que no debe filtrarse". Está perfectamente bien tener un nombre que sea indicativo de qué tipo de cosa es, en mi humilde opinión.

+4

Al igual que Listable ... oh wait – Woot4Moo

+3

No creo que haya realmente una extensión "capaz". Se trata más bien de hacer que sea un adjetivo o un rol en lugar de una operación (por ejemplo, Escucha, Visitante, etc.) – Uri

+0

según la convención de nomenclatura de las interfaces, algo que se puede enumerar sería enumerable o ible no seguro de cuál, pero termina con ble :) – Woot4Moo

4

Se usa bastante en Eclipse Framework. Depende de los estilos de proyecto individuales, pero no es una convención estándar. Sin embargo, ciertamente puede ayudar a programar el mantenimiento y la búsqueda en algunos casos.

-8

I, err, no me gusta este tipo de cosas. Trabajé con un producto Java que lo hizo y fue enloquecedor.

En última instancia, este tipo de cosas data de FORTRAN-I en la década de 1950 cuando I, J, K, ... hasta que me olvido de dónde eran automáticamente enteros y el resto del alfabeto era real (coma flotante).

+1

Veo que tengo al menos 3 fanáticos silenciosos. ¿Alguna * razón * para su elección? – EJP

+1

Creo que esta es la palabra "odio" y el hecho de que está fuera de tema y subjetivo. (PD: no te devolví) – chburd

+2

Blimey. 4 downvotes por una palabra y cero atención por la otra 46 que son hechos históricos. Y niego que sea fuera de tema. – EJP

5

El uso de un prefijo "I" en las interfaces es algo fundado por COM (.NET acaba de heredar esta convención) y no es un estándar en Java. Mire cualquiera de los JDK u otro código desarrollado por Sun y no verá un prefijo I. Y no es solo Sun, la mayoría de los proyectos de Java no usan el prefijo I. Lejos de ser un estándar Java, el prefijo I es una aberración adoptada en algunos rincones del mundo Java.

+3

LOL en la votación negativa. Cuidado para explicar por qué? –

3

que quería mencionar que en el otro lado, una verdadera puesta en práctica de una interfaz, se puede encontrar el postfix Impl o todo un paquete de nombre impl (example).

Pero esto no es un estándar de todos modos.

+0

@jax: +1 ... En un mundo donde traduces de OOA/OOD a OOP, entonces todo lo que importa son abstracciones. Tengo mucha suerte y trabajo en algún lugar donde * cada * abstracción está definida por una interfaz (se deriva en parte, pero no solo, del hecho de ser traductores de OOA/D, estamos usando herencia múltiple todo el tiempo, y bajo Java eso significa interfaces + delegación). No ponemos 'I' delante de los nombres de la interfaz, sin embargo ponemos 'Impl' después de * cada * implementación de clase, para asegurarnos de recordar siempre que estos son detalles de implementación y que nunca deberían estar "programados para". – SyntaxT3rr0r

1

No recomendaría su uso. Nunca se sabe si su interfaz se convierte en clase abstracta de un día. Entonces tendrías que renombrar cada uso individual o simplemente quedarte con la fea clase abstracta nombrada con el prefijo.

(Fuente: Robert C. Martin - desarrollo ágil de software: principios, modelos y prácticas)

+1

no puede convertirse en clase abstracta porque rompería el código. no puedes hacer "implementa AbstractClass". Como no puedes cambiar el nombre de la clase, no puedes cambiar "implements" para "extender". – IAdapter

+0

Correcto, mi culpa. Me confundí un poco con C# donde usas ":" para extender e implementar. –

+1

@ 01 A la inversa, es igualmente importante. Si tiene una clase abstracta de la que decide crear una interfaz, tendrá que alejarse de la convención elegida y tener una interfaz sin la notación I (bueno, una de las suyas y todas las estándar) y la descansa con la notación I (o el código se romperá). – Fredrik

0

Este tipo de estilo de codificación se llama notación húngara , ya que fue inventado por Charles Simonyi en Microsoft, quien es húngaro El objetivo de la notación húngara es codificar información semántica que no se puede expresar dentro del sistema de tipos en nombres de identificadores.

Sin embargo, sistema de tipos de Java es perfectamente capaz de distinguir entre las interfaces (solo tratan de extend uno con una clase), las clases abstractas (solo tratan de crear una instancia de uno) y clases (solo tratan de implement uno), y también lo son la mayoría IDEs. Entonces, usar la notación húngara de esta manera es completamente inútil.

Nunca ha sido una convención hasta donde yo sé, y ciertamente no lo es ahora. Al menos en la comunidad Java. (Sin embargo, hay algunos proyectos Java que lo usan. También a veces se usa en C++, pero tiene sentido, porque no existe una interfaz en C++, por lo que debe tener una forma de marcarlos. También se usa en la CLI, donde no tiene ningún sentido por la misma razón que en Java).

+1

¿Tiene una referencia donde hacen esta parte de HN? En mi mundo HN se usa principalmente en nombres de variables, no en nombres de tipos. – Fredrik

Cuestiones relacionadas