请考虑以下不可变类型:
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
类型是否适合结构化?为什么/为什么不呢?
答案 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'。我关于为什么它应该是一个类的论点是因为大多数应用程序的选项往往会随着时间而增长。 (如果您正在扩展模块,编写新代码等。)