Question about large objects

[JoeC]

I have been writing games and I also read about good programming
techniques. I tend to create large objects that do lots of things. A
good example I have is a unit object. The object controls and holds
everything a unit in my game is supposed to do. What are some some
cures for this kind of large object or are they OK because they
represent one thing. If not what are better ways to design objects
that behave the same way. Would it be better to use inheritance or
friends and where can I look to be able to do the same thing in a
better way?

Here is a unit from a completed game I created. The header file at
least to give an idea of one of my larger objects.

#include<fstream>
#include<vector>
#include<cmath>
#include<map>

#include"coord.h"
#include"color.h"
#include"graphics.h"
#include"tbox.h"

#ifndef UNIT_H
#define UNIT_H

class unit{
protected:

HWND hwnd;
coord loc;
coord currentLoc;
graphics * gr;
tbox * combatBox;
std::vector<color>colors;
std::map<char, coord> keys; //movement engine
coord n; //directions
coord s;
coord e;
coord w;
char kind;

float attack;
float dattack;
float defence;
int move;
int moved;
int dmove;
int range;
bool canmove;
bool selected;
bool mark;
bool disburse;
int col;

void create();
void displayBox(HDC, coord);
int convert(const int n){return n * 16;}

public:
unit();
unit(HWND,graphics*,int,int,int);
unit(HWND,graphics*,int,int,int,int,int);
unit(HWND,graphics*,DWORD,float, float, int, int, int);
unit(HWND,graphics*,DWORD,float, float, int, int, int, bool);
unit(unit*);
~unit();

DWORD sideColor(){return colors[0].getCode();}
int intAttack(){return attack;}
int intDefence(){return defence;}
float Attack(){return attack;}
float Defence(){return defence;}
int Moved(){return moved;}

void display(HDC); //display at crrent loc
void display(HDC, int, int); //display at specific loc
void display(HDC, int); //display with offset for stacking
void displayBig(HDC, int, int);
void change(HWND);
void update(HWND, coord);

coord nextCoord(char);
void mover(coord&, int);
void reset();
void tomark(); //marks unit for death;
bool marked(){return mark;}
coord getCoord(){return loc;}
coord getCurrent(){return currentLoc;}
bool canMove(){return canmove;}
bool isSelect(){return selected;}
bool inRange(coord);
void selectOn(){selected = true;}
void selectOff(){selected = false;}
void isArt(){range = 12;}
void cBoxOn(){combatBox = new tbox;};
void disbersed();
void unDisberse(){disburse = false;}
void write(std:fstream&);
void load(std::ifstream&);
void addk(char k){kind = k;}
};

#endif

 

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

I have been writing games and I also read about good programming
techniques. I tend to create large objects that do lots of things. A
good example I have is a unit object. The object controls and holds
everything a unit in my game is supposed to do. What are some some
cures for this kind of large object or are they OK because they
represent one thing. If not what are better ways to design objects
that behave the same way. Would it be better to use inheritance or
friends and where can I look to be able to do the same thing in a
better way?

That depends on a lot of things, like what a unit is. If unit is a
generalization of a lot of things and your unit-class can act as any of
those then you should definitely break it down into a unit-class which
has all code shared among the different unit types and create subclasses
of it for each of the unit types. Or perhaps create a subclasses which
are further subclasses if it's possible to identify code that is common
for only a subset of the unit-types.

From the code posted it looks like the unit is a graphical object that
can be drawn on the screen, much of this functionality could probably be
put in a base-class. The save and load methods does not necessarily have
to be members, perhaps they are better of as friends or so, it's hard to
tell just from looking at the code given.

 

[Puppet_Sock]

I have been writing games and I also read about good programming
techniques. I tend to create large objects that do lots of things. A
good example I have is a unit object. The object controls and holds
everything a unit in my game is supposed to do. What are some some
cures for this kind of large object or are they OK because they
represent one thing. If not what are better ways to design objects
that behave the same way. Would it be better to use inheritance or
friends and where can I look to be able to do the same thing in a
better way?

[snip]

There is no one-size answer, but there are philosophical notions
to use to hunt for the right answer. Or at least a better answer.

