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<fstrea m>
#include<vector >
#include<cmath>
#include<map>

#include"coord. h"
#include"color. h"
#include"graphi cs.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<col or>colors;
std::map<char, coordkeys; //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,graph ics*,int,int,in t);
unit(HWND,graph ics*,int,int,in t,int,int);
unit(HWND,graph ics*,DWORD,floa t, float, int, int, int);
unit(HWND,graph ics*,DWORD,floa t, float, int, int, int, bool);
unit(unit*);
~unit();

DWORD sideColor(){ret urn colors[0].getCode();}
int intAttack(){ret urn attack;}
int intDefence(){re turn defence;}
float Attack(){return attack;}
float Defence(){retur n 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(){retu rn loc;}
coord getCurrent(){re turn currentLoc;}
bool canMove(){retur n canmove;}
bool isSelect(){retu rn selected;}
bool inRange(coord);
void selectOn(){sele cted = true;}
void selectOff(){sel ected = false;}
void isArt(){range = 12;}
void cBoxOn(){combat Box = new tbox;};
void disbersed();
void unDisberse(){di sburse = false;}
void write(std::ofst ream&);
void load(std::ifstr eam&);
void addk(char k){kind = k;}
};

#endif

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

On 2007-04-20 17:53, JoeC wrote:

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.

--
Erik Wikström

[Puppet_Sock]

On Apr 20, 11:53 am, JoeC <enki...@yahoo. comwrote:

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]

JoeC <en*****@yahoo. comwrote in message ...

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<fstrea m>
#include<vector >
#include<cmath>
#include<map>
#include"coord. h"
#include"color. h"
#include"graphi cs.h"
#include"tbox.h "

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

>
class unit{ protected:

// .....

public:

// .....

}; // class unit
#endif

--
Bob R
POVrookie

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

On Apr 20, 10:53 pm, JoeC <enki...@yahoo. comwrote:

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]

On Apr 20, 11:24 am, Erik Wikström <Erik-wikst...@telia. comwrote:

On 2007-04-20 17:53, JoeC wrote:

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.

--
Erik Wikström

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]

On Apr 20, 12:37 pm, Puppet_Sock <puppet_s...@ho tmail.comwrote:

On Apr 20, 11:53 am, JoeC <enki...@yahoo. comwrote: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

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<window s.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<col or>colors;
coord loc;

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

};

#include<fstrea m>
#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::ofstr eam&);
void load(std::ifstr eam&);
};

#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<window s.h>
#include<fstrea m>

#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(){ret urn p->sideColor(); }
int intAttack(){ret urn p->intAttack(); }
int intDefence(){re turn p->intDefence() ;}
float Attack(){return p->Attack();}
float Defence(){retur n 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(){retu rn p->getCoord();}
coord getCurrent(){re turn p->getCoord();}
bool canMove(){retur n p->canMove();}
bool isSelect(){retu rn 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(HWN D 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]

On Apr 20, 4:04 pm, "BobR" <removeBadB...@ worldnet.att.ne twrote:

JoeC <enki...@yahoo. comwrote in message ...

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<fstrea m>
#include<vector >
#include<cmath>
#include<map>
#include"coord. h"
#include"color. h"
#include"graphi cs.h"
#include"tbox.h "

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

class unit{ protected:

// .....

public:

// .....

}; // class unit
#endif

--
Bob R
POVrookie

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

[JoeC]

On Apr 20, 11:40 pm, Kirit Sælensminde <kirit.saelensm [e-mail]>
wrote:

On Apr 20, 10:53 pm, JoeC <enki...@yahoo. comwrote:I have been writinggames 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 athttp://c2.com/cgi/wiki?ClassicOoA ntiPatternsand especiallyhttp://c2.com/cgi/wiki?ClassesWit houtOo

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?=]

On Apr 24, 9:10 am, JoeC <enki...@yahoo. comwrote:

On Apr 20, 11:40 pm, Kirit Sælensminde <kirit.saelensm [e-mail]>
wrote:

On Apr 20, 10:53 pm, JoeC <enki...@yahoo. comwrote: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 athttp://c2.com/cgi/wiki?ClassicOoA ntiPatternsande speciallyhttp://c2.com/cgi/wiki?ClassesWit houtOo

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