Re: [Reactor For CF] OO terminology etc (was: MG RoCS

[Jared Rypka-Hauer]

OK, I'll throw in here. When I first started with CF back in '97, I'd been programming or "developing" as a hobby since I was 9... which means (blech) that I wrote my first computer program almost 25 years ago. HELP ME!! ;) I was still doing CFMX like it was CF5 as late as 2002... call me oblivious, I just didn't have a lot of exposure outside my little environment. But I got back to going to CFUGs and started reading more about CFMX and CFCs and stuff... and I met Sean on CF-Talk. Finally after years and years of wondering and even asking repeatedly, someone started to explain things a bit and I started reading blogs, articles online, and things like Ray Camden's ColdFusion Dev Guide... Guy Rish's chapter on OO and encapsulation was the thing. I "officially" started learning OO one year, one month and nine days ago. I don't know why Jan 12 2005 got glued into my head, but it did. I caught the bug. I still get lost in my applications... I think I tend to overcomplicate things by trying to write n-tier applications from the start rather than letting controllers have a little more authority than they should. Often I get the idea right away, but when I go to use it I sit there staring at my graph paper wondering where to start. It's getting easier and easier all the time, though. What was key was understanding the basics... what's an object, what's an instance, what's a class, what's encapsulation, polymorphism, and inheritance, yadda yadda. It's hard going from PP to OOP because with OOP you so often start with the "don't worry about what it does, worry about what it is" but from a procedural background there is no "is"... there is only does. So looking at examples like C++ or Java that have a main() method that kicks off the loading, starting, INSTANTIATING! hehe really helped me see... OH I get it, sequence over procedure... bah, syntax sux. Anyway, I basically learned OO by nagging friends with questions (and some even still talk to me!) and by reading Mach-II's source code, believe it or not. That was where I started to see patters like index.cfm bootstrapping the framework into the application scope, method chaining, and how encapsulation really works in a CF application. My biggest challenge now is abstraction... it makes my brain hurt. I'm working on writing an event validation framework/library that allows Fusebox, Mach-II or ModelGlue to validate data in the "event" (or the attributes scope, as Fusebox calls it) and I've got 99% of it done. It's that last 1% that involves the highest level of abstraction and deepest set of composite objects that's proving hardest because I can't SEE it. I guess you could say I'm very visual, so I'm actually starting to contemplate using coins and colored string to model my applications. ;) If anyone wants more info on Sting just let me know. It should be most cool because it'll allow an entire event to be validated with one validate() call, has strict or loose validation, etc., and will make the validation side of things as much a snap as Reactor makes the DB side of things. I know that the "seeing it" thing is actually offset by... gasp... UML. I'm just not good enough at predicting what objects will go where yet to be very good at modeling, then writing... one day soon i hope. For now, it's all about the coffee, graph paper, and coins+colored string. Hehe.. Anyway, enough of the commercial. Suffice to say I've been at OO for a year and still literally get dizzy headaches from it once in a while... but it gets easier and easier all the time and I keep getting faster at it to boot. Laterz! J ------------------------------------------------ Jared C. Rypka-Hauer Continuum Media Group LLC http://www.web-relevant.com Member, Team Macromedia - ColdFusion "That which does not kill me makes me stranger." - Yonah Schmeidler On Feb 21, 2006, at 4:02 PM, Sean Corfield wrote: On 2/21/06, Doug Hughes <[EMAIL PROTECTED]> wrote: You hit the nail on the head.  My path to OOishness started more than two years ago (after many many years of procedural programming).  I started by taking Hal Helm's class on Mach-II.  I figured after 3 days I'd know this stuff backwards and forwards.  (I consider myself to be reasonably bright too.)  So, after the class I quickly ran home and was absolutely unable to get anything done.  I spent the next two years trying and trying and trying again. My OO history: I started back in January '92 by picking up C++ and it was really painful. It took me at least a couple of years to get comfortable with the OO styles of the day back then and they've been evolving ever since and I've tried to keep up with it all. I picked up Java in '97, I dabbled in Smalltalk on and off through the 90's and these days I do my OO in ColdFusion mostly. Almost no one had heard of design patterns back when I started doing OO - something we've all had to pick up along the way. And idioms keep changing - and each language has its own set of idioms which adds to the difficulty. I like to think I'm a fairly competent OO designer these days but even so, it was only last year that I 'got' inversion of control and why anyone might program that way! Then, one day, I was working in Java (of all languages) and realized that (holy hell!!) I was applying OO unconsciously.  From that point forward my learning curve has returned to my pre-OO days. That's pretty much how it is for most folks. One day, the lightbulb goes on. That day can be weeks, months or sometimes years into the learning process - depending on how you learn and what resources you have at your disposal (training courses, a mentor, access to good OO code examples, books - whatever suits you). As Sean frequently says, "This stuff is hard!" Yeah, I had one guy get really irate at CFUN-04 because I told him not to expect to pick up OO in "a few days" (his expectation was that he'd read a book and be off and running). He felt I was being elitist or telling him he was stupid because I insisted it would take him longer than his "few days"... Unfortunately, this stuff is just plain hard. And as I always say, "You've got to try and screw up a few times before you'll get it".  Why? Because by messing up you'll be able to see what went wrong.  This, at least for me, helps me to understand how to avoid this problem next time around. Yes, that helps too - although sometimes figuring out that you have actually screwed up isn't always easy :) But I do feel that making mistakes and learning from them really does help bring home the concepts behind OO. -- Sean A Corfield -- http://corfield.org/ Got frameworks? "If you're not annoying somebody, you're not really alive." -- Margaret Atwood -- Reactor for ColdFusion Mailing List -- reactor@doughughes.net -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/