Ignorance
I have this class that''s keeping up with all the other entities in the game, so it has to have knowledge of all the other types of entities in the game.
Also, each entity has to have knowledge of the database.
The problem is if I do that, each entity must also have knowledge of every other type of entity!
This is what i mean, in pseudo-code:
database class header:
#include "joe"
#include "bob"
#include "fred"
joe''s header:
#include "database"
bob''s header:
#include "database"
fred''s header:
#include "database"
And so by Joe getting knowledge of the database, he also finds out about Bob and Fred!
Is there a simple way to fix this or do I need a book?
Forward declaration. As long as the implementations of each class use only pointers to instances of the other classes, you should be okay doing something like this:
//entities.h
class Bob;
class Joe;
class Fred;
#include "bob.h"
#include "joe.h"
#include "fred.h"
//manager.h
#include "entities.h"
//bob.h, etc
class Manager;
#include "entities.h"
#include "manager.h"
I *think* that may work.
Later,
ZE.
//email me.//zealouselixir software.//msdn.//n00biez.//
miscellaneous links
//entities.h
class Bob;
class Joe;
class Fred;
#include "bob.h"
#include "joe.h"
#include "fred.h"
//manager.h
#include "entities.h"
//bob.h, etc
class Manager;
#include "entities.h"
#include "manager.h"
I *think* that may work.
Later,
ZE.
//email me.//zealouselixir software.//msdn.//n00biez.//
miscellaneous links
Put in some defines to keep the structures within your headers from being compiled more than once, too.
Inside joe.h:
#ifndef JOE_H
#define JOE_H
(joe's declarations)
#endif
[edited by - Waverider on August 11, 2002 7:55:28 PM]
Inside joe.h:
#ifndef JOE_H
#define JOE_H
(joe's declarations)
#endif
[edited by - Waverider on August 11, 2002 7:55:28 PM]
quote:Original post by BradDaBug
It just seems like bad architecture when you modify joe.h and bob.cpp has to recompile.
Think about it like this: if you and I are business contacts and I change my phone number, you have to be notified of the change to keep up with me.
It''s just an unfortunate necessity. Besides, you''ll probably be changing the implementations a whole lot more than the header files.
Later,
ZE.
//email me.//zealouselixir software.//msdn.//n00biez.//
miscellaneous links
Generally, you would try and avoid such ''circular references'' in your design. They can often be broken if you give it some thought, and this will reduce the amount of recompilation. Using pointers (which can be forward declared) rather than instances (which cannot) is perhaps the most common way to do it in C/C++, although you then have to worry about pointer management which is a big source of errors. You might also be able to split your database up into 2 parts, with separate headers - one for the database implementation, and one for the interface that the various Bob/Joe/Fred classes use. Bjarne Stroustrup shows something like this in his book The C++ Programming Language.
[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions | Organising code files | My stuff ]
[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions | Organising code files | My stuff ]
quote:Original post by ZealousElixir Think about it like this: if you and I are business contacts and I change my phone number, you have to be notified of the change to keep up with me.
It''s just an unfortunate necessity. Besides, you''ll probably be changing the implementations a whole lot more than the header files.
Later,
ZE.
as a real business man i have a PHONE_NUMBER BizMan::GetPhoneNumber() Method.. cheers
(or you have a class PhoneBook where each person can change its number, and you can look up other persons numbers..)
"take a look around" - limp bizkit
www.google.com
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement