Thursday, August 03, 2006

Fondling the Tools

In this entry I want to look at the various high-level approaches that we might take to solving this problem.  Once we have outlined the different approaches that we might take, I will take a look at each of these approaches in more detail in later entries.

Before we start though I want to reiterate a couple of definitions:  a “tight” class is one that probably comes closest to what most of us think of as a classic domain object; the properties of the class are strongly typed and the class is very careful to not allow invalid data; a “loose” class is one that has very little if any validation and will accept (within reason) virtually anything that the user could enter on a webpage or Windows form.  And now on with the approaches:

  • Container approaches: In this approach I take it as a given that we’re going to have two or more classes,  ranging along some continuum of

    finickiness from the very “loose” to very “tight”.  Because we don’t want to have multiple classes visible to the external world, we pick one class to be the external representative and encapsulate the other classes within that externally visible class.  There are three or four ways that this can be done and we’ll talk about those in a later entry.

  • Converter approaches: In this approach we have multiple, parallel objects and at the appropriate times we convert the contents of one of these objects to produce an instance of one of the other objects.  The most likely conversion would be to take an instance of a “looser” class and convert it (or least attempt to convert it) to an instance of a “tighter” class.  In order to preserve the illusion that we’re dealing with a single object, we would probably define a common interface that each of these objects would implement.  Client software would deal with this interface and, if we were clever enough to perform the conversion without disturbing the client, the client might think that he was dealing with a single object that could exhibit different behaviors depending upon what stage the data was in.  This would probably require us to use some form of proxy class that would serve as a layer of indirection.  Again, there is lots of material for subsequent entries.

  • Integrated approaches: In this approach, we would create a single class that was capable of supporting all of the different degrees of “looseness” and “tightness”.  The approach that I have used in the past involves creating a separate class to represent each of the properties.  These property classes provide a number of different looks at contents of an individual property.  This approach is more complex than the other approaches but I think brings a lot of flexibility to the party.  Again, this is something that will look at in more detail in later entries.

A personal note, the problem with being two time zones away from where I normally live in is my body body is ready for bed long before the clock showing local time is ready for bed.  I tend to stay on my home time zone which gets me up very early in the morning and sends me off to bed early as well.  I’ll do some more on this tomorrow morning.


Post a Comment

Links to this post:

Create a Link

<< Home