Re: When can one use "bare" procedural code?
mike3 <mike4ty4@yahoo.com> wrote:
On Apr 1, 9:04?pm, "Daniel T." <danie...@earthlink.net> wrote:
mike3 <mike4...@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?
Probably something like "MoveFunc".
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 { };
But the different MoveFunc are assigned on a per-tile basis. So the
above would implying having different types of tiles, i.e. a bunch of:
class LevelTile { ... }
class LevelTileWithSign1Move : public LevelTile { ... }
class LevelTileWithSign2Move : public LevelTile { ... }
...
Is it OK to throw all these into a vector of LevelTile (like the
LevelMap)? It would seem here you'd need to make LevelMap have a
vector of pointers, then. Is that a good idea?
And why should we stop at moveFunc? But then combinatorially, things
get really big.
First to address the combinatorial issue... Strategy pattern to the
rescue:
LevelTile {
MoveFunc* moveFunc; // MoveFunc is a pure virtual class
SomeOtherType* someOtherType; // SomeOtherType is also pure virtual
//...
};
Now you get however many MoveFunc sub-types times however many
SomeOtherType sub-types without having to sub class LevelTile at all.
The Decorator Pattern helps too.
In addition, if I want to save the map to disk (something I will want
to do!), we need to make sure the type of moveFunc needs to get saved
out, and then when we load in, we need to have a switch() somewhere to
switch between the different kinds of LevelTile and, see where this is
going?
The key here is that you will have at most one switch/if. That's why I
said at the beginning that if you have more than one switch/if
discriminating on the same variable, then inheritance is a better
solution. It's a way to avoid duplicated code.
The question is, would you even need to pass in "moveFunc"?
You listed it as a parameter going into handleMove in the
player and monster class. I wasn't clear on the intention
behind that. And now that you said that, I'm even less clear.
Once you write a few of the functions that use your moveFunc variable,
post them or email them to me and I'll show you what I mean.
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.
However, unused stuff seems like clutter, so why not just
cut it out?
The getters come in handy when it comes time to save the object in a
file.