选项类型是结构的良好候选者吗?

时间:2016-09-09 15:21:39

标签: c# struct

请考虑以下不可变类型:

public class/struct AServiceOptions {

    public AServiceOptions (Uri baseAddress, int workersCount, TimeSpan maxIdleTime) {
        BaseAddress = baseAddress;
        WorkersCount = workersCount;
        MaxIdleTime = maxIdleTime;
    }

    public Uri BaseAddress { get; }
    public int WorkersCount { get; }
    public TimeSpan MaxIdleTime { get; }
}

以下列方式使用:

public class AService {

    public AService (AServiceOptions options) {
        Options = options;
        Initialize();
    }

    AServiceOptions Options { get; }

    private void Initialize () {
        InitHttpClient(Options.BaseAddress);
        InitWorkers(Options.WorkersCount);
        InitTimer(Options.MaxIdleTime);
    }

    // Service implementation details
}

AServiceOptions类型是否适合结构化?为什么/为什么不呢?

3 个答案:

答案 0 :(得分:1)

不,因为这种类型的实例适合在调用堆栈中共享,并且你知道结构是值,所以当你将它作为方法的参数传递时你不会共享同一个对象但是你'重新创建副本,除非您使用ref关键字。

总之,它应该是

请参阅此其他问答以获取有关何时使用结构的更多详细信息:When to use struct?

答案 1 :(得分:1)

这不是struct的良好候选者,因为所有AService对象都将仅限于使用相同的选项实现,而无法继承特定于子类的选项。

使用struct

无法做到这一点
public struct AServiceOptions {
}
public struct ADerivedServiceOptions : AServiceOptions { // Not possible
}
public class AService {
    public AService(AServiceOptions opt) ...
}
public class ADerivedService {
    public ADerivedService (ADerivedServiceOptions opt) ...
}

此外,struct不会“购买”任何东西:不可变类也会同样好,如果你需要将选项作为object传递,它也可以避免装箱/拆箱。

答案 2 :(得分:0)

我设计并实施了一个选项系统。我认为解决这个问题的最佳方法是建立一个基类' Option'。我关于为什么它应该是一个类的论点是因为大多数应用程序的选项往往会随着时间而增长。 (如果您正在扩展模块,编写新代码等。)