> As I've thought more about the package, I don't understand why some > design decisions were made. First let me say that I think of Chains > as being an OO way to simulate procedural logic. Many of my comments > will basically be concerning why some of the standard control flow > abilities (if/then statements, loops, exception handling, etc) in Java > aren't more easily done/simulated using the Chain package.
Have you reviewed the pattern descriptions for Chain of Responsibility, Composite, and Command from the Design Patterns book? I believe the scope of this package is provide a flexible, concrete implementation of these patterns. The alternatives you mentioned are certainly doable, but don't seem to be in line with the patterns this package is meant to realize.
As for the second point, it's certainly possible that we will see a need for a catchException method, but I'd suggest we put some more use-cases on the table first. Once an extension point is added to the interface it's very difficult to take it back, so it can be better to let usage steer the implementation.
-Ted.
Sgarlata Matt wrote:
The conversation threads are getting kind of crazy, so I'm going to skip inline quotes for parts of this.
Craig, now I do see your point about using the ConfigRuleSet to digest a portion of an arbitrary XML file. That is very cool, and now I understand why the names of the XML elements are configurable. I always understood the value of letting attributes to the <command> element (and other elements). This is a much slicker approach than creating nested <set-property> elements. Still, I think it could be useful to have a DTD for the *default* behavior of the ConfigRuleSet. I think in general users will start off using the default behavior, and then may at a later date decide to fold their commands into some other file, so a DTD will be nice to get people started with the Chain package. I agree with most your points about the constraints I placed in the DTD being inappropriate, and will explicitly address each if we ever decide to make a DTD.
As I've thought more about the package, I don't understand why some design decisions were made. First let me say that I think of Chains as being an OO way to simulate procedural logic. Many of my comments will basically be concerning why some of the standard control flow abilities (if/then statements, loops, exception handling, etc) in Java aren't more easily done/simulated using the Chain package. So, here I go with questions: 1) How come Chains have a static structure? Related to this, how come Command.execute returns boolean instead of returning Command? If it returned Command this would basically eliminate the need for a Chain interface altogether. Chain would become a concrete implementation of Command that repeatedly executed Commands until the last command executed returned null (which would be the new value to indicate the end of a chain). Static chains (such as those configured using an XML file) would easily be supported by another concrete implementation of Command which executed a series of commands in order, completely ignoring their return values. 2) How come Filters have a postprocess method but no catchexception method? The postprocess block can deal with exceptions, but it seems to me like it would be more natural for exceptions to be dealt with in a catchexception block and for postprocess to be strictly for freeing resources that the Command acquired when its execute method was called.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
