Super erzwingen, konzept/pattern gesucht.

[Empire Phoenix]

Hi, mein Problem ist folgendes:

Ich habe die Klassen
SEntity
-> ..
SUseable
->
SChest....

SEntity ist hierbei die Obersteklasse für ein Serverseitiges Entity, und enthält umbeding notwendigen code. Unter anderem auch die methode update(), die alle 50 ms aufgerufen wird und aus netzwergründen wichtig ist.

Nun erbt SUseable sowie einige dutzend andere Klassen von SEntity, die alle ebenfalls eigene logic im update() hinzufügen. Als beispiel sei hier eine SChest genannt.

Nun kann es passieren das zb bei der SChest vergessen wird im update() super.update() aufzurufen, gibt es einen weg wie ich dieses erwingen kann?

Das normale vorgehen währe ja update in SEntity final zu machen und eine leere methode doupdate() zu erstellen die dann dort aufgerufen wird und von den subklassen untsprechend implementiert wird. Jedoch habe ich eine nicht vorhersagbare tiefe von vererbungen und muss dennoch garantieren können, das IMMER alle super aufgerufen werden.

 

[Landei]

Soweit ich weiß geht das nur, in dem man update [c]final[/c] macht, und in den Unterklassen andere Namen verwendet, etwa:

public abstract class SEntity {
    public final void update(){ 
        beforeUpdate();
        //wichtiger Code
        afterUpdate();
    }
  
    public abstract void beforeUpdate();
    public abstract void afterUpdate();
}

Die Unterklassen können dann in [c]beforeUpdate[/c] und [c]afterUpdate[/c] tun, was sie wollen, aber [c]update[/c] selbst nicht mehr überschreiben. Natürlich kann dieses Design für manche Aufgaben zu unflexibel sein.

 

[Gastredner]

Ich glaube kaum, dass es da eine technische Lösung geben wird. Spontan würde mir nur ein Flag einfallen, welches von der doupdate-Methode in SEntity gesetzt wird (doupdate dürfte dann nicht abstract sein). update würde nach dem Aufruf von doupdate dann überprüfen, ob dieses Flag gesetzt worden ist und bei Bedarf eine Exception schmeißen. Irgendetwas in diese Richtung also:

public class SEntity {

	private boolean checkSuper;

	public final void update() {
		doUpdate();
		if (checkSuper) {
			checkSuper = false;
		} else {
			throw new IllegalStateException("Overridden doUpdate methods MUST call super.doUpdate()!");
		}
	}

	public void doUpdate() {
		checkSuper = true;
	}
}

Dem Entwickler, der das super in seiner überschriebenen doupdate-Methode vergisst, würde das Programm daher beim ersten Test mit einer entsprechenden Fehlermeldung um die Ohren fliegen. Sonderlich elegant kommt mir das allerdings nicht vor.
Am einfachsten und womöglich auch am besten wäre einfach ein entsprechender, sehr deutlicher Hinweis in der Dokumentation von SEntity bzw. update.

 

[SlaterB]

unbekannt viele Ebenen sorgen höchstens für unschöne Methodennamen: update2(), update3(), ..,
wären technisch aber denkbar zusammen mit final

 

[FArt]

Ich würde hier von Vererbung absehen und Delegation verwenden. Der ursprünglichen Beschreibung nach, könnte das Dekorierer-Muster hier ein passendes Muster sein. Man könnte dann z.B. die entsprechenden Objekte mit der Netzwerkfunktionalität aus "update" dekorieren.

 

[Empire Phoenix]

Hi, danke erstmal für die vorschläge,

@Landei
hätte halt wie SlaterB sagt das problem das ich dann (schon derzeit) auf update6() kommen würde, und das ganze relativ unübersichtlich wird, ansonsten technsich gesehen sicher eine stabile Lösung.

@Gastredner
Denke ich werde das erstmal mit dem flag einbauen, das ist zwar nicht die technisch geniale Lösung, jedoch bin ich soweiso die Person die das ab und zu vergisst und auch die einzige die mit arbeitet (trotz doku davon inner Javadoc)

@Fart an und für sich klingt das Decorator pattern hier sinnvoll, das Problem ist jedoch das das update lediglich ein kleiner teil der ganzen Klasse ist, und ich für den rest normale vererbung brauche.

 

[Landei]

Es scheint jedenfalls keine "ordentliche" Lösung zu geben:

java - How to force derived class to call super method? (Like Android does) - Stack Overflow

java - How do I make sure a super method is called in a child? - Stack Overflow

c# - Force base method call - Stack Overflow

 

[FArt]

@Fart an und für sich klingt das Decorator pattern hier sinnvoll, das Problem ist jedoch das das update lediglich ein kleiner teil der ganzen Klasse ist, und ich für den rest normale vererbung brauche.

Das ist oft so. Man kann ja auch verschiedene Konzepte und Pattern kombinieren, z.B. gibt es Belange (concerns), die eine engere Bindung benötigen. Die regelt man gerne über Vererbung. Andere können mit Delegation besser gelöst werden. Und auch dafür gibt es mehr als nur einen Ansatz...

Generell: favour composition over inheritance... ist immer eine gute Regel...

 

[Landei]

Hier eine Rube-Goldberg-Overkill-Lösung, die ausnutzt, dass eine Klasse super im Konstruktor aufrufen muss:

public class Super {
    
    private final Class<? extends Super.Updater> clazz;
    
    public static class Updater {
        public Updater() {
            System.out.println("Do some super stuff"); 
        } 
    }
    
    public Super(Class<? extends Super.Updater> clazz) {
        if (! Super.Updater.class.isAssignableFrom(clazz)) {
              throw new IllegalArgumentException("Cheater!");
        }
        this.clazz = clazz;
    }
    
    public final void update() {
        try {
          clazz.newInstance();
        } catch (Exception ex) {
            ex.printStackTrace();
        }
    }
}

public class Sub extends Super {
    
    public static class Updater extends Super.Updater {
        public Updater() {
           System.out.println("Do some sub stuff");   
        }
    }
    
    public Sub() {
        super(Updater.class);
    }
   
}

new Sub().update();
//--> Do some super stuff
//--> Do some sub stuff