Hilfsklasse

🚧

Diese Seite befindet sich in Bearbeitung

🚧

🤓

Diese Seite ist eine Bewertungsrichtlinie, die ab Blatt 2 annotiert und ab Blatt 3 abgezogen wird.

🤓

Achtung

Hilfsklassen sind keine objektorientierte Programmierung.

Sie müssen alle Aufgaben objektorientiert lösen. Hilfsklassen sind, wenn überhaupt, nur für nicht zur Modellierung gehörenden Funktionen erlaubt!

Bevor Sie eine Hilfsklasse oder statische Methoden schreiben, vergewissern Sie sich, ob diese Funktionalität nicht eher zu einem Objekt passt!

Deutliche Indizien für fehlerhafte Modellierung mit Hilfsklassen sind:

• Funktionalität wird durch die Hilfsklasse ausgeführt
• Klassen halten nur einen Zustand, bieten aber keine oder nur wenig Funktionalität
• Klassen greifen auf Attribute/Objekte mithilfe der Hilfsklasse zu

Rechnen Sie mit deutlichem Punktabzug bei falscher Verwendung, die Aufgaben sind alle auf objektorientierte Programmierung ausgelegt!

Einleitung

Manchmal kommt es vor, dass wir bestimmte Funktionalitäten unabhängig von Klassen und deren Objekten implementieren wollen. Entsprechend rufen wir die Methoden dann auch nicht auf Objekten auf, sondern übergeben wenn dann welche als Parameter. Ein Hinweis, dass eine Utility Klasse benötigt werden könnte, ist, dass dieselbe Methode in mehreren Klassen vorkommt, aber nicht auf dem Objekt operiert. In diesem Fall wäre es besser, diese Methode "auszulagern" in eine Utility-Klasse.

Ein solches Beispiel dafür könnte eine Methode sein, die die Quersumme einer Zahl berechnet.

Hilfsklassen bringen auch eine Konvention mit:

Konvention

• Utility-Klassen müssen einen privaten Konstruktor besitzen, um sie nicht instanziieren zu können (Das wäre technisch gesehen kein direktes Problem, kann aber zu Verwirrung führen).
• Klasse zum Instanziieren ist im Singular zu benennen (z.B. Path).
• Utility-Klassen sind im Plural zu benennen (z.B. Paths).
• Das Mischen von Klassen- und Instanzmethoden in einer Klasse ist erlaubt. Innerhalb von Utility-Klassen sind allerdings nur Klassenmethoden zu definieren.
• Utility-Klassen müssen final sein, damit auch durch Vererbung keine Instanziierung möglich ist.

Negativbeispiel

public class StringUtilitiesBad {
    public static Magic performSomeMagic(final String string) {
        // ...
        return null;
    }
}

Hier ist es wegen dem fehlenden final Modifier und privaten Konstruktor möglich, die Klasse zu intanziieren. Das würde allerdings keinen Sinn ergeben, da wir die Methode ohne ein StringUtilBad Objekt verwenden können.

Positivbeispiel

public final class StringUtilitiesGood {
 
    private StringUtilitiesGood() {
        // No need to throw an exception here.
    }
 
    public static Magic performSomeMagic(final String string) {
        // ...
        return null;
    }
 
}

Hier wurden die Fehler behoben, die Klasse kann nicht mehr instanziiert werden.

Wenn du diese Seite interessant fandest, findest du hier noch mehr Seite(n) dazu:
Static