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]
