RE: Polymorphism - retrieving type information from thedatabase or how

Question

Don,
Ok but if I was to model a real restaurant, I would then have a head chef
that can then delegate to other chefs. This head chef would have the
additional task of coordinating the completion of subservient chefs. This
does not and would not mean that the head chef is stuck (or partitioned) in
one part of the kitchen. Further a head chef would most likely also be a
chef so that he would be running around the kitchen using and interacting
with different objects to get his part of the recipe completed. Then once
all chefs have completed their part of the recipe the head chef could return
the meal.
I would also point out that it does not make sense to me to be talking about
the chef and its ability to scale. I would look that the resource limited
devices that must be used to prepare meals to see scalability. In this case
the grill, the stove and the microwave. Scalability of the restaurant is a
function of the amount of resource limited devices versus the number of
process (i.e. chefs) that need to use those devices concurrently and the
amount of time they require access to those devices. By talking about chefs
as if they are the scalability limiting factor seems to bring us back to the
notion that the chef is a manager object that is shared. And again I come
back to the question, why?
You may now think that in a real restaurant, there are only so many chefs so
why not make it a shared service? Well in a real restaurant there are only
so many of any object, but this is not a consideration in our restaurant
model. In our "virtual" restaurant hiring a chef is as easy as:
Chef = new;
And of course chefs are of zero mass so there can be a whole lot in the
kitchen. Now assuming the Grill, Stove and Microwave map to physical
objects in our computing environment, then that is the limiting factor and
are therefore partitioned. Whenever communication has to go through a
single source, then scalability breaks down. I fear that too many people
make shared objects and create communication bottlenecks where they simply
don't exist. The only place your scalability bottlenecks should exist is in
the actual resource limited objects of your computing environment. Simply
said, if something isn't a resource limited object, then why is it shared?
If anyone is not clear how to architect an application independently of the
business model, then I would suggest looking at various framework products
and reading some technical architecture white papers to get a different, and
possibly enlightening, point of view.
Mark Perreira
Sage IT Partners.
-----Original Message-----
From: Don Nelson [mailto:[email protected]]
Sent: Wednesday, June 17, 1998 9:04 AM
To: Mark Perreira
Cc: [email protected]
Subject: RE: Polymorphism - retrieving type information from the
database
Mark,
First, I completely agree about the naming. I purposely used rather
euphamistic names for these "managers", since I see many convoluted names
for common things in various applications. But that is a topic for another
thread...
Simply because there is a "manager" of some type, does not imply that it is
chained to a particular duty. However, let's look at a real life case. In
a large restaurant, you would rarely see a chef chopping carrots or serving
dishes to customers. Those are the responsibilities of the sous-chef and
the waiter. So, we see that the chef does not really follow the food
around. Why not? Because it simply doesn't scale. When scalability isn't
a problem, (the restaurant isn't that popular, for example) the chef has
some lattitude to accept more responsibility, and might even get involved
with purchasing, etc.
In the real world, the more scalable something has to be, the narrower the
responsibilities are for each of the participating members.
Don
At 12:59 AM 6/17/98 -0700, Mark Perreira wrote:
Don,
One thing that always baffles me is when should an Object get the moniker
"Manager." This practice seems to tell me a couple of things about these
objects. In general when someone makes reference to a "Manager" objectthat
it is probably a service object and probably contains no or very little
attribution. The question is why? If I am developing an object model why
am I thinking about such implementation issues.
Surely if you are trying to model cooking an egg I would not see
"SustenancePreparationManager" in your model. Using a more common term I
would still be alarmed to see "CookManager" in your model. What does the
CookManager manage? Does it manage other cooks or eggs. Maybe it shouldbe
called an EggManager, but that doesn't make sense. How about just Cook.
There that seems like the real world. And this brings me to a problem in
the analogy. Conjuring up managers in a model can sometimes make you missa
container. For example, I would say that if we wanted to model the real
world, then eggs is a specialization of ingredient that is contained by
recipe that can be given to a cook to be prepared.
I may have many cooks (objects) that can prepare recipes and my application
architecture not the object model needs to deal with how to best let those
cooks utilize the grill, stove and microwave that sits on different
partitions on my server. My cooks can move around and when they do they
take their ability to know how to cook with them. In the real world Iwould
expect a cook to use the right appliance to prepare the recipe based on its
contents. I would not chain every cook to its appliance and them make me
responsible for giving the right cook the right recipe. This is what
managers can cause. They cause the consumer of cooks to know which cookcan
prepare what recipes based on where they are chained. This then makes me
know something about cooking. And if I don't know anything about cooking I
can only image what my egg would look like if I accidentally gave therecipe
to the cook stationed at the microwave.
Ok Ok, I have seen many architectures use facades to hide the fact that I
like to chain my cooks to their appliance. But what is that. I have gone
to restaurants and I don't know what a cook facade is. If I ask themanager
to present the cook facade manager employee I would probably be met by the
bouncer employee.
So what is the answer? Well for a start keep the application architecture
out of the model. The model should stand alone in describing the
interactions required to satisfy use cases. Second find an architecture
that describes a more responsibility driven design and how that design and
can map your business object behavior to a physical implementation with
appliances and cooking rules. And lastly, don't be so quick to chain your
cooks to their appliances. Give them some control over where they cook
their recipes, after all that is what they do.
Mark Perreira
Sage IT Partners.
-----Original Message-----
From: [email protected]
[<a href="mailto:[email protected]">mailto:[email protected]]On</a> Behalf Of Don Nelson
Sent: Tuesday, June 16, 1998 2:07 PM
To: Nick Willson
Cc: [email protected]
Subject: Re: Polymorphism - retrieving type information from the
database
This thread is switching context a bit, but I would add one thought tothe
idea of encapsulating behavior. One of the advantages to OO is that it
helps us model real world behavior. In the real world, I would not askan
invoice to stuff itself into an envelope and mail itself to its
customer; I
would not ask my vehicle to fuel itself or change its own oil; I wouldnot
tell an egg carton to ask one of its eggs to fry itself. Even if these
things were physically feasible, I could list a number of reasons why I
still wouldn't want to do them. That is why we haveVehicleRepairManagers
and SustenancePreparationManagers (aka, "Mechanics" and "Cooks").
Don
At 11:28 PM 6/15/98 -0700, Nick Willson wrote:
Tim,
You've had lots of good suggestions so I hope you won't mind an attempt
at another one. The consensus seems to be for your option (1) for the
Vehicle table, and Steve's example of a GenericConstraint (taking the
place of your Vehicle) is probably how most people would go about
answering your question. I don't have much to add to that, just wanted
to offer something about where the persistence mechanism lives and how
things look to clients that depend on it.
Suppose for a moment you think about the Vehicle classes' persistence as
being just one aspect of their behavior. In addition to persistence,
you might have to implement security, or locking for concurrent access,
or caching of vehicle objects to improve performance, and of course you
want to calculate the vehicle tax and probably do other things with
Vehicles too.
You can put the persistence aspect of Vehicles into a
PersistenceObjectManager, but then the others need somewhere too. If
you use a bunch of Managers (one for security, one for locking...) then
each class's behavior is scattered across these various Manager classes,
each of which has to know about many classes. Or if you use one Manager
class, it's going to know still more, plus you are forced to implement
all the behavior in (or at least via) that manager's partition.
An alternative would be to keep all the Vehicle classes' behavior
encapsulated together, so a client always makes requests to a Vehicle,
and the Vehicle delegates the implementation of requests to a chain of
handler objects that hang off the vehicle object (a handler for
security, another for persistence, and so on).
One of the nice things about this is, the handlers can be responsible
for going to another partition (if necessary), e.g. to perform
persistence operations, or for more business-specific operations like
tax calculations. And because the handlers are smart, you don't have to
put a lot of code into service objects, the SOs can stay pretty simple.
This isn't an approach you'll see in Express, so I hope of it's of some
interest.
General wrote:
Part 1.1 Type: Plain Text (text/plain)
Encoding: quoted-printable--
Nick Willson
SCAFFOLDS Consultant,
Sage IT Partners, Inc.
[phone] x 373
[email protected]
The Leaders in Internet Enabled Enterprise Computing
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:<a href=
"http://pinehurst.sageit.com/listarchive/">http://pinehurst.sageit.com/listarchive/</a>>
>>>
>>>
>>
>>
============================================
Don Nelson
Regional Consulting Manager - Rocky Mountain Region
Forte Software, Inc.
Denver, CO
Phone: [phone]
Corporate voice mail: 510-986-3810
aka: [email protected]
============================================
"When you deal with higher numbers, you need higher math." - Hobbes
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:<a href=
"http://pinehurst.sageit.com/listarchive/">http://pinehurst.sageit.com/listarchive/</a>>
>>
>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:<a href=
"http://pinehurst.sageit.com/listarchive/">http://pinehurst.sageit.com/listarchive/</a>>
>
>
============================================
Don Nelson
Regional Consulting Manager - Rocky Mountain Region
Forte Software, Inc.
Denver, CO
Phone: [phone]
Corporate voice mail: 510-986-3810
aka: [email protected]
============================================
"When you deal with higher numbers, you need higher math." - Hobbes
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:<a href=
"http://pinehurst.sageit.com/listarchive/">http://pinehurst.sageit.com/listarchive/</a>>

