Re: OOD beginner (i already did a searc of the archives of comp.object)
- From: "H. S. Lahman" <h.lahman@xxxxxxxxxxx>
- Date: Sun, 11 Jun 2006 16:51:56 GMT
Responding to Arnuld...
I have a phone directory of my state (named punjab, INDIA). this
directory alphabetically lists all names and their phone numbers and
addresses, while it is easy to search for a name (because names are
arranged like a dictionary) it is very tough to look for a phone number
as they are arranged randomly. directory is arranged only by names &
nothing else. my father wanted me to write a programme for this problem
which can provide a person's phone number when given name or address as
input or which can provide address when given name/phone as input etc
etc i.e. we should not be bound by limited choices.
i struggled for months with Python (i was just beginning programming at
that time & does not even know what a person means by saying OOP).then
with SCHEME & forgot about it. after i finished LISP
(www.gigamonkeys.com/book), i had a bit of experience with CLOS. it was
very tough but i liked that approach, one day i was reading about Ruby
(whihc is OO language) and suddenly i thought that i can follow my OLD
hunches in OO way, Ruby gave the thought but i ended with CLOS. i
created a small programme with 10 different names, phone numers &
addresses and it did what my father wanted.
Alas, this doesn't explain the solution; it just lists the OOPLs that you tried to implement it with. B-)
From an OOA/D perspective, the solution seems to be pretty simple:
[Phone Directory]
| 1
| listed in
|
| R1 <<ordered>>
|
| accesses
| *
[Person]
+ name
+ address
+ phone number
The problem is that the list is ordered by name rather than address or phone number. So if you are given an address or phone number a linear search is required. To do this more efficiently you essentially need additional ordering. One way to do that is with multiple relationships:
1 1
+------------------ [Phone Directory] -------------------+
| | 1 |
| | |
| R1 <<ordered>> | R2 <<ordered>> | R3
| | | <<ordered>>
| | * |
+---------------------- [Person] ------------------------+
where each relationship is ordered in a different way. Then you navigate the appropriate relationship for the type of request. There is little overhead in having three relationships because they are each instantiated by a collection class add(...) as [Person] objects are created.
However, in practice this would usually be done at OOP time. The first diagram is the OOA/D view where all one needs to know is that the collection is ordered somehow. The second diagram is really an overspecification of the problem. The specific ordering does not affect the collaboration itself. More important, the problem of a linear search is really low level performance issue, which is a tactical issue for OOP. So specifying three collection classes usurps the prerogatives of OOP.
At OOP time would provide a specific implementation. That could be three separate collection objects, as in the second diagram, or a single collection object with three internal orderings and three interface methods (e.g., getByName, getByAddress, getByPhone).
well, that is histoy, only to tell you that i liked OO way of
thinking. sometimes i feel even when i know the syntax of LISP, RUBY &
LIST, i can not solve any problems untill i do it in a specific way. so
i need to learn OOA & D, generic programming (GP)for C++, functional
programming (FP), i mean different approaches. i tried and found that i
can only create programmes by following one of the OO, GP, FP ways,
otherwise not.
The OO, FP, and P/R paradigms are inherently incompatible, so one can't mix & match them and has to pick just one for a particular application development.
2) learning OOD.
I still consider myself a beginner at OO way and nothing else.
lurking into comp.object, comp.lang.c++ & accu.org tells me the
followin boks (listing only those books which are available in INDIA)
1.) OOA & D by Booch
2.) OOA by Peter Coad
3.) Design Patterns by GAMMA et al.
4.) Object-Oriented Modeling and Design by Rumbaugh
That is unfortunate because 1, 2, and 4 are all pretty ancient. (Booch is planning to come up with an updated edition shortly.) However, any of them will do for basic OOA/D. Coad uses more of a cookbook approach and doesn't provide as much detail, though. I would do one of the other two first for the basics and then read Coad to get practical tips.
Design Patterns is an advanced text that is really only useful once one already has a pretty good basis in OOA/D. However, it is a book every OO developer should eventually have on their bookshelf.
[If you get lucky and run across some other books, the Books category of my blog has some suggestions for selecting an OOA/D book.]
"OOA & D with applications" by Booch is not available in INDIA, so not
going to buy. by the way, what's difference b/w these 2 books:
"OOA & D" & "OOA & D with applications" both by Booch.
The one with applications has more soup-to-nuts examples.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
.
- Follow-Ups:
- References:
- Prev by Date: Re: OO and RDB war : in the advent of MRAM
- Next by Date: Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
- Previous by thread: Re: OOD beginner (i already did a searc of the archives of comp.object)
- Next by thread: Re: OOD beginner (i already did a searc of the archives of comp.object)
- Index(es):
Relevant Pages
|
