Best Practice Alternativen für Event-Handling

[MR_UNIX]

Hallo Leute,

für mein aktuelles Projekt suche ich noch Vorschläge, wie ich das Event-Handling umsetzen kann.

Natürlich habe ich selber schon ein wenig recherchiert - ich möchte mir ja nur Unterstützung suchen und nicht alles vorkauen lassen - aber da habe ich eigentlich ausschließlich das Observer-Observable Pattern gefunden.
Es gibt aber mehrere Gründe, warum mir dieses in meinem Kontext nicht wirklich gut gefällt:

• Events sollen bei mir nur aus einer Klasse abgefeuert werden
• Das "Observable" wäre die Hauptklasse, was nicht sonderlich schön ist
• Versch. Events nicht wirklich schön umsetzbar aufgrund vorhergehender Fakten

Bei der Software, in die das Eventsystem integriert werden soll, ist eine Client-Server Anwendung. Events sollen dann bspw. ausgelöst werden, wenn ein Client sich anmeldet bzw. abmeldet, der Server crasht (Exception geworfen) oder ähnliches.

Ich würde mich sehr freuen, wenn ihr mir sinnvolle Alternativen für ein solches Event-Handling Prinzip nennen könntet. Am besten wäre es, wenn ihr direkt auch kleine Codebeispiele dazu schreiben könntet.
Bei weiteren Fragen stehe ich natürlich zur Verfügung.

Danke im Voraus!

 

[Ruzmanz]

Ehrlich habe ich nicht ganz verstanden, warum das Observer Pattern nicht infrage kommt. Eine vereinfachte Form könnte so aussehen:

Interface:

public interface IEatable {
    public void eat(EatEvent event);
}

Zusätzliche Informationen, wenn die dem Listener übergeben werden (optinal). Am besten immutable gestalten:

public class EatEvent {
    private Fruit fruit;
    
    public EatEvent(Fruit fruit) {
        this.fruit = fruit;
    }

    public String getFruitName() {
        return fruit.getName();
    }
}

Zentrale Klasse, welche alle IEatable-Klassen kennt. Kann man z.B. als Singleton umsetzen. Oder man passt ein bisschen auf ...

publlic class FruitBasket {
    private ArrayList<IEatable> eatables;

    public void addFruit(Fruit fruit) {
         notifyAll(new EatEvent(fruit));
    }

    public void addEatableListener(IEatable eatable) {
        eatables.add(eatable);
    }

    public void notifyAll(EatEvent ev) {
        for(IEatable e: eatables) e.eat(ev);
    }
}

// FruitBasket b = new FruitBasket();
// b.addEatableListener(klasse1);
// b.addEatableListener(klasse2);
// b.addFruit(new Apple());
// --> Die Methode eat() wird von klasse1 und klasse2 aufgerufen.

Kann man noch einiges ausbauen, ist halt nur ein Grundgerüst.

 

[turtle]

eine Client-Server Anwendung. Events sollen dann bspw. ausgelöst werden, wenn ein Client sich anmeldet bzw. abmeldet, der Server crasht (Exception geworfen) oder ähnliches.

DAS ist wohl ein grundsätzliches Problem. Und deine Beschreibung ist da nicht eindeutig, WAS genau passieren soll (im Client bzw. im Server).

Erstens ist wichtig welche Client/Server-Kommunikation du einsetzen möchtest, denn davon ist abhängig ob und wie die beiden Teile sich unterhalten können.

Du kannst dem Server mitteilen, das der Client nicht mehr da ist obwohl das schwieriger ist, weil ein Client ja auch einfach, ohne den Server zu benachrichtigen, abstürzen kann (Netzwerkkabel ziehen).

Noch schwieriger wird es, wenn der Server die Clients informieren soll, wenn einer der Clients verloren wurde. Oftmals wird diese Situation ignoriert, weil es halt SCHWIERIG ist. Wie stellst du sicher das der Server Informationen an die Clients schicken kann und wie behandelst du Probleme, wenn der Client die Informationen gerade nicht bearbeiten kann? (Daher updaten Clients ihre Informationen über aktuelle Clients, indem sie beim Server nachfragen.)

Diese Notifications über JVM-Grenzen hinweg sind von der eingesetzten Technik abhängig. Hast du eine Socket-Verbindung kannst du derartige Meldungen "leicht" hin-und herschicken. Aber wie geht das beispielsweise mit RMI?

Und ein Server-Crash ist für Notification-Events natürlich der GAU, denn es gibt keine Events mehr, die irgendwie zugestellt werden könnten.

Alles in allem ein aufwändiges Thema und du musst dir genauer den Workflow zwischen Client/Server überlegen und beschreiben.

 

[MR_UNIX]

Hallo,

danke für eure beiden umfangreichen Antworten. Beide haben mir bei meiner Problemstellung einen Fortschritt verschafft.

@Ruzmanz:
Deinen Vorschlag werde ich die Tage mal versuchen, in das bestehende System zu integrieren - wobei so weit ich das gesehen habe die Ähnlichkeit zum Observer/Observable Pattern doch recht ähnlich ist.

@turtle:
Das Eventhandling soll dazu dienen, dass - ähnlich wie bei Bukkit - bei bestimmten Ereignissen eben Plugins (oder auch integrierte Bestandteile im Server) informiert werden sollen, damit dann eine bestimmte Aktion ausgeführt werden kann. So wird zum Beispiel wenn ein Benutzer sich ausloggt ein Event ausgelöst und die Serveranwendung selbst reagiert mit einer Push-Mitteilung an die verbleibenden Clients. Ein Plugin soll dies zum Beispiel nutzen können, um die aktuelle Benutzerzahl abzurufen o.ä.

Die Kommunikation zwischen Server und Clients erfolgt über (SSL-)Sockets. In meinem Anwendungs-Szenario spielt das aber keine Rolle, da der Client wenn dann nur explizit durch Servermodule aber nicht durch das Event implizit informiert werden soll. Eine Abmeldung des Benutzers, die nicht geplant ist (wie bspw. dein "Kabelziehenbeispiel") wird so erkannt, dass Heartbeat Nachrichten gesendet werden - bekanntes Prinzip. Wenn die nicht beantwortet werden, wird der Client als "tot" eingestuft und vom Server aus abgemeldet.

Die Kommunikation bzw. die Anwendung an sich steht auch schon, es geht nur darum, in das bestehende System möglichst ohne großen Aufwand ein solches Event-Handling einzufügen. Generell wurde eine Art eigenes Protokoll auf Basis bestimmter Kommandos realisiert, welches explizit modular aufgebaut ist, damit Plugins sogar das Protokoll an sich und nicht nur die Funktionalität erweitern können. Genaue Quellcodebeispiele möchte ich hier aus gewissen Gründen nicht nennen.

Klar, ein Crash an sich kann durch ein Eventsystem nicht wirklich abgedeckt werden. Wenn man aber das Exception-Handling entsprechend aufbaut - und das ist der Fall - dann kann wenigstens im Falle einer solchen Ausnahme ein Event ausgelöst werden. Das ist hier auch das Ziel.

Ich hoffe, ich konnte alle Fragen klären.