Sorry, I can't give you a reference. It is something I first learned from an Oracle consultant back in '87 and have since embraced and extended to many different environments - including Perl. That said, most 4GL tools worthy of the label implement this idiom. Think PowerBuilder, et al.
Another way to look at it is "data dictionary driven development". If, in your data model, you have enumerated types, then it makes sense to provide flexibility in defining the value domain of those types. Moreover, just as we have UI tools for currency, numeric, date and time values, it makes sense to support enumerated types as well. Nothing dramatic here. Naive implementations of enumerated types tend to give each domain its own unique table and database constraints, model and view classes, etc., etc. This is just overkill. By stepping up one level of metadata, you can treat enumerated types in a much more general way. Of course, as usual, Uri is right. There is no magic bullet for hiding complexity. But that isn't really what this technique is about. Rather, by simply dealing with enumerated types as such, it reduces the complexity without making the code look like an interpreter. At 09:55 AM 4/4/2006 -0400, Tolkin, Steve wrote: >Thank you Charlie. That is the idea I am trying to get across. Do you >have any suggestions about how to get developers to see the benefits of >writing programs this way? Any specific books, techniques, etc.? Any >pitfalls to be aware of? > >Thanks, >Steve > > >-----Original Message----- >From: Charlie Reitzel >Sent: Tuesday, April 04, 2006 9:18 AM >Subject: Re: Put similarities in code and differences in data > > >Not really. I believe it is intended to mean "data driven programming" >as Jeremy mentioned earlier. To me, data driven programming means "use >lotsa lookup tables, the contents of which are user tweakable". As simple as >it sounds, it can be an effective technique to let you quickly adapt a >system as requirements "evolve" - without code changes. > >Having found this hammer early in my programming career, I find a great >many nails. Early days in any new design are spent setting up a "lookup > >table" table, along with utility routines for reporting, validation, UI >picking values (one or several), etc. > >It may be a use case, but I don't think this is quite the same thing as >the subject of this thread which, as Uri says, is a general approach to >analysis. > >At 09:00 AM 4/4/2006 -0400, [EMAIL PROTECTED] wrote: > >( 06.04.04 08:46 -0400 ) Tolkin, Steve: > > > The difference is that I am trying to find a quote that > > > focuses on the benefits of using data in a special way, > > > as "control data", to determine > > > the specific execution path taken by the code. > > > >um, isn't this the scientific method? _______________________________________________ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
