Hilfsklasse: Unterschied zwischen den Versionen

Aus Programmieren-Wiki
Keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
Zeile 3: Zeile 3:
|blatt=2
|blatt=2
|beschreibung=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.
|beschreibung=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.
Ein solches Beispiel dafür könnte eine Methode sein, die die Quersumme einer Zahl berechnet.
Zeile 15: Zeile 16:
* Utility-Klassen müssen final sein, damit auch durch Vererbung keine Instanziierung möglich ist
* Utility-Klassen müssen final sein, damit auch durch Vererbung keine Instanziierung möglich ist
|schweregrad=leicht
|schweregrad=leicht
|negativ=<syntaxhighlight lang="Java">
public class StringUtilBad {
    public static Magic performSomeMagic(final String string) {
        // ...
        return null;
    }
}
</syntaxhighlight>
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.
|positiv=<syntaxhighlight lang="Java">
public final class StringUtilsGood {
    private StringUtilGood() {
        // No need to throw an exception here.
    }
    public static Magic performSomeMagic(final String string) {
        // ...
        return null;
    }
}
</syntaxhighlight>
Hier wurden die Fehler behoben, die Klasse kann nicht mehr instanziiert werden.
|kategorie=Java Grundlagen, Objektorientierung
|kategorie=Java Grundlagen, Objektorientierung
|weiterlesen=Ja
|weiterlesen=Ja
|seite=Static
|seite=Static
}}
}}

Version vom 2. Juni 2024, 18:48 Uhr

🚧 Diese Seite befindet sich in Bearbeitung 🚧
🤓 Diese Seite ist eine Bewertungsrichtlinie, die ab Blatt 2 annotiert und ab Blatt 3 abgezogen wird. 🤓

Beschreibung

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 StringUtilBad {
    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 StringUtilsGood {
 
    private StringUtilGood() {
        // 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