构造函数过度注入和门面服务概念

Question

我有一个非常简单的界面来管理业务提案的更新，特别是在每晚的批处理过程中，每条记录都在这里提交（但它可能用于其他场景）。 此接口在 EJB 2.0 Bean 内部使用，它获取记录并“循环”它们。 注意名字是从意大利语翻译成英语的，所以请原谅可能的错误。我还简化了一些概念。

public interface ProposalUpdateService {
    void updateProposal(final ProposalFirstType proposal);
    void updateProposal(final ProposalSecondType proposal);
}

这个接口的实现有相当多的依赖：

public class ProposalUpdateDefaultService implements ProposalUpdateService {
    private final ComplexService complexService;
    private final OtherComplexService otherComplexService;

    private final ProposalStep<Proposal> stepOne;
    private final ProposalStep<Proposal> stepTwo;
    private final ProposalStep<ProposalTypeTwo> stepThree;
    private final ProposalStep<Proposal> stepFour;

    public ProposalUpdateDefaultService(
            final ComplexService complexService,
            final OtherComplexService otherComplexService,
            final YetAnotherComplexService yetAnotherComplexService,
            final SimpleService simpleService,
            final OtherSimpleService otherSimpleService,
            final YetAnotherSimpleService yetAnotherSimpleService,
            final Converter<ProposalTypeOne, ComplexServiceType> converterProposalTypeOne,
            final Converter<ProposalTypeTwo, OtherComplexServiceType> converterProposalTypeTwo) {
        this.complexService = complexService;
        this.otherComplexService = otherComplexService;

        stepOne = new StepOne(yetAnotherComplexService);
        stepTwo =
                new StepTwo(
                        complexService,
                        otherComplexService,
                        yetAnotherComplexService,
                        converterProposalTypeOne,
                        converterProposalTypeTwo);
        stepThree =
                new StepThree(
                        simpleService,
                        otherSimpleService,
                        yetAnotherSimpleService);
        stepFour = new StepFour();
    }

    ...

如你所见，这个类封装了一个Proposal对象的更新，这个过程分为四个阶段，每个阶段代表一个单一的概念（例如，“这个提案应该过期吗？”或“我应该提前它的状态？”）。这四个阶段在不同类型的Proposal 之间可能会有不同的安排。

这是这两个updateProposal 方法的高度简化实现：

@Override
public void updateProposal(final ProposalTypeOne proposal) {
   stepOne.process(proposal);
   stepTwo.process(proposal);

   if (...) {
      stepFour.process(proposal);
   }
}

@Override
public void updateProposal(final ProposalTypeTwo proposal) {
   stepOne.process(proposal);
   stepTwo.process(proposal);
   stepThree.process(proposal);
   stepFour.process(proposal);
}

两个私有字段

private final ComplexService complexService;
private final OtherComplexService otherComplexService;

用于辅助私有方法。

正如您所见，这个类只是组织和委派工作，但是，它确实依赖于太多其他类。对于某些ProposalStep(s) 也可以这样说。

*Service(s) 在每个步骤中用于从数据库中检索详细信息、更新相关条目等。

您会接受这么多的依赖项吗？
您将如何重构以简化？

我已经阅读了有关 Facade Service 概念作为减少依赖项的一种方式，以及我应该如何将依赖项集群组合在一起，但在这里我真的不明白该怎么做。

我可以将使用它们的Converter(s) 和Service(s) 分组，但无论如何它们会太多。

如果需要其他详细信息，请告诉我。

Answer 1

我看到的问题是ProposalUpdateDefaultService 做的事情太多，知道的太多。它接受大量服务，创建步骤并执行步骤，而它应该只接受单个参数对象并在不知道步骤是什么的情况下进行更新。

首先，我会尝试通过创建一个包含服务和转换器的单独类来减少构造函数 ProposalUpdateDefaultService 的参数。

public class ServicesAndConverters {
    ComplexService complexService;
    OtherComplexService otherComplexService

    //...

}

这样代码会更干净

public class ProposalUpdateDefaultService implements ProposalUpdateService {
    ServiceAndConverters serviceAndConvert;

    public ProposalUpdateDefaultService(final ServiceAndConverters serviceAndConverters) {
        this.serviceAndConvert = serviceAndConverters; //maybe group them in two different class??
    }

}

现在我可以看到在ProposalUpdateDefaultService 本身中创建步骤的第二个问题。这应该是不同班级的责任。如下所示

 public class ProposalUpdateDefaultService implements ProposalUpdateService {
         ServiceAndConverters serviceAndConvert;
         StepCreator stepCreator = new StepCreator();

         public ProposalUpdateDefaultService(final ServiceAndConverters serviceAndConverters) {
             this.serviceAndConvert = serviceAndConverters;
             stepCreator.createSteps(this.serviceAndConverter);
         }

     }

StepCreator 类应该是这样的

public class StepCreator implements ProposalUpdateService {
        private final ProposalStep<Proposal> stepOne;
        private final ProposalStep<Proposal> stepTwo;
        private final ProposalStep<ProposalTypeTwo> stepThree;
        private final ProposalStep<Proposal> stepFour;

        public void createSteps(ServiceAndConverters s) {
                // do the step processing here
        }

}

现在ProposalUpdateDefaultService 可以在不知道步骤是什么以及需要执行哪个服务的情况下执行这些步骤

@Override
public void updateProposal(final ProposalTypeOne proposal) {
   stepCreator.getStepOne().process(proposal);
   stepCreator.getStepTwo().process(proposal);

   if (...) {
      stepCreator.getStepFour().process(proposal);
   }
}

Answer 2

我发现更方便的解决方案是删除 ProposalUpdateService 抽象，让 EJB Bean 管理各个步骤。

到目前为止，这个抽象层是不必要的，每个步骤仍然可以单独使用。两个 ProposalUpdateService 方法调用都成为 EJB Bean 中的私有方法。