Steve, Some months ago i started looking for recommendations on OO books. Here's what i've read so far based on other's recommendations:
The Object Primer - Scott Ambler (very good - it's quite practical and down to earth) Design Patterns Explained - Alan Shalloway (i really like the way this book covers the basics of how OO patterns are derived) Object Technology: A Managers Guide - David A. Taylor (Good overview of the basics - Hal's recommendation) Streamlined Object Modeling (more advanced, but they "Simplify business analysis by using 12 core patterns" - i liked it because it gave me a handle to think in more OO terms. Some of it is still a little over my head tho'.) I also have the Head First Java book, but i haven't had a chance to get into that yet. There are a few more here, but these top my list. Nando -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Steve Bryant Sent: Friday, April 30, 2004 4:31 AM To: [EMAIL PROTECTED] Subject: RE: [CFCDev] CFC interaction (take 2) 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] ---------------------------------------------------------- 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]