Think of an object as an exporter of a service. If that service
makes sense as a unified single collection, then that's a good
object. If that object happens to be enormous, it is not always
a bad thing.

As Erik said, you may well be able to use inheritance to put
common features in a single class, and only implement them
one time. That will make each of a collection of objects
simpler at the expense of some abstraction. It is not always
an easy decision whether that's a win or not. So, looking at
your unit, you might think about inheriting from a class of
"thing that moves" or "thing that attacks" or "thing that gets
drawn on the screen" and so on. However, if there's only one
kind of unit, that may not be a big improvement.

Another common idiom is composition. Maybe you can have
a "thing that moves" class, and give each unit a data
member that is an instance of the "thing that moves."
You could then divide the "moving" service from the
rest of the class, and only implement moving once.
Again, this will make each of a collection of objects
somewhat simpler at the expense of some complexity
in the design. Again, it's not always easy to decide if
this makes sense.

You want to think about such service classes when
you have something that is going to be common to
several classes. For example, getting drawn on the
screen is likely to be quite common in a graphic
heavy program. So that makes a lot of sense as a
service class that a lot of other code uses.

To decide between inheritance and composition, think
about how the classes are related. You've got a unit
class. Are there other things in your program or game
that are "kinds of" that unit? If there are, then you
probably want to think inheritance. If you need a unit
and can put a "tree unit" there, just as an example,
that's a real good case for inheritance. But maybe
you've got unit meaning things that can move around,
and background stuff, like trees, as drawn in some
other way with much simpler data. So that might be
a good case for composition. You add onto the unit
and the tree the portions they need.

Try to analyse your program's task into packages of
services that make sense as single wholes, but that
would not make sense if you tried to subdivide them.
Look for areas where there is a lot of interaction among
tightly bound data, objects, methods, etc., and try
to keep them in one or a few objects. When there is
very loose connection between services, say one or
two function calls only, that's a good candidate for a
spot to divide things into two or more classes. If two
objects wind up calling eachother with many calls,
maybe they ought not to be two objects but one.

And try to think in terms of relationships between the
packages. In particular look for "is a" and "has a"
and "talks to a" relationships.
Socks

 

[BobR]

Here is a unit from a completed game I created. The header file at
least to give an idea of one of my larger objects.

One little thing (not related to your question): Put your header include
guards
'around' everything in your header.
[ On small projects, it makes little difference. On big projects, it will
parse faster
(thus, compile faster). ]


#ifndef UNIT_H // put these here.
#define UNIT_H
// now the compiler does not have to check the include guards
// in *each* of the following headers every time (only the first use).

#include<fstream>
#include<vector>
#include<cmath>
#include<map>
#include"coord.h"
#include"color.h"
#include"graphics.h"
#include"tbox.h"

// > #ifndef UNIT_H // move to top of file
// > #define UNIT_H

 

[=?iso-8859-1?q?Kirit_S=E6lensminde?=]

I have been writing games and I also read about good programming
techniques. I tend to create large objects that do lots of things. A
good example I have is a unit object. The object controls and holds
everything a unit in my game is supposed to do. What are some some
cures for this kind of large object or are they OK because they
represent one thing. If not what are better ways to design objects
that behave the same way. Would it be better to use inheritance or
friends and where can I look to be able to do the same thing in a
better way?

Here is a unit from a completed game I created. The header file at
least to give an idea of one of my larger objects.

[snip huge class]

You're using the class more like a namespace here. Objects should be
cohesive, which is a word that takes a look of thinking about to
really understand. A simple definition is that they should do only one
thing and do that one thing well. The smaller the scope of the one
thing they do the better.

Look at http://c2.com/cgi/wiki?ClassicOoAntiPatterns and especially
http://c2.com/cgi/wiki?ClassesWithoutOo


K

 

[JoeC]

That depends on a lot of things, like what a unit is. If unit is a
generalization of a lot of things and your unit-class can act as any of
those then you should definitely break it down into a unit-class which
has all code shared among the different unit types and create subclasses
of it for each of the unit types. Or perhaps create a subclasses which
are further subclasses if it's possible to identify code that is common
for only a subset of the unit-types.

