Redundanzen

Definition

Erläuterungen

Redundanzen sind in der Regel unerwünscht, da sie den Quelltext unübersichtlich machen, die Wartung erschweren und die Fehleranfälligkeit erhöhen. Ändert sich etwa eine Anforderung, muss die Änderung an mehreren Stellen vorgenommen werden, was das Risiko von Inkonsistenzen erhöht.

In der Softwareentwicklung wird daher versucht, Redundanzen durch geeignete Techniken zu vermeiden, etwa durch Modularisierung (Zerlegung in wiederverwendbare Methoden oder Klassen) oder durch Vererbung und Polymorphie in der objektorientierten Programmierung.

Entfernung von Redundanzen

Betrachten wir einen simplen Quelltext mit stark redundantem Code:

public void zeigeKreis()
{
   System.out.println("Figur: Kreis");
   System.out.println("Farbe: blau");
}

public void zeigeQuadrat()
{
   System.out.println("Figur: Quadrat");
   System.out.println("Farbe: blau");
}

Die beiden Methoden sind fast völlig identisch, sie unterscheiden sich nur in einem Punkt, nämlich in der Angabe der Figur "Kreis" oder "Quadrat".

Entfernung durch Modularisierung

Hier eine Version ohne Redundanzen, die durch Modularisierung erreicht wurde:

public void zeigeFigur(String name)
{
   System.out.println("Figur: " + name);
   System.out.println("Farbe: blau");
}

Der gemeinsame (redundante) Code wurde in ein neues Modul ausgelagert, in Java wäre das also eine neue Methode (bei größeren "Umbauten" würde man dann eine eigene Klasse anlegen, für dieses kurze Beispiel reicht aber eine eigene Methode).

zeigeFigur("Kreis");
zeigeFigur("Quadrat");

Die so erstellte Methode wird dann einmal mit dem Parameter "Kreis" und einmal mit dem Parameter "Quadrat" aufgerufen.

Wenn sich jetzt die Anforderungen an die Ausgabe ändern, muss nur noch an einer Stelle in der Klasse gearbeitet werden, nämlich in der neuen Methode zeigeFigur().

Entfernung durch Polymorphie

Zunächst benötigen wir eine Oberklasse, die wir einfach mal Figur nennen:

public abstract class Figur
{
    private String farbe = "blau";   // gemeinsame Eigenschaft

    public final void zeige()
    {
        System.out.println("Figur: " + bezeichnung());
        System.out.println("Farbe: " + farbe);
    }

    protected abstract String bezeichnung();
}

Die gesamte Ausgabe der Informationen wird von der Oberklasse bereit gestellt. Für jede Figur erstellen wir dann eine Unterklasse, Kreis und Quadrat. Hier der Quelltext von Kreis:

public class Kreis extends Figur
{
    @Override
    protected String bezeichnung()
    {
        return "Kreis";
    }
}

Die Quelltext von Quadrat ist analog aufgebaut.

Schließlich die Klasse Demo, die auf die beiden Klassen zugreift:

public class Demo
{
    public static void main(String[] args)
    {
        Figur f1 = new Kreis();
        Figur f2 = new Quadrat();

        f1.zeige();
        f2.zeige();
    }
}

Zugegeben, der Quelltext dieser Version ist deutlich länger als der der redundanten Version, aber er dient ja auch nur zur Demonstration des Prinzips: "Vermeidung von Redundanzen durch Polymorphie".

Hier ein paar Gründe, wieso der überarbeitete und längere Quelltext doch besser ist als die kurze aber redundante Version.

Warum Redundanz durch Polymorphie vermeiden?