You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by "Pilgrim, Peter" <pe...@csfb.com> on 2005/06/01 14:03:15 UTC
RE: [OT] Business Layer Ideas
> -----Original Message-----
> From: Dakota Jack [mailto:dakota.jack@gmail.com]
===////===
>
> Hi, Peter,
>
> I am not sure what you are saying here. I had trouble
> following you.
>
> The Strategy Pattern is roughly the following:
>
> public class DefaultStrategyInterface implements StrategyInterface {
> private Helper helper;
>
> public void setHelper(Helper helper) {
> this.helper = helper;
> }
>
> public void doWork() {
> // Do business logic
> int value = hleper.calculateSomething(params);
> // Do more business logic
> }
> }
>
> The Template Method Pattern used in Struts which necessitates the use
> of the Chain of Responsibility Pattern, cf.
> http://www.onjava.com/pub/a/onjava/2005/03/02/commonchains.html, is
> roughly the following:
>
> public abstract class AbstractMethodInterface implements
> MethodInterface {
> public void doWork() {
> // Do some business logic
> int value = calculateSomething(params);
> // Do more business logic
> }
>
> protected abstract int calculateSomething(params);
> }
>
> So, in a real sense, the Strategy Pattern advocates, in comparison to
> the Template Method Pattern, composition over inheritance allowing for
> ease of testing and a host of other good results.
>
> Struts is based on the Template Method Pattern which Sigglelow rightly
> sees is rescued by the Chain of Responsibility Pattern. This is the
> context in which I was addressing the Strategy Pattern. Can you give
> a little demo of how CoR "metamorphasis's into this? I find your not
> interesting but cannot see what it means.
>
> Thanks
>
Consider a GUI algorithm that displays rows from the database.
The typical problem is to work out the best column width for
rendering the screen.
interface IFormatDatabaseColumnWidth {
public int calcColumnWidth( Object[][] data, MetaData metaData[], int
columnNo );
}
// Slowest and most accurate algorithm iterates all rows in the result set
class AllRowsFDCW implements IFrameDatabaseColumnWidth { ... }
// Algorithm based on the first 100 rows
class First100FDCW implements IFrameDatabaseColumnWidth { ... }
// Algorithm that calculates the column width for every N rows
class StepwiseFDCW implements IFrameDatabaseColumnWidth { ... }
This is the classic strategy pattern, as I remember writing it in a Swing/JDBC
five years ago. (In fact Xenon-SQL is still out there somewhere, but it
is broken against JDK 1.3 and 24/7/365 the time to fix it! )
You can rewrite the above strategy with Chain of Responsibility
pedantically. If you have a very functional requirement for it.
class ChainFDCW implements IFrameDatabaseColumnWidth {
Catalog catalog;
String commandName;
// IoC container friendly
public void setCatalog( catalog ) { ... }
public void setCommandName( name ) { ... }
public int calcColumnWidth( Object[][] data, MetaData metaData[], int
columnNo )
{
Context context = new FDCWContext( data, metaData, columnNo );
Command command = catalog.getCommand( commandName );
command.execute( context );
if ( context.isCalculatedOk() )
return context.getColumnWidth();
else
throw new StrategyRuntimeException(
"Failed to calculate column width" );
}
}
Ok writing a CoR for calculating data width takes a bit of stretching
the imagination, but of course you can do it, which is the point.
> On 5/31/05, Pilgrim, Peter <pe...@csfb.com> wrote:
> > > -----Original Message-----
> > > From: Dakota Jack [mailto:dakota.jack@gmail.com]
> > ==////==
> > >
> > >
> > > 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 <dw...@dtcc.com> 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: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
>
>
> --
> "You can lead a horse to water but you cannot make it float
> on its back."
> ~Dakota Jack~
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Business Layer Ideas
Posted by Martin Gainty <mg...@hotmail.com>.
Dave-
could you give us an example of over-using a weak abstraction ?
Martin-
----- Original Message -----
From: "Dave Newton" <ne...@pingsite.com>
To: "Struts Users Mailing List" <us...@struts.apache.org>
Sent: Wednesday, June 01, 2005 2:19 PM
Subject: Re: [OT] Business Layer Ideas
> Frank W. Zammetti wrote:
>
>>Related to this, patterns are a wonderful invention, but I see day in and
>>day out people trying to find a pattern for every single situation. People
>>seem to think that they have to solve every problem by finding a
>>suitable pattern. The problem is, everyone seems to be so
>>"pattern-gung-ho" nowadays that they simply want to apply a pattern and if
>>it actually makes things more complex, too bad. If it doesn't really fit
>>the problem but does happen to solve it, that's fine too. A pattern
>>mismatch, or a pattern where none was truly needed, is just as bad as no
>>pattern at all in my experience.
>>
> "This practice is not only common, but institutionalized. For example, in
> the OO world you hear a good deal about "patterns". I wonder if these
> patterns are not sometimes evidence of case (c), the human compiler, at
> work. When I see patterns in my programs, I consider it a sign of trouble.
> The shape of a program should reflect only the problem it needs to solve.
> Any other regularity in the code is a sign, to me at least, that I'm using
> abstractions that aren't powerful enough-- often that I'm generating by
> hand the expansions of some macro that I need to write." -- Paul Graham
>
> Dave "No, really, he's not a cult" Newton
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Business Layer Ideas
Posted by Dave Newton <ne...@pingsite.com>.
Frank W. Zammetti wrote:
>Related to this, patterns are a wonderful invention, but I see day in and
>day out people trying to find a pattern for every single situation.
>People seem to think that they have to solve every problem by finding a
>suitable pattern. The problem is, everyone seems to be so
>"pattern-gung-ho" nowadays that they simply want to apply a pattern and if
>it actually makes things more complex, too bad. If it doesn't really fit
>the problem but does happen to solve it, that's fine too. A pattern
>mismatch, or a pattern where none was truly needed, is just as bad as no
>pattern at all in my experience.
>
>
"This practice is not only common, but institutionalized. For example,
in the OO world you hear a good deal about "patterns". I wonder if these
patterns are not sometimes evidence of case (c), the human compiler, at
work. When I see patterns in my programs, I consider it a sign of
trouble. The shape of a program should reflect only the problem it needs
to solve. Any other regularity in the code is a sign, to me at least,
that I'm using abstractions that aren't powerful enough-- often that I'm
generating by hand the expansions of some macro that I need to write."
-- Paul Graham
Dave "No, really, he's not a cult" Newton
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Business Layer Ideas
Posted by Simon Chappell <si...@gmail.com>.
Good stuff Frank. Your point is a good one and well made.
I just spoke at a Java User Group here in Wisconsin on a similar
issue, about how most people don't need to improve their Java
programming skills, rather they need to improve their programming
skills!
I think that pattern use falls in the same area. There are folks that
use patterns religiously, thinking that they're being good
programmers. All the while not realising that they're reducing
themselves down to the level of a coding monkey.
Too much of the Java code that I see is not object-oriented, it's
object-obsessed. Objects defined for any small silly thing. Wrappers
upon wrappers, calls to super in multiple levels of inheritance.
Arrgh. It's like trying to follow the plot of one of Frank Herbert's
Dune novels. (Good for novels, bad for programs though!)
Simon
On 6/1/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
> On Wed, June 1, 2005 9:47 am, Dakota Jack said:
> > This is what our
> > fellow traveler Frank Zammettie finds inherently suspicious about the
> > *OOP nuts*.
>
> Woah, leave me out of this. I've purposely stayed away from this thread
> all this time, now I have to get in...
>
> I don't want anyone thinking I'm anti-OOP or anything remotely like that.
> I am very much an OOP proponent. While I almost certainly have used the
> term "OOP nuts" at some point because I think some people could probably
> be described that way, that really sounds a lot more harsh than my opinion
> actually is, so let me clarify...
>
> What I have said is that I have seen many instances where people take the
> OOP exercise so far in trying to get a perfect architectural structure in
> place that they wind up writing code that is actually harder to understand
> than it otherwise could be. There is great benefit to writing code that
> is composed of smaller, largely interchangeable pieces rather than large
> monolithic pieces. We all know this. However, I have seen this taken so
> far that it takes forever to grasp how all the pieces fit together to form
> the larger whole, and this is just as bad as writing one larger whole
> would have been.
>
> Related to this, patterns are a wonderful invention, but I see day in and
> day out people trying to find a pattern for every single situation.
> People seem to think that they have to solve every problem by finding a
> suitable pattern. The problem is, everyone seems to be so
> "pattern-gung-ho" nowadays that they simply want to apply a pattern and if
> it actually makes things more complex, too bad. If it doesn't really fit
> the problem but does happen to solve it, that's fine too. A pattern
> mismatch, or a pattern where none was truly needed, is just as bad as no
> pattern at all in my experience.
>
> Simplicity is a beautiful thing. That is always my underlying design goal
> for two reasons...
>
> One, in a corporate environment as I work in, you never know when someone
> else is going to have to come along and maintain your code. You aren't
> doing them any favors by writing code that, while architecturally sound,
> is more complex to grasp. If after three months they say "wow, this guy
> architected this code perfectly!", that's great, but if those three months
> are spent not being especially productive while they try and understand
> what you built, then the code wasn't well-written in the end.
>
> Two, when you jump around between many different projects, you tend to
> forget your own work quickly. I sometimes look at code I wrote just last
> year and go "I don't remember how or why I did this". Fortunately I
> comment the hell out of everything I do, but more importantly I try to
> code in straight-forward ways. Sometimes that means *NOT* creating that
> helper class to encapsulate 10 lines of code, even though that might
> architecturally be better and fit some pattern, but instead just inline it
> (assuming I don't expect it to be shared of course).
>
> In a nuthshell, my point is absolutely *USE* OOP and patterns, and other
> related techniques, think in those ways all the time, but don't
> over-engineer things!! Don't make design decisions because you CAN do
> something, make them because it is the RIGHT thing to do. And don't
> over-complicate things for the sake of achieving some theoretical design
> utopia. Make your code easy to understand, even if sometimes at the cost
> of design trade-offs. Naturally there is a balance to be struck...
> architecture *IS* after all important!
>
> Frank
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Business Layer Ideas
Posted by gd...@cmhc-schl.gc.ca.
I have these 2 phrases posted in my office as a reminder...
" Simplicity is the ultimate sophistication " - Leonardo da Vinci
" The ability to simplify means to eliminate the unnecessary so that the
necessary may speak" - Hans Hofmann
- Glenn
Leon Rosenberg <st...@anotheria.net>
01/06/2005 11:42 AM
Please respond to
"Struts Users Mailing List" <us...@struts.apache.org>
To
Struts Users Mailing List <us...@struts.apache.org>
cc
Subject
Re: [OT] Business Layer Ideas
On Wed, 2005-06-01 at 10:31 -0400, Frank W. Zammetti wrote:
> ...
> Simplicity is a beautiful thing. That is always my underlying design
goal
> for two reasons...
Now this is really a perfect statement on architectures!
Thanx Frank
Leon.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Business Layer Ideas
Posted by Leon Rosenberg <st...@anotheria.net>.
On Wed, 2005-06-01 at 10:31 -0400, Frank W. Zammetti wrote:
> ...
> Simplicity is a beautiful thing. That is always my underlying design goal
> for two reasons...
Now this is really a perfect statement on architectures!
Thanx Frank
Leon.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Business Layer Ideas
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Not a problem. Just didn't want anyone else to get the wrong impression.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Wed, June 1, 2005 10:35 am, Dakota Jack said:
> Sorry, Frank. I did not mean to misrepresent you in any way but
> merely to use a jocular reference out of good nature. I know you are
> into OOP.
>
> On 6/1/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
>> On Wed, June 1, 2005 9:47 am, Dakota Jack said:
>> > This is what our
>> > fellow traveler Frank Zammettie finds inherently suspicious about the
>> > *OOP nuts*.
>>
>> Woah, leave me out of this. I've purposely stayed away from this thread
>> all this time, now I have to get in...
>>
>> I don't want anyone thinking I'm anti-OOP or anything remotely like
>> that.
>> I am very much an OOP proponent. While I almost certainly have used the
>> term "OOP nuts" at some point because I think some people could probably
>> be described that way, that really sounds a lot more harsh than my
>> opinion
>> actually is, so let me clarify...
>>
>> What I have said is that I have seen many instances where people take
>> the
>> OOP exercise so far in trying to get a perfect architectural structure
>> in
>> place that they wind up writing code that is actually harder to
>> understand
>> than it otherwise could be. There is great benefit to writing code that
>> is composed of smaller, largely interchangeable pieces rather than large
>> monolithic pieces. We all know this. However, I have seen this taken
>> so
>> far that it takes forever to grasp how all the pieces fit together to
>> form
>> the larger whole, and this is just as bad as writing one larger whole
>> would have been.
>>
>> Related to this, patterns are a wonderful invention, but I see day in
>> and
>> day out people trying to find a pattern for every single situation.
>> People seem to think that they have to solve every problem by finding a
>> suitable pattern. The problem is, everyone seems to be so
>> "pattern-gung-ho" nowadays that they simply want to apply a pattern and
>> if
>> it actually makes things more complex, too bad. If it doesn't really
>> fit
>> the problem but does happen to solve it, that's fine too. A pattern
>> mismatch, or a pattern where none was truly needed, is just as bad as no
>> pattern at all in my experience.
>>
>> Simplicity is a beautiful thing. That is always my underlying design
>> goal
>> for two reasons...
>>
>> One, in a corporate environment as I work in, you never know when
>> someone
>> else is going to have to come along and maintain your code. You aren't
>> doing them any favors by writing code that, while architecturally sound,
>> is more complex to grasp. If after three months they say "wow, this guy
>> architected this code perfectly!", that's great, but if those three
>> months
>> are spent not being especially productive while they try and understand
>> what you built, then the code wasn't well-written in the end.
>>
>> Two, when you jump around between many different projects, you tend to
>> forget your own work quickly. I sometimes look at code I wrote just
>> last
>> year and go "I don't remember how or why I did this". Fortunately I
>> comment the hell out of everything I do, but more importantly I try to
>> code in straight-forward ways. Sometimes that means *NOT* creating that
>> helper class to encapsulate 10 lines of code, even though that might
>> architecturally be better and fit some pattern, but instead just inline
>> it
>> (assuming I don't expect it to be shared of course).
>>
>> In a nuthshell, my point is absolutely *USE* OOP and patterns, and other
>> related techniques, think in those ways all the time, but don't
>> over-engineer things!! Don't make design decisions because you CAN do
>> something, make them because it is the RIGHT thing to do. And don't
>> over-complicate things for the sake of achieving some theoretical design
>> utopia. Make your code easy to understand, even if sometimes at the
>> cost
>> of design trade-offs. Naturally there is a balance to be struck...
>> architecture *IS* after all important!
>>
>> Frank
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
>
> --
> "You can lead a horse to water but you cannot make it float on its back."
> ~Dakota Jack~
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Business Layer Ideas
Posted by Dakota Jack <da...@gmail.com>.
Sorry, Frank. I did not mean to misrepresent you in any way but
merely to use a jocular reference out of good nature. I know you are
into OOP.
On 6/1/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
> On Wed, June 1, 2005 9:47 am, Dakota Jack said:
> > This is what our
> > fellow traveler Frank Zammettie finds inherently suspicious about the
> > *OOP nuts*.
>
> Woah, leave me out of this. I've purposely stayed away from this thread
> all this time, now I have to get in...
>
> I don't want anyone thinking I'm anti-OOP or anything remotely like that.
> I am very much an OOP proponent. While I almost certainly have used the
> term "OOP nuts" at some point because I think some people could probably
> be described that way, that really sounds a lot more harsh than my opinion
> actually is, so let me clarify...
>
> What I have said is that I have seen many instances where people take the
> OOP exercise so far in trying to get a perfect architectural structure in
> place that they wind up writing code that is actually harder to understand
> than it otherwise could be. There is great benefit to writing code that
> is composed of smaller, largely interchangeable pieces rather than large
> monolithic pieces. We all know this. However, I have seen this taken so
> far that it takes forever to grasp how all the pieces fit together to form
> the larger whole, and this is just as bad as writing one larger whole
> would have been.
>
> Related to this, patterns are a wonderful invention, but I see day in and
> day out people trying to find a pattern for every single situation.
> People seem to think that they have to solve every problem by finding a
> suitable pattern. The problem is, everyone seems to be so
> "pattern-gung-ho" nowadays that they simply want to apply a pattern and if
> it actually makes things more complex, too bad. If it doesn't really fit
> the problem but does happen to solve it, that's fine too. A pattern
> mismatch, or a pattern where none was truly needed, is just as bad as no
> pattern at all in my experience.
>
> Simplicity is a beautiful thing. That is always my underlying design goal
> for two reasons...
>
> One, in a corporate environment as I work in, you never know when someone
> else is going to have to come along and maintain your code. You aren't
> doing them any favors by writing code that, while architecturally sound,
> is more complex to grasp. If after three months they say "wow, this guy
> architected this code perfectly!", that's great, but if those three months
> are spent not being especially productive while they try and understand
> what you built, then the code wasn't well-written in the end.
>
> Two, when you jump around between many different projects, you tend to
> forget your own work quickly. I sometimes look at code I wrote just last
> year and go "I don't remember how or why I did this". Fortunately I
> comment the hell out of everything I do, but more importantly I try to
> code in straight-forward ways. Sometimes that means *NOT* creating that
> helper class to encapsulate 10 lines of code, even though that might
> architecturally be better and fit some pattern, but instead just inline it
> (assuming I don't expect it to be shared of course).
>
> In a nuthshell, my point is absolutely *USE* OOP and patterns, and other
> related techniques, think in those ways all the time, but don't
> over-engineer things!! Don't make design decisions because you CAN do
> something, make them because it is the RIGHT thing to do. And don't
> over-complicate things for the sake of achieving some theoretical design
> utopia. Make your code easy to understand, even if sometimes at the cost
> of design trade-offs. Naturally there is a balance to be struck...
> architecture *IS* after all important!
>
> Frank
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Business Layer Ideas
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
On Wed, June 1, 2005 9:47 am, Dakota Jack said:
> This is what our
> fellow traveler Frank Zammettie finds inherently suspicious about the
> *OOP nuts*.
Woah, leave me out of this. I've purposely stayed away from this thread
all this time, now I have to get in...
I don't want anyone thinking I'm anti-OOP or anything remotely like that.
I am very much an OOP proponent. While I almost certainly have used the
term "OOP nuts" at some point because I think some people could probably
be described that way, that really sounds a lot more harsh than my opinion
actually is, so let me clarify...
What I have said is that I have seen many instances where people take the
OOP exercise so far in trying to get a perfect architectural structure in
place that they wind up writing code that is actually harder to understand
than it otherwise could be. There is great benefit to writing code that
is composed of smaller, largely interchangeable pieces rather than large
monolithic pieces. We all know this. However, I have seen this taken so
far that it takes forever to grasp how all the pieces fit together to form
the larger whole, and this is just as bad as writing one larger whole
would have been.
Related to this, patterns are a wonderful invention, but I see day in and
day out people trying to find a pattern for every single situation.
People seem to think that they have to solve every problem by finding a
suitable pattern. The problem is, everyone seems to be so
"pattern-gung-ho" nowadays that they simply want to apply a pattern and if
it actually makes things more complex, too bad. If it doesn't really fit
the problem but does happen to solve it, that's fine too. A pattern
mismatch, or a pattern where none was truly needed, is just as bad as no
pattern at all in my experience.
Simplicity is a beautiful thing. That is always my underlying design goal
for two reasons...
One, in a corporate environment as I work in, you never know when someone
else is going to have to come along and maintain your code. You aren't
doing them any favors by writing code that, while architecturally sound,
is more complex to grasp. If after three months they say "wow, this guy
architected this code perfectly!", that's great, but if those three months
are spent not being especially productive while they try and understand
what you built, then the code wasn't well-written in the end.
Two, when you jump around between many different projects, you tend to
forget your own work quickly. I sometimes look at code I wrote just last
year and go "I don't remember how or why I did this". Fortunately I
comment the hell out of everything I do, but more importantly I try to
code in straight-forward ways. Sometimes that means *NOT* creating that
helper class to encapsulate 10 lines of code, even though that might
architecturally be better and fit some pattern, but instead just inline it
(assuming I don't expect it to be shared of course).
In a nuthshell, my point is absolutely *USE* OOP and patterns, and other
related techniques, think in those ways all the time, but don't
over-engineer things!! Don't make design decisions because you CAN do
something, make them because it is the RIGHT thing to do. And don't
over-complicate things for the sake of achieving some theoretical design
utopia. Make your code easy to understand, even if sometimes at the cost
of design trade-offs. Naturally there is a balance to be struck...
architecture *IS* after all important!
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Business Layer Ideas
Posted by Dakota Jack <da...@gmail.com>.
Thanks, Peter,
This reply is in three parts: Oops, Ugh and GoF.
FIRST PART: Oops!
I am afraid there is a fatal flaw in your reasoning. Your example of
the Strategy Pattern is *not* the Strategy Pattern. It is merely two
differing implmentations of an interface. The Strategy Pattern is a
client based pattern. As the Gang of Four (GoF) in "Design Patterns:
Elements of Reusable Object-Oriented Software" said on the inside of
the cover:
"Strategy (315) Define a family of algorithms encapsulate each
one, and make them
interchangeable. Strategy lets the algorithm vary independently
from clients that use
it."
So, your point about the Strategy Pattern, of course, does not work
and is a non-starter.
A Strategy Pattern most importantly introduces some Helper utility
interface for the various implementations of an algorithm. Thus, you
could have either
A.
interface IFormatDatabaseColumnWidth {
public void setHelper(Helper helper);
public void doWork();
}
or
B.
Inteface IFormatDatabaseColumnWidth {
public void doWork();
}
But the implementations would have to be something like:
public class IFormatDatabaseColumnWidthImpl {
private Helper helper;
public void setHelper(Helper helper) {
this.helper = helper;
}
public void doWork() {
// Do business logic
int value = helper.calcColumnWidth(data,metaData[]),columnNo);
// Do more business logic
}
}
Thus, there would be a Helper interface:
interface Helper {
int calcColumnWidth(Object [][] data, MetaData metaData[]) int columnNo);
}
The differing calculations, then, would go into the Helper interface
implementations and not into the IFormatDatabaseColumnWidth interface
implementations. So, you might have
public class AllRowsFDCW implements Helper {
public int calcColumnWidth(Object [][] data, MetaData metaData[])
int columnNo) {
// Slowest and most accurate algorithm iterates all rows in
the result set
}
}
and
public class First100FDCW implements Helper {
public int calcColumnWidth(Object [][] data, MetaData metaData[])
int columnNo) {
// Algorithm based on the first 100 rows
}
}
and
public class class StepwiseFDCW implements Helper {
public int calcColumnWidth(Object [][] data, MetaData metaData[])
int columnNo) {
// Algorithm that calculates the column width for every N rows
}
}
Please note that the pattern essentially uses polymorphism and late
binding not through implementations of an interface but through a
composite pattern.
Thus, when inversion of control (IoC) is used with the Strategy
Pattern, whether you are doing Dependency Injection (DI) or Dependency
Lookup (DL), the Helper is what is the subject of the lookup or
injection. (IoC, including DL, cannot be identified as DI merely.)
Your explanation of the Strategy Pattern leaves out what is essential
to the pattern. Consequently, your explanation is merely how Chain of
Responsibiltiy (CoR) can be used instead of differing implementations
of an interface. See below for a short note on your CoR example.
On 6/1/05, Pilgrim, Peter <pe...@csfb.com> wrote:
> Consider a GUI algorithm that displays rows from the database.
> The typical problem is to work out the best column width for
> rendering the screen.
>
> interface IFormatDatabaseColumnWidth {
> public int calcColumnWidth( Object[][] data, MetaData metaData[], int
> columnNo );
> }
>
> // Slowest and most accurate algorithm iterates all rows in the result set
> class AllRowsFDCW implements IFrameDatabaseColumnWidth { ... }
> // Algorithm based on the first 100 rows
> class First100FDCW implements IFrameDatabaseColumnWidth { ... }
> // Algorithm that calculates the column width for every N rows
> class StepwiseFDCW implements IFrameDatabaseColumnWidth { ... }
>
> This is the classic strategy pattern, as I remember writing it in a Swing/JDBC
> five years ago. (In fact Xenon-SQL is still out there somewhere, but it
> is broken against JDK 1.3 and 24/7/365 the time to fix it! )
SECOND PART: Ugh!
In my opinion, by the way, as an aside, using the CoR to replace mere
implementations of an interface would be rather *nuts*. This would
merely obfuscate and provide no benefit at all. This is what our
fellow traveler Frank Zammettie finds inherently suspicious about the
*OOP nuts*. This is, I am afraid, similar to some of the rather *knee
jerk* uses of CoR floating around. How does that old saw go? A boy
with a new hammer sees the whole world as a nail?
THIRD PART: GoF
The GoF used as their signal example a Composition class which
traversed and repaired (traverse(), repair()) and, much like your
algorithms with result sets, employed a field utility class Compositor
with the method compose() to implement various linebreaking strategies
(SimpleCompositor, TeXCompositor, and ArrayCompositor).
According to the GoF, who defined these things, the Strategy Pattern
must contain:
A Context interface holding a Strategy (which I called a "Helper")
interface that has varying ConcreteStrategy implementations holding
the optional algorithms (strategies). Indeed, they suggested that you
might use inheritance to factor out the common factors in the
ConcreteStragey (Helper implementation) classes.
Let me be clear about something, as Richard Nixon said. The Strategy
Pattern is used to eliminate conditional statements, among other
things. So, if you are merely saying that CoR can also be used for
this, then that is clearly true. Lots of patterns can be used for
that, including the questionable Template Method Pattern. That does
not make the patterns equivalent. I am not saying that you are saying
that does make them equivalent. I am just saying that we need to make
sure we are not making that mistake.
Anyway, your example does not work because you understanding here of
the Strategy Pattern is flawed. No?
>
> You can rewrite the above strategy with Chain of Responsibility
> pedantically. If you have a very functional requirement for it.
>
> class ChainFDCW implements IFrameDatabaseColumnWidth {
>
> Catalog catalog;
> String commandName;
>
> // IoC container friendly
> public void setCatalog( catalog ) { ... }
> public void setCommandName( name ) { ... }
>
> public int calcColumnWidth( Object[][] data, MetaData metaData[], int
> columnNo )
> {
> Context context = new FDCWContext( data, metaData, columnNo );
> Command command = catalog.getCommand( commandName );
> command.execute( context );
> if ( context.isCalculatedOk() )
> return context.getColumnWidth();
> else
> throw new StrategyRuntimeException(
> "Failed to calculate column width" );
> }
> }
>
> Ok writing a CoR for calculating data width takes a bit of stretching
> the imagination, but of course you can do it, which is the point.
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org