Re: Comparing old and new state data in an object?
From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 11/07/03
- Next message: Hoff, Todd: "Re: OOP - a question about database access"
- Previous message: H. S. Lahman: "Re: XP, a Criticism"
- In reply to: Ken: "Comparing old and new state data in an object?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 07 Nov 2003 19:34:58 GMT
Responding to Ken...
> I have an object whose state data can change several times in my
> application. After a certain amount of processing, and potentially a
> certain amount of changing, I need to compare the current state with
> the object's original state. If it is different, I do something. In
> fact, I need to check each attribute of the object, since each
> attribute is assocaited with discreet processing resulting from the
> change. Note that each attribute could change--but then change back
> to the original value, in which case I do nothing. So getting
> triggered by the change is not an option. I actually have to do the
> compare after a particular event occurs.
>
> Any suggestions as to how to keep track of the original state data for
> later comparison? Any patterns out there for doing this?
At the moment you make the check the object in hand (i.e., the critter
with a unique identity) has only one state, the values of its state
variables (attributes) at that moment. What you are comparing those
values to is a snapshot of the object's state variables at some moment
in the past. The snapshot is conceptually a different problem space
entity. So you have:
1 *
[Object] ------------------- [HistorySnapshot]
[HistorySnapshot] may have the same state variables, but presumably it
won't have the same behaviors. [As a practical matter, it is unlikely
the data will be exactly the same. There will probably have to be some
way to identify [HistorySnapshot], such as a timestamp or a sequence
number.]
Bottom line: it is just a collection of dumb data holders. The
[HistorySnapshot] instances are created against whatever rules and
policies determine when you need snapshots (i.e., whatever defines your
"certain amount of processing"). As they are created the relationship
is instantiated by adding them to the collection. When it is time to
check, the collection is searched for the timestamp (or whatever defines
the snapshot) and the check is performed.
Moral 1: the GoF patterns are very useful but they are overkill when a
simple 1:* association will do.
Practical note: your description implies (to me) that all you care about
is whether a given attribute has changed and that there might only be
one "active" snapshot at a time. If so, then [HistorySnapshot] might be
better implemented with a single bitmap attribute in [Object] itself.
In that case the snapshot bitmap is nulled whenever the snapshot is
needed and the [Object]'s attribute setters set the appropriate bit in
the bitmap. When it is time to check, one just scans for set bits.
Moral 2: it all depends upon the problem context. B-)
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindersol.com
(888)-OOA-PATH
- Next message: Hoff, Todd: "Re: OOP - a question about database access"
- Previous message: H. S. Lahman: "Re: XP, a Criticism"
- In reply to: Ken: "Comparing old and new state data in an object?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
