Re: When can one use "bare" procedural code?
mike3 <mike4ty4@yahoo.com> wrote:
On Mar 31, 2:26?pm, "Daniel T." <danie...@earthlink.net> wrote:
[see earlier messages for context]
It's likely a bad idea to turn LevelTile into a struct. With what
you have, at least you can move toward a better design. Let me see a
function or two that uses a LevelTile object.
OK, I'll leave it a class then. As for functions that use them,
currently it's just the level generator, where I've got two routines
that invoke one of the constructors with a set of default parameters
for making wall/ floor tiles. (room floor tiles, for various reasons,
have a flag TFL_ROOM set, thus this routine provides a way to wrap
that setting and others.)
I'm especially interested in the 'moveFunc' member variable, it
obviously isn't a function even though the comments describe it as
such...
That's because there are actually two functions, not one, that will be
involved. (one for the player, one for monsters.) This is a
not-yet-implemented feature. "moveFunc" holds a code (will likely be
from an enum, in which case I'll switch the type to that of the enum
-- I just don't have it as one yet since that feature is not yet
implemented) that will reference the function to be called. When
implemented, I'll likely add some member to LevelTile to do this.
Storing a function pointer would not work here -- for one, it's not as
easy to save that out to a file (you can't just save a pointer that
won't necessarily be the same on the next run, you'd have to compare,
and that sounds pretty dorky and bad.).
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.)
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...
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);
};
'trapType' should probably be a Trap class instead of a integer as
well. How is trapType being used?
Again, this is another to-be-added feature. It stores which type of
trap, if any, should be on the tile. When the player or a monster
moves onto the tile, this would activate. I suppose I could make a
small "Trap" class wrapping this field plus a pair of functions to
handle moves by player or monster. If not, it'll probably become
another enum too (like moveFunc).
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; }
};
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.)
I've heard this stuff about "don't use structs", etc. (which is
the only reason it's the way it is) but in this case I can't
really think of anything else this should be. Except there's going
to be routines at some point that open/close doors, handle trap
triggering, etc. and I'm not sure if those could/should go in
there or not.
Would they modify any of the states of a LevelTile? Have you written
any of these routines yet?
Yes and no, respectively.
Any proposed function that modifies the state of a LevelTile should be a
member-function of the LevelTile class.