This discussion is archived
12 Replies Latest reply: Mar 21, 2011 11:04 AM by jschellSomeoneStoleMyAlias RSS

What pattern should I use?

fxbird Newbie
Currently Being Moderated
Hello all:
I'm writing an app to determine whether the execution result of struts action and bussiness object intercepted through intercepter of spring and struts is successful, the interface to do it is named 'SuccessChecker' , six default build-in checker implement classes have been developed, if those don't reach the requirement, you need to implement it on your own, below is part code of the factory class.
public class SuccessCheckerFactory {
    public static SuccessChecker getCustomerChecker(ActionExeResult actionRst, Map<String, ExeResult> resultPath) {
        return null;
    }

    public static SuccessChecker getActionErrNotEmptyChecker(BaseAction action) {
        return null;
    }

    public static SuccessChecker getAlertMsgChecker(String msgKey) {
        return null;
    }

    .......
}

public interface SuccessChecker {
     boolean isSccessful();
}
My confusion is there're many logic to select a proper concrete factory method , whose parameters are different from other's. In this case , do I still need write such factory? Is that right I don't use it and just create a implement class of SuccessChecker? But meanwhile I discovered java.util.Calendar is in a situation similar to mine. Calendar has method with different parameters to return a concrete Calendar implement class, but it's an abstract class that is extended by like GregorianCalendar. Is that suitable I mimic Calendar.
thanks.
  • 1. Re: What pattern should I use?
    EJP Guru
    Currently Being Moderated
    Sounds like a job for Abstract Factory?
  • 2. Re: What pattern should I use?
    fxbird Newbie
    Currently Being Moderated
    EJP wrote:
    Sounds like a job for Abstract Factory?
    Hi, I think Abstract Factory's method doesn't have so many different signature, usually has one only.
  • 3. Re: What pattern should I use?
    EJP Guru
    Currently Being Moderated
    Sigh. Where did you get that idea? And who is going to stop you using > 1 method anyway?
  • 4. Re: What pattern should I use?
    fxbird Newbie
    Currently Being Moderated
    EJP wrote:
    Sigh. Where did you get that idea? And who is going to stop you using > 1 method anyway?
     If so, how we deal with multiple signature, since they need a determining logic and prepare proper parameter for the factory method outside the factory, why we need a factory , just put new ConcreteSuccessChecker code in it? Can u give me a productivity example to throw a light on it? thanks.

    Edited by: fxbird on Mar 16, 2011 12:13 AM
  • 5. Re: What pattern should I use?
    EJP Guru
    Currently Being Moderated
    public abstract <T extends SuccessChecker> <T> getSuccessChecker(...);
    Repeat as often as necessary.
  • 6. Re: What pattern should I use?
    fxbird Newbie
    Currently Being Moderated
    The point is different factory method has different signature , so we need to prepare different parameter for them , there's nothing good to use such factory. My thought.
  • 7. Re: What pattern should I use?
    YoungWinston Expert
    Currently Being Moderated
    fxbird wrote:
    The point is different factory method has different signature , so we need to prepare different parameter for them , there's nothing good to use such factory. My thought.
    So is this a problem with constructing your objects, or a problem with getting a SuccessChecker? If the former, you might want to have a look at the Builder pattern (a lot of Builders start out life as Factories).

    Winston
  • 8. Re: What pattern should I use?
    fxbird Newbie
    Currently Being Moderated
    YoungWinston wrote:
    fxbird wrote:
    The point is different factory method has different signature , so we need to prepare different parameter for them , there's nothing good to use such factory. My thought.
    So is this a problem with constructing your objects, or a problem with getting a SuccessChecker? If the former, you might want to have a look at the Builder pattern (a lot of Builders start out life as Factories).

    Winston
      Probably Both not, the problem is what pattern should be used so that client doesn't have to prepare many method parameter and need excessive determing logic like below:
    private SuccessChecker createChecker(Functionality func,String returnValue,ActionExeResult actionExeResult) {
            SuccessChecker checker = null;
            String exceptionChecker = func.getCheckerClassName();
            if (exceptionChecker.contains("Default")) {
                if (exceptionChecker.equalsIgnoreCase("DefaultActionErrNotEmptyChecker")) {
                    checker=SuccessChecker.getActionErrNotEmptyChecker(actionExeResult.getAction());
                } else if (exceptionChecker.equalsIgnoreCase("DefaultActionMsgNotEmptyChecker")) {
                    checker=SuccessChecker.getActionMsgNotEmptyChecker(actionExeResult.getAction());
                } else if (exceptionChecker.equalsIgnoreCase("DefaultActionResultChecker")) {
                    checker=SuccessChecker.getReturnValueChecker(returnValue,func.getCheckerComparedValue());
                } else if (exceptionChecker.equalsIgnoreCase("DefaultAlertMsgChecker")) {
                    checker=SuccessChecker.getAlertMsgChecker(func.getCheckerComparedValue());
                } else if (exceptionChecker.equalsIgnoreCase("DefaultDestinationChecker")) {
                    checker=SuccessChecker.getDestinationChecker(Util.getFromRequest("nextUrl").toString(),func.getCheckerComparedValue());
                } else if (exceptionChecker.equalsIgnoreCase("DefaultNoExceptionChecker")) {
                    checker=SuccessChecker.getExceptionChecker(null);
                }
            }else{
               checker=SuccessChecker.getCustomerChecker(func.getCheckerClassName(), actionExeResult,
                       (Map<String,ExeResult>)Util.getFromRequest(Constants.SAVE_NON_ACTION_EXERESULT));
            }
    
            return checker;
    
        }
       If I put the determing logic into the factory class ,I think the multiple parameters will make the factory's coupling with parameters object each of that is not always used in single method, is too tight. Do u guys understand me? I'm not good at English. thanks.
  • 9. Re: What pattern should I use?
    YoungWinston Expert
    Currently Being Moderated
    fxbird wrote:
    Both not, the problem is what pattern should be used so that client doesn't have to prepare many method parameter and need excessive determing logic like below:
    If I put the determing logic into the factory class ,I think the multiple parameters will make the factory's coupling with parameters object each of that is not always used in single method, is too tight. Do u guys understand me? I'm not good at English. thanks.
    I think you've explained it pretty well, but your basic problem remains that you have a set of similar classes, each of which needs a different set of values for construction. If you're worried that you might need to add others later on, you could always package them into a single SuccessCheckerParameters object.

    First off I notice that your Functionality object is the determining factor in all cases (via getCheckerClassName()).
    Second: doesn't the code calling this factory know which Checker to create? Possibly not, but something does; otherwise how did the class name get initialized?

    If you take EJPs advice, you could store a concrete factory for the SuccessChecker rather than the class name. Then your call might be something like:
    SuccessChecker sc = 
       func.getCheckerFactory().newInstance(
          func, returnValue, actionExeResult);
    and the factory decides how to deal with the parameters it's been passed. No selection logic required at all, but you will need a concrete factory for each SuccessChecker type.

    Winston
  • 10. Re: What pattern should I use?
    fxbird Newbie
    Currently Being Moderated
    YoungWinston wrote:
    fxbird wrote:
    Both not, the problem is what pattern should be used so that client doesn't have to prepare many method parameter and need excessive determing logic like below:
    If I put the determing logic into the factory class ,I think the multiple parameters will make the factory's coupling with parameters object each of that is not always used in single method, is too tight. Do u guys understand me? I'm not good at English. thanks.
    I think you've explained it pretty well, but your basic problem remains that you have a set of similar classes, each of which needs a different set of values for construction. If you're worried that you might need to add others later on, you could always package them into a single SuccessCheckerParameters object.

    First off I notice that your Functionality object is the determining factor in all cases (via getCheckerClassName()).
    Second: doesn't the code calling this factory know which Checker to create? Possibly not, but something does; otherwise how did the class name get initialized?

    If you take EJPs advice, you could store a concrete factory for the SuccessChecker rather than the class name. Then your call might be something like:
    SuccessChecker sc = 
    func.getCheckerFactory().newInstance(
    func, returnValue, actionExeResult);
    and the factory decides how to deal with the parameters it's been passed. No selection logic required at all, but you will need a concrete factory for each SuccessChecker type.

    Winston
    Hello Winston:
    I have a piece of app parsing all the configuration information and then creating the proper SuccessChecker instance for each client call, so I do a lot selection logic. Even using SuccessCheckerParamets object, it still can't avoid doing a lot selection logic , cause that decide the what parameters to use for the factory method and you need to drop them to the SuccessCheckerParamets , they can't be removed from client end. Actually ,as u see,SuccessChecker.getReturnValueChecker etc is exactly my factory method, SuccessChecker is changed to a abstract class , like DateFormat does. How can I gracefully and simplely solve this problem? I noticed that might not be done in abstract factory or factory method pattern way.

    Edited by: fxbird on 2011-3-17 上午7:14
  • 11. Re: What pattern should I use?
    YoungWinston Expert
    Currently Being Moderated
    fxbird wrote:
    Even using SuccessCheckerParamets object, it still can't avoid doing a lot selection logic
    Yes it can, but it requires a concrete factory for each type of SuccessChecker.
    cause that decide the what parameters to use for the factory method and you need to drop them to the SuccessCheckerParamets , they can't be removed from client end.
    OK, so I assume that what you're saying is that you're stuck with the parameter list that you already have.
    Actually ,as u see,SuccessChecker.getReturnValueChecker etc is exactly my factory method, SuccessChecker is changed to a abstract class , like DateFormat does.
    Which is, I'm quite sure, why EJP suggested that you use an AbstractFactory.
    How can I gracefully and simplely solve this problem? I noticed that might not be done in abstract factory or factory method pattern way.
    Can you explain to me what's wrong with my previous post?

    Something sets the class name in your Functionality object. That something MUST know which SuccessChecker is to be created. My point is: instead of setting a class Name, set its Factory.

    The business of passing redundant parameters is completely separate. If you can't change the client end then maybe you can't add a SuccessCheckerParameters object (at least, not yet :-) ), but it shouldn't stop you from using whatever factory setup you want.

    Winston

    Edited by: YoungWinston on Mar 17, 2011 3:39 PM

    And if you absolutely, positively cannot change your Functionality object. I'd suggest a simple method to map the class name to a factory, viz:
    SuccessChecker sc = Utils.classNameToFactory(
      func.getCheckerClassName()).newInstance(
         func, returnValue, actionExeResult);
    but it looks clumsier to me.
  • 12. Re: What pattern should I use?
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    fxbird wrote:
    Probably Both not, the problem is what pattern should be used so that client doesn't have to prepare many method parameter and need excessive determing logic like below:
    Didn't see this addressed above...

    You have "many" parameters. They must come from somewhere.

    So if the "client" isn't sending them then where exactly are you going to get them from?

    If the client must send them then I don't think there is a point in trying to make it easier because the complexity of understanding the parameters is going to mean that they will need to understand the very logic that you are attempting to hide. And in that case you might as well expose it.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points