RE: framework question

> From: NGay@xxxxxxxxxxxxx
> 
> Joe,
> 
> Ok say you were writing an application for automobile insurance.  Say
you
> have some general rules about how to generate a quote (by reading
database
> tables no doubt) but cars + motorbikes each have a handful of complex
> rules
> that apply only to them...
> 
> Then you'd create an Automobile object, inherit Car and Motorbike
objects
> from them.  Define Automobile.quote () and override this in Car.quote
()
> and Motorbike.quote () which would probably call super.quote () and
> add/subtract as necessary depeding on the additional rules for those
types
> of vehicles.

I wouldn't write it this way.  I would write a generalized table-driven
quoting engine and drive the differences between cars and motorbikes
from the database, not from some hardcoded inheritance rule.  Because
what happens when I now have two classes of motorbikes, but one no
longer uses the same rules as the car?  In my design, I simply change
the database records, whereas in yours you are going to have to rewrite
your class hierarchy.

No, business rules and OO do not mix.  OO is best used to define
processes that are rarely if ever subject to change (communications
protocols, HTML formatting, that sort of thing).  Procedural languages
are by far better for writing business logic that can change from day to
day based on external circumstances.

Joe