Re: Pattern question - MyClassStore?

On Tuesday, May 25, 2004, 11:06:19 PM, Tim wrote:

> Hi all,
> I am writing an application whose main purpose is data storage (it's a
> computerised log book). It stores its data as yaml.

That pertains to disk, not to memory, I presume?  (I.e. when the
program is running, it deals with normal objects.)

> I need some way of keeping a collection of objects that are
> "sanctioned" (in the log book) so I can search them, calculate
> statistics on them, write them to disk and so on.

OK, so you have an array (or some other collection) of "sanctioned"
objects (whatever that means).

Since I don't know what it means, it could be that you have a (larger)
collection of objects, some for some of which the 'sanctioned?' method
responds 'true'.

In any case, if you regularly access the sanctioned objects, you want
a collection that contains them and only them, even if that's not the
only collection you have.

> I've done some hunting around for a pattern which fits this, and I
> can't see one that fits my problem (which would seem to be a fairly
> common one).

The "problem" being (from all I can gather) that you want to perform
some operations on a collection of objects?

> I don't want to just search ObjectSpace, because that would turn up
> half-formed not-yet-"sanctioned" objects.

Searching ObjectSpace for this kind of thing is the wrong answer no
matter how you look at it.  It may give you the right answer, but it's
not actually attacking the problem.

> Can anyone suggest one or more possible ways I might approach such a
> problem? The obvious way seems to be to create an XyzStore class
> (probably inheriting from a builtin data structure) which carries
> extra methods to do whatever aggregate calculations I want, but I do
> wonder if there's a better solution that I am missing, not being
> terribly versed in programming patterns.

If your objects are of class Xyz, then having a class XyzStore seems
like the right way to go. [1]  I wouldn't inherit from a builtin data
structure, but others would. [2]  This is great when there are some
operations you want to apply to a single Xyz, and some operations that
make sense only on the whole collection.

For instance, a number of years ago I wrote a Space Invaders clone in
C++.  Here is a Rubyized selection of classes and methods (embellished
from memory).

  class Baddie
    def move(speed)
    def position
    def on_collision
  end

  class BlueBaddie < Baddie  # and Red and Green

  class BaddieGroup
    def initialize(level)
    def num_alive
    def position  # top left corner of the group
    def speed
  end

Hope this helps (and would like more detail if it doesn't),
Gavin

[1] I'd commonly call it XyzManager.
[2] For example, Hash is a generic data type that is applicable to a
    plethora of problems.  A subclass should maintain that spirit, not
    shoehorn it into a domain type.  Proper subclasses of Hash include
    OrderedHash, BoundedLruHash, SuperHash, etc.  Improper subclasses
    of Hash include DiaryEntries, OxfordDictionary, and XyzStore.
    That's my opinion only.