• 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

One large action class vs multiple small classes

 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Bartender
Posts: 9626
16
Mac OS X Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.

 
Andre Perez
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!
 
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Andre Perez
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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...
 
Sheriff
Posts: 13411
Firefox Browser VI Editor Redhat
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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?
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic