Die Frage ist ein falsches Dilemma. Die ordnungsgemäße Anwendung des YAGNI-Prinzips ist keine unabhängige Sache. Das ist ein Aspekt von gutem Design. Jedes der SOLID-Prinzipien ist auch ein Aspekt guten Designs. Sie können nicht immer jedes Prinzip in jeder Disziplin vollständig anwenden. Probleme in der realen Welt bringen eine Menge Kräfte in Ihren Code, und einige davon gehen in entgegengesetzte Richtungen. Prinzipien des Designs müssen all das berücksichtigen, aber keine Handvoll Prinzipien kann in alle Situationen passen.
Schauen wir uns nun jedes Prinzip mit dem Verständnis an, dass sie zwar manchmal in verschiedene Richtungen ziehen, aber keineswegs inhärent miteinander in Konflikt stehen.
YAGNI wurde entwickelt, um Entwicklern dabei zu helfen, eine bestimmte Art von Nacharbeit zu vermeiden: die, die aus dem Bauen der falschen Sache resultiert. Dies geschieht, indem es uns anleitet, Fehlentscheidungen zu vermeiden, die auf Annahmen oder Vorhersagen darüber beruhen, was sich unserer Meinung nach in Zukunft ändern oder erforderlich sein wird. Die kollektive Erfahrung zeigt uns, dass wir uns in der Regel irren, wenn wir dies tun. Zum Beispiel würde YAGNI Sie auffordern, keine Schnittstelle zum Zwecke der Wiederverwendbarkeit zu erstellen , es sei denn, Sie wissen gerade, dass Sie mehrere Implementierer benötigen. Ebenso würde YAGNI sagen, dass Sie keinen "ScreenManager" zum Verwalten eines einzelnen Formulars in einer Anwendung erstellen sollten, es sei denn, Sie wissen gerade, dass Sie mehr als einen Bildschirm haben werden.
Im Gegensatz zu dem, was viele Leute denken, geht es bei SOLID nicht um Wiederverwendbarkeit, Generizität oder gar Abstraktion. SOLID soll Ihnen dabei helfen, Code zu schreiben, der für Änderungen vorbereitet ist , ohne etwas darüber zu sagen, was für eine bestimmte Änderung dies sein könnte. Die fünf Prinzipien von SOLID schaffen eine Strategie zum Erstellen von Code, die flexibel ist, ohne zu generisch zu sein, und einfach, ohne naiv zu sein. Die ordnungsgemäße Anwendung von SOLID-Code erzeugt kleine, fokussierte Klassen mit genau definierten Rollen und Grenzen. Das praktische Ergebnis ist, dass eine Mindestanzahl von Klassen berührt werden muss, damit sich die Anforderungen ändern können. Und in ähnlicher Weise gibt es für jede Codeänderung eine minimierte Menge an "Ripple" bis zu anderen Klassen.
Schauen wir uns die Beispielsituation an, die Sie haben, und lassen Sie uns sehen, was YAGNI und SOLID zu sagen haben. Sie ziehen eine gemeinsame Repository-Schnittstelle in Betracht, da alle Repositorys von außen gleich aussehen. Der Wert einer gemeinsamen, generischen Schnittstelle ist jedoch die Fähigkeit, einen der Implementierer zu verwenden, ohne wissen zu müssen, um welche es sich handelt. Sofern es in Ihrer App keine Stelle gibt, an der dies notwendig oder nützlich wäre, sagt YAGNI, dass Sie dies nicht tun sollten.
Es gibt 5 SOLID-Prinzipien zu betrachten. S ist Einzelverantwortung. Dies sagt nichts über die Schnittstelle aus, aber es könnte etwas über Ihre konkreten Klassen aussagen. Es könnte argumentiert werden, dass die Verarbeitung des Datenzugriffs selbst am besten in die Verantwortung einer oder mehrerer anderer Klassen fällt, während die Verantwortung der Repositorys darin besteht, aus einem impliziten Kontext (CustomerRepository ist ein Repository, das implizit für Entitäten des Kunden bestimmt ist) explizite Aufrufe an das zu übertragen Allgemeine Datenzugriffs-API, die den Entitätstyp des Kunden angibt.
O ist offen-geschlossen. Hier geht es hauptsächlich um Vererbung. Dies würde zutreffen, wenn Sie versuchen, Ihre Repositorys von einer gemeinsamen Basis abzuleiten, die gemeinsame Funktionen implementiert, oder wenn Sie erwarten, dass Sie weitere Informationen von den verschiedenen Repositorys ableiten. Aber das bist du nicht, also nicht.
L ist Liskov Substituierbarkeit. Dies gilt, wenn Sie die Repositorys über die gemeinsame Repository-Schnittstelle verwenden möchten. Es enthält Einschränkungen für die Schnittstelle und die Implementierungen, um die Konsistenz zu gewährleisten und eine spezielle Behandlung für verschiedene Impelementer zu vermeiden. Der Grund dafür ist, dass eine solche spezielle Behandlung den Zweck einer Schnittstelle untergräbt. Es kann nützlich sein, dieses Prinzip in Betracht zu ziehen, da es Sie möglicherweise davor warnt, die gemeinsame Repository-Schnittstelle zu verwenden. Dies stimmt mit den Leitlinien von YAGNI überein.
Ich bin Schnittstellentrennung. Dies kann zutreffen, wenn Sie beginnen, Ihren Repositorys verschiedene Abfragevorgänge hinzuzufügen. Die Schnittstellentrennung wird angewendet, wenn Sie die Mitglieder einer Klasse in zwei Teilmengen aufteilen können, wobei eine von bestimmten Verbrauchern und die andere von anderen Verbrauchern verwendet wird, aber wahrscheinlich kein Verbraucher beide Teilmengen verwendet. Die Anleitung besteht darin, statt einer gemeinsamen Schnittstelle zwei separate Schnittstellen zu erstellen. In Ihrem Fall ist es unwahrscheinlich, dass das Abrufen und Speichern einzelner Instanzen von demselben Code verbraucht wird, der für allgemeine Abfragen verwendet wird. Daher ist es möglicherweise hilfreich, diese in zwei Schnittstellen zu unterteilen.
D ist Abhängigkeitsinjektion. Hier kommen wir zum selben Punkt wie das S. Wenn Sie Ihren Verbrauch der Datenzugriffs-API in ein separates Objekt aufgeteilt haben, besagt dieses Prinzip, dass Sie es beim Erstellen übergeben sollten, anstatt nur eine Instanz dieses Objekts neu zu erstellen ein Repository. Auf diese Weise können Sie die Lebensdauer der Datenzugriffskomponente einfacher steuern und Verweise auf diese Komponente zwischen Ihren Repositorys austauschen, ohne sie zu einem Singleton machen zu müssen.
Es ist wichtig zu beachten, dass die meisten SOLID-Prinzipien nicht unbedingt in diesem bestimmten Stadium der Entwicklung Ihrer App gelten. Ob Sie beispielsweise den Datenzugriff unterbrechen sollten, hängt davon ab, wie kompliziert er ist, und ob Sie Ihre Repository-Logik testen möchten, ohne auf die Datenbank zuzugreifen. Es hört sich so an, als wäre dies unwahrscheinlich (meiner Meinung nach leider), also ist es wahrscheinlich nicht notwendig.
Nach all diesen Überlegungen stellen wir fest, dass YAGNI und SOLID tatsächlich einen gemeinsamen soliden, sofort relevanten Ratschlag geben: Es ist wahrscheinlich nicht erforderlich, eine gemeinsame generische Repository-Schnittstelle zu erstellen.
All diese sorgfältigen Überlegungen sind äußerst nützlich als Lernübung. Es ist zeitaufwändig, wie Sie lernen, aber im Laufe der Zeit entwickeln Sie Intuition und werden sehr schnell. Sie wissen, was zu tun ist, müssen aber nicht über all diese Wörter nachdenken, es sei denn, jemand fragt Sie, warum.
(Interessierte, das nennt man