Head first OOA&D is a good book, but it assumes a familiarity with OO coding. I'd actually read head first design patterns before their OOA&D book (which is good, but to my mind, not intro level). The DP book isn't specifically about OO, but it covers the basics and also introduces a bunch of patterns you're going to need to learn over time to get how to make OO work in practice.
Best Wishes, Peter On 2/20/07 7:02 AM, "Sammy Larbi" <[EMAIL PROTECTED]> wrote: > Jim, > > For those questions I'd take a look at > http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod and > specifically the first 5 principles listed there. It's a great > introduction to OOD. If you encounter a term you haven't seen, I'd look > it up to understand it. Finally, I'd have a look at the DRY principle, > because that one is pretty helpful too. > > If you're down for a bigger read, check out Steve McConnell's Code > Complete 2 (I'm currently reading it). It has a lot of information > regarding the questions you asked (plus a lot more). I've also heard > good things about Head First OOAD, which would address some of your > questions, but I haven't read it myself. > > -Sam > > > Jim Cassata wrote, On 2/19/2007 4:04 PM: >>> even the mechanics of using CFC's properly might >>> be a hidden mystery in the beginning, one that you >>> may not find explained clearly anywhere. >>> >>> Nando >> >> YES Nando! huge emphasis on properly! I can make the CFCs work real >> fast and real easy, but am I doing it properly? I have no idea. I have >> been religiously following the Forta CFMX7-WACK but the examples are >> so basic. How many fnctions in a CFC are too much? How many CFC >> invokes in a CFM page are too much? WHen to use CFObject vs CFInvoke? >> >> For example one of my cfm pages maybe had a query joining 4 tables and >> then 4 other queries that get records from some supporting tables. How >> should I break that logic into CFCs and CFFunctions? Well, by not >> knowing the answer to that question my approach has been to put the >> functionality for that page into it's own function, with cffunctions >> to similar pages grouped into the one CFC. If I did add a feature, >> instead of updating multiple cfm pages, now I go to one CFC and update >> several cffunctions. Better than the way it was but is it proper? or best? >> >> As for the ModelGlue, if I want an existing app to be in MG am I >> essentially rewriting the whole thing? >> >> Jim >> >> You are subscribed to cfcdev. To unsubscribe, please follow the >> instructions at http://www.cfczone.org/listserv.cfm >> >> CFCDev is supported by: >> Katapult Media, Inc. >> We are cool code geeks looking for fun projects to rock! >> www.katapultmedia.com >> >> An archive of the CFCDev list is available at >> www.mail-archive.com/[email protected] > > > > You are subscribed to cfcdev. To unsubscribe, please follow the instructions > at http://www.cfczone.org/listserv.cfm > > CFCDev is supported by: > Katapult Media, Inc. > We are cool code geeks looking for fun projects to rock! > www.katapultmedia.com > > An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] > You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
