EDITED:
I’ve since then changed the behavior to use composition of the registers versus sub-class. One of the reasons I’m using delegates is to try to minimize a whole bunch of interface implementation. So sub-classing just to register for event pumps defeats the whole purpose.
So now I’m using composition, allocating the registers on the heap, and deleting them as soon I’m done with registering.
——————
Everyone has to re-factor, right? But, if you are Programming God, who never needs any re-factoring, then I bow down to your greatness, hell, forget bowing, I kowtow to you! *KOWTOWS*
Anyway, I got rid of some fugliness with the way I was doing delegate subject/observer pattern injection (try saying that out loud on your next date, nerd factor engage!) code. It’s much cleaner now.
So I have this class called LifeCycleRegister; it’s responsibility is to register LifeCycleObservers. The idea is that any class who needs LifeCycle events pumped to them should subclass this class.
namespace ZGame
{
class LifeCycleRegister
{
public:
LifeCycleRegister();
virtual
~LifeCycleRegister();
void injectLfcSubj(const LifeCycle::LifeCycleSubject &subj);
protected:
virtual void regLfcObsForInjection() = 0; //called to register for lifecycle subject injection.
void registerLfcObs(const LifeCycle::LifeCycleObserver& obs); //helper function to do the actual registration.
LifeCycle::LifeCycleObserver _obs;
bool _isRegistered;
};
}
Now, in my GameState class I just need to do this
void GameMainState::regLfcObsForInjection()
{
LifeCycle::LifeCycleObserver lfcObs;
lfcObs.onInit.bind(&GameMainState::onInit,this);
lfcObs.onUpdate.bind(&GameMainState::onUpdate,this);
lfcObs.onDestroy.bind(&GameMainState::onDestroy,this);
//don't forget to call helper method to register, else exception is thrown.
registerLfcObs(lfcObs);
}
Admittedly, it is a abit more involved than that with a bit more boilerplate/plumbing code. But it’s exponentially better than what I was doing before. Before, each subclass called a base-class to register an injector; the injector delegates to a method in the subclass to inject the subject delegate, which gets called from the base-class (confused yet?) Now, I got rid of that, an inutile extra layer to accomplish the injection of subjects for which we add observers to.
So it’s all good!
Is there another design for this event driven programming? I thought about having a singleton class for which to register for events. But then what is the behavior for unregistering events? My current design followed from my thinking on implementing the game behaviors as a finite state machine, with the concept of stateful and stateless states (every state also has a meta state, with which we can use to realize an actual state). For a “noob” like me there is always the question of balancing design and the instant gratification of coding, not to mention the factor of time.