From the code posted it looks like the unit is a graphical object that
can be drawn on the screen, much of this functionality could probably be
put in a base-class. The save and load methods does not necessarily have
to be members, perhaps they are better of as friends or so, it's hard to
tell just from looking at the code given.

I did see that about graphics functions. I am not sure if it is an is-
a or has-a relationship. I did derive the graphics in a previous
version of the program. In an earlier version I did the graphics as
an is-a. I am just trying to find the right balance for creating
objects.

 

[JoeC]

techniques. I tend to create large objects that do lots of things. A
good example I have is a unit object. The object controls and holds
everything a unit in my game is supposed to do. What are some some
cures for this kind of large object or are they OK because they
represent one thing. If not what are better ways to design objects
that behave the same way. Would it be better to use inheritance or
friends and where can I look to be able to do the same thing in a
better way?

[snip]

There is no one-size answer, but there are philosophical notions
to use to hunt for the right answer. Or at least a better answer.

Think of an object as an exporter of a service. If that service
makes sense as a unified single collection, then that's a good
object. If that object happens to be enormous, it is not always
a bad thing.

As Erik said, you may well be able to use inheritance to put
common features in a single class, and only implement them
one time. That will make each of a collection of objects
simpler at the expense of some abstraction. It is not always
an easy decision whether that's a win or not. So, looking at
your unit, you might think about inheriting from a class of
"thing that moves" or "thing that attacks" or "thing that gets
drawn on the screen" and so on. However, if there's only one
kind of unit, that may not be a big improvement.

Another common idiom is composition. Maybe you can have
a "thing that moves" class, and give each unit a data
member that is an instance of the "thing that moves."
You could then divide the "moving" service from the
rest of the class, and only implement moving once.
Again, this will make each of a collection of objects
somewhat simpler at the expense of some complexity
in the design. Again, it's not always easy to decide if
this makes sense.

You want to think about such service classes when
you have something that is going to be common to
several classes. For example, getting drawn on the
screen is likely to be quite common in a graphic
heavy program. So that makes a lot of sense as a
service class that a lot of other code uses.

To decide between inheritance and composition, think
about how the classes are related. You've got a unit
class. Are there other things in your program or game
that are "kinds of" that unit? If there are, then you
probably want to think inheritance. If you need a unit
and can put a "tree unit" there, just as an example,
that's a real good case for inheritance. But maybe
you've got unit meaning things that can move around,
and background stuff, like trees, as drawn in some
other way with much simpler data. So that might be
a good case for composition. You add onto the unit
and the tree the portions they need.

Try to analyse your program's task into packages of
services that make sense as single wholes, but that
would not make sense if you tried to subdivide them.
Look for areas where there is a lot of interaction among
tightly bound data, objects, methods, etc., and try
to keep them in one or a few objects. When there is
very loose connection between services, say one or
two function calls only, that's a good candidate for a
spot to divide things into two or more classes. If two
objects wind up calling eachother with many calls,
maybe they ought not to be two objects but one.

And try to think in terms of relationships between the
packages. In particular look for "is a" and "has a"
and "talks to a" relationships.
Socks

Good advice. I am trying to take what I read and create my own
projects. I like the ask questions on what I have done so see if I am
implementing concepts correctly. Here is my next generation of
graphics objects it is much more divided:

#include<windows.h>
#include<vector>

#include "graphics.h"
#include "color.h"
#include "coord.h"

#ifndef GRBIN_H
#define GRBIN_H

class grBin{

protected:
graphics * gr;
std::vector<color>colors;
coord loc;

public:
~grBin(){delete gr;}
void display(HWND, const int, const int);
void displayClear(HWND, const int, const int);
void displayBig(HWND, const int, const int);
int getX(){return loc.x;}
int getY(){return loc.y;}

};

#include<fstream>
#include<vector>

#include "grBin.h"
#include "grRiver.h"

#ifndef RIVER_H
#define RIVER_H

