Execute Bound Procedures Dynamically

[MCWebsite.Staff]

** This thread discusses the article: Execute Bound Procedures Dynamically **
** This thread discusses the Content article: Execute Bound Procedures Dynamically **
0

[Guest.Visitor]

Execute Bound Procedures Dynamically

** This thread discusses the article: Execute Bound Procedures Dynamically **
just make getnozzle a subroutine, that looks at the state in a select statement then calls the appropriate subroutine, or procedure to get the correct result. Thats all you are really doing anyway. your just making the call to the other procedure more complicated. You still have the select statement, you still have the one subroutine that calls another subroutine conditionally, and you still have a procedure for each state. While i salute your attempt at simplification, your making it more complex, not simpler.

[dmjae2004@yahoo.com]

Execute Bound Procedures Dynamically

** This thread discusses the article: Execute Bound Procedures Dynamically **
I agree this looks to be an overly complicated approach with potential overheads of long term maintenance. A simple wrapper procedure getnozzle(GeographyID,Nozzle.Spread) could do the select would hide all the complexity from the main program. It would also enable introduction of different geographic levels without a need to maintain the main program (e.g. rules at County levels or Regional levels). Also the orginal proposed aproach appears to be limited by an assumption that paramters are identical for all manifestations of the getnozzle procedure (states). This could be handled more gracefully within the wrapper procedure.

[pbhall@ameritech.net]

Execute Bound Procedures Dynamically

** This thread discusses the article: Execute Bound Procedures Dynamically **
While, it's true that a select could do the trick, the concept is that the function is a black box, which produces a standard object, containing parts that might be different, depending on the trading partner. Having in-line logic handle conditional requirements would require looking at the special code for all of the other trading partners each time a change was made, and ensuring that each still works when the change is done. I suppose it goes without saying, but there's more than one function that's unique by trading partner, and some trading partners don't require some functions at all. The need to isolate special requirements from the process flow logic, was extreme in this case (it's a real application.) That's why I opted for the additional setup work. My experience so far has been that the concept seems valid. It really has isolated the special processing from the process flow, and the isolation provided by separate special processing functions makes problem resolution and testing much easier. So far, the main problem has been locating the correct function. To date, that hasn't been too serious, but the jury may be out on the issue for a few years. The ability of partner-specific functions to call the standard base function has been especially handy. It's almost as good as real class inheritance.