tsongwei wrote:
This is a general design practice question.
Say if I am designing User Account Management component that does the
following:
1) User Profile info update -- updates firs name, last name, etc,...
2) Change password. -- do password verification, and change password
3) User Payment info update. -- add credit card info.
My question is, since these three function requires similar info from user,
how many action class should I use?
Should I use one: "UserAccountAction.java"?
or three actions: "UserProfileAction.java", "UserPasswordAction.java", and
"UserPaymentInfoAction.java"?
The approach I took is using one actions: "UserAccountAction".
But the problem is I created many properties and getters setters that are
not used for all struts action mappings.
So I am wondering if this is good practice or not, or should I break it into
three action classes.
How would you design this?
Personally I tend to use multiple actions, mostly to avoid having
unnecessary action properties. For me it's easier to deal with many
tightly-focused classes (as opposed to a small number of classes with
multiple responsibilities).
I don't think there's a right or wrong way, really--I just happen to
prefer keeping classes as light and lean as possible; they're easier for
me to read and understand that way. The negative is that I end up with a
lot of classes--but I'm okay with that.
Common functionality often gets broken out into super-classes. For
example a recent project now has a user admin action base class with a
bunch of services used across all user admin functionality, with a
number of sub-classes that handle specific tasks.
Bigger codespace, more lines of code. Lower cognitive overhead for each
class (although it's not always immediately obvious where shared
functionality is handled), more granularity making things easier to mock
and/or stub.
Ah, I miss Smalltalk.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