class river : public grBin{

void create();
int num;

public:
river();
river(const int);
void save(std:fstream&);
void load(std::ifstream&);
};

#endif

This game is a different concept and is still in progress. In my last
game I did create a handle in case I wanted different kinds of units:

#include<windows.h>
#include<fstream>

#include "unit.h"
#include "grboard.h"

#ifndef HUNIT_H
#define HUNIT_H

class hunit{

unit * p;
int * cnt;

void make(HWND, char, DWORD, int, int, bool);

public:
hunit() : cnt(new int(1)), p(new unit) {}
hunit(HWND, char, DWORD);
hunit(HWND, char, DWORD, int, int);
hunit(HWND, char, DWORD, int, int, bool);
hunit(const hunit& u) : cnt(u.cnt), p(u.p) {++*cnt;}
hunit& operator = (const hunit&);
~hunit();
DWORD sideColor(){return p->sideColor();}
int intAttack(){return p->intAttack();}
int intDefence(){return p->intDefence();}
float Attack(){return p->Attack();}
float Defence(){return p->Defence();}
int Moved(){return p->Moved();}

void display(HDC hdc){p->display(hdc);} //display at crrent loc
void display(HDC hdc,int n1, int n2){p->display(hdc,n1,n2);} //
display at specific loc
void display(HDC hdc ,int n1){p->display(hdc,n1);} //display with
offset for stacking
void displayBig(HDC hdc, int n1, int n2){p->displayBig(hdc,n1,n2);}
void change(HWND hwnd){p->change(hwnd);}
void update(HWND h, coord c){p->update(h,c);}

coord nextCoord(char c){return p->nextCoord(c);}
void mover(coord& c, int n){p->mover(c,n);}
void reset(){p->reset();}
void tomark(){p->tomark();} //marks unit for death;
bool marked(){return p->marked();}
coord getCoord(){return p->getCoord();}
coord getCurrent(){return p->getCoord();}
bool canMove(){return p->canMove();}
bool isSelect(){return p->isSelect();}
bool inRange(coord c){return p->inRange(c);}
void selectOn(){p->selectOn();}
void selectOff(){p->selectOff();}
void isArt(){p->isArt();}
void cBoxOn(){p->cBoxOn();}
void disbersed(){p->disbersed();}
void unDisberse(){p->unDisberse();}
void save(ofstream& f){p->write(f);} //saves the units

};

void hunit::make(HWND hwnd, char n, DWORD c, int x, int y, bool dis){

extern grFactory gf;

switch(n){

case 'i': //creates infantry
p = new unit(hwnd, &gf.make(0),c,4,4,6,y,x,dis);
break;
case 't': //creates tanks
p = new unit(hwnd, &gf.make(1),c,6,3,12,y,x,dis);
break;
case 'm': //creates mech infantry
p = new unit(hwnd, &gf.make(2),c,4,6,12,y,x,dis);
break;
case 'a': //creates artillery
p = new unit(hwnd, &gf.make(3),c,8,1,4,y,x,dis);
p->isArt();
break;
case 'f':
//p = new air;
break;
case 's':
//p = new sea;
break;
}
p->addk(n);
}

 

[JoeC]

Here is a unit from a completed game I created. The header file at
least to give an idea of one of my larger objects.

One little thing (not related to your question): Put your header include
guards
'around' everything in your header.
[ On small projects, it makes little difference. On big projects, it will
parse faster
(thus, compile faster). ]

#ifndef UNIT_H // put these here.
#define UNIT_H
// now the compiler does not have to check the include guards
// in *each* of the following headers every time (only the first use).

#include<fstream>
#include<vector>
#include<cmath>
#include<map>
#include"coord.h"
#include"color.h"
#include"graphics.h"
#include"tbox.h"

// > #ifndef UNIT_H // move to top of file
// > #define UNIT_H

class unit{ protected: // .....
public: // .....
}; // class unit
#endif

Thanks. I will try to do that, good point, the little tips are really
useful.

 

[JoeC]

