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 _______________________________________________ patterns-discussion mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/patterns-discussion
