Thursday, August 10, 2006

The Unusual Suspects

The Unusual Suspects


One of the key things that the reader should have taken away from the entry on abstraction was that the point of view that underlies abstraction is very important.  I wrote that entry because this entry is going to take a look at the problem that I've been playing with from a variety of different points of view.


We have already taken a brief look at the problem from the perspective of the client is using the Address class.  From its perspective, it sends and retrieves data in string format to the Address class.  From time to time it might send a request to save the Address data on a persistent data store.  And from time to time it may request that the Address validate the data that it currently contains and provide information about validation errors and validation rules.  All of this is fairly conventional and familiar.


The question is: are there other points of view that we could get some useful insights from?  As noted, we could look at this problem from the perspective of almost anything: for example, the third bit from the left in the fifth accumulation register of the CPU could have a perspective on this problem.  Not a useful perspective but still a perspective.  All design is about making choices from possibilities.  I've put together a list of what I think are reasonable possibilities.  Is quite possible I have left something useful off the list and is equally possible that something I've included on the list will turn out to be a waste of time.  My philosophy is to try to do the best job I can but do not obsess over getting it to a level of high perfection.  And now for the list:


  • The Address itself, taken as a whole.
  • The individual values within the entity.  By this, I mean the address lines, the city, the state, and the zip code, taken as individual items.
  • The individual rules that are applied to the individual values within the entity.
  • The container that holds and manages the individual rules.
  • The rules that apply to the entity as a whole.
  • The container that holds and manages the individual rules.

What I want to do is to examine the problem from these different points of view.  We are going to take a “behind the scenes” look at the players in our little drama.


Let's take our roving microphone over to interview the Address:


Well, my responsibility is sort of like being a den mother.  I have to keep all the individual values together.  I also have to keep track of all the rules that are applied to each of these individual values as well as the rules that apply to me as a whole.  Of course, being an experienced entity, I know that I need to delegate a lot of these responsibilities to other classes.  A lot of what I do is simply passing requests that I receive on to the appropriate object that is under my supervision.


Now I see that all of the individual values are assembled over there and are ready for questioning:


It might seem like there are a lot of us but that's just an illusion created by the use of modern digital object-oriented technology.  For example take String over there.  For this application he can hold the first name, last name, the address lines, even the city and state values.  And then there's “Numbers” (who are used to be just a plain String but now has the ability to restrict the contents of the string to numeric characters).  He is doing the two parts of the zip code.  While they are not part of this particular entity, we also have individual values that can hold floating-point numbers or dates or Boolean values and so on. 


Each of us can accept and return a string representation of the value that we hold and some of us can convert an incoming string value to our internal representation.  Of course, String has no need to do such a conversion.  Confidentially, he doesn't get the respect that the other individual values do, but he makes up for that by getting an awful lot of work.  Why I can't remember the last entity class that didn't need good old String.  We also have to hold error status information such as whether our contents are valid and what specifically is not valid.  We also hold the set of rules that apply to us.  Those change from entity and application to application.  It really depends a lot upon the specific entity that includes us and the application of that entity is supporting. 


The work is not glamorous but it is interesting; we do get to see a whole wide variety of values flowing through us (with the exception of Boolean over there who sees the same old true and false values, but again he tends to get a lot of work which can't be said for double and decimal).


We take our roving microphone over to interview one of the rules that apply to individual values:


I am the "string length" rule.  When the "rules manager" cues me to look at a particular individual value, I examine the contents of that value to see if the length of the string that contains is it least a minimum value and no more than the maximum value.  Since there are so many individual string values in Address, I get to play a lot of different roles.  The "script" for this particular entity called me to test each of the individual values to make sure that they are behaving properly.  This sounds more important than it really is. All that I really do is examine the individual value and mark its value as valid or invalid.  If it is invalid, I have to leave a message about why it's invalid.  That is, if I'm allowed to do my work.  Sometimes I am deactivated and simply have to stand around waiting for the right moment to do my work.  This has something to do with managing expectations for the various stages in which we perform.  But you know the old saying: “we also serve who stand and wait.”


There are some would say that the role of the individual rule players is so small as to be insignificant, but I regard this effort as a team effort.  I depend upon my fellow rules, "can't be null" and "can't be empty" to prevent me from making a fool of myself by raising a null reference exception.  I will not even examine a value unless those two rules have done their job and cleared the value for further rule tests.  Of course there are other rules that depend upon me just as I depend upon those two rules.  Together, we add a substantial amount of value to the application.


Now stepping up to our microphone is the rules manager:


I am sort of like an assistant den mother.  My job is to know what rules should be applied to each of the individual values (or in some cases to the entity as a whole) and in what order.  I don't actually do any of the validation, I just make sure that the rules for the individual values cooperate with each other to determine what the validity of individual values and of the Address as a whole are.  Sigh, it is one of those jobs where if I do my job perfectly nobody ever notices.  But it does give me the opportunity to be a part of show business.


The point of this, perhaps silly, exercise is to give us a number of different perspectives on the problem.  Each of our “players” above could be a separate class, each with their own set of responsibilities.  Rather than having multiple classes, each representing a different stage and exhibiting different behavior, we might be able to bring all of the behavior back into a single class (hierarchy) where we can dynamically turn off and turn on various validation behaviors in each stage.  I would explore this one in more detail in subsequent entries


Post a Comment

Links to this post:

Create a Link

<< Home