Re: Question about large objects
On Apr 20, 12:37 pm, Puppet_Sock <puppet_s...@hotmail.com> wrote:
On Apr 20, 11:53 am, JoeC <enki...@yahoo.com> 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?
[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::ofstream&);
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);
}