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 --- "Barney Boisvert" <[EMAIL PROTECTED]> wrote: > PREFACE: This isn't a personal attack on you, Andy. If it sounds that way, > it's because of the impersonal communication mechanism, not my intentions. > To paraphrase, "fu**in' email". > > Using objects doesn't mean you're doing OO programming. I can take a > vanilla FB application, convert each circuit's fuses to methods of > per-circuit CFCs, and then write a CFC that encapsulates the switch file and > have a perfectly functional app with no non-CFC files in it. However, it's > just as procedural as the original FB app. There's no way to say which > version will be better, but I suspect the vanilla FB one will be simpler, > which gives it a significant edge. > > A good way to look at it, in my opinion, is to ask yourself if you can take > a request, and determine exactly what'll happen to process that request. If > you can, you've got a procedural application. If you can't, it very likely > uses event-driven and implicit-invocation mechanisms to do its thing, which > usually implies an OO design. > > That's still not quite an accurate way to measure an application, but it's > far better than "am I using objects/CFCs", which is what a lot of people > look at as the determining factor of an OO app. > > To close this out, there is nothing wrong with procedural coding. I still > do a lot of it, more than I do OO coding. The reason is that it's generally > simpler, it's faster to develop, and it doesn't take the amount of > preplanning that an OO app does. For larger systems the encapsulation and > abstraction that OO can provide becomes very important, and the procedural > benefits are lessened. And as a final point, you can get very good > encapsulation and abstraction with non-OO techniques (though most will say > OO makes applying them easier), and that's really the holy grail, not what > technique you use to achieve it. > > barneyb > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Behalf Of cf_nut > > Sent: Tuesday, October 07, 2003 10:32 AM > > To: [EMAIL PROTECTED] > > Subject: Re: [CFCDev] Data validation > > > > > > We're using an adapted version of FuseBuilder to generate our data > > components. Fusebuilder (as downloaded) generates useful qry_ > > fusefiles from a SQL Server DB. We adapted it to generate data > > components based on a PostgreSQL DB. I think Barry (who did all the > > work on this) plans to put something up on redev.org about this in > > the next few days. > > > > The reason for having save and validate as separate functions is > > related to our procedural (vs event driven) presentation layer, I > > think. If you have validate() implicitly invoked by store() then > > presumably if validation fails, then validate(), and store() too, > > must throw exceptions and these must be caught by the caller, the > > presentation layer. I guess I've got a procedural mindset, as I've > > said before, it seems cleaner to me to say "Am I going to take the > > store fork, or the show error fork" rather than "I'll take the store > > fork ... whoops, (exception occurred) turns out I'm in the wrong > > place". > > > > As you say, an interesting discussion. It's certainly highlighted > > aspects of my thinking that I hadn't been aware of before. I've got > > a background in procedural languages, and I'm sold on OO, so I guess > > my outlook is procedural-OO, whereas yours seems to be event- driven- > > OO. I find it interesting that some people regard event-driven > > programming as something you must do when you go for an OO language, > > whereas to me event-driven programming is a separate concept. I'm > > now looking for an opportunity to apply event-driven principles > > (Mach-II probably) to an application :-) > > > > Does procedural-OO make sense as a concept ? I've got a suspicion I > > may get a lot of flak for this :-) > > > > 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] ---------------------------------------------------------- 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]
