RE: [CFCDev] method variations

[Nathan Dintenfass]

I'm not sure this is really an OO question, per se -- it's more a general code design issue, from what I can see.  I'll leave any OO-specific comments to the OO experts on the list, but more generally, it seems to me that when designing your API you should think about what's going to be most productive for the end-developer (Even that person is you).   So, in that framework, your API seems quite cumbersome.  I don't think you need to write methods to "cater for every possibility" -- we do have arguments, after all, but you should also make things as intuitive/simple as they can be while still providing the functionality you desire. I also don't like the metaphor of a "WHERE CLAUSE" as part of my API because I like to think that the SQL itself is an implementation detail, not an interface consideration.   To give input on your specific question, I think it depends on how known the potential scenarios are.  For instance, if there are really only 3 kinds of filters (where clauses) you might apply when calling "getAttendList" then it makes a lot of sense to just make 3 methods that reflect those 3 scenarios and have each call the private method, as you suggest.  That way, you get very descriptive semantics, documented for free, just by adding a few lines of code to your CFC.  For instance, "getAcceptedAttendees" instead of just "getAttendees" with the esoteric filter applied (even if, behind the scenes, you end up calling getAttendees anyway).  If, on the other hand, there are a very large number of filters and/or a large number of permutations of filters, then there's probably nothing wrong with a generic method that accepts the filter as an argument.  Personally, I opt for descriptive semantics for my methods whenever possible.   That said, you might consider a cleaner way to implement the filter than the array of structures.  For instance, in your example, you might consider making another CFC called QueryFilter, or something like that --- it can have methods to add your "where" clauses and can then be passed as a whole into your other method.  That way you get free documentation of a queryFilter (Whereas your "aWhereClause" array is totally opaque to anyone who doesn't either have sample code written by you or looks inside the CFC) and your code will be cleaner. You can also then reuse your QueryFilter for other methods in other CFCs, and if you need to change the implementation details at some point down the road you'll be much safer.   HTH.         -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Barry Beattie Sent: Wednesday, May 26, 2004 4:58 PM To: [EMAIL PROTECTED] Subject: [CFCDev] method variations hi all   not everything here is following a nice OO approach. we’ve got some CFC’s that are just query wrappers. they take in a struct of arrays to build the select fields and WHERE clause and return a query. While I’ve only inherited this method here, it’s similar to what I used to do in ASP (classic) – I can see the value in decoupling this way.   <cfif isDefined("FORM.accept_flg")><!--- accepted = "Y" checkbox on FORM --->             <CFSET aWhereClause[3] = StructNew()>             <CFSET aWhereClause[3].field = "r2.accept_flg">             <CFSET aWhereClause[3].value = "#FORM.accept_flg#"> </cfif>     <CFSET get_donors = eventObj.getAttendList(APPLICATION.dsnInfo,VARIABLES.selectFields,aWhereClause,FORM.sortBy)>   and in the CFC:       <cfquery name="getAttendList" …>       SELECT #selectList#               FROM donor AS r1, donevent AS r2               #whereClause#               AND r1.donor_num = r2.donor_num               #andClause#       can such variations of calls to CFC functions fit in to OO design? or should multiple methods be written to cater for every possibility, each one a wrapper to the same private query method (passing whatever has been sent)?   feel free to throw up your 2c worth. cheers barry.b   PS: please ignore the potential security hole in directly sending form data as CFC method arguments. They just need some take-up time to see the light…