> -----Original Message----- > From: Dakota Jack [mailto:[EMAIL PROTECTED] ==////== > > > I should have added that Rod (Johnson) in the book cited pointedly > advocates extensive use of the Strategy Pattern, see pp. 421 ff. The > use of CoR in Struts 1.3 for the extensible RequestProcessor is not a > feature but is a way of solving the problem created by the original > use of the Template Method Pattern in that context. Had the Strategy > Pattern been used in the first instance, everything would have worked > better, in my opinion. In many ways, I think in the future the > Template Method Pattern may be seen as an Anti-Pattern. > > Just to forestall flamethrowers, I want to emphasize that others > probably think differently and even the "majority", i.e. by definition > the members ipsa facto of the "meritocracy", may think differently. > But, Rod Johnson is no slouch on these matters. He thinks the use of > Strategy Pattern is "one of the reasons [Spring] is such a flexible > and extensible framework". >
Hello Jack It can be shown that ``Chain of Responsibility'' pattern can be metamorphed into the ``Strategy'' pattern. The first proviso is that one of your commnds becomes a catalogy factory or invoker of other generic commands itself. The second proviso is you must pass all your information back and forward the ``strategy command'' using a general context object. fyi > On 5/27/05, David Whipple <[EMAIL PROTECTED]> wrote: > > This is an off topic post, but there seem to be a lot of > people with good > > opinions here. > > > > I am trying to provide a framework (based on Stuts and > Spring) for our > > company > > to use. I'd like to make a reinforcement of the business layer in > > applications. > > > > We do not use EJBs, so a lot of the patterns that are out > there do not seem > > to > > apply. I have not been able to find any references I like. > > > > The goal is to encourage better program design and development by > > having a clear definition of what are the business objects > in the program. > > > > We want to come up with a way through patterns to help > programmers avoid > > poor > > programming practices. Clear separation into layers is one > basic idea > > behind > > this. We want to come up with some interface to the > business layer which > > will > > force programmers to know what are to be the business > objects in their > > architecture. > > > > Does anyone have any ideas and/or know of any references for this? > > > > Thanks, > > Dave ==////== -- Peter Pilgrim Operations/IT - Credit Suisse First Boston, Floor 15, 5 Canada Square, London E14 4QJ, United Kingdom Tel: +44-(0)207-883-4497 ============================================================================== This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, Credit Suisse, its subsidiaries and affiliates (CS) do not waive any confidentiality or privilege. CS retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CS until they are confirmed by us. Message transmission is not guaranteed to be secure. ============================================================================== --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
