Wann veraltet und wann in Java gelöscht werden

Im Rahmen eines Refactoring-Vorhabens oder einer laufenden Weiterentwicklung kann eine bestimmte Methode oder möglicherweise eine ganze Klasse in gewissem Sinne veraltet sein. Java unterstützt die @DeprecatedAnnotation, um anzuzeigen, dass es wahrscheinlich eine bessere Möglichkeit gibt, mit der fraglichen Funktionalität umzugehen. Ich stelle mir vor, dass dies besonders in öffentlichen APIs nützlich ist, in denen die Auswirkungen des Entfernens von Teilen einer API möglicherweise nicht bekannt sind. Wann ist es für eine nicht öffentliche API und ein Projekt, das Revisionskontrollsysteme verwendet (sodass das Löschen in gewissem Sinne rückgängig gemacht werden kann) angemessen, die veralteten Elemente zu verwerfen, anstatt sie zu löschen?

Ist Ihre API eine öffentlich zugängliche API? Das bestimmt, ob Sie ablehnen oder entfernen sollen oder nicht. Wenn die API ausschließlich zu Ihrem Vorteil ist (dh nur in Ihrem Unternehmen verwendet wird), entfernen Sie am besten einfach den fehlerhaften Code. Es ist viel sauberer und verursacht auf lange Sicht weniger Wartungsprobleme.

Wenn die API jedoch öffentlich zugänglich ist, kann das einfache Entfernen einer Methode dazu führen, dass Code, der früher mit älteren Versionen Ihrer Bibliothek funktioniert hat, nicht mehr funktioniert. Dort wird es chaotisch. Im Folgenden sind einige Richtlinien aufgeführt:

• Interne API: Entfernen statt veralten. Wenn ein Client eine interne Klasse oder Methode verwendet, ist er schuld, wenn das Tool beschädigt wird.
• Externe API: zuerst veraltet, später entfernen. Verfall ist ein Flag, dass etwas später entfernt wird. Später kommt es darauf an, was Sie für vernünftig halten. Geben Sie mindestens 2-3 Versionen an, bevor Sie den veralteten Code entfernen.

Es ist wahrscheinlich eine gute Idee, eine Erinnerung einzurichten, wenn Sie eine Klasse oder Methode @deprecate. Sie tun es, um seine Veralterung zu fördern. Erraten Sie also, wie lange es in Ihrer Freizeit dauern wird, bis alle Referenzen beseitigt sind. Markieren Sie es als @deprecated und fügen Sie eine Erinnerung in Ihren Kalender ein. Wenn Sie die Erinnerung erhalten, überprüfen Sie. Wenn es nicht mehr verwendet wird, löschen Sie es. Wenn noch einige Referenzen vorhanden sind, die schnell aktualisiert werden können, tun Sie dies und löschen Sie das Element. Wenn noch größere Arbeit übrig ist, stoßen Sie Ihre Erinnerung ein wenig nach vorne.

Wenn Sie dies genügend oft tun, entwickeln Sie ein Gefühl dafür, wie lange es dauert, eine Klasse oder Methode in Ihren Projekten loszuwerden.

IMHO, wenn Sie sicherstellen können, dass niemand es benutzt und es niemals wird, entfernen Sie es einfach. (Dies kann bei Vorhandensein von Reflexion oder externen Komponenten wie Velocity-Makros schwierig sein. Moderne IDEs wie IntelliJ können Referenzen in z. B. JSP finden, jedoch nicht über Reflection oder in Velocity.)

Wenn es eine bessere Alternative gibt, die alte jedoch immer noch an vielen Stellen verwendet wird und Sie derzeit keine Zeit haben, den gesamten Client-Code umzugestalten, ist es ausreichend, die veraltete Klasse / Methode zu verwerfen (mit einem angemessenen Kommentar zu) die bevorzugte Alternative).