Re: When can one use "bare" procedural code?
On Apr 1, 2:19 pm, "Daniel T." <danie...@earthlink.net> wrote:
mike3 <mike4...@yahoo.com> wrote:
<sip>
So your plan is to have a few switch statements that all use "moveFunc"
to decide what to do. This begs for inheritance (if "moveFunc" never
changes once set,) or the strategy pattern (if "moveFunc" can change.)
Inheritance of what from what?
Also, you say that the value of moveFunc depends on what type of
creature is in the room, player or monster? Those should probably be
classes...
The _value_ does not depend, but which function is called does. And
not
"which type is in the room" but "which type moves over the tile". It
is
triggered on moving over the tile.
class MobileObject {
public:
virtual ~MobileObject() { }
virtual void handleMove(unsigned char moveFunc) = 0;
};
class Monster : public MobileObject {
public:
virtual void handleMove(unsigned char moveFunc);
};
class Player : public MobileObject {
public:
virtual void handleMove(unsigned char moveFunc);
};
So then when the object moves onto the tile, we pass
the tile's moveFunc value through the handleMove function?
Shouldn't that be done internally, inside whatever
function moves the mover from one tile to another?
Otherwise we could neglect that call.
<snip>
Presumably each trap type does something different? I suggest that you
go ahead and make a Trap class. Give it a setter, but no getter. So
something like this:
class Trap {
unsigned char trapType;
public:
Trap(unsigned char trapType): trapType(trapType) { }
void setTrapType(unsigned char v) { trapType = v; }
};
I was thinking of something like that, with an additional routine to
trigger (use) the trap.
When you find yourself wanting to use the value from outside the class,
don't. Instead make a function in the class that does the right thing.
The above is a good general rule to start with. Remove your getters and
that will tend to force you into a better object oriented design. (Don't
get too pedantic about this idea though, sometimes a getter is just what
you need.)
Maybe I should remove all the getters and only add ones back when
really
necessary (like, e.g. the buildaux field, which the level generator
uses
to store information while generating the level)?
<snip>
Any proposed function that modifies the state of a LevelTile should be a
member-function of the LevelTile class.
That's what I thought.