"Extern" bedeutet in diesem Zusammenhang "für Benutzer beobachtbar". Benutzer können im Falle einer Anwendung Menschen sein, oder andere Programme im Falle einer öffentlichen API.
Wenn Sie also die Methode M von Klasse A in Klasse B verschieben und sich beide Klassen tief in einer Anwendung befinden und kein Benutzer aufgrund der Änderung eine Änderung im Verhalten der App feststellen kann, können Sie sie zu Recht als Refactoring bezeichnen.
Wenn OTOH, ein anderes übergeordnetes Subsystem / eine andere übergeordnete Komponente, sein Verhalten ändert oder aufgrund der Änderung zusammenbricht, ist dies tatsächlich (normalerweise) für Benutzer (oder zumindest für Sysadmins, die Protokolle überprüfen) beobachtbar. Oder wenn Ihre Klassen Teil einer öffentlichen API waren, gibt es möglicherweise Code von Drittanbietern, der davon abhängt, dass M Teil der Klasse A und nicht B ist. In beiden Fällen handelt es sich also nicht um ein Refactoring im eigentlichen Sinne.
Es gibt die Tendenz, Codeüberarbeitungen als Refactoring zu bezeichnen, was vermutlich falsch ist.
In der Tat ist es eine traurige, aber zu erwartende Folge, dass das Refactoring in Mode kommt. Entwickler arbeiten seit Ewigkeiten ad hoc an Code, und es ist mit Sicherheit einfacher, ein neues Schlagwort zu lernen, als tief verwurzelte Gewohnheiten zu analysieren und zu ändern.
Also, was ist das richtige Wort für Überarbeitungen, die das äußere Verhalten verändern?
Ich würde es Redesign nennen .
Aktualisieren
Viele interessante Antworten zur Benutzeroberfläche, aber würde das Umgestalten von Methoden die Benutzeroberfläche nicht ändern?
Von was? Die spezifischen Klassen, ja. Aber sind diese Klassen in irgendeiner Weise für die Außenwelt direkt sichtbar? Wenn nicht - weil sie sich in Ihrem Programm befinden und nicht Teil der externen Schnittstelle (API / GUI) des Programms sind - ist keine dort vorgenommene Änderung für externe Parteien erkennbar (es sei denn, die Änderung bringt natürlich etwas kaputt).
Ich habe das Gefühl, dass es darüber hinaus eine tiefere Frage gibt: Existiert eine bestimmte Klasse als eigenständige Einheit? In den meisten Fällen lautet die Antwort nein : Die Klasse existiert nur als Teil einer größeren Komponente, eines Ökosystems von Klassen und Objekten, ohne das sie nicht instanziiert werden kann und / oder unbrauchbar ist. Dieses Ökosystem umfasst nicht nur seine (direkten / indirekten) Abhängigkeiten, sondern auch andere Klassen / Objekte, die davon abhängen. Dies liegt daran, dass ohne diese übergeordneten Klassen die mit unserer Klasse verbundene Verantwortung für die Benutzer des Systems möglicherweise bedeutungslos / nutzlos ist.
ZB in unserem Projekt, das sich mit Mietwagen befasst, gibt es eine ChargeKlasse. Diese Klasse ist für die Benutzer des Systems für sich genommen nutzlos, da Vermittler von Mietstationen und Kunden mit einer einzelnen Gebühr nicht viel anfangen können: Sie beschäftigen sich mit Mietvertragsverträgen als Ganzes (die eine Reihe verschiedener Arten von Gebühren enthalten). . Die Benutzer interessieren sich hauptsächlich für die Gesamtsumme dieser Gebühren, die sie am Ende zahlen sollen; Der Makler interessiert sich für die verschiedenen Vertragsoptionen, die Länge der Anmietung, die Fahrzeuggruppe, das Versicherungspaket, die ausgewählten zusätzlichen Gegenstände usw. usw., die (über ausgefeilte Geschäftsregeln) bestimmen, welche Gebühren anfallen und wie die Restzahlung berechnet wird von diesen. Und Ländervertreter / Business Analysten kümmern sich um die spezifischen Geschäftsregeln, ihre Synergien und Auswirkungen (auf das Einkommen des Unternehmens usw.).
Kürzlich habe ich diese Klasse überarbeitet und die meisten ihrer Felder und Methoden umbenannt (um der Standard-Java-Namenskonvention zu folgen, die von unseren Vorgängern völlig vernachlässigt wurde). Ich plane auch weitere Refactorings zu ersetzen Stringund charFelder mit angemessenere enumund booleanTypen. All dies wird sicherlich die Oberfläche der Klasse verändern, aber (wenn ich meine Arbeit richtig mache) wird nichts davon für die Benutzer unserer App sichtbar. Keiner von ihnen kümmert sich darum, wie einzelne Gebühren dargestellt werden, obwohl sie den Begriff der Gebühr sicher kennen. Ich hätte als Beispiel hundert andere Klassen auswählen können, die kein Domänenkonzept repräsentieren, also für die Endbenutzer sogar konzeptionell unsichtbar sind, aber ich fand es interessanter, ein Beispiel auszuwählen, bei dem es zumindest eine gewisse Sichtbarkeit auf Konzeptebene gibt. Dies zeigt deutlich, dass Klassenschnittstellen (bestenfalls) nur Darstellungen von Domänenkonzepten sind, nicht die Realität *. Die Darstellung kann ohne Auswirkung auf das Konzept geändert werden. Und Benutzer haben nur das Konzept und verstehen es; es ist unsere aufgabe, das mapping zwischen konzept und darstellung vorzunehmen.
* Und man kann leicht hinzufügen, dass das Domain-Modell, das unsere Klasse darstellt, selbst nur eine ungefähre Darstellung einer "echten Sache" ist ...