{"id":628,"date":"2015-08-26T16:00:50","date_gmt":"2015-08-26T14:00:50","guid":{"rendered":"http:\/\/invidit.de\/blog\/?p=628"},"modified":"2015-09-20T10:24:58","modified_gmt":"2015-09-20T08:24:58","slug":"ausbruchsversuch-gelungen","status":"publish","type":"post","link":"https:\/\/invidit.de\/blog\/ausbruchsversuch-gelungen\/","title":{"rendered":"Ausbruchsversuch gelungen"},"content":{"rendered":"

Hallo Spa\u00df-Coder.<\/p>\n

In diesem Artikel besch\u00e4ftigen wir uns wieder mit dem Thema Refactoring und stellen zwei weitere Refaktorisierungsmuster vor.<\/p>\n

Ihr habt eine Klasse, in der ihr eine bestimmte Methode \u00e4ndern m\u00fcsst. Habt ihr schon einmal erlebt, dass die Klasse f\u00fcr einen Test nicht instanziiert werden kann? Zu viele Abh\u00e4ngigkeiten an Datenbanken, Dateisystem oder anderen komplexen Klassen verhindern leider die Klasse per Konstruktor zu erzeugen. Was nun? Die Methode ohne Unit-Tests zu \u00e4ndern ist zu riskant. Aus diesem Grund m\u00fcssen erst einmal Tests geschrieben werden – aber wie?<\/p>\n

Vielleicht ist es in solchen F\u00e4llen m\u00f6glich mit Hilfe eines Mocking-Frameworks die gew\u00fcnschte Methode testbar zu machen und alle Abh\u00e4ngigkeiten zu „entfernen“. Sollte dies nicht m\u00f6glich sein (oder wilden Spaghetti-Mocking-Code ergeben), helfen vielleicht diese beiden Muster.<\/p>\n

 <\/p>\n

Expose Static Method<\/h1>\n

Manchmal m\u00fcssen wir Klassen ver\u00e4ndern, die wir nicht testen k\u00f6nnen, weil die Methode, die wir \u00e4ndern m\u00f6chten leider privat ist. Wir \u00e4ndern aber keinen Code, der nicht getestet ist, weil die Gefahr zu hoch ist, dass wir etwas kaputtmachen.<\/p>\n

Verwendet die betroffene Methode keine Instanzvariablen oder andere Methoden der Klasse, k\u00f6nnen wir diese einfach in eine \u00f6ffentliche, statische Methode umwandeln. Diese statische Methode l\u00e4sst sich nun problemlos testen.<\/p>\n

In aller Regel f\u00fchren Methoden dieser Art dazu, dass die Klasse eine geringe Koh\u00e4sion aufweist. Wenn ihr gerade nicht mehr genau wisst, was das nochmal gleich bedeutet und warum das nicht\u00a0 gut ist, lest nochmal die Artikel Teile und Herrsche<\/a> sowie Aus Prinzip nur eine Verantwortlichkeit<\/a>. Darin sind wir auf das Thema bereits eingegangen.<\/p>\n

Wir wollen bei der Refaktorisierung m\u00f6glichst kleine, risikoarme Schritte machen. Deshalb ist es besser nicht gleich die Koh\u00e4sion g\u00e4nzlich aufzul\u00f6sen, sondern zun\u00e4chst den betroffenen Code durch Tests abzusichern und anschlie\u00dfend erst zu ver\u00e4ndern.<\/p>\n

 <\/p>\n

Anleitung<\/h2>\n

Wie aber gehen wir nun vor, um unsere Methode statisch und damit testbar zu machen?<\/p>\n

Die kurze Anleitung dazu besteht aus wenigen Schritten:<\/p>\n

    \n
  1. Unit-Test f\u00fcr die neue, statische Methode schreiben<\/li>\n
  2. Methodenrumpf der Methode in eine neue, statische Methode extrahieren<\/li>\n
  3. Code kompilieren (lean on the compiler)<\/li>\n
  4. Nicht-statische Verwendungen innerhalb der neuen Methode ebenfalls statisch machen<\/li>\n<\/ol>\n

    Haben\u00a0 wir alle Schritte ausgef\u00fchrt, sollte unser Code kompilierbar sein und der Unit-Test aus Schritt 1. gr\u00fcn<\/span> sein.<\/p>\n

     <\/p>\n

    Hinweise<\/h2>\n

    Manchmal m\u00f6chten wir die Methode aber gar nicht nach au\u00dfen sichtbar machen. Wir m\u00f6chten unsere Klassen schlie\u00dflich absichern. Insbesondere, wenn wir in Schritt 4. weitere nicht-statische Abh\u00e4ngigkeiten aufl\u00f6sen.<\/p>\n

    In einem solchen Fall bieten uns Sprachen wir Java oder C# die M\u00f6glichkeit, die Methode auf den aktuellen Bereich zu beschr\u00e4nken. In Java k\u00f6nnen wir die Klasse package scoped <\/em>machen; in C# nutzen wir das Schl\u00fcsselwort internal<\/em>. Beides f\u00fchrt dazu, dass wir in unserem Test, welcher im gleichen package liegt oder Zugriff auf internals hat, auf die Methode zugreifen k\u00f6nnen.<\/p>\n

    Eine weitere M\u00f6glichkeit liegt darin, die Methode protected <\/em>zu definieren und die Test-Klasse davon abzuleiten. In diesem Fall k\u00f6nnen wir auf die Methode zugreifen, nicht abgeleitete Klassen aber nicht. (Dies funktioniert dann auch in Sprachen wie C++).<\/p>\n

     <\/p>\n

    Break Out Method Object<\/h1>\n

    Was aber tun wir, wenn unsere zu testende Methode sehr lang ist und viele Abh\u00e4ngigkeiten hat? Einen Test zu schreiben w\u00fcrde bedeuten, die gesamte, riesige Klasse zu instanziieren und alle Abh\u00e4ngigkeiten in unserem Test aufzubauen. Das Muster Expose Static Method <\/em>ist hier mitunter ungeeignet, wenn es einfach zu viele Abh\u00e4ngigkeiten gibt, die Koh\u00e4sion der Methode also recht hoch ist.<\/p>\n

    In einem solchen Fall hilft es, der Methode eine eigene Klasse zu spendieren. Wenn sie so gro\u00df und umfangreich ist, tut sie oft ohnehin viel zu viel und geh\u00f6rt h\u00e4ufig gar nicht in die Klasse, in der wir sie vorgefunden haben.<\/p>\n

    Beim Muster Break Out Method Object <\/em>ziehen wir die zu testende Methode mitsamt allen Abh\u00e4ngigkeiten in eine eigene Klasse. Dabei werden nur diejenigen Abh\u00e4ngigkeiten mitgenommen, die von der zu testenden Methode verwendet werden. Alle anderen bleiben in der bisherigen Klasse. Dies sorgt f\u00fcr eine bessere Trennung der Aufgaben, verringert die Abh\u00e4ngigkeiten und erleichtert es uns, die Methode in der neuen Klasse zu testen.<\/p>\n

     <\/p>\n

    Anleitung<\/h2>\n

    Das Erstellen einer neuen Klasse und das \u00fcberf\u00fchren der Methode dort hinein ist ein wenig aufwendiger als im obigen Muster.<\/p>\n

    Hier die Schritt-f\u00fcr-Schritt Anleitung dazu:<\/p>\n

      \n
    1. Neue, leere Klasse f\u00fcr die Methode erstellen<\/li>\n
    2. Konstruktor mit der Signatur der bisherigen Methode erstellen\n