java - 用静态包装方法封装类是个好主意吗？

Question

我在我工作的项目中重构了一个巨大的方法，并提出了这个想法来创建这样的验证服务 -

public class TrickyValidation {
    String validationVariable1;
    String validationVariable2;
    String validationVariable3;

    HashMap<String, Object> itemsMap;
    Object dependentObject;

    @Autowired
    SpringService service;

    public static boolean doTrickyValidation(HashMap<String, Object> itemsMap, Object dependentObject) {
        return new TrickyValidation(itemsMap, dependentObject).validate();
    }

    private TrickyValidation(Object itemsMap, Object dependentObject) {
        this.itemsMap = itemsMap;
        this.someDependentObject = dependentObject;
        init();
    }

    private boolean validate() {
        // loads of logic for validation by using validationVaribales
        return true;
    }

    private void init() {
        // Some methods to extract thease variables from itemsMap, dependentObject etc..
       this.validationVariable1 = service.get(dependentObject); 
       this.validationVariable1 = ...;
       this.validationVariable1 = ...;
    }
}

我的目标是尽可能封装所有内容并使用干净的代码原则。

• 我在这里感觉有点像与 spring 框架作斗争，因为我不想“TrickyValidation”类将是@Servcie并且属于spring容器。 Autowired 在这里还能工作吗？

• 这是一个好的设计吗？我很可能会循环使用此验证。我喜欢这个解决方案，因为当我必须验证事物时，我只需调用此类的一个且唯一的公共(public)静态方法 TrickyValidation.doTrickyValidation(map, obj)

欢迎就如何改进这一点或为什么这是一个坏主意提出任何建议。

Answer 1

此代码可能无法工作，因为在对象的 init 方法中，您尝试访问的 service 未自动连接到此实例中。一般来说， Autowiring 仅适用于 Spring 管理(创建)的对象。

在这种情况下，您“手动”创建类 TrickyValidation 的对象...

IMO 更好的设计是将可以由 Spring 管理的“Validator”对象和不基于 spring 的验证本身分开。

@Component
public class Validator {

   @Autowired
   private Service service;

    public boolean doTrickyValidation(HashMap<String, Object> itemsMap, Object dependentObject) {
        // resolve the validation strategy from the items passed to this method.

        TrickyValidation validation = resolveTrickyValidation(itemsPam, dependentObject);

        return validation.validate();
    }

    private TrickyValidation resolveTrickyValidation(...) {
      // construct the proper validation strategy
      // access service if you want
    }



}