• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Using the Strategy Pattern in Struts Actions

 
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Is there any way to apply the "strategy pattern" to struts Actions?

Or maybe, the "Chain of Command" ?

This way your Struts applications wouldn't be doomed to a subclass heirarchy.
 
Andrew Leer
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I know that Action subclasses are not supposed to contain local varables, since actions are static. So is there anyway around this?
 
Ranch Hand
Posts: 4864
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Is there any way to apply the "strategy pattern" to struts Actions?


No. Not unless you want to go in and make some fairly radical changes to the framework. In that case, you might as well write your own framework. If having a framework that uses interfaces instead of inheritance is really important to you, I'd suggest you use the Spring MVC framework.

This way your Struts applications wouldn't be doomed to a subclass hierarchy.


This comment obviously assumes that a framework that requires you to write a subclass of a framework class is automatically bad. It isn't. It also assumes that having to write a subclass of one or two framework classes automatically ties your whole application to a subclass hierarchical structure. It doesn't.

There is a real advantage in having a subclass instead of an interface: That being that a subclass inherits actual usable methods, whereas an interface only tells me what my methods should look like. Since the action class is what ties my application into the framework, it's handy to have a few functioning methods written by the framework authors right there in my super-class that will help me tie into the framework.

One disadvantage to a subclass in Java is that I can only subclass once. That means that my action class can't subclass any other classes that I've already written. Granted, there are other disadvantages as well.

In the case of an Action class, I don't see these disadvantages as a major problem, though. An action class is a piece of the controller space in a Model/View/Controller architecture, and it has to do only 4 things:

1-evaluate input received from the request
2-decide what to do
3-instantiate model classes and send/receive messages to them to do what needs to be done
4-forward to a view component that formats and returns the response

That's a pretty simple task list. If I'm writing action classes that do much more than that, I'm putting too much logic in my action class. To tie this simple class into a hierarchical structure is no big deal.

My model classes -- the ones that do the real work of the application -- are a different story. I'm free to do whatever I want with my Model classes. I can go crazy with whatever the Pattern flavor of the month is and write whatever cool, sexy classes I want to write. I'm not tied down or restricted in any way as to what I can do or how I have to do it.

I know that Action subclasses are not supposed to contain local variables, since actions are static


Not a true statement. Of course you can have local variables in your execute() method. How could you get along without them? I suspect what you mean to say is that Action classes are not supposed to contain instance variables. It's fine to have instance variables that are the same for all users. For example, most of my action classes have an instance variable that refers to an instance of the log4j logger. What is not encouraged is instance variables that do vary for each user. The reason for this is not that the class is static (I'm not even sure what you mean by that). It's that the class is multi-threaded in the application server and must be coded as thread-safe. The same restriction applies to a Servlet or any other class that is used by multiple threads.

So is there anyway around this?


No, there isn't.
[ August 04, 2006: Message edited by: Merrill Higginson ]
reply
    Bookmark Topic Watch Topic
  • New Topic