aspose file tools*
The moose likes Struts and the fly likes One large action class vs multiple small classes Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Frameworks » Struts
Bookmark "One large action class vs multiple small classes" Watch "One large action class vs multiple small classes" New topic
Author

One large action class vs multiple small classes

Andre Perez
Greenhorn

Joined: Jan 31, 2008
Posts: 4
I'm curious as to what the struts community opinion on this practice is. I'm working on a project which has a huge action class. Essentially, it looks at a
button request value, which is different for various links on the page, and does a 6 block if/else lookup. Is this a recommended practice. It's a large class mainly because the business logic is contained in the actions, but I was wondering if it would also be valuable to break up the if/else conditional into separate classes. The argument i'm getting is get the business logic out first, and the if/else lookup won't be very big, so one action class is better. So I guess the question is , what is the view on passing a submit button value to the single action, and acting depending on the type of submit?

Hope this makes sense.

Thanks.
Joe Ess
Bartender

Joined: Oct 29, 2001
Posts: 8997
    
    9

Originally posted by Andre Perez:
Essentially, it looks at a button request value, which is different for various links on the page, and does a 6 block if/else lookup.

Struts acts as the controller for an MVC application and it sounds like you are duplicating that functionality in your actions. I'd be inclined to point those 6 buttons at different actions.

Originally posted by Andre Perez:
It's a large class mainly because the business logic is contained in the actions


That's another Bad Idea. It says right in the introduction:
. . .in most cases, an Action object should invoke another object, usually a JavaBean, to perform the actual business logic. This lets the Action focus on error handling and control flow, rather than business logic.


[How To Ask Questions On JavaRanch]
Andre Perez
Greenhorn

Joined: Jan 31, 2008
Posts: 4
I agree about the business logic. I am moving everything out into a model now, but am getting resistance to separating out multiple actions. I was just wondering how others in the community view multiple actions vs. a single action with a large if/else block. Thanks for the reply. Looking forward to even more opinions please!
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61766
    
  67

A single, monolithic action is an affront against all that is good and just -- as well as an egregious violation of best-practice OO principles.

How's that for not mincing words?


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Andre Perez
Greenhorn

Joined: Jan 31, 2008
Posts: 4
Hah! I feel the same way too. Now how can I word things like that in a business argument? Mind you, i am working with folks who don't know what dispatch actions are...
Ben Souther
Sheriff

Joined: Dec 11, 2004
Posts: 13410

Originally posted by Bear Bibeault:
A single, monolithic action is an affront against all that is good and just -- as well as an egregious violation of best-practice OO principles.

How's that for not mincing words?


Why don't you stop beating around the bush and tell us how you really feel about this issue?


Java API J2EE API Servlet Spec JSP Spec How to ask a question... Simple Servlet Examples jsonf
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61766
    
  67

Following best-practice OO methodologies that lead to clarity, extensibility, testability and those other really-good-ibilities should be business justification enough, I would think.

Originally posted by Ben Souther:
Why don't you stop beating around the bush and tell us how you really feel about this issue?
Well, you know me. I'm just the shy type.
Eric Nielsen
Ranch Hand

Joined: Dec 14, 2004
Posts: 194
Sounds like you might want to look at using multiple action methods within your action.

Step one (already mentioned up-thread): get the business logic out of the action

Step two: look at the else-if logic tree remaining and decide which of the three approaches below makes the most sense for your app and "philosophy"
a) Many small, non-related actions
b) Many small, inheritance related actions with shared behavior
c) Single action with multiple methods honoring the execute contract (aka a more "dispatch" action inspired approach)

My guess from your description of the problem would be that either b or c would be a good match. To me both b and c are often "correct" and equally good... the choice between them is normally a more personal opinion...
Andre Perez
Greenhorn

Joined: Jan 31, 2008
Posts: 4
Bear, I tried to use that approach, it seemed to not work so well. Apparently , OO isn't quite used here other than the fact they say they use java. Hence the massive use of large static classes.

Eric, I was trying to convince them that option B would probably be the way I would go, since there is definitely duplicated logic in each block. I also mentioned option C, but they had never heard of a dispatch action, and said they didn't want to introduce "new" technologies.

I didn't think I was so far off on my thinking to correctly refactor the code.

Thanks for everyone replying. Maybe i'll print out the thread and show it to the managers

As always, I welcome more thoughts on this issue. If there are valid points for the current way it's being done, speaking strictly from an action perspective and not the business logic in the action, I would love to hear them.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: One large action class vs multiple small classes