A Few OO Design Questions...

[WuzZeH]

As you might have guessed, I am fairly new to OO design so I’m going to bundle a few questions together:

First off, I've written several .NET libraries over the past few months which basically have the following common classes in a single library (I’ll use Customer as an example):

CustomerCollection (Inherits from System.Collections.CollectionBase)
Customer Exception (Inherits from System.ApplicationException)
CustomerItem (standard class which just represents the fields of a typical Customer)
CustomerReader (reads data from a database and populates its own CustomerCollection full of Customer objects)
CustomerWriter (writes data to a database by iterating through its own CustomerCollection (previously populated by the caller)).

Is there anything particularly wrong with the above design, if so give some practical examples as to why its not so good.

Secondly, I’ve come across a situation where I would like to use an interface as follows:

Interface

IApplicationItem
string Code
string Description

Classes

WindowsServiceItem Implements IApplicationItem
string Code
string ServiceName
string ServerCode
string Description
string ConfigFilePath

QueueForDayItem
int ID
IApplicationItem Application
Etc..

Basically I want to pass an application object into a QueueForDayItem object as above. This works fine as it allows different types of application items to be passed in (i.e. web app, windows app etc.) as long as they implement that interface. However, things get a little more complicated when you want to store and retrieve this data in a database. For example, say I wanted to write the QueueForDayItem to a tblQueueForDayItems database table, how do I store the ApplicationItem information? If I just store the code field how do I later retrieve the description without knowing where this applicationitem came from (i.e. it could be a windows service, web app, win app etc. each of which could be stored in different database tables.) Am I missing something here, or is there a better way of designing this set of interfaces/classes?

Any help would be greatly appreciated.

Thanks

 

[stevexff]

WuzZeH

First, the library classes.

[ol][li]CustomerCollection - does this provide any added functionality over the base class?[/li][li]CustomerException seems OK[/li][li]CustomerItem - isn't this just a Customer?[/li][li]Reader/Writer - this could be a bit flaky. Consider what would happen if a Customer object knew how to persist itself. You could then call CustomerCollection.persist(), and it could iterate over the collection calling Customer.persist() on each one. As an added refinement, you could have an isDirty flag in each customer that gets set if any of the setter methods have been called since it was read from the database. Then Customer.persist() would only need to persist items that had changed since they were fetched.[/li][li]An interface is a contract to provide implementations of a set of method signatures. You can call the methods and it will do what it says on the tin. That's all.[/li][/ol]

You might want to take a look at NHibernate. It's an open source .NET clone of the Java Hibernate framework, which takes care of your object-relational mapping and persistence. It also handles mapping of inheritance hierarchies to relational databases, so you could lose the interface and have Application as the superclass with WebApp and WinApp as subclasses. (it supports several ways of doing this, but basically you end up with an Application table with the common data on it, and WinApp and WebApp tables that share a common key). They make a big deal about it being in alpha stage, but as Java Hibernate has been through several version iterations it's building on a pretty solid foundation.

The main advantage is that once you have set up your class to table mappings (an XML file) you can just work with the objects, without having to worry about the database at all.

Check it out

http://www.nhibernate.org

 

[WuzZeH]

Sorry for not replying sooner…

Library Classes...

1. Yes it adds additional functionality by stopping any old object from being put in, only CustomerItem objects can be added.
3. Yes its just a habit to prevent class and namespace confusion i.e. Customer[Namespace].Customer(Class).
4. Interesting point about persistence I guess a careless coder could do some damage with the reader and writer.

As far as the overall design goes though is this ok? I've heard about n-tier architecture where you have a data layer and a business object layer, have I kind of mixed the two here?

I’ll definitely take a look at that NHibernate tool. I guess my main gripe at the moment is knowing which database design to go for. I’ve come across an interesting book which I’m reading at the moment:

http://www.ambysoft.com/agileDatabaseTechniques.html

(Chapter 14 Mapping Objects To Relational Databases).

 

[stevexff]

Depends on how big the application is, and how much time you could save later on if you need to extend it.

It's much easier to write an application that only deals with the business objects, and the business objects interact with the data objects to handle persistence. But of course, it's more effort to set up in the first place.

Patterns of Enterprise Architecture (Fowler) is a pretty good reference for design patterns, and so is Core J2EE Patterns (Alur). Although it's Java oriented, the design patterns hold good regardless of language.

But both authors sit on the fence a bit in the persistence area, giving a couple of alternatives and leaving it up to the reader to make the choice depending on the needs of the application. The basic problem seems to be the disjoint between the relational and object models, so there is no 'one size fits all' answer.

 

[WuzZeH]

Thanks for the info.