OO question beginner

  • Thread starter Thread starter .net lear
  • Start date Start date
N

.net lear

if I have an object, say a recipe, which is added to a database, whose
responsibility is it to add to the db? The recipe or something else?

Let's say I want to delete a recipe? Does the recipe kill itself? Or does
the database or something else do the removal?

Where does the responsibility lie?

Thanks.
 
Usually, you will use the Layers pattern (see Buschmann) and you would
seperate the business object (recipe) from the CRUD code needed to insert or
delete it from the database (in the persistence layer)

The object itself is responsible for using the persistence layer, and for
knowing what methods to call to persist its data.

So, a recipe stores itself using the persistence layer, and a recipe deletes
itself using the persistence layer.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
 
ok thanks. I thought the recipe would be responsible but I don't know
anything about the persistence layer.
 
The recipe only tells you how to cook the dish, it has no concept of where
the recipe is stored in your kitchen. As it happens its stored in the
cookbook (the persistence or data layer). storing the recipe has nothing to
do with cooking the dish, so you should refrain from including that logic in
your business layer (the recipe) - ideally the cookbook would do the
deletions and inserts with the recipe being an argument passed to it as the
persistence layer as inserts and deletions are something that occur to your
cookbook not your recipe.

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director
 
Thanks a lot.

I'm just getting started with this concept, very used to procedural
programming.

Isn't the cookbook just a collection of recipes? In other words,
doesn't it inherit from recipe to some degree?

When you say "stored in the cookbook (persistence or data layer)", can
you elaborate? What does that mean?
 
How it inherits depends on your encapsulation, and whether there is any
interaction between the cookbook and the recipe. In an ideal OO scanrio the
recipe should be self contained, telling you only how to make the dish. The
cookbook knows nothing about making the dish, thus it needs to inherit none
of the properties of the recipe to function as a cookbook - it only needs to
contain recipe objects, like a namespace containing lots of different
classes. The classes in the namespace can be interelated by existing in the
namespace, but need not know anything about each other unless thats how to
need the objects to interact. Connected to this, the way you serve the
recipe (the presentation (layer)) has nothing to do with how it is stored in
the cookbook (persistence (layer)) or how it is cooked (business (layer))

Mutli tiered or layered implementations perform different and self contained
elements of your programming logic, like your presentation layer knowing
about plates and cress but nothing about cooking times. Theres a very nice
and straingtforward explanation of multi tiered applications here that might
be worth taking a look at.

http://www.dfpug.de/konf/konf_1999/gruppe08_tier/e_tier/e_tier.htm

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director
 
thanks a lot.


John Timney (ASP.NET MVP) said:
How it inherits depends on your encapsulation, and whether there is any
interaction between the cookbook and the recipe. In an ideal OO scanrio the
recipe should be self contained, telling you only how to make the dish. The
cookbook knows nothing about making the dish, thus it needs to inherit none
of the properties of the recipe to function as a cookbook - it only needs to
contain recipe objects, like a namespace containing lots of different
classes. The classes in the namespace can be interelated by existing in the
namespace, but need not know anything about each other unless thats how to
need the objects to interact. Connected to this, the way you serve the
recipe (the presentation (layer)) has nothing to do with how it is stored in
the cookbook (persistence (layer)) or how it is cooked (business (layer))

Mutli tiered or layered implementations perform different and self contained
elements of your programming logic, like your presentation layer knowing
about plates and cress but nothing about cooking times. Theres a very nice
and straingtforward explanation of multi tiered applications here that might
be worth taking a look at.

http://www.dfpug.de/konf/konf_1999/gruppe08_tier/e_tier/e_tier.htm

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director
Click to expand...
 
Back
Top