techniques. I tend to create large objects that do lots of things. A
good example I have is a unit object. The object controls and holds
everything a unit in my game is supposed to do. What are some some
cures for this kind of large object or are they OK because they
represent one thing. If not what are better ways to design objects
that behave the same way. Would it be better to use inheritance or
friends and where can I look to be able to do the same thing in a
better way?

Here is a unit from a completed game I created. The header file at
least to give an idea of one of my larger objects.

[snip huge class]

You're using the class more like a namespace here. Objects should be
cohesive, which is a word that takes a look of thinking about to
really understand. A simple definition is that they should do only one
thing and do that one thing well. The smaller the scope of the one
thing they do the better.

Look athttp://c2.com/cgi/wiki?ClassicOoAntiPatternsand especiallyhttp://c2.com/cgi/wiki?ClassesWithoutOo

K

This is what I am asking. I use namespace std other than that I have
little experience or information on creating or using one. Most of
the stuff in my unit objects affect other thing in that object. I can
understand the graphics part and it has graphics and it would be good
to create a movable object and derive that into my class. I came up
with this after the game was done when I went back and tried to learn
lessons from my project.

 

[=?iso-8859-1?q?Kirit_S=E6lensminde?=]

[snip huge class]

You're using the class more like a namespace here. Objects should be
cohesive, which is a word that takes a look of thinking about to
really understand. A simple definition is that they should do only one
thing and do that one thing well. The smaller the scope of the one
thing they do the better.

Look athttp://c2.com/cgi/wiki?ClassicOoAntiPatternsandespeciallyhttp://c2.com/cgi/wiki?ClassesWithoutOo

K

This is what I am asking. I use namespace std other than that I have
little experience or information on creating or using one. Most of
the stuff in my unit objects affect other thing in that object. I can
understand the graphics part and it has graphics and it would be good
to create a movable object and derive that into my class. I came up
with this after the game was done when I went back and tried to learn
lessons from my project.

As an exercise see how small you can make your class by putting things
into helper classes. Look for things that are logically grouped. It'll
take you a while to work through the dependencies to get them right,
but your aim is to try to reduce your main class into the absolute
minimum that you can.

When you do it you should try to arrange the classes such that the
members of the unit class don't need to know that unit exists. I.e.
that every class you use as an attribute doesn't know anything about
the class that uses it. This is an ideal and isn't always possible,
but think very carefully before breaking it -- never do it until
you've exhausted every other possibility.


K

 

[Krice]

What are some some
cures for this kind of large object or are they OK because they
represent one thing.

They are perfectly ok, but if there are actions that could be
moved to a separate class (and used elsewhere) then do so.
Your class wasn't even that large. Some of the classes in
my game project are about three times bigger.

 

[JoeC]

On Apr 20, 11:40 pm, Kirit Sælensminde <[email protected]>
wrote:

techniques. I tend to create large objects that do lots of things. A
good example I have is a unit object. The object controls and holds
everything a unit in my game is supposed to do. What are some some
cures for this kind of large object or are they OK because they
represent one thing. If not what are better ways to design objects
that behave the same way. Would it be better to use inheritance or
friends and where can I look to be able to do the same thing in a
better way?
Here is a unit from a completed game I created. The header file at
least to give an idea of one of my larger objects.
[snip huge class]
You're using the class more like a namespace here. Objects should be
cohesive, which is a word that takes a look of thinking about to
really understand. A simple definition is that they should do only one
thing and do that one thing well. The smaller the scope of the one
thing they do the better.
Look athttp://c2.com/cgi/wiki?ClassicOoAntiPatternsandespeciallyhttp://c2.co...
K

This is what I am asking. I use namespace std other than that I have
little experience or information on creating or using one. Most of
the stuff in my unit objects affect other thing in that object. I can
understand the graphics part and it has graphics and it would be good
to create a movable object and derive that into my class. I came up
with this after the game was done when I went back and tried to learn
lessons from my project.

As an exercise see how small you can make your class by putting things
into helper classes. Look for things that are logically grouped. It'll
take you a while to work through the dependencies to get them right,
but your aim is to try to reduce your main class into the absolute
minimum that you can.

