Just one last little thing, Peter, so that there is no misunderstanding. It is absolutely critical in the Strategy Pattern that we deal with a Java Bean. A great proportion of the fruits of the Strategy Pattern rely on that so that if your "metamophasis" does not retain this feature, it is not a true metamorphasis.
On 5/31/05, Pilgrim, Peter <[EMAIL PROTECTED]> wrote: > > -----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] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
