Inconsistency in Constructors in ProjectTracker?

david.wendelken posted on Friday, July 07, 2006

The constructors that create a new ProjectInfo and ResourceInfo have radically different parameter lists.

ProjectInfo lists each parameter as a separate, strongly typed parameter.

ResourceInfo just accepts a SafeDataReader and parses things out inside the constructor.

Why the difference?

Is it just:

• Um.  Never noticed I was inconsistent.  :)  (No one else has ever done that... :)
• The Guid in ProjectInfo makes me want to (have to?) do it differently.  (And then why?)
• Just to show it doesn't matter which way you want to do it. (and then which do you prefer, and why?)

Thanks!

PS.  I just put a junior programmer on the task of cranking out basic <thing>Info and <thing>InfoList classes.  She's bopping right thru them with a 10 minute or less intro to each sample class we're using as a base, and a 10 minute or less walk-thru when she gets the first of each type done.  Productivity is sweet! 

 

 

ajj3085 replied on Friday, July 07, 2006

I believe the difference is just to show you can use either method, because its internal to the business layer, and thus doesn't matter as much.

david.wendelken replied on Saturday, July 08, 2006

ajj3085:

I believe the difference is just to show you can use either method, because its internal to the business layer, and thus doesn't matter as much.

Which way do you prefer, and why?

I'm leaning towards the constructor with specific parameters.  If I have to parse out the fields anyway, might as well make it easier for other classes to create it from their own source data.

RockfordLhotka replied on Sunday, July 09, 2006

It is to show multiple approaches.

Also, it is due to reviewer feedback during the writing process. I originally went with one approach (which was to do more work in the constructor, and not have a private Fetch() method for instance), but then my region scheme was confusing (because the constructor, which was doing the "fetch" was in the factory region, not the data access region).

The result was a flurry of emails between myself and the reviewers. The code in the book, then, shows the "wordy" way of doing it - where each region has proper code for the region, and the constructor calls a private Fetch(). There's no doubt in my mind that this is the most clear and "proper" way of doing it (though it took some convincing to get me there ). However, I thought it worthwhile to show other approaches too - at least in the code.

But the real point has already been made - it doesn't matter a lot because this is all hidden within the business layer. As long as you pick an approach and are consistent with it I really don't think it matters a lot.

Personally, I've been sticking with the factory->constructor->Fetch() approach.