- This topic has 3 replies, 2 voices, and was last updated 19 years, 8 months ago by
.
-
Posts
-
Ok….my “procedural programmer” roots are probably going to show in this question.
Say you have a typical data entry forum with the Create, Retrieve, Update, Delete functions.
Do you create separate action classes and paths for each of these, or do you create on action which looks for a parameter to determine what action to take, followed by if/then or switch blocks with calls to appropriate methods.
After I’ve typed this, it occurs to me that there is a “Dispatch Action” class for just this sort of issue (I’m developing with struts)
Still….it begs the question of “best practices” when developing with OO software. Every time I come to a “if this, then to that, else if this2 to that2” portion of code, I’m wondering if I’m falling back into procedural programming.
However, I’m also unsure of the benefit of having 4 separate little classes for handling the CRUD of a single form.
Lee
Do you create separate action classes and paths for each of these, or do you create on action which looks for a parameter to determine what action to take, followed by if/then or switch blocks with calls to appropriate methods.
I’m assuming you are talking Struts, so I’ll answer it in Struts terms. You can do either here, with Struts 1.1 your only ‘good’ choice IMO was using multiple actions, it keeps the actions simple, maintence is a cake-walk and your struts-config and app design are extremely clear and easy to follow. There was also the stupid LookupDispatchAction in 1.1 that I don’t think is any good for many reasons… BUT now with the nightly builds and soon-to-be-released Struts 1.2, there is a new class MappingDispatchAction which allows you to have many methods that all have the same signature as the ‘execute’ method, then in your struts-config file, you identify WHICH method in the Action to call via the ‘parameter’ attribute. So you might end up with something like this (psuedo code):
<action parameter="loginUser" type="com.UserAction" /> <action parameter="logoffUser" type="com.UserAction" />and then in your UserAction class, you would have two methods:
public ActionForward loginUser( ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception { /* impl */ } public ActionForward logoffUser( ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception { /* impl */ }So this approach will simplify your code tree and compact similar functionality into single class files and also simplify your struts-config.xml file, but it does make your Action classes longer, a little harder to maintain and your struts-config might not be as visually easy to follow since you now need to consider the paraemter attribute to figure out what is going on.
Its all a trade off, you decide what you think is more important.
Still….it begs the question of “best practices” when developing with OO software. Every time I come to a “if this, then to that, else if this2 to that2” portion of code, I’m wondering if I’m falling back into procedural programming.
Hha, me too… any time that happens I implicitly feel like I’m doing something wrong.
However, I’m also unsure of the benefit of having 4 separate little classes for handling the CRUD of a single form.
More classes == easier for a human to understand the app’s impl and flow, Less classes (dispatch action) == easier to understand the app big picture, takes a bit more detective work to figure out impl details… for example, a user leearning your app needs to know what a MappingDispatchAction does to understand why 1 Action seems to represent 20 smaller ones, little learning curve like that.
