Mail Archives: djgpp/1999/04/02/23:45:49
Willem D wrote:
> Hi Matthew,
> It is very good practice to break down your code in modules, so that you are
> able to use some of it in your next program. With a module, I do not mean
> files exactly, but rather a set of files, i.e. directories. The trick is to
> make design decisions on which module (or component) uses which.
> You end up with a layered design.
> For instance, a system could could have a human interface component (HIC), a
> problem domain component (PDC) and a Process Control Component (PCC). The HIC
> uses the PDC, and the PCC uses the HIC and the PDC. No other usages are
> allowed.
>
> The charpic below show which components provides services to which.
>
> HIC <-- PDC
> | |
> |----------> PCC
>
> In practice you see a game (shoot 'em up tanks) devided as follows: PDC:
> tank.cpp (postitioning, movement etc) misile.cpp (same a above) The PDC
> contains the "mathematics" of your game. HIC: Here you could implement
> deffered draw methods (via inheritance etc) of the PDC. e.g. tank_alleg.cpp
> etc. PCC: Here the implemenation of communication to other players and game
> state information can be managed, also the main loops for the game could be
> written in this component. In this simple example you can replace the HIC to
> use DirectX later (by creating and using tank_dx.ccp for example) without
> touching the rest of your code, and fully reusing the actual source. Ie. a
> fix ion your allegro game could 'imply' a fix in your directx game. This is
> not a full definition of a program. The point I want to make it that you
> should sit down and think about the components (or modules) and their
> dependancies before you "break up" you current code. I hope my explanation is
> clear enough. Good luck.
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Thanks for your help. This will definately help.
Matthew Heyman
- Raw text -