Prev: Q: the dreaded diamond...
Next: FINAL CfIP, Conference Reliable Software Technologies, Ada-Europe 2008
From: Patrick May on 6 Jan 2008 18:25
James Barrett <xucaen(a)comcast.net> writes:
> Patrick May wrote:
>> If that's the case, you might get some insight by focusing on the
>> behaviors of your system and introducing state-like attributes only
>> as and when required by the desired behavior.
>
> So in other words, modify the Creature class and/or existing State
> classes to add new behaviors?

No, I'm suggesting that you take a step back from the problem and
think in terms of use cases. What do you want the system to do? What
actors are involved? What triggers do those actors fire? What
response is expected?

Once you have a use case or two defined, start partitioning the
behavior among candidate classes. Don't force a particular data model
or set of design patterns on the solution. Write some unit tests to
clarify your thinking.

You may still have a need for State or other patterns, but you'll
know exactly why you're using them.

Regards,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
pjm(a)spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)
From: topmind on 6 Jan 2008 18:54
On Jan 5, 4:40 pm, r...(a)zedat.fu-berlin.de (Stefan Ram) wrote:
> James Barrett <xuc...(a)comcast.net> writes:
> >I am confused about how to handle multiple States that can be
> >active at the same time.
>
> A system might be in a single state at any instant of time.
>
> The set of all states of a system usually has more than
> one element, because otherwise the concept of state is useless.
>
> A state is like a value, so it usually is not said to
> be »active«. I take this »active« to mean that this
> is the state of its system at the current instance.
>
> There can never be multiple states at a single instance.
> Not even in quantum mechanics.
>
> But you can always rename your states to »substates« and
> investigate a new set of states that is the power set
> of the set of substate. Then, a state { s(0), s(1), ... s(n-1) }
> is a set of substates.
>
> >So then it would be Hunting while Poisoned.
>
> These seems to be fields of the object.
>
> For example, in »Java«
> <http://java.sun.com/docs/books/jls/third_edition/html/j3TOC.html>
> a creature can be specified as
>
> class Creature
> { private boolean isHunting;
> private boolean isRoaming;
> ... }
>
> I do not get the problem. Is something wrong with this
> simple approach?
>
> >The more I think about it, the more I am leaning towards a
> >linked-list style of pattern for my States (Decorator?)
>
> This only is necessary when the set of all possible states
> is to be altered at run time. Then you can't use the features
> of the language anymore to directly implemnt states as above.
>
> But you should try to keep things as simple as possible and
> refrain from run-time flexibility whenever a static approach
> is sufficient.
>
> >Calling State->Execute()
>
> Maybe I am just too ignorant about this topic. But a state
> AFAIK is not usually something one can execute. Possibly your
> states are executable. But then they are not plain states.
>
> I look up
>
> http://en.wikipedia.org/wiki/State_pattern
>
> for »xecute«, but do not find it mentioned there. So it
> also is not explained as part of the state pattern entry
> in Wikipedia.
>
> >Would that be the way to do it?
>
> You already have fixed the design decision to model
> a creature by a single object of a creature class.
>
> Now, start with:
>
> class Creature
> {}
>
> Then, write the main program:
>
> { Creature c = new Creature(); /* This already works! */
> /* .... */
> /* Creature can now do his next step */
> c.nextStep( world );
> /* ... */
>
> You now can observed that the creature needs to find and
> do his next step. So, you implement this:
>
> class Creature
> { public void nextStep( final World world ){ ... }}
>
> While you implement this, you might find that the
> creature needs to remember whether he is Roaming.
> So, you add a field:
>
> class Creature
> { public void nextStep( final World world ){ ... }
> private boolean isRoaming; }
>
> In the course of implementing more features, you
> will find that a creature might need more public
> methods. So you implement them.
>
> Each public method might need private methods or
> private fields, which therefore are added as needed.
>
> This is one approach to a field known as »object
> oriented design«.

(begin rant)

These kinds of questions are relatively trivial for us relational
fans. These kinds of issues make me thank Zeus that I'm not an OOP
nut.

(end rant)

A relational solution would generally take the form of:

table: character
-----------------------
charID
charName
isState_1 // actual name would be more natural
isState_2
isState_3
isState_etc.

Or:

table: states_of_character
--------------------
charRef // foreign key to Character table
stateRef // existence = on (state table not shown and may not be be
needed in smaller apps)

-T-
From: Martin Vuille on 6 Jan 2008 19:52
James Barrett <xucaen(a)comcast.net> wrote in
news:FMSdnfbwJ9nhyRzanZ2dnUVZ_q6mnZ2d(a)comcast.com:

> I think my biggest confusion is deciding what pattern or
> structure it is that controls behavior when there seem to be
> more than one State (property or attribute?) controlling that
> behavior. I keep reading that you can have only one State at
> a time, but that seem to be not true. So either there is more
> to State than what I have read, or my example is not one of
> State. Is Poisoned really a State? I can see that in the
> future there could be others like Hungry, Injured, Sad,
> Angry.. and possibly more. Are those really States or what
> are they?

I'm not sure that your problem is one that's appropriate to the
State pattern, but I want to respond to the "only one state at a
time" notion.

In the State pattern, the state variable can only refer to one
ConcreteState at any one time. So only one ConcreteState can be
active at any one time.

However, there is no reason why the Creature could not have
several state variables, with each one representing and
governing some aspect of the Creature's overall "state". For
example, it could have a "health" state, a "strength" state, a
"hunger" state, a "mood" state, etc.

Each "partial state" would be defined by its own set of
ConcreteStates. So the "health" state might have Healthy,
Injured, and Poisoned ConcreteStates, while the "hunger" state
might have Hungry and Sated ConcreteStates.

One concern is that you mentioned that the various aspects of
the Creature's state are not independent of each other.
Consequently, for each Creature behaviour you would have to call
a method on each of the relevant states and then come up with an
algorithm for combining the results into one behaviour.

So, for example, the outcome of a fight may well depend on the
"health" state as well as the "strength" state and the Creature
object might have a method to handle receiving a blow during a
fight. In the ReceiveBlow method, you would have to call some
method of the "health" state and some method of the "strength"
state and then somehow combine the results to decide what to do.

MV

--
I do not want replies; please follow-up to the group.
First  |  Prev  | 
Pages: 1 2
Prev: Q: the dreaded diamond...
Next: FINAL CfIP, Conference Reliable Software Technologies, Ada-Europe 2008