C# 继承:使用静态字段?
可能的重复:
C# 继承:静态字段与非静态字段
我正在研究为控制电路创建类库:
private abstract class ControllerBasics
{
protected SerialPort serial; // The serial port to communicate with the controller.
protected Dictionary<int, string> errorDescriptions = new Dictionary<int, string> {{1, "Sensor Error"},{2, "Controller Error"}, ...}; // Possible errors for the controller (known and fixed). Won't change from controller to controller.
public string SendReceiveCommand(string command){...} // Method to send string command over "serial".
}
public class OverallController : ControllerBasics // The actual class used to communicate with the controller.
{
// Add top-level controller settings.
private string controllerName = "Controller1"; // Have a property to get/set.
private bool controllerON; // Controller on/off. Have property to get/set.
... // Other similar fields and methods.
// Used to "sort" the controller's many settings/functions.
private SensorSettings sensorSettings; // Have get/set properties for these so I could do the following: overallControllerInstance.GetSensorSettingsProperty.SetActiveSensorCount(5);
private OutputSettings outputSettings;
private EnvironmentSettings environmentSettings;
public OverallController(string name, string comPort, ...) // Constructor.
{
// Basic settings initialization.
// Create serial port.
this.sensorSettings = new SensorSettings(this.serial);
this.outputSettings = ...
}
public class SensorSettings : ControllerBasics // Class to hold the controller's specific sensor settings and their respective get/set methods. Not a new type of controller.
{
private int activeSensorCount; // Have public method to get/set.
... // Others.
public void SetActiveSensorCount(int sensorCount)
{
// Send command using inherited SendReceive().
}
... // Others.
}
public class OutputSettings : ControllerBasics // Same logic as SensorSettings.
{
private string units; // Have public method to get/set.
... // Others.
public string GetUnitType() // Meters, mm, um...
{
// Send command using inherited SendReceive().
}
... // Others.
}
public class EnvironmentSettings : ControllerBasics // Same logic as SensorSettings.
{
...
}
因此,如果在 ControllerBasics
中定义的 errorDescriptions
已知并在编译时修复,我应该将其设为静态还是应该将其保留为受保护状态,并且每个派生类将有它自己的字典(即 this.errorDescriptions)?如果我将其设为静态,我将如何在派生类中引用它?例如,如果在Sensor Settings
中,我会使用ControllerBasics.errorDescriptions
还是SensorSettings.errorDescriptions
?
谢谢!
Possible Duplicate:
C# Inheritance: Static vs. Non-Static Field
I am working on creating a class library for a control circuit:
private abstract class ControllerBasics
{
protected SerialPort serial; // The serial port to communicate with the controller.
protected Dictionary<int, string> errorDescriptions = new Dictionary<int, string> {{1, "Sensor Error"},{2, "Controller Error"}, ...}; // Possible errors for the controller (known and fixed). Won't change from controller to controller.
public string SendReceiveCommand(string command){...} // Method to send string command over "serial".
}
public class OverallController : ControllerBasics // The actual class used to communicate with the controller.
{
// Add top-level controller settings.
private string controllerName = "Controller1"; // Have a property to get/set.
private bool controllerON; // Controller on/off. Have property to get/set.
... // Other similar fields and methods.
// Used to "sort" the controller's many settings/functions.
private SensorSettings sensorSettings; // Have get/set properties for these so I could do the following: overallControllerInstance.GetSensorSettingsProperty.SetActiveSensorCount(5);
private OutputSettings outputSettings;
private EnvironmentSettings environmentSettings;
public OverallController(string name, string comPort, ...) // Constructor.
{
// Basic settings initialization.
// Create serial port.
this.sensorSettings = new SensorSettings(this.serial);
this.outputSettings = ...
}
public class SensorSettings : ControllerBasics // Class to hold the controller's specific sensor settings and their respective get/set methods. Not a new type of controller.
{
private int activeSensorCount; // Have public method to get/set.
... // Others.
public void SetActiveSensorCount(int sensorCount)
{
// Send command using inherited SendReceive().
}
... // Others.
}
public class OutputSettings : ControllerBasics // Same logic as SensorSettings.
{
private string units; // Have public method to get/set.
... // Others.
public string GetUnitType() // Meters, mm, um...
{
// Send command using inherited SendReceive().
}
... // Others.
}
public class EnvironmentSettings : ControllerBasics // Same logic as SensorSettings.
{
...
}
So if errorDescriptions
defined in ControllerBasics
is known and fixed at compile time should I make it static or should I just leave it protected and each derived class will have it's own dictionary (i.e. this.errorDescriptions)? If I make it static, how would I reference it in a derived class? For example, if in Sensor Settings
would I use ControllerBasics.errorDescriptions
or SensorSettings.errorDescriptions
?
Thanks!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我建议您使用静态方法,它更具逻辑性、速度更快且内存效率更高。
是的,您可以使用 ControllerBasics.errorDescriptions 或 SensorSettings.errorDescriptions。
I recommend you to use the static approach, it's more logic, faster and memory efficient.
And Yes, you could use ControllerBasics.errorDescriptions or SensorSettings.errorDescriptions.
两个都。如果在编译时已知错误消息,您可能最好将两者结合起来 - 使其成为
protected static Dictionary; errorDescriptions
然后您可以使用类名或 this.errorDescriptions。
Both. If the error messages are known at compile time you're probably best off combining the two - make it
protected static Dictionary<int, string> errorDescriptions
and then you can use either class name or this.errorDescriptions.
由于错误至少目前是恒定的,因此我认为将它们静态化并在所有实例之间共享没有任何问题。根据使用情况,它可能会引入代码气味,但重构气味很容易。
另一方面,我会问您实际使用错误消息的频率以及将它们存储在实际类之外是否可能是更好的解决方案。此外,最好创建自己的异常类,以便使用您的库的人可以在不搜索字符串的情况下确定失败的类型。
只是想法。
Since the errors are, at least for now, constant, I see nothing wrong with having them static and shared amongst all instances. Depending on use, it could introduce a code smell, but it is easy enough to refactor the smell out.
On the other side of the equation, I would ask how often you actually use the error messages and whether or not storing them outside the actual class might be a better solution. In addition, would it be better to make your own exception classes so one consuming your library could determine the type of failure without searching strings.
Just thoughts.