This example necessitates your program broken down into blocks which I like to call a module. If you consider that a module does one specific task (in the OOP philosophy) each module has to talk to its other modules in order to perform more complex tasks. Eg. Your cells work together to keep oxygen in the blood and the blood flowing to keep you alive (no offense to androids or aliens out there).
A flow chart/spider diagram (mind map as some people say - I have no idea which is correct). To illustrate, here is a picture of a map I had to do to make my life so much easier when dealing with the Prometheus rewrite: its modular and shows what module depends on what other module:
From that image alone I can tell one thing - the first thing I will be working on will NOT be PM_Window. Why? Because for that to happen I need PM_X11Window, PM_Event and so on. If I draw up PM_Window and I say I just need a few variables, then arrive to write the PM_X11Window module and find that for that to happen I need a more complex, unimplemented datatype. Or worse, I start work on PM_Window and write it up. In the process, I find I need a common module like PM_Debug, so I quickly write that up too. But after I write up PM_Window doing so I find it clashes with procedures from PM_Utils (No, that actually happened). I must now tear up PM_Window to fix this because PM_Debug needed to talk to other, non WM related modules. Before you set out making stuff, at least know how it fits together...
vBulletin Message