La pregunta presenta un falso dilema. La aplicación adecuada del principio YAGNI no es algo sin relación. Es un aspecto del buen diseño. Cada uno de los principios SÓLIDOS también son aspectos del buen diseño. No siempre se puede aplicar completamente todos los principios en cualquier disciplina. Los problemas del mundo real ejercen muchas fuerzas en su código, y algunos de ellos empujan en direcciones opuestas. Los principios de diseño tienen que dar cuenta de todos ellos, pero ningún puñado de principios puede adaptarse a todas las situaciones.
Ahora, echemos un vistazo a cada principio con el entendimiento de que, si bien a veces pueden tomar diferentes direcciones, de ninguna manera están inherentemente en conflicto.
YAGNI fue concebido para ayudar a los desarrolladores a evitar un tipo particular de retrabajo: lo que viene de construir algo incorrecto. Lo hace al guiarnos para evitar tomar decisiones errantes demasiado pronto en base a suposiciones o predicciones sobre lo que creemos que cambiará o será necesario en el futuro. La experiencia colectiva nos dice que cuando hacemos esto, generalmente estamos equivocados. Por ejemplo, YAGNI le diría que no cree una interfaz con el propósito de reutilización , a menos que sepa en este momento que necesita múltiples implementadores. De manera similar, YAGNI diría que no cree un "ScreenManager" para administrar el formulario único en una aplicación a menos que sepa en este momento que tendrá más de una pantalla.
Al contrario de lo que mucha gente piensa, SOLID no se trata de reutilización, genérico o incluso abstracción. SOLID tiene la intención de ayudarlo a escribir código que esté preparado para el cambio , sin decir nada sobre cuál podría ser ese cambio específico. Los cinco principios de SOLID crean una estrategia para construir código que es flexible sin ser demasiado genérico y simple sin ser ingenuo. La aplicación adecuada del código SOLID produce clases pequeñas y enfocadas con roles y límites bien definidos. El resultado práctico es que para cualquier cambio de requisitos necesarios, se debe tocar un número mínimo de clases. Y de manera similar, para cualquier cambio de código, hay una cantidad minimizada de "ondulación" a través de otras clases.
Mirando la situación de ejemplo que tiene, veamos qué podrían decir YAGNI y SOLID. Está considerando una interfaz de repositorio común debido al hecho de que todos los repositorios se ven iguales desde el exterior. Pero el valor de una interfaz genérica común es la capacidad de usar cualquiera de los implementadores sin necesidad de saber cuál es en particular. A menos que haya algún lugar en su aplicación donde esto sea necesario o útil, YAGNI dice que no lo haga.
Hay 5 principios SÓLIDOS para ver. S es responsabilidad única. Esto no dice nada sobre la interfaz, pero podría decir algo sobre sus clases concretas. Se podría argumentar que manejar el acceso a los datos en sí mismo podría ser una responsabilidad de una o más clases, mientras que la responsabilidad de los repositorios es traducir de un contexto implícito (CustomerRepository es un repositorio implícito para las entidades del Cliente) en llamadas explícitas a la API de acceso a datos generalizada que especifica el tipo de entidad del Cliente.
O es abierto-cerrado. Esto se trata principalmente de herencia. Se aplicaría si intentara derivar sus repositorios de una base común que implementa una funcionalidad común, o si espera derivar más de los diferentes repositorios. Pero no lo eres, así que no.
L es la sustituibilidad de Liskov. Esto se aplica si tenía la intención de utilizar los repositorios a través de la interfaz de repositorio común. Establece restricciones en la interfaz y las implementaciones para garantizar la coherencia y evitar un manejo especial para diferentes impelementers. La razón de esto es que tal manejo especial socava el propósito de una interfaz. Puede ser útil considerar este principio, porque puede advertirle que no use la interfaz de repositorio común. Esto coincide con la guía de YAGNI.
I es la segregación de interfaz. Esto puede aplicarse si comienza a agregar diferentes operaciones de consulta a sus repositorios. La segregación de interfaz se aplica cuando puede dividir a los miembros de una clase en dos subconjuntos donde uno será utilizado por ciertos consumidores y el otro por otros, pero es probable que ningún consumidor use ambos subconjuntos. La guía es crear dos interfaces separadas, en lugar de una común. En su caso, es poco probable que la búsqueda y el almacenamiento de instancias individuales se consuman con el mismo código que haría consultas generales, por lo que podría ser útil separarlos en dos interfaces.
D es inyección de dependencia. Aquí volvemos al mismo punto que la S. Si separó su consumo de la API de acceso a datos en un objeto separado, este principio dice que, en lugar de simplemente actualizar una instancia de ese objeto, debe pasarlo cuando cree Un repositorio. Esto facilita el control de la vida útil del componente de acceso a datos, abriendo la posibilidad de compartir referencias a él entre sus repositorios, sin tener que seguir la ruta de convertirlo en un singleton.
Es importante tener en cuenta que la mayoría de los principios SOLID no se aplican necesariamente en esta etapa particular del desarrollo de su aplicación. Por ejemplo, si debe romper el acceso a los datos depende de lo complicado que sea, y si desea probar la lógica de su repositorio sin tocar la base de datos. Parece que esto es poco probable (desafortunadamente, en mi opinión), por lo que probablemente no sea necesario.
Entonces, después de toda esa consideración, descubrimos que YAGNI y SOLID realmente proporcionan una pieza común de consejos sólidos e inmediatamente relevantes: probablemente no sea necesario crear una interfaz de repositorio genérica común.
Todo este pensamiento cuidadoso es extremadamente útil como ejercicio de aprendizaje. A medida que aprende, lleva mucho tiempo, pero con el tiempo desarrolla la intuición y se vuelve muy rápido. Sabrá qué hacer, pero no necesita pensar todas estas palabras a menos que alguien le pida que explique por qué.
(cualquiera interesado, esto se llama