General talk about software patterns

["Jim Scott" <jscott AT infoconex.com>]

I wanted to introduce myself a little bit before I asked questions so you 
can get a feel for my background and what I am after.

My name is Jim Scott and I have been writing software for about 3 years 
using C# and most of my work has been ASP.NET related. I have been self 
taught for the most part and over the years have refined my development 
skills. While on a recent vacation I decided to read a book "Design Patterns 
Explained - A New Perspective on Object Oriented Design" by Alan Shalloway 
and James Trott.

I read the book from cover to cover and I can say that this is the very 
first technical book I have read entirely. While I have been using OO for 3 
years the way in which I used it was not really OO by design. I now see more 
clearly how some of the design patterns are used and that my work to date if 
it matches any of them is by pure accident ;-)

I have been struggling since I read this book to relate the patterns to work 
I have been doing and see how maybe I could have benefited by this knowledge 
previously. So I figured I would search out some forums to start asking 
questions.

Question 1 :  Lightweight objects - In ASP.NET it is common to store objects 
in Session for retrieval during a web session. An example is that when a 
customer logs into the website we might create a customer object and load it 
after authentication with the customers information. Our customer class is 
very large as it has every method you need to modify or perform actions 
based on the customer. What I would like to do is keep the customer object 
very small  so it only really represents the properties of the customer and 
have all the methods live some place else. Is there a pattern that I might 
look at that matches this description?

An example of a how I have modified a recent project to follow this approach 
is something like this.

Create my customer object as only properties and method signatures. I create 
a second class called CustomerManager that gets called by the customer 
object to perform all the work. So in my Customer object I might have a 
method like Customer.Save() which internally calls 
CustomerManager.Save(this) . My idea here is to limit the amount of code 
that resides in the customer object so that when it is stored in session it 
is small.


Question 2 : Inheritance - After reading the design book I see a common 
approach to using the Factory methods for creating objects. I like the 
concept but I am struggling to see how I would personally implement this in 
a current situation. Currently we have a Customer class that we use as a 
base class and this is not currently an abstract class or an interface. We 
also have a class called ParentAccount that inherits from Customer. A 
ParentAccount has all the same properties as a Customer but has additional 
methods that a customer would not have. AN example is that a ParentAccount 
has a InventoryPool. This is not something in common with a customer class.

So today we might do something like this.

Customer customer = new Customer();
customer.Load(customerId);

// perform various customer related actions.

Then at some point we may be on a page that is parentaccount related. We do 
some simple validation to make sure that the customer is really a 
parentaccount. The customer object has a property called CustomerType that 
we check.

SO assuming we have a customer object that can be represented as a 
parentaccount we would cast it to a parenaccount   ParenAccount 
parentAccount = (ParenAccount)customer;

I now realize that what we could have done before would have been to create 
a factory that returns customer objects. The factory method would then 
decide what type of object to return. If just a customer customer = new 
Customer() otherwise if parent customer = new ParentAccount()

We do this manually now and I can see that if we are dealing with the 
customer object we should not have to really know or care at that point if 
it is a parentAccount or customer.

However what I don't see is how to apply the special rules. In my 
parentAccount object I mentioned I have some unique methods that are only 
available if you have a parentaccount object.

So I do this

ParentAccount parentAccount = (ParentAccount)customer;
DataTable inventoryPool = parentAccount.InventoryPool();


So I see now using a factory removes me from having to worry about which 
type of object my customer object represents and can take advantage of 
polymorphism but I don't see how I can avoid at some point instantiating the 
actual concrete object directly to get to my methods available only as a 
parentaccount. My assumption is there is a different way of designing this?

Thanks in advance.

Jim Scott