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.
