Re: When can one use "bare" procedural code?
mike3 <mike4ty4@yahoo.com> wrote:
On Apr 1, 2:19?pm, "Daniel T." <danie...@earthlink.net> wrote:
mike3 <mike4...@yahoo.com> wrote:
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?
If you were to list all your moveFunc values in an enum, what would you
call the enum? What would the individual values be?
When you have code like:
enum Foo { A, B, C };
There's a good chance you can do:
class Foo { };
class A : public Foo { };
class B : public Foo { };
class C : public Foo { };
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.
The question is, would you even need to pass in "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; }
};
I was thinking of something like that, with an additional routine to
trigger (use) the trap.
That sounds like a good idea.
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)?
I suggest you try it and see what happens. You don't have to actually
remove the getters of course, you could simply resist using them.
A good paper to read along these lines is "Assuring Good Style for
Object-Oriented Programs" by Karl Lieberherr and Ian Holland.
<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.50.3681&rep=rep
1&type=pdf>
An excellent book to get is, "Object-Oriented Design Heuristics" by
Arthur J Riel. If your library doesn't carry it, ask at the reference
desk if you can get it through an inter-library loan.