Betrachtet man die (ausgereifte) Codebasis bei meinem neuen Job, gibt es eine Schnittstelle, und nur eine Klasse implementiert sie (soweit ich das beurteilen kann). Kann/sollte ich die Schnittstelle loswerden?Gibt es einen Hinweis auf eine Schnittstelle, wenn nur eine Klasse sie implementiert?
Kein Weg! Es hat keinerlei schädliche Auswirkungen und eines Tages kann jemand eine Implementierung austauschen, ohne dass Tonnen von Code umgestaltet werden müssen.
Mit "Tonnen Code" meinen Sie, dass eine andere Klasse mit einer anderen Implementierung der Schnittstelle geschrieben werden könnte und in Methoden mit einer Variablen implementiert werden könnte Schnittstelle ohne Änderung der Methodensignaturen?Irgendwelche anderen Beispiele für Refactorings, die vermieden werden könnten, indem die Schnittstelle beibehalten und eine neue Klasse implementiert wird? – user343587
@ user343587 Ja, aber was ist, wenn Sie zwei verschiedene Implementierungen dieser Schnittstelle benötigen und sie zur Laufzeit austauschen müssen? Sicher, du könntest es abstrakt abstrahieren aber dann bist du noch im selben Boot. – jfar
Ja, es gibt einen Punkt für Schnittstellen, da es in Zukunft möglicherweise mehr als eine Implementierung geben könnte. Sie können natürlich hier über Bord gehen und Schnittstellen für alles schaffen, so dass ein Gleichgewicht gefunden werden muss.
Heute, nein. In den nächsten Monaten hat sich das Projekt in der Komplexität verzehnfacht? Wer weiß. Wenn es sich hierbei um Legacy-Code handelt, hat dies für eine Schnittstelle, die einmal implementiert wird, wenig Wert, aber es hat auch keinen Sinn, das Refactoring zu durchlaufen, das daran beteiligt ist, es zu entfernen. "Wenn es funktioniert, repariere es nicht".
Tidier, weniger verwirrender Code? Ist das nicht ein Refactoring-Punkt? – user343587
Dient die Schnittstelle zum Organisieren, Dokumentieren oder Identifizieren? Wenn ja, lass es in Ruhe! Wenn es nur Unordnung ist, könnte das Refactoring in Ordnung sein. –
Ich weiß nicht, was so verwirrend sein könnte. Ich habe Tonnen von Single-Use-Schnittstellen in meinem Code. – jfar
Abgesehen von den in den anderen Antworten angegebenen Gründen ermöglicht die Implementierung einer Schnittstelle das Abfangen von Methoden, indem Proxys ohne Instrumentierung erstellt werden. Dies wird zum Protokollieren, Einkapseln von Operationen in einer Transaktion usw. verwendet. Es wird von mehreren Frameworks verwendet.
Auch wenn die Leute sich nicht einig sind über die Anzahl der Fehler pro 1000 Zeilen Code, scheinen diese beiden korreliert zu sein (https://stackoverflow.com/questions/862277/what-is-the-industry-standard-for-bugs-per-1000-lines-of-code). Weniger Zeilen == weniger Bugs.
Auch die Änderung des Namens der Implementierung für den Namen der Schnittstelle sollte alles sein, was hier zu tun ist.
Wenn der Refactoring Aufwand ist minimal und es reduziert den Code, ich werde eher für die Unterdrückung der Schnittstelle sein.
Da Sie eine ausgereifte Basis erwähnen, möchte ich ein anderes Beispiel aus der realen Welt erwähnen: Hibernate's Session.
Session ist eine Schnittstelle nur von einer Klasse implementiert: SessionImpl. Wenn Sie jedoch in der Vergangenheit den Ruhezustand verwendet oder den Quellcode gelesen haben, haben Sie wahrscheinlich bemerkt, dass Session an Stelle von SessionImpl überall verwendet wird.
Ist das falsches Design? Definitiv nein. Es heißt "Substitutionsprinzip" oder "Programmierung für Schnittstellen". Das bedeutet, dass Sie mit der Schnittstelle statt mit der Implementierung Ihren Code ohne Aufwand erweitern können, indem Sie Ihre neuen Klassen entsprechend instanziieren, aber immer die Schnittstelle verwenden. Wird es immer noch falsch sein, wenn niemand eine neue Klasse erstellt, die die Sitzung implementiert? Nein, immer noch nicht falsch.
Meine zwei Cent.
Zusätzlich zu den bereits gegebenen guten Antworten - wenn irgendwann in der Zukunft eine Klasse zu Testzwecken verspottet werden muss, ist es viel einfacher, wenn bereits eine Schnittstelle verfügbar ist!
Ich würde sagen, es hängt davon ab, aber in den meisten Fällen ist eine Schnittstelle eine gute Idee für bestimmte Klassen. Die Verspottung wird durch die Verwendung von Schnittstellen vereinfacht. Wenn Sie einen IoC-Container verwenden, sind Schnittstellen sehr sinnvoll, insbesondere wenn Sie mit der Implementierung von Diensten beginnen, die im Container gemeinsam genutzt werden. Sie können dann die Implementierung des Service von der Klasse entkoppeln, die den Service benötigt.
Es sieht so aus, als müssten Sie eine Münze werfen :) –