Code versus Design versus Time versus, ahh forget it, just call it armagedon

So what is the best way to software engineer a large project? Well, I learned about the object oriented design in school, which basically (hand waving commence) is use case driven with iteration and refinement at every stage of the development process (not too sure man, I don’t remember a damn thing from that class). But what about the agile method and all that other “stuff.” No idea. Maybe I should read up on it. Well, the S.E course I took went over Agile, among an assortment of other S.E stuff, but I don’t remember much about it. *Cynical statement* Nice way to burn wads of cash when you think about it, going through 4 years of school and not remember a darn thing.

But for Project Zombie, I started with a few use cases and scenarios, then I drew some UML class diagrams to map out an initial picture of the relationships between classes. Then I just sat down and banged them out. And pretty much along the way I did the iteration and refine thing.

So far I’m happy with the way this project is going.

—

Refactor, refactor, refactor…

So I refactored again my event delegation thingy. What I’m doing now is instead of composing the event Registers inside classes, I am simply pushing these objects to whatever classes that needs to register for events. This is a better design. (Much cleaner, since they can be allocated on the stack)

Also, having thought about the Singleton thing, I think if I re-coded the way events are registered by invoking directly the event PUMPS (the thing that updates all observers observing an subject. Observer pattern) to register events is a BETTER design. I chose my current design initially because I was worried about the behavior when changing states (remember, my system is Finite STATE driven with the concept of stateful and stateless states, think of them as stateless or stateful webpages; I totally jacked this concept from SEAM), i.e. what is the behavior when I need to unregister events? During my initial refatoring, I ALMOST went with the singleton route, but I got freaked out, totally concentrating too much on decoupling (and KISS, and DRY, damn you the Pragmatic programmer! You should go out and read this book now. It’s awesome although I haven’t finished it yet). That is to say, the way I’m doing it now registering for events is decoupled from the event pump itself.

But now I think about it, this is a none issue. When state changes everything should be automatically unregistered from the event pump (current behavior), so if I implemented the PUMPS as singletons they would behave the same.

But who knows, maybe the way I’m doing it now may have advantages later.

I may have to implement other events such as Camera changes etc, I may implement them using the Singleton design mentioned above.

I sort of rushing things, so perhaps I should give more thoughts to design when iterating and refining.

Refactor, refactor, refactor!!!

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.