Refactoring Aspekte - Vorteile - Nachteile

Aspekte: Altes -> neues Error Handlig: - neue Exceptions auswählen/ erstellen (mit texthandling) - ersetzen der Schnittstellle - ersetzen der Auslöser, alle mit sinnvollen Texten versehen - ersetzen der Aufrufer, weiterreichen als neue Exceptions (ggf. weitere Aufrufstellen anpassen da keine parallele Verwendung alter und neuer Ex möglich -> ??? wenn weitere aufgerufene Methoden nicht angepasst werden können? Wrapper?) oder Behandlung der Exception mit Auswertung des Textes ( CATCH zcx_error into data(lo_error). MESSAGE i000(zact_all) with lo_error->get_text( ).) - rekursiv Aufrufe der Aufrufe prüfen – auch mit erweiterter Prüfung oder Code inspector (?)

Nachteil: - Kein Syntaxfehler, wenn Exception weder abgefangen noch behandelt wird - Overhead/ Verunstaltung durch try/ catch/ endtry, insbesondere wenn Auswertung nicht erforderlich ist oder zb bei int. Tabellenzugriff über […] - etwas aufwändiger zum Auslösen (z.B. * Keine Daten gemäss Selektion vorhanden. MESSAGE e005 INTO data(lv_text). RAISE EXCEPTION TYPE zcx_not_found EXPORTING text = conv #( lv_text ). - Erstellung neuer Exceptionsklassen ist aufwändiger, insbesondere mit Texthandling (alte Ex. können als Freitext festgelegt werden)

Vorteile: - Spezifischer Text kann weitergereicht und an passender Stelle ausgwertet werden - Einfaches Weiterreichen, mit alten Exceptions ist bei jedem Aufruf Abfangen der sy-subrc nötig

Probleme:- Umbenennung von Parametern, Methoden, Attributen: weder klasseninterne noch externe Verwender werden angepasst, nicht mal Methodenintern bei Parametern... - Schnittstellenänderung bei Methoden: Aufrufer werden nicht angepasst, auch nicht syntax geprüft. (auch nicht bei erweiterter Prüfung?) - Umbenennung oder Sichtbarkeitsänderung von Redefinierten Methoden in der Oberklasse kann zu Codeverlust der reimplementierung oder doppelten Methoden führen. Inkonsistenzen sind heikel zu eliminieren.- Beim Hinaufschieben einer Methode in Oberklasse: Fehler in weiterer Unterklasse "Methode schon vorhanden" (methods xy REDEFINITION fehlt). Bei geänderter Signatur nicht automatisch geändert, ev. weil Typ nicht bekannt. - Drag und Drop in Objektliste der Workbench zum Verschieben von Methoden, Attributen, Typen, Makros wäre sehr hilfreich. Refactoring Assitent nicht zum Verschieben von Makros und Typen.- Refactoring Assistent: zum Verschieben in "fremde Klasse": erst fremde Klasse zur "assoziierten Klasse" machen durch hinzufügen als Attribut.

Testing:Das folgende Feature TEST-SEAM / TEST-INJECTION klingt für uns ("if you have to deal with code that never came in touch with the concept of separation of concerns" trifft für uns natürlich zu) nach einer Antwort auf viele Gebete :-) Im Kern ist dieses Feature ähnlich einer ENHANCEMENT-SECTION, aber für Testcode: Man markiert Teile des produktiven Codes, die z.B. Datenbankselektionen machen und daher für Unit Tests nicht geeignet sind, als TEST-SEAM, und kann dann in Unit Tests mittels TEST-INJECTION alternativ zu durchlaufenden Code angeben. Unschön finde ich nur den Namen des Schlüsselwortes "TEST-SEAM" im produktiven Code. Aber der Code, für den man diese Technik anwenden muss, ist ja sowieso nicht schön, also macht es nichts. So können wir uns schon auf SAP_BASIS 7.50 freuen... :-)

Verwendungsnachweis Messages:IF 1 = 0. "für Verwendungsnachweis * Cannot read transfer types MESSAGE e011(retail_st_ts_msg). ENDIF. CALL FUNCTION 'BALW_BAPIRETURN_GET2' EXPORTING type = 'E' cl = 'RETAIL_ST_TS_MSG' number = '011' IMPORTING return = ls_message. APPEND ls_message TO return.

Prozeduralen Code modularisieren (Riesen fugruppen): Formroutinen in Klasse als private Methoden verlagern Fubas/ Fugroups in Klassen überführen, ggf. Fuba als Adapter belassen, insbesondere für RFC-Aufrufe