1

我在Stack OverflowMicrosoft Developer Network和一些博客中阅读了很多详细的内容。普遍的共识是“AConstructor不应包含大量参数”。 所以遇到这个让我思考-

  • 最初的问题:我的应用程序包含大约 15 个变量,这些变量在整个应用程序中不断使用。 我想出的解决方案是我将创建一个将值注入到Properties.

所以这似乎工作得很好,它让我的生活变得很容易,因为我可以通过 传递object到另一个classConstructor而不必将所有这些变量分配给每个method。除了这导致另一个问题 -

public class ServerParameters
{
    // Variable:
    private string template;
    private string sqlUsername;
    private string sqlPassword;
    private string sqlDatabase;
    private string sqlServer;

    public ServerParameter(string _template, string _sqlDatabase, string _sqlServer, 
string _sqlUsername, string _sqlPassword)
    {
        template = _template;
        sqlUsername = _sqlUsername;
        sqlPassword = _sqlPassword;
        sqlDatabase = _sqlDatabase;
        sqlServer = _sqlServer;
    }

// Link the private strings to a group of Properties.

}

所以这Constructor已经变得非常臃肿了-但是现在我需要实现更多的 参数

  • 问题二:所以我有一个臃肿Constructor的,并通过实施不完全符合这个特定的其他项目Class我对此的解决方案是创建一个subclasscontainer保存这些不同classes但能够使用这些classes.

您现在看到了两难境地,这引发了一个非常重要的问题——当您只能继承一次时,您如何构建一个容纳所有这些子类的容器?

为什么不应该在构造函数中使用这么多参数,为什么它确实不好?

我对如何实现 a 的想法,Container但我觉得我做错了——因为当我尝试使用其中的一些时,我经常得到Null Reference ExceptionParameters

public class VarContainer
{
     private ServerParameter server;
     private CustomerParameter customer;

     public VarContainer(ServerParameter _server, CustomerParameter _customer)
     {
         server = _server;
         customer = _customer;
     }
}

我假设这是因为内部类本身实际上并没有获得那些分配的变量,但是我完全迷失了实现目标的最佳方法-

4

4 回答 4

3

“不要在构造函数中工作”的主要目的是避免在创建对象时产生副作用,并且它会执行大量可能会意外影响全局状态甚至需要很长时间才能完成的工作,这可能会破坏调用者的代码流。

在您的情况下,您只是在设置参数值,所以这不是“不工作”的意图,因为这不是真正的工作。最终容器的设计取决于您的要求 - 如果您可以接受在您的class(或struct) 上设置的属性的变量列表,那么构造对象时的初始化程序可能更合适。

假设您从一开始就想要所有属性,并且想要像问题中所说的那样进行分组,我将构建类似于:

public class Properties 
{
    public ServerProperties Server { get; private set; }
    public CustomerProperties Customer { get; private set; }

    public Properties(ServerProperties server, CustomerProperties customer)
    {
         Server = server;
         Customer = customer;
    }
 }

我将ServerProperties和的实现留给CustomerProperties你,但它们遵循相同的实现模式。

于 2013-06-07T19:11:54.917 回答
1

这当然是一个偏好问题,但我总是为我的构造函数提供他们需要的所有参数,以便我的对象具有基本功能。我不认为 5 个参数是臃肿的,在我看来,添加一个容器来传递参数比添加更多参数会增加更多的膨胀。我所说的新膨胀是指您可能会有一个新文件,其中包含新类和新导入。调用代码必须编写更多using指令并链接到需要正确导出的正确库。

为参数添加一个包装类掩盖了真正的问题,即你的类可能太复杂了,它不能解决它并且通常会加剧它。

于 2013-06-07T19:07:01.143 回答
0

您可以在构造函数中拥有任意数量的参数。只是如果你有太多(多少太多了?这真的很主观),创建该类的新实例变得越来越难。

例如,假设您有一个有 30 个成员的类。其中 27 个可以为空。如果你强制它为构造函数中的每个成员接收一个值,你会得到如下代码:

Foo bar = new Foo(p1, p2, p3, null, null, null, null, null, null /*...snip*/);

这写起来很无聊,而且可读性也不是很好,而三参数构造函数就可以了。

IMO,这是您应该在构造函数中收到的内容:

  • 首先,您的实例为了工作而绝对需要的任何东西。它需要有意义的东西。例如,与数据库连接相关的类可能需要连接字符串。
  • 在上面提到的那些之后,您可能有接收最有用的东西的重载。但不要在这里夸大其词。

其他一切,你让任何人稍后通过set访问器在属性中使用你的代码集。

于 2013-06-07T19:07:37.947 回答
0

在我看来,您可以使用UnityCastle Windsor等依赖注入容器。

于 2013-06-07T19:16:40.320 回答