coding style - guidelines - Confundido acerca de las pautas de codificación de Interfaz y Clase para TypeScript

google typescript

Question

Leí las directrices de codificación de TypeScript.

Y encontré esta declaración bastante desconcertante:

No use "I" como prefijo para los nombres de interfaz

Quiero decir que algo como esto no tendría mucho sentido sin el prefijo "I"

class Engine implements IEngine

¿Me estoy perdiendo algo obvio?

Otra cosa que no entendí del todo fue:

Las clases

Por coherencia, no utilice clases en la canalización del compilador principal. Utilice los cierres de funciones en su lugar.

¿Eso dice que no debería usar clases?

Espero que alguien me pueda aclarar :)

Answer 1

Aclaración sobre el enlace al que hace referencia:

Esta es la documentación sobre el estilo del código para TypeScript y no una guía de estilo sobre cómo implementar su proyecto.

Si usar el prefijo I tiene sentido para usted y su equipo, utilícelo (yo lo hago).

Si no es así, tal vez el estilo Java de SomeThing (interfaz) con SomeThingImpl (implementación) lo use por todos los medios.

Answer 2

Cuando un equipo / empresa envía un marco / compilador / conjunto de herramientas, ya tienen algo de experiencia, conjunto de mejores prácticas. Lo comparten como pautas. Las pautas son recomendaciones . Si no te gusta ninguno puedes ignorarlos. El compilador todavía compilará tu código. Aunque cuando en Roma ...

Esta es mi visión por la que el equipo de TypeScript recomienda no las interfaces de prefijo.

Razón # 1 Los tiempos de la notación húngara han pasado.

El principal argumento de I -prefix-for-interface supporters es que el prefijo es útil para el grokking inmediato (peeking) si el tipo es una interfaz. La declaración de que el prefijo es útil para el grokking (peeking) es una apelación a la notación húngara . Prefijo el nombre de la interfaz, C para la clase, A para la clase abstracta, s para la variable de cadena, c para la variable const, i para la variable entera. Estoy de acuerdo en que dicha decoración de nombres puede proporcionarle información de tipo sin mover el mouse sobre el identificador o navegar a la definición de tipo a través de una tecla de acceso rápido. Este pequeño beneficio es superado por las desventajas de la notación húngara y otras razones que se mencionan a continuación. La notación húngara no se utiliza en marcos contemporáneos. C # tiene un prefijo (y este es el único prefijo en C #) para las interfaces debido a razones históricas (COM). En retrospectiva, uno de los arquitectos .NET (Brad Abrams) cree que hubiera sido mejor no usar el prefijo I TypeScript es COM-legacy-free, por lo que no tiene ninguna regla I -prefijo para la interfaz.

Razón # 2 I prefijo viola el principio de encapsulación

Supongamos que consigues alguna caja negra. Obtienes una referencia de tipo que te permite interactuar con ese cuadro. No debe importarte si es una interfaz o una clase. Solo usas su parte de interfaz. Exigir saber qué es (interfaz, implementación específica o clase abstracta) es una violación de la encapsulación.

Ejemplo: supongamos que necesita corregir el mito de diseño de API: Interfaz como contrato en su código, por ejemplo, elimine la interfaz ICar y use la clase base de Car en su lugar. Entonces necesita realizar dicho reemplazo en todos los consumidores. I -prefix conduce a la dependencia implícita de los consumidores en los detalles de implementación de caja negra.

Razón # 3 Protección de mala denominación

Los desarrolladores son perezosos a pensar correctamente acerca de los nombres. Nombrar es una de las dos cosas difíciles en informática . Cuando un desarrollador necesita extraer una interfaz, es fácil agregar la letra I al nombre de la clase y se obtiene un nombre de interfaz. Deshabilitar el prefijo I para interfaces obliga a los desarrolladores a forzar sus cerebros para elegir nombres apropiados para las interfaces. Los nombres elegidos deben ser diferentes no solo en el prefijo, sino también en la diferencia de intención.

Caso de abstracción: no debe definir una interfaz ICar y una clase de Car asociada. Car es una abstracción y debe ser la utilizada para el contrato. Las implementaciones deben tener nombres descriptivos y distintivos, por ejemplo SportsCar, SuvCar, HollowCar .

Buen ejemplo: WpfeServerAutosuggestManager implements AutosuggestManager , FileBasedAutosuggestManager implements AutosuggestManager .

Mal ejemplo: AutosuggestManager implements IAutosuggestManager .

Razón # 4 Los nombres elegidos correctamente lo vacunan contra el mito de diseño de API: Interfaz como contrato .

En mi práctica, conocí a mucha gente que duplicó sin pensar parte de la interfaz de una clase en una interfaz separada con Car implements ICar esquema de nombres de Car implements ICar . La duplicación de la parte de la interfaz de una clase en un tipo de interfaz independiente no lo convierte mágicamente en abstracción. Aún obtendrá una implementación concreta pero con parte de interfaz duplicada. Si su abstracción no es tan buena, la duplicación de la interfaz no mejorará de ninguna manera. Extraer la abstracción es un trabajo duro.