Whenever there are conditional choices between classes, as with those implementing Comparator, shouldn't we favor polymophism as an OOP solution rather than some procedural solution?
Last word unless requested otherwise on this: just trying to be helpful. The five options below are all procedural except the first one. Why use procedural logic in an OOP setting? On Sun, 20 Feb 2005 10:26:14 -0800, Don Brown <[EMAIL PROTECTED]> wrote: > Ah, we finally stumble onto the very slipperly slope that is conditional > support for commons-chain. As we put more and more code into chain, we > will inevitably have commands that only need to execute under certain > conditions. There are three possibilities: <SNIP CHOICE='1 OOP-POLYMORPHISM'> Use polymorphism and the basic benefits of OOP with a Strategy pattern </SNIP> <SNIP CHOICE='2 PROCEDURAL-LOGIC IN COMMAND'> <snip choice='procedural-logic-inside-command'> 1. Bury conditional logic inside the command itself. This is the > approach many of the current chains take, but has the disadvantage of > the flow being very unclear to the reader of the config file, requiring > digging into the source code. </SNIP> <SNIP CHOICE='3 PROCEDURAL-LOGIC IN NEW COMMANDS> > 2. Create an "if" command, which then would logically lead to a > "switch" command and perhaps a "for" command. These commands would > check certain conditions then execute configured commands based on the > outcome. </SNIP> <SNIP CHOICE='4 PROCEDURAL-LOGIC IN XML'> <snip choice='procedural-logic-in-xml'> 3. Modify the XML so that the branching code is described as XML > elements. While this option produces the clearest code, it also brings > all the problems of something like Jelly with it. </SNIP> <SNIP CHOICE='5 PROCEDURAL-LOGIC IN GUI> I wonder what a merging of commons-chain and a scripting language like > beanshell would look like... </SNIP> -- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