Answer 1

Don,
You are absolutely correct. But this is where I honestly think you are
missing the point. While the mail program sends the mail, my mail message
has an interface (i.e. send button) which can delegate that to the mail
program. This makes it nice and simple for me the consumer of the mail
program. It also means I can think of mailing by focusing on the interface
(i.e. the button). It would suck if every time I wanted to mail something I
had to identify the correct pop server to send it to (i.e the MailManager).
Mailing something is the collaboration of the setup information of the mail
program and my mail message. If I were to model this my mail object would
indeed have a send method that could delegate to the correct mail servers.
This is just simplicity of interface and it is a good practice in UI
development just as it is in business model development. A simpler
interface, I think we can all agree, provides for a better and quicker
understanding.
Mark Perreira
Sage IT Partners.
-----Original Message-----
From: [email protected]
[<a href="mailto:[email protected]">mailto:[email protected]]On</a> Behalf Of Don Nelson
Sent: Thursday, June 18, 1998 9:22 AM
To: Nick Willson
Cc: [email protected]
Subject: Re: Polymorphism - retrieving type information from the
database
Nick,
It turns out that your message does not, indeed send itself. Your mailing
program does that.
Don
At 11:54 PM 6/17/98 -0700, Nick Willson wrote:
Hey Don,
In the real world, no, you can't tell an invoice to put itself into anenvelope
and mail itself. You have to know about stamps and post boxes and wherethey
are located. But isn't it nice that in software you don't have to followthe
real world very closely if you don't want to?
Above the top left hand corner of this message I'm typing right now, thereis a
send button which lets me tell the message to 'stuff itself into anenvelope
and mail itself'. Why wouldn't you want to do that?
Don Nelson wrote:
This thread is switching context a bit, but I would add one thought to
the
idea of encapsulating behavior. One of the advantages to OO is that it
helps us model real world behavior. In the real world, I would not askan
invoice to stuff itself into an envelope and mail itself to its customer;I
would not ask my vehicle to fuel itself or change its own oil; I wouldnot
tell an egg carton to ask one of its eggs to fry itself. Even if these
things were physically feasible, I could list a number of reasons why I
still wouldn't want to do them. That is why we haveVehicleRepairManagers
and SustenancePreparationManagers (aka, "Mechanics" and "Cooks").
Don
At 11:28 PM 6/15/98 -0700, Nick Willson wrote:
Tim,
You've had lots of good suggestions so I hope you won't mind an attempt
at another one. The consensus seems to be for your option (1) for the
Vehicle table, and Steve's example of a GenericConstraint (taking the
place of your Vehicle) is probably how most people would go about
answering your question. I don't have much to add to that, just wanted
to offer something about where the persistence mechanism lives and how
things look to clients that depend on it.
Suppose for a moment you think about the Vehicle classes' persistence as
being just one aspect of their behavior. In addition to persistence,
you might have to implement security, or locking for concurrent access,
or caching of vehicle objects to improve performance, and of course you
want to calculate the vehicle tax and probably do other things with
Vehicles too.
You can put the persistence aspect of Vehicles into a
PersistenceObjectManager, but then the others need somewhere too. If
you use a bunch of Managers (one for security, one for locking...) then
each class's behavior is scattered across these various Manager classes,
each of which has to know about many classes. Or if you use one Manager
class, it's going to know still more, plus you are forced to implement
all the behavior in (or at least via) that manager's partition.
An alternative would be to keep all the Vehicle classes' behavior
encapsulated together, so a client always makes requests to a Vehicle,
and the Vehicle delegates the implementation of requests to a chain of
handler objects that hang off the vehicle object (a handler for
security, another for persistence, and so on).
One of the nice things about this is, the handlers can be responsible
for going to another partition (if necessary), e.g. to perform
persistence operations, or for more business-specific operations like
tax calculations. And because the handlers are smart, you don't have to
put a lot of code into service objects, the SOs can stay pretty simple.
This isn't an approach you'll see in Express, so I hope of it's of some
interest.
General wrote:
Part 1.1 Type: Plain Text (text/plain)
Encoding: quoted-printable--
Nick Willson
SCAFFOLDS Consultant,
Sage IT Partners, Inc.
[phone] x 373
[email protected]
The Leaders in Internet Enabled Enterprise Computing
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:<a href=
"http://pinehurst.sageit.com/listarchive/">http://pinehurst.sageit.com/listarchive/</a>>
>>>
>>>
>>
============================================
Don Nelson
Regional Consulting Manager - Rocky Mountain Region
Forte Software, Inc.
Denver, CO
Phone: [phone]
Corporate voice mail: 510-986-3810
aka: [email protected]
============================================
"When you deal with higher numbers, you need higher math." - Hobbes--
Nick
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:<a href="http://pinehurst.sageit.com/listarchive/">http://pinehurst.sageit.com/listarchive/</a>>
>
>
============================================
Don Nelson
Regional Consulting Manager - Rocky Mountain Region
Forte Software, Inc.
Denver, CO
Phone: [phone]
Corporate voice mail: 510-986-3810
aka: [email protected]
============================================
"When you deal with higher numbers, you need higher math." - Hobbes
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:<a href=
"http://pinehurst.sageit.com/listarchive/">http://pinehurst.sageit.com/listarchive/</a>>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:<a href=
"http://pinehurst.sageit.com/listarchive/">http://pinehurst.sageit.com/listarchive/</a>>