构造函数的参数太多

我们有一个Transaction类，它非常容易加载;所以加载，我原本最终通过了近20个参数ctor。提取几个值对象后，仍然有12个参数，我仍然认为它太多了。构造函数的参数太多

我该如何去避免这种情况？我认为将参数传递给构造函数是合理的，因为它们都是必需的，我想明确说明。我也喜欢如果我添加一个属性，我可以将其添加到ctor，让我的编译器找到它打破的位置，而不必依赖测试本身。我不认为对象初始化器或者构建器能够解决这个问题。在未来的日子里，这些争论可能会变得更加明显，哪些争论是共同的，尽管如此。

public class MyEntity() 
{ 
    public MyEntity(ValueType prop2, ValueType prop3, ...) 
    { 
     Id = Guid.NewGuid(); 
     Prop2 = prop2; 
     Prop3 = prop3; 
     ... 
    } 

    public Guid Id { get; private set; } 

    public ValueType Prop2 { get; private set; } 

    public ValueType Prop3 { get; private set; } 

    public ... 
}

来源

2013-01-15 JefClaes

这些参数可以用任何有意义的方式分组吗？如果不是，他们服务的目的是什么？ – Oded

如果这些参数具有所有相同的类型，只需使用MyEntity（params Type []参数），然后以不同的方式组织它们，如通过List或Dictionary ...或者传递结构或类作为参数包含你需要的一切。另一种选择是使用构造函数冒泡。 –

@Zarathos - 这违背了DDD，域的含义就是它的全部内容。 – Oded

您确定所有的参数都是必需的吗？ “required”这个词具有欺骗性，例如，编译器可能会强制我提供一个字符串参数，但它不会强制我提供一个不为空或空的值。

真正强制提供有效数据的唯一方法是在使用时验证它。有时这必须在构造函数中，例如一个包装类仅在初始化时才有意义的类，如I/O对象。但是，允许调用代码以任何旧方式设置属性通常就足够了，然后在需要它们的方法调用中验证它们的值。

我在散步。我的观点是，不要挂上构造函数参数作为向类提供初始化数据的唯一方法。除了简单的属性之外，它们提供的附加编译器保护很少

来源

2013-01-15 20:09:45

这是一个银行业务领域，所以如果你明白我的意思，我宁愿永远不要让一个对象处于无效状态。 – JefClaes

我也编写银行应用程序。我认为没有什么能够传递愚蠢的DTO，因为这些数据在使用时被验证。您选择的架构模式应该指导您的类设计，而不是您的验证策略的低级细节。 –

如何将参数封装在结构中，并将结构传入？

public struct ParamsStruct 
{ 
    Type1 param1; 
    Type2 param2; 
    ... 
} 

public void Method(ParamsStruct p) 
{ 
    ... 
} 

public void Main(String[] args) 
{ 
    ParamsStruct p; 
    p.param1 = ... 
    p.param2 = ... 
    Method(p); 
}

来源

2013-01-15 20:12:50 Porkbutts

这不就是解决问题吗？ – JefClaes

至少你可以将这些参数逻辑分组到几个结构中，这应该有助于组织。 – Porkbutts

我同意最后的评论。我将尝试发现更多的概念。 – JefClaes

public class MyEntity() 
{ 
    public ValueType Prop1 { get; set; } 

    public ValueType Prop2 { get; set; } 

    // And so on... 

    public MyEntity() 
    { 
     Id = Guid.NewGuid(); 
    } 
}

然后：

MyEntity entity = new MyEntity(); 
entity.Prop1 = prop1; 
entity.Prop2 = prop2; 
// And so on...

最后，您可以考虑两种不同的设计方法：

的 essence 模式。
fluent interface 模式。

来源

2013-01-15 20:35:38

当您在用户或系统界面中输出完整的交易详情时，您将需要所有的零件。这不太可能帮助您找到拆分。

但是，看看您的内部处理 - 是否存在您仅使用交易中字段子集的情况？你有没有在交易中通过的地方，但只使用4个字段？如果您从字面上始终使用所有字段，请将它们保存在一个对象中。

在银行交易的情况下，我会考虑拆分沿着这些线路： -

这些钱从
的钱哪里去了
的钱是如何移动来了 - 该支付工具或设备使用
为什么钱很感动 - 参考号码等
的金额和币种
日期
交易

的状态（显然，这取决于你的精确域）。

来源

2013-01-16 00:49:43

构造函数的参数太多

回答

相关问题