*giggle* The following i actually learned after sifting through the pages of IBM's OO Rexx manual:
Simple design strategy: construct multiple sentences concerning the actions of the program: for example, The customer inserts an item into his shopping cart. In this case, you can variably choose nouns to represent some objects- "customer" and "shopping cart" and "item" (product). Verbs will be the functions- ShoppingCart.insert(Item); Try this a few times to get the hang out it. Why not try sifting through one of the thousands of complete shopping apps and trying to perhaps redo it with OO design for practice.
AgentM Systems nor Nasca Enterprises nor
Bone::Easy nor Macperl is responsible for the
comments made by
AgentM. Remember, you can build any logical system with NOR.
| [reply] |
I've seen the sentence metaphor used a whole lot in OO
introductions. I think it's a pretty good one, but then you
have to get into the whole sentence composition rules, such
as what's the subject and the object (pardon the pun) of the
sentence? Don't forget that if you go creating objects
willy-nilly from all of the nouns in the sentence, you'll
end up with more objects than you need (unless you're
programming in Java or Smalltalk, in which case, you can't
do anything but objects).
ALL HAIL BRAK!!!
| [reply] |
You will want to read these books:
I especially recommend the Analysis Patterns book. It is a bit dry, but pays off handsomely.
Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com
| [reply] |
One school of thought is that anything that is identifiable
outside the context of another object is itself an object.
A customer order in one sense is nothing but an old shopping
cart. It reflects the contents of a shopping cart from a
previous visit, and it probably extends the amount of
information normally associated with a shopping cart.
So, as you can see, an order is a shopping cart
with some extra info. Common to the school of thought that
I am describing (in a limited sense, since OO is not an
entirely easy concept to describe within the constraints of
this node) is the use of is a and has a
descriptions in as many places as possible. By designing
this information, a clearer picture as to what objects are
"super-objects" and what objects are "detail-objects" will
emerge. The "super-objects" will contain the necessary code
to meet basic needs and the "detail-objects" will contain
the majority of the code in relation to that object. You'll
probably override/overload some of the functionality in the
"super-objects" when you get to the "detail-objects".
I had a pretty decent book in my OO class at school
written by Timothy Budd called
An
Introduction to Object-Oriented Programming, which covers
a good portion of theory. I thought it was useful, albeit
the book lacks Perl implementation.
ALL HAIL BRAK!!! | [reply] |
i can't say i know of any specifically web-oriented OO books. but in addition to the ones already listed:
i've found it to be a great, language neutral set of guidelines for creating OO-designs.
| [reply] |
A greatful thank you to all. AgentM's tip on using sentence structure to identify a set of objects is a great design hueristic. Thanks to the rest of you for the book recommendations as well.
Off to Fat Brain I go... No bookshelf is ever full enough!
sz | [reply] |