Mail Archives: djgpp/1999/04/01/20:07:35
In article <E5119E9B3D7E6103 DOT 0C2B744CC0FAB02E DOT C83C40393E95C2F8 AT library-
proxy.airnews.net>,
kay DOT heyman AT airmail DOT net wrote:
> Hello
> I was recently messing with a program I was writing, and was wondering
> if there was any worth in breaking it up into smaller .cpp files with
> very specific stuff, IE one for keyboard commands, one for various other
> stuff. Is it wise to do this, or is it just a preferential thing?
> I
>was also wondering how to actually implement functions from other .cpp
> files into the main file. I tried a direct cut-paste into a second
> file, but ended up with a bunch of errors. I'm not sure how to do it in
> the first place, and that could be my problem. Any thoughts, pointers,
> or ideas?
>
> Matthew Heyman
>
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
- Raw text -