Responses are following <snippets> of your remarks, Frank. <snip> Anyone can quote chapter and verse from the GoF book. Can you instead explain *why* what's in Struts isn't CoR? </snip>
I assumed you had looked at the code, and in case you had not, encouraged you to do so and even indicated where the problem was by telling you there were "Iterations". <snip> And, perhaps more importantly, explain why, even if it isn't an exact match for the pattern, it matters one bit? </snip> If you think that there are "exact" and "inexact" "matches" for patterns, as if this were something like a pattern for making a dress, then I don't have much to say. Patterns don't work like that in software development. <snip> Would you deny that that the flexibility of the chain approach, regardless of it's "correctness" as far as pattern implementation goes, doesn't make Struts better? THAT is what I care about, and likely most other developers would care about. </snip> I in fact said it was flexible. So are POJOs. If you don't care if it is CoR or not and want to call it "CoR" whether it is or not, go ahead. I cannot say I would trust a developer much who used basic pattern names wrong. But, if you are comfortable not understanding what you say or what you are talking about, you and your "other developer[]" friends can have at it. I work and live in development communities and we damn sure do care about being precise and knowing what we talk about. <snip> I'm not writing my thesis on why or why not Struts implements this pattern or that pattern as advertised, I'm interested in whether it makes my life better, and I for one am convinced the chain approach does. If you disagree, that's fine, I would like to hear why, but with specifics, not by quoting a theoretical abstraction. </snip> If you have decided that the GoF book is a "theoretical abstraction", then you and I probably have very little to discuss. If you don't care if it is CoR or not, I have no idea why you responded to the note that it is not, which it is not. If you think understanding and employing design patterns in a wise way is an academic "thesis" matter, then you are running in a very different development crowd than I am. If you said anything like that where I work, they would be shocked. We don't write theses around here. We write code. Good code and we know what patterns we are using. Actually, the reason Struts has to be tossed is just because it is a mess in regard to the flexibility and the use of deep level design patterns. Maybe it is easy to use, but so are lots of bad ideas. Had Struts used a Strategy pattern instead of whatever that is that they have now, it might have had a chance to use AOP, and other cook features that this code won't help. It is easy to code, that is true. It is flexible as hell in the sense that anyone with any sense can code it and it is easy to change in the concrete classes. There are much deeper problems which it not only does not address but exascerbates. Why don't you look at the code and see where there is iteration? I don't think I should have to go to the code and show you. If you insist you don't want to even look at the code and still defend it, then that's your perogative. -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack
