haxe: How to create neat observer pattern prototype

Question

I have created simple observer prototype:

class CObservable<T> {

    public function new() {
        mObservers = new Array<T>();
    }

    public function sign(aObserver:T):Bool {
        for (observer in mObservers)
            if (observer == aObserver)
                return false;
        mObservers.push(aObserver);
        return true;
    }

    private var mObservers:Array<T>;

}

And create interface with some callback functions:

interface IConcreteObserver {

    function onStart(aObservable:CConcreteObservable):Void;

    function onStop(aObservable:CConcreteObservable):Void;

    // ... more callbacks with same signature that differs only by names ...

}

And then I extend prototype with some concrete class:

class CConcreteObservable extends CObservable<IConcreteObserver> {

    public function new() {
        super();
    }

    public function notifyStart():Void {
        for (observer in mObservers)
            observer.onStart(this);
    }

    public function notifyStop():Void {
        for (observer in mObservers)
            observer.onStop(this);
    }

    // ... more notify methods for every callback ...
    // ... more and more ...
    // ... and even more ...

}

All these copy-pastes looks quite impractical for me especially when I have over than a dozen callback methods. Is there any neat trick to declare one simple notify method or may be macro in prototype and call them like notify(onStart), notify(onStop) and so on?

It's a bit unclear what you're trying to achieve here, but it looks like some weird Java pattern that makes no sense in a language with first class functions. I suggest using Signals which are the way to go in Haxe. Take a look at [tink_core](https://github.com/haxetink/tink_core#signal) or [msignal](https://github.com/massiveinteractive/msignal). — back2dos, Mar 02 '14 at 07:23
I am trying to use clean descriptive interfaces (onStart, onStop ...) for every observer classes instead of strange function-oriented callbacks (sign(eventType, eventListener) -- what is event type? what is listener syntax?). And thus when concrete observable class dispatches some notification it calls one significant method of every observer that implements corresponding interface. It have one big drawback that even if you don't need all events you MUST at least implement dummy functions at observer class or I have to split all quantity of possible events to the bunch of different interfaces. — meps, Mar 02 '14 at 20:17
Of cause I can create something like `signStart(listener:CConcreteObservable->Void)`, `signStop(listener:CConcreteObservable->Void)` and so on without any interfaces at all. But it will produce the same or even heavier copy-paste problem with a list of inner containers for different listeners references. — meps, Mar 02 '14 at 20:32
There's no "event type" involved. I suggest you actually read about the things I proposed. I would also point out that Haxe's enums act as algebraic data types and you can thus force a handler to deal with many different notifications, e.g. `enum Message { Start; Stop; }` and then have a `Signal`. There's no copy pasting or anything. — back2dos, Mar 03 '14 at 12:13

haxe: How to create neat observer pattern prototype

0 Answers0