Self populating collection

6 Jun 2005 11:10 AM

bblac

Hi

Has anyone encountered the following situation (I cant believe I am the
first.)

As part of a system I am designing I require a collection class that
populates itself.

So far I have a design along the following lines.

public interface IFactory
{
IItem NewItem();
IItem[] NewItem(int count);
}

public interface IItem
{
void Load(OLEDBCommand Command); Implementers load internal values by
executing command
void Load(OLEDBDataReader DataReader);Implementers load internal values by
reading current record.
}

public interface ISelfLoadingCollection
{
void Load(OLEDBCommand command , IFactory factory, bool loadAll);
}

public class SomeItemClass :IItem
{
.... Implementation of IItem and other class specific stuff. (You get the
general idea)
}

public class SomeItemClassFactory:IFactory
{
....Implementation of the IFactory stuff.
IItem NewItem()
{
   return new SomeItem();
}
}

public class SelfPopulatingCollection : DictionaryBase, ISelfLoadingCollection
{
.... Implements self loading collection stuff and exposes strongly typed
dictionary of IItem's

void Load(OLEDBCommand command , IFactory factory, bool loadAll);
   {
      Code here calls ExecuteReader on command, loops through rows
      calls newitem on the factory and passes the DataReader to the new IItem.
      The new IItem is then added to the dictionary.
   }
}

In the app I intend to create a new instance of the
SelfPopulatingCollection, call the Load passing in the correct factory and
command and watch it do its work.

Why ? well I only want to write my collection management code the once and
have all collections load the same way across my system (there are other
reasons.)

I am sort of happy with the design but it doesnâ€™t feel entirely natural. The
factory part seems inelegant (maybe the whole design is.) So I thought maybe
someone had a better pattern for this. Who knows? rip it/me to shreds then
ladies and gents.

Regards

Ben.

6 Jun 2005 2:23 PM

Cowboy (Gregory A. Beamer) - MVP

If it feels unnatural, you are probably over-engineering the solution.

From OO Class Design 101 ---

1. We have the following basic pieces of design:

Properties - hold state
Methods - model behavior
Constructors - Initialize state

This is an over simplification, as it does not cover class (static/Shared)
versus instance items (as well as events), but it is effective.

2. There are two basic types of common classes: those that perform work and
those that hold state.

Once again, over simplified, as there are plenty of cases for hybrid
classes. But, in most business systems, your classes are either performing
work (part of the process) or hold state (objects being processed).

----
If the above holds true, a self-populating object (or collection of objects)
is most likely implemented something like this:

public class MyClass
{
    public MyClass()
    {
       //Initialize state here
    }
}

In general, you will see little behavior in this type of object/collection,
as it is used to hold state rather than perform work. So, which is the better
solution:

1. Create an Init method that uses you DAL to fill the collection.
Optionally, expose the same init method to refill a collection rather than
instantiate a new one.
2. Create an abstract factory that fills collections and then a concrete
factory to fill the particular collection.

If you said #2, you are probably getting a bit pattern happy.

Don't get me wrong. I love patterns and think every OO developer should
learn them, but patterns often blind us to simpler solutions. I would prefer
the simplest approach necessary and then refactor to patterns where it makes
sense. In the case above, heading towards the pattern first does not make as
much sense, although I am certain there are implementations that need the
factory.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

Show quoteHide quote

"bblac" wrote:

> Hi
>
> Has anyone encountered the following situation (I cant believe I am the
> first.)
>
> As part of a system I am designing I require a collection class that
> populates itself.
>
> So far I have a design along the following lines.
>
> public interface IFactory
> {
> IItem NewItem();
> IItem[] NewItem(int count);
> }
>
> public interface IItem
> {
> void Load(OLEDBCommand Command); Implementers load internal values by
> executing command
> void Load(OLEDBDataReader DataReader);Implementers load internal values by
> reading current record.
> }
>
> public interface ISelfLoadingCollection
> {
> void Load(OLEDBCommand command , IFactory factory, bool loadAll);
> }
>
> public class SomeItemClass :IItem
> {
> ... Implementation of IItem and other class specific stuff. (You get the
> general idea)
> }
>
> public class SomeItemClassFactory:IFactory
> {
> ...Implementation of the IFactory stuff.
> IItem NewItem()
>   {
>    return new SomeItem();
>   }
> }
>
> public class SelfPopulatingCollection : DictionaryBase, ISelfLoadingCollection
> {
> ... Implements self loading collection stuff and exposes strongly typed
> dictionary of IItem's
>
> void Load(OLEDBCommand command , IFactory factory, bool loadAll);
>    {
>       Code here calls ExecuteReader on command, loops through rows
>       calls newitem on the factory and passes the DataReader to the new IItem.
>       The new IItem is then added to the dictionary.
>    }
> }
>
> In the app I intend to create a new instance of the
> SelfPopulatingCollection, call the Load passing in the correct factory and
> command and watch it do its work.
>
> Why ? well I only want to write my collection management code the once and
> have all collections load the same way across my system (there are other
> reasons.)
>
> I am sort of happy with the design but it doesnâ€™t feel entirely natural. The
> factory part seems inelegant (maybe the whole design is.) So I thought maybe
> someone had a better pattern for this. Who knows? rip it/me to shreds then
> ladies and gents.
>
> Regards
>
> Ben.
>