Singleton mit protected Konstruktor

In der Vorlesung Modellbasierte Softwareentwicklung sollten wir in der Übung eben ein Template zur Generierung des Codes für ein Singleton-Pattern angeben.

Ein Kommilitone hat ein Template mit protected-Konstruktor angeben. Ein Beispiel eine Klasse, die aus dem Template erzeugt werden könnte, ist:

package mbse;

public class Singleton {
    private static Singleton instance = null;
protected Singleton() {
}

public static Singleton getInstance() {
    if(instance == null) {
        instance = null;
    }
    return instance;
}

}

Immerhin kann man von der Klasse direkt keine weiteren Instanzen erzeugen. Soweit dies ja schon mal keine naive Implementierung.

Auf die Nachfrage von mehreren Studenten, dass der Konstruktor doch private sein müsse, wurde nur reagiert mit dem Hinweis, dass dies eine Implementierungsalternative wäre. Nein, dies ist es nicht. Mit einem protected-Konstruktor kann die Singelton-Eigenschaft einfach aus gehebelt werden.

Mit einem protected-Konstruktor kann jeder von der Klasse eine neue Klasse ableiten. Diese Klasse könnte wie folgt aussehen:

package other;

import mbse.Singleton;
public class SubSingleton extends Singleton {
    public SubSingleton() {
}

}

Von dieser Klasse lassen sich durch den public-Konstruktor einfach beliebig viele Instanzen erstellen. Die Eigenschaft, dass nur eine Instanz der Klasse existiert wurde damit sehr einfach aus gehebelt. Wenn sich dieser Code in einer API befinden würde, dann wäre dies möglicherweise kritisch. Aber auch aus Versehen könnte so etwas passieren, wenn einem anderem Entwickler nicht bewusst ist, dass es sich um ein Singleton handelt.

Wenn Singelton (meist ist dies keine so gute Idee), dann doch bitte nur mit private-Konstruktor.