I don't know what the standard definition is either. I suppose the simplest definition is that the code uses objects, but I think we can both agree that's insufficient. When I wrote that "is it OO" test, I carefully phrased it so that it wouldn't give an answer for apps like how yours seems to be structured. Not because I wanted a cop out, but because I don't have good answer about whether those apps are OO or not.
I think I'd say you have a procedural frontend system that leverages an OO backend. I really like Mach-II, but I think my preference is still for that duality between the UI and the backend, for exactly the same reason as you. HTTP is an inherently procedural protocol to work across, and forcing it to interface directly with an OO system seems wrong in some ways. Before I dove into Mach-II, I wrote a couple FB4 apps where only the dsp_ fuses were actual fuses. The entire model and most of the controller (the parts that didnt' have to be in the switch) were all CFCs, and it worked very well. There were some minor issues with getting everything to play nice, but much of that was with fusebox specifically, not with using a procedural front-end. Later, I converted one of those apps to Mach-II, and almost nothing changed. Bascially the switch files became the mach-ii.xml file, and I had to add some very thin listeners between the framework and my existing back end. Pretty much everything else stayed the same. Strictly meeting anyone's definition of OO is pretty irrelevant, IMHO. Much better to ensure you have sufficiently used the tenets that OO is based upon (encapsulation, abstraction, and code reuse), and if using objects makes that easier great. It's just another way to solve the same problem, and any good solution needs to have certain characteristics which are separate from the method used to create the solution. cheers, barneyb > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of cf_nut > Sent: Wednesday, October 08, 2003 3:05 AM > To: [EMAIL PROTECTED] > Subject: Re: [CFCDev] Procedural vs OO (Was: Data validation) > > > Barney, before I start, your preface applies here too, I'm not > making an attack, just trying to reach an understanding (having > started from a different point of view). > > Okay, so by this definition (sorry I don't know if it's > the 'standard' definition, if there is such a thing) if I'm writing > an application that uses CFCs (or objects), applies encapsulation > strictly (instance data is private), uses inheritance, abstraction, > if I do all these things but I DON'T use an event-driven model, then > I'm not really doing Object-Oriented programming ? > > If that's the definition that's generally accepted, then okay, I'm > not doing OO programming, but I am still getting all the benefits of > encapsulation, etc, etc. > > I have to say though, (educate me if I'm wrong) that it seems to me > that the event driven model for programming arises out of the rich > GUI we're all used to, where asynchronous events arise out of users > using dropdown box, radio button, text entry field in any old order. > In the far simpler world of the HTTP protocol, where one HTTP > request gets one HTML page delivered as a response, maybe event- > driven programming is less appropriate ? (I've not tried it yet, so > maybe I shouldn't judge). > > Cheers, Andy > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the word '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]