When you do it you should try to arrange the classes such that the
members of the unit class don't need to know that unit exists. I.e.
that every class you use as an attribute doesn't know anything about
the class that uses it. This is an ideal and isn't always possible,
but think very carefully before breaking it -- never do it until
you've exhausted every other possibility.

K

I have looked into java a bit and everything is an object there.

For this object the best I can do is seperate out the movment into a
movable class. It seems like every variable should be an object.
Object, set and get. It just seems like a great deal of unnecessary
overhead. I know it is a simple question but what is the rational for
such small classes? Most of the class are these facors:

float attack;
float dattack;
float defence;
int move;
int moved;
int dmove;
int range;
bool canmove;
bool selected;
bool mark;
bool disburse;
int col;

These are the numbers that control the unit.

std::map<char, coord> keys; //movement engine
coord n; //directions
coord s;
coord e;
coord w;
char kind;

This should have been separated out and I will make that a separate
class in my next project.

These are my graphics and helper classes.

HWND hwnd;
coord loc;
coord currentLoc;
graphics * gr;
tbox * combatBox;
std::vector<color>colors;

Too bad I can't post a picture here what it all looks like but here is
a link:
http://planetsourcecode.com/Upload_PSC/ScreenShots/PIC20061121202309521.JPG

 

[JoeC]

They are perfectly ok, but if there are actions that could be
moved to a separate class (and used elsewhere) then do so.
Your class wasn't even that large. Some of the classes in
my game project are about three times bigger.

That is good perspective. I only know about programming what I read
in books. I don't have much contact with other programmers and my
programs don't really get seen by anyone although I look for places to
post them. I try to ask good questions and find ways to improve what
I am doing.

 

[BobR]

[snip]

Good advice. I am trying to take what I read and create my own
projects. I like the ask questions on what I have done so see if I am
implementing concepts correctly. Here is my next generation of
graphics objects it is much more divided:

// again, put the guards around all:
#ifndef GRBIN_H
#define GRBIN_H

#include<windows.h>
#include<vector>
#include "graphics.h"
#include "color.h"
#include "coord.h"

// > #ifndef GRBIN_H
// > #define GRBIN_H

class grBin{ protected:
graphics * gr;
std::vector<color>colors;
coord loc;
public:
~grBin(){delete gr;}
void display(HWND, const int, const int);
void displayClear(HWND, const int, const int);
void displayBig(HWND, const int, const int);
int getX(){return loc.x;}
int getY(){return loc.y;}
};

This game is a different concept and is still in progress. In my last
game I did create a handle in case I wanted different kinds of units:

#ifndef HUNIT_H
#define HUNIT_H

#include<windows.h>
#include<fstream>
#include "unit.h"
#include "grboard.h"

// > #ifndef HUNIT_H
// > #define HUNIT_H

