Nando,
I think that you hit the nail on the head on two counts.
I will go back and start modelling my objects (and probably buy a book on OO - maybe even the one you mentioned).
Then I will try to relax a bit. You are certainly correct that my early procedural code was pretty stinky. It is probably unrealistic of me to expect too much from my first stab at OO. I guess I needed permission to build a less-than-perfect application. =)
Thanks!
Steve
At 11:51 PM 4/29/2004 +0200, you wrote:
Steve,
Not a direct answer but one thing i notice is the use of the plural form "articles" -
you might be better off using the singular form "article" when thinking about it - so
that you are clear that this construct you want to build models a single article.
The next step is to think about attributes and responsibilities ... "I am an article.
What do i know about myself ... what are my responsibilities - what do i need to do
within this system." I know you're doing this, but it might help you to do it
systematically so you don't get lost in all the possibilities. Probably most people
need to approach it this way, even the very experieced.
There are 2 ways i've read about for sorting this out, step by step. One is to use
flash cards, the other is UML. In the flash card system, [Scott Ambler, The Object
Primer] you can develop an object model by identifying the nouns in your system, User,
Security, Article, etc. and then by running through the verbs or actions that you can
think of, and seeing where they make sense, who should be responsible for taking care
of this? Write them down as responsiblities on the cards. Use the first person to
assume the role of the object, to see the system from the object's perspective.
"Ok, let's see ... I'm an Article. I have an incoming request ... now i have to figure
out if i can show myself to the person who is asking. Do i need help doing that, or
can i do it alone? Then depending on what I (or We) determine, i need to get some data
from somewhere, maybe it's the database, and deliver it to the presentation layer."
As you go, you might find a few more nouns or objects that were not apparent ... and
you might also find some verbs or methods that you didn't think of initally. Sort them
out on your flashcards or in your UML model - shift things around until it seems to
make sense.
Ambler even suggests getting a group of people together, among them should be some
people who know the "business" the system is to model really well, the business
experts ... to develop the model on flash cards and act out the objects' roles and see
if everything works as it should - refining the model as they go. He says it is one of
the best ways to develop a model, but because it looks so low tech, he sometimes has
trouble convincing people to go along.
Then you might take a look at it from a more professional OO standpoint and check if
you are "encapsulating what varies" and "favoring composition over inheritance", etc -
you might then refactor your model.
I tried to do this just in my head in the beginning. In fact, i don't think i even
realized that what i was doing was trying to develop an object model. I just thought
... ok, what cfc's do i need. And it was very confusing.
I've found that it really helps to use a technique to sort this out, especially in the
beginning. I would suggest it highly.
And i think it also helps to realize that just like in procedural code, there is no
one right way to do something ... but in any case, the majority of experienced
procedural programmers might agree on certain tendencies and vary on the margins. When
we first started out writing procedural code, we wrote some pretty strange stuff, no
doubt. Remember? But as time went on, the general tendencies that just make sense
became clearer and clearer to us, and our procedural code became tighter, more
efficient, more reusable, and more capable.
It seems the same process happens when using CFC's in an OO style. CFC's can be used
as just a programming construct - a convenient way to reuse code - or they can also be
used as objects. In the beginning, i wasn't too sure of the difference.
Now i'm not too sure of the implications sometimes in using one approach or another,
for instance, why encapsulation seems so danged important to the experienced OO'ers.
What's the benefit to tightly encapsulating my objects when i'm the only one working
on the app?
If you take a few steps on this path, there are more up ahead. In the meantime, it
might be useful to give ourselves the permission to build a few somewhat sloppy apps
and learn from them. I have a feeling you want to get this perfect the first time.
Me too. ;-)
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
