Confundido acerca de la Interfaz y las pautas de codificación de clases para TypeScript

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

Esta es mi visión por la que el equipo de TypeScript recomienda no I-prefijar interfaces.

Razón #1 Los tiempos de la notación húngara tienen aprobado

El argumento principal de I-prefix-for-interface supporters es que el prefijo es útil para grokking inmediatamente si type es una interfaz. La afirmación de que el prefijo es útil para grokking inmediatamente es una apelación a la notación húngara. I prefijo para nombre de interfaz, C para clase, A para clase abstracta, s para variable de cadena, c para variable const, i para variable entera. Estoy de acuerdo en que dicha decoración de nombre puede proporcionarle el tipo información sin pasar el ratón 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 se ve compensado por la notación húngara desventajas y otras razones mencionadas a continuación. La notación húngara no se utiliza en los marcos contemporáneos. C# tiene el prefijo I (y este es el único prefijo en C#) para interfaces debido a razones históricas (COM). En retrospectiva, uno de los arquitectos de.NET (Brad Abrams) piensa que habría sido mejor no usar I prefijo. TypeScript es COM-legacy-free por lo que no tiene I-prefix-for-interface rule.

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

Supongamos que obtienes alguna caja negra. Obtienes alguna referencia de tipo que te permite interactuar con esa caja. No debería importarle si es una interfaz o una clase. Solo tienes que usar 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 arreglar Mito de diseño de API: Interfaz como Contrato en su código, por ejemplo, eliminar ICar interfaz y usar Car clase base en su lugar. A continuación, es necesario realizar dicho reemplazo en todos los consumidores. I-el prefijo conduce a la dependencia implícita de los consumidores en los detalles de la implementación de la caja negra.

Razón #3 Protección contra el mal nombre

Los desarrolladores son perezosos para pensar correctamente acerca de los nombres. Nombrar es una de las Dos Cosas Difíciles en Ciencias de la Computación . Cuando un desarrollador necesita extraer una interfaz es fácil simplemente agregar la letra I al nombre de la clase y se obtiene un nombre de interfaz. Rechazar el prefijo I para las 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 que también deben enfatizar la diferencia de intención.

Caso de abstracción: debe no no definir una interfaz ICar y una clase Car asociada. Car es una abstracción y debería 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 correctamente elegidos lo vacunan contra Mito de diseño de API: Interfaz como Contrato.

En mi práctica, conocí a muchas personas que duplicaban sin pensar parte de la interfaz de una clase en una interfaz separada que tenía Car implements ICar un esquema de nombres. Duplicación de la parte de interfaz de una clase en un tipo de interfaz separado no lo convierte mágicamente en abstracción. Todavía obtendrá implementación concreta, pero con la parte de interfaz duplicada. Si su abstracción no es tan buena, duplicar la parte de la interfaz no la mejorará de todos modos. Extraer la abstracción es un trabajo duro.