class hunit{
unit * p;
int * cnt;
void make(HWND, char, DWORD, int, int, bool);
public:
hunit() : cnt(new int(1)), p(new unit) {}
hunit(HWND, char, DWORD);
hunit(HWND, char, DWORD, int, int);
hunit(HWND, char, DWORD, int, int, bool);

You may be able to reduce the number of constructors here by using
default values.

// hunit(HWND, char, DWORD);
// hunit(HWND, char, DWORD, int, int);
// following line not syntax correct (for posting)

hunit(HWND, char, DWORD, int I1 = 0, int I2 = 0, bool flag = false);

Then you can 'call' it with 3, 4, 5 or 6 parms. as needed. It's a
style/design thing. If you don't understand, experiment a little, then
decide.

IMHO, I'd also watch out for how/where you use 'HWND' and 'DWORD'. If you
ever go to a GNU/Linux box, you will get a great headache changing all
instances of those. (you do know about wxWidgets, don't you?). 'DWORD'
sounds to me like a define/typedef of 'long' (32bit+ type), so, maybe use
that if you can. Just something to think about, the choice is always yours.

 

[=?iso-8859-1?q?Kirit_S=E6lensminde?=]

On Apr 20, 11:40 pm, Kirit Sælensminde <[email protected]>
wrote:
techniques. I tend to create large objects that do lots of things. A
good example I have is a unit object. The object controls and holds
everything a unit in my game is supposed to do. What are some some
cures for this kind of large object or are they OK because they
represent one thing. If not what are better ways to design objects
that behave the same way. Would it be better to use inheritance or
friends and where can I look to be able to do the same thing in a
better way?
Here is a unit from a completed game I created. The header file at
least to give an idea of one of my larger objects.
[snip huge class]
You're using the class more like a namespace here. Objects should be
cohesive, which is a word that takes a look of thinking about to
really understand. A simple definition is that they should do only one
thing and do that one thing well. The smaller the scope of the one
thing they do the better.
Look athttp://c2.com/cgi/wiki?ClassicOoAntiPatternsandespeciallyhttp://c2.co...
K
This is what I am asking. I use namespace std other than that I have
little experience or information on creating or using one. Most of
the stuff in my unit objects affect other thing in that object. I can
understand the graphics part and it has graphics and it would be good
to create a movable object and derive that into my class. I came up
with this after the game was done when I went back and tried to learn
lessons from my project.

As an exercise see how small you can make your class by putting things
into helper classes. Look for things that are logically grouped. It'll
take you a while to work through the dependencies to get them right,
but your aim is to try to reduce your main class into the absolute
minimum that you can.

When you do it you should try to arrange the classes such that the
members of the unit class don't need to know that unit exists. I.e.
that every class you use as an attribute doesn't know anything about
the class that uses it. This is an ideal and isn't always possible,
but think very carefully before breaking it -- never do it until
you've exhausted every other possibility.

K

I have looked into java a bit and everything is an object there.

For this object the best I can do is seperate out the movment into a
movable class. It seems like every variable should be an object.
Object, set and get. It just seems like a great deal of unnecessary
overhead. I know it is a simple question but what is the rational for
such small classes? Most of the class are these facors:

I know what you mean about it seeming to be a lot of work. The flip
side is that collapsing the small classes into the larger class is in
effect an optimisation and we all know that premature optimisation is
evil This is why you get away with it on small projects, but on
larger projects it will start to cause problems. Eventually it can get
so bad that it is effectively impossible to continue to maintain the
software.

Take a read of a couple of my papers on encapsulation and accessors.

http://www.kirit.com/On following rules/Encapsulation is a Good Thing™

This first one describes why encapsulation came about and then
describes what sorts of attributes should get read and write
accessors.

http://www.kirit.com/C++ killed the get & set accessors

The second shows a simple template technique that can be used to write
accessors with virtually no typing overhead. By keeping the syntax in
a certain form they can be replaced with more complex accessors later
on without having to edit all the code that uses the class.

For the attributes that you listed I'm not really sure what they're
meant to do as the names aren't always that illuminating (for example
"move", "moved", "dmove"), so I'll give another example that may be
relevant.

Let's assume we split off a small class for storing the location of
the unit which has x() and y() members. So if we have an instance
"unit" we can do this:

unit.position().x();
unit.position().y();

Let's then assume that you write some A* path finding so that the unit
can come up with a plan for how it will move over the next few
minutes. It can store this in a list now:

Attribute< std::list< Location > > plan;

*unit.plan().begin(); // The next waypoint the unit is moving towards.

By simply splitting this little class out you've gained the ability to
handle a bit of forward planning for your units. If you'd kept the x/y
co-ordinates within the unit directly then this extra bit would never
have occurred to you. You could still manage the same thing, but it
would have been much more messy.

To update the location you could have this:

unit.position().x( unit.position().x() + 1 );
unit.position().y( unit.position().y() + 1 );

This is what you'd do if you didn't have the Location class, but with
it you can do something a bit neater. What if Location contained a
moveTowards() member?

unit.position().moveTowards( *unit.plan().begin(), unit.speed() );

Now you've tied together the position, the speed and the plan in a
fairly neat way. You also get the benefit that the movement
calculations are in one place (moveTowards).

These benefits may not be obvious to start with, but if you try
working in this way you'll see that what you're doing is keeping a lid
on the complexity. It means that you can tackle something much larger
and much more complex because everything is managed into smaller
chunks.


K