General talk about software patterns

[Peter Horan <peter AT deakin.edu.au>]

Jim Scott wrote:

Welcome, Jim.

> 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?

This is an initial simple answer, which is a good place to start.

It helps to make a clear distinction between classes and objects as follows:
   Class (source code concept)      Object (run time concept)
   ===========================      =========================
declares data elements           has memory allocated for this
associations with other classes  holds memory addresses of objects
                                 of the other classes
defines routines in source code  holds memory addresses of compiled
                                 code

Note that many objects can reference the same compiled code, and the  
compiled code is shared and physically resides outside of the memory  
allocated to each object.

> My idea here is to limit the amount of code that resides in the  
> customer object

Code does not reside in each object. It is referenced by each object  
and shared.

> Question 2 : Inheritance

I think your question is in your last paragraph:

> 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?

If you want to run code belonging to an object which is specialised by  
inheritance, you must have a specialised "actual concrete" object. It  
must have been created somehow. In your example, you must have an  
object of the ParentAccount class to use the InventoryPool specialty.  
This is true even though you may frequently interact (polymorphically)  
with the object as an instance of the more general Customer class.

> So today we might do something like this.
>
> Customer customer = new Customer();
> customer.Load(customerId);

From your code above, the object is only an instance of the Customer class.

> So assuming we have a customer object that can be represented as a  
> parentaccount we would cast it to a parentaccount  ParentAccount  
> parentAccount = (ParentAccount)customer;

This casting would fail if it is only a Customer object. (Think of  
casting as putting on a different coat/interface, but the body/object  
it covers does not change). To succeed, it must already be a  
ParentAccount object.

> 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()

There is nothing magic about factories. Instead of creating the object  
directly, the client asks the factory to create an object with these  
or those predefined characteristics. The factory hides the details of  
the differences.

> 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.

Whether it is a Customer object or a ParentAccount object, it can be  
treated as a Customer object because the ParentAccount class inherits  
or implements the Customer class.

> However what I don't see is how to apply the special rules.

I am not sure what is meant by "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();

This is only valid after
   Customer customer = new ParentAccount();
or
   ParentAccount customer = new ParentAccount();

Note that the C# compiler will allow you to write
   ParentAccount parentAccount = (ParentAccount) new Customer();
but, at the very least, it should warn you that this is invalid.
--
Peter Horan             Faculty of Science and Technology
peter AT deakin.edu.au
     Deakin University
+61-4-0831 2116 (Voice) Geelong, Victoria 3217, AUSTRALIA
+61-3-5227 2028 (FAX)   http://www.eit.deakin.edu.au/~peter

-- The Eiffel guarantee: From specification to implementation
-- (http://www.cetus-links.org/oo_eiffel.html)