Yo lo hago a veces cuando en typescript estan en el mismo fichero y el objeto se llama Coche por ejemplo pues la interfaz del coche ICoche
Y ya, para evitar la colision de nombres y no pensar mucho jeje
Este hilo es el microcosmos perfecto de /dev porque hay gente sosteniendo vehementemente una postura y otra gente sosteniendo vehementemente justo la postura contraria como si ambos tuvieran la razón absoluta.
#35 si no usas algún tipo de distinción muchas veces tienes colisión en el naming y te queda usar un type alias a nivel local
ej: un repositorio de DB cualquiera, el 99% de veces vas a tener uno sólo y se va a llamar como la interfaz
puedes no meter una interfaz y llamar a la instanciación de la clase directamente pero entonces estás rompiendo las abstracciones al articular semánticas de infraestructura en tus casos de uso; tus casos de uso/servicios/negocio no deberían tener acceso directo a nada de infraestructura
el tema de ser vago para nombrar las cosas aplica a veces y a veces no, pero en última instancia esto es bike shedding como una catedral (que ya sé que es un shitpost)
#37 en repositorios si que necesitas interfaz. Un dia puedes tener un repositorio de DB cualquiera pero ma;ana puede ser una llamada a una API externa por ejemplo (caso de uso real).
Pero por ejemplo para unas bean random no necesitas implementar ninguna interfaz que contenga funciones del tipo getEdad()
#38 no digo que no necesites, sólo que como vas a tener sólo una implementación es fácil argumentar a favor de no meter una interfaz por el medio (cosa que se ha hecho y por eso lo he mencionado)
técnicamente aunque pase de ser un repo a un cliente api deberías poder ser capaz de refactorizar sin necesidad de tocar el contrato de la clase (los métodos públicos), que a efectos prácticos es lo mismo que tener una interfaz por el medio
que yo no estoy de acuerdo eh, personalmente no me gusta no usar interfaces
#39 si, aunque incluso con una sola implementacion creo que seguiria con interfaz.
Y a esa interfaz no la llamas IUserRepository. La llamas UserRepository y las implementaciones no es UserRepository, son JdbcUserRepository, ExternalUserRepository etc, como sea.
#40 yo la llamo IUserRepository y lo que no me gustaría es tener chorrocientas *EntityFrameworkRepository, pero es un detalle de estilo; por defecto en el flujo normal voy a tirar del orm base o de sus APIs, el resto de repos/componentes sí los voy a matizar más cuando se salgan de esa norma.
btw yo en c# también pongo el _ como prefijo en los class fields porque está así en los docs y el código oficial
que es herencia cultural de la notación húngara? pues... vale, no sé ponme un linter en el precommit mi negro
#43 de hecho lo de que las interfaces empiecen por I segun he leido en C# es por COM, no por otra cosa y ya se quedo asi para siempre. Pero joder en lenguajes mas nuevos no lo entiendo
Se hace porque el código tiene que ser lo más fácilmente entendible para cualquiera que lo lea, no sólo para tí, entonces existen ciertos convenios o buenas prácticas para determinados lenguajes que se suelen utilizar para facilitar eso mismo, y ponerle la I a una Interface delante en C#, por ejemplo, es una buena manera y bastante sencilla de que cualquiera que tenga que leer el código entienda a simple vista que se trata de una interfaz sin tener que mirar nada más.
no sé yo lo veo útil para evitar esas colisones, que lo mismo en algunas situaciones puedes llamar a la implementación default distinto que al contrato, pero otras probablemente sea darle vueltas de más (como algo que tire de un servicio muy acotado de terceros, una estructura de datos como un diccionario o una lista o tus propios servicios/casos de uso de dominio)
cuando leo la definición de una clase me resulta cómodo saber qué es una interfaz y qué una superclase
y aparte de esas dos así a bote pronto también cuando estoy con estructuras de datos de la stdlib me gudta saber si estoy con un interfaz o un tipo concreto sin tener que preguntarle al linter
por curiosidad, yo llamo los servicios de dominio como DashboardService o DashboardUsecase, si le meto una interfaz le pongo el prefijo I, cómo usas esas cosas tú?
#45 pero si ni los mismos diseñadores de C# querían poner ese prefijo lol.
#46 pues yo sigo sin verlo. Que tipo de colisiones? Y que información buscas cuando necesitas saber que es una interfaz y que es una clase? Yo lo veo como que me llega un X me la suda si es clase o interfaz a no ser que necesite cambiar algo de como funciona internamente.
#48 No sé si querían ponerlo o no, pero lo pusieron. xd
DO prefix interface names with the letter I, to indicate that the type is an interface.
For example, IComponent (descriptive noun), ICustomAttributeProvider (noun phrase), and IPersistable (adjective) are appropriate interface names. As with other type names, avoid abbreviations.
DO prefix interface names with the letter I, to indicate that the type is an interface.
#48 lo que he dicho justo encima, normalmente cuando tienes una implementación por defecto que es demasiado generalista o abstracta como para añadirle ninguna coletilla extra. No sé así que se me ocurran más, clases base abstractas, como una superclase para definir un CRUD de un repo o una superclase para llevarte toda la guarrería de un cliente http o similares. Pues lo llamo IBaseRepo y BaseRepo y sigo con lo que tenga que hacer.
Sobre las colecciones y demás, a mí hay veces que me gusta saber bien si estoy con la instanciación o con la interfaz porque las colecciones implementan muchas interfaces y hay mucha herencia por el medio y aunque técnicamente ni me haga falta me gusta diferenciarlo rápido.
tampoco te voy a dar unas razones irrefutables de cencia objetiva de por qué tengo una ligera preferencia, que estamos hablando nivel pascal vs camel case,
pero si es un puto nombre, que mas os da. no me digais que no veis el codigo directamente como un AST vaya cringe
1 mes después
