这种情况适合用工厂模式吗？

[fxbird]

做了一个校验用spring和webwork拦截到的action或业务对象的执行结果是否符合条件的工厂类，返回SuccessChecker接口的实现类，如下示例：

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;
    }
}

如你所见，getActionErrNotEmptyChecker和getAlertMsgChecker是返回一些内置的系统checker，getCustomerChecker是返回用户自定义的实现类，但问题是，每个方法都需要不同的参数，判断用哪种这些逻辑本身代码也不少，所以这时候还有必要建这个工厂吗？直接在判断之后new 一个具体的实现类是否就行了，看过的书上工厂类都是根据一个字符串就能返回一个类，实际上哪有这么简单哪，类都是需要若干参数才能构造出来并工作的。不解ing.

[嘴哥臭鼬]

不管什么设计模式都只有1,2个原则，其中很重要的一条就是封装变化，什么地方有变化的就可以用设计模式，楼主个类可能会有变化吗？比如数据库变化，dal实现变化等等，有变化就可以用工厂模式

[donkey301]

多加几个设为Factory继承类的私有变量，就不需要参数了，大概这样：

class CustomerFactory: public SuccessCheckerFactory
{
private: 
ActionExeResult m_actionRst;
Map<String, ExeResult> m_resultPath;

public:
void SetActionRst(ActionExeResult actionRst)
{
   m_actionRst = actionRct;
}
virtual SuccessChecker* GetSuccessChecker()
{
    return getCustomerChecker(m_actionRst, m_resultPath); 
}

}

[bluesage]

模式的原则就是封装变化，只要把变化封装起来，将来这部分发生变动的时候，不要整个工程、系统里寻找修改就行。如果这部分不会有变化，甚至没必要这么做，现在敏捷开发的原则就是先实现，等发生变化的时候再进行重构。

[水晶平衡木]

这个答案我给不出，呵呵，原因是我对楼主的具体情况还不是很了解。不过，可以给出一些建议：

工厂模式一般应用于当使用者获取某类实例时，系统要统一做一些使用者并不关心的事情的情景。比如，从缓冲池中取一个闲置的类实例而不是新建一个，或者是记录日志，或者是像楼主说的“书上工厂类都是根据一个字符串就能返回一个类”的这种，呵呵，其实是根据需要的类型获取一个对应类型的工厂产品。

工厂模式其实就是将“根据情况判断返回哪个实例”的责任交给了工厂，由工厂统一判断。根据楼主的话：“每个方法都需要不同的参数，判断用哪种这些逻辑本身代码也不少”，这些参数哪里来的？这些判断是根据什么条件来的？我猜想有一种称之为Context(“环境”或“上下文”)的东西存在吧，这些参数和当时的具体情况都从这个Context来的吧？我们不妨直接把这个作为参数传给工厂，让工厂来判断返回什么SuccessChecker的实例吧：

public class SuccessCheckerFactory {
    public static SuccessChecker getChecker(Context context) {
        return ...;
    }
}

希望有帮助，呵呵。有关面向对象设计方面的问题，欢迎莅临小弟的博客共同探讨：http://blog.sina.com.cn/crystalbalance