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

[Krice]

On 20 huhti, 18:53, JoeC <enki...@yahoo. comwrote:

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 23, 10:48 pm, Kirit Sælensminde <kirit.saelensm [e-mail]>
wrote:

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.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, coordkeys; //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<col or>colors;

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

[JoeC]

On Apr 24, 2:11 am, Krice <pau...@mbnet.f iwrote:

On 20 huhti, 18:53, JoeC <enki...@yahoo. comwrote:

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.

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]

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

[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<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;}
};

>
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<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);

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.

--
Bob R
POVrookie

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

On Apr 24, 11:16 pm, JoeC <enki...@yahoo. comwrote:

On Apr 23, 10:48 pm, Kirit Sælensminde <kirit.saelensm [e-mail]>
wrote:

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.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%20following%...Thing%E2%84%A2

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%2B%2B%20kille...et%20accessors

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().be gin(); // 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().be gin(), 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