java构造函数过度注入和Facade服务概念
我有一个非常简单的界面来管理业务提案的更新,特别是在一个夜间批处理过程中,每个记录都在这里提交(但它可能会用于其他场景)。 这个接口在EJB2.0bean中使用,它获取记录并“循环”它们。 注意名字是从意大利语翻译成英语的,所以请原谅可能的错误。我还简化了一些概念
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;
用于助手私有方法
正如你所看到的,这个类只是组织和委派工作,然而,它确实依赖于太多的其他类。对某些人来说也是如此
在每个步骤中使用*Service
,从数据库中检索详细信息,更新依赖项等
你会接受这个数量的依赖项吗
您将如何重构以简化
我已经读过Facade服务概念,它是一种减少依赖性的方法,以及我应该如何将依赖性集群组合在一起,但在这里我真的不知道该怎么做
我可以将使用它们的Converter
和Service
进行分组,但无论如何它们都太多了
如果需要其他细节,请告诉我
# 1 楼答案
我看到的问题是
ProposalUpdateDefaultService
做了太多的事情,知道的太多。它接受很多服务,创建步骤并执行步骤,而应该只接受一个参数对象并在不知道步骤是什么的情况下进行更新首先,我将尝试通过创建一个单独的类来减少构造函数
ProposalUpdateDefaultService
中的参数,该类将包含服务和转换器这样代码就可以更干净
现在我看到的第二个问题是在
ProposalUpdateDefaultService
本身创建步骤。这应该是不同阶层的责任。比如下面而
StepCreator
类应该是这样的现在
ProposalUpdateDefaultService
可以执行这些步骤,而不知道这些步骤是什么以及需要执行哪个服务