Advice on good OO design

[Rob Thomas]

Hi,

I'm just getting started with real OO design and programming and am
after a little advice.

Basically, I've got a Customer class and an Agency class. The Agency
class inherits all the properties and methods from Customer but I have
come accross a couple of problems:

I've got a Save, Add and Delete method in both of the objects. I'm going
on the assumption that it's a good idea to allow each object to control
itself. Each of these methods in the Agency class override the methods
in the Customer class and the base.Save etc methods are added to each of
the methods in the Agency class to fire off the assiciated method in the
Customer class before performing it's own Save etc.

I would like to pass in a database connection object to these classes
and force the Save methods to run in a transaction as there's no point
saving the Agency details without the Customer details. This is the area
that is causing me problems. I am currently passing the connection and
transaction objects directly into the Agency object via a constructor
and I then set relevant properties in the Customer object using
base.localDbConnection so that the Customer object has a connection to
work with. Bearing in mind that I am probably going to introduce
additional variants of Customer later, is this a good way of managing
the database connections etc ?

Any advice would be appreciated.

Rob

 

[Chris Hornberger]

I don't think you should allow your customer class (put aside any
inheritence issues a sec) to add, save or delete themselves at all.
Think about it from a Real World perspective. You don't call up John
the customer and ask him to drop by and delete himself from your
records. You have an administrator... or a "factory class"... handle
the responsibilities of creating, modifying and removing customers
(and other objects) from the data storage container.

 

[Thomas Tomicek [MVP]]

eing one of the few people that ever write a professional commercial
persistence layer (for .NET, btw.) let me second this.

Load, Save, query etc has NOTHING to do with the object per se - these are
operations that belong to a manager class. Not to the object.

BESIDES you never save the object, you save the object plus maybe subobjects
that got created etc.

--
Regards

Thomas Tomiczek
THONA Software & Consulting Ltd.
(Microsoft MVP C#/.NET)

 

[james]

This is known as Responsibility Driven OOP. The question to ask is
"who's responsibility is it to perform this action". Your example of
the Customer coming over to delete himself from the database
is a perfect example of placing the responsibility on the wrong class.
Great example !

This is the biggest mistake new OO programmers make. They use
objects to do procedural programming. I have found that by asking
the simple question or responsibility, that these problems can be
turned from procedural to OO


JIM