multiple - Herencia de C#: campo estático frente a no estático

polimorfism c#

Question

Tengo una clase base de biblioteca ( Controller ) y tres subclases que heredan del Controller ( Sensor , Output y Environment ) donde:

public class Controller
{
private SerialPort serial;
private Sensor sensorSettings;
private Output outputSettings;
private Environment environmentSettings;
protected Dictionary<int, string> ErrorDescriptions
{ get{ this.errorDescriptions; } }
protected SerialPort ControllerSerialPort
{ get{ this.serial; } }
protected Sensor SensorSettings
{ get{ this.sensorSettings; } }
// The other sub-class get properties.
protected string SendReceive(string controllerCommand)
{ ... }
...
}
public class Sensor : Controller {...}
... // Other sub-classes

Mi pregunta es esta: ¿Debería hacer errorDescriptions static? Estas descripciones de error no cambiarán de controlador a controlador (es decir, estático), pero no estaba seguro de qué sucede en las clases heredadas. ¿Tendré que referirme a ellos como Sensor.errorDescription en la clase Sensor o seguirá siendo Controller.errorDescription ?

EDITAR

Wow, me acabo de dar cuenta de que cometí un error a lo grande. Así es como debería ser, creo:

private abstract class ControllerBasics
{
protected SerialPort serial; // The serial port to communicate with the controller.
protected Dictionary<int, string> errorDescriptions = new Dictionary<int, string> {...}; // Possible errors for the controller (known and fixed). Won''t change from controller to controller.
public enum Sensors {One, Two, ...}; // Possible sensor selection.
public string SendReceiveCommand(string command){...} // Method to send string command over "serial".
}
public class OverallController : ControllerBasics // The controller class.
{
// 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.
{
...
}

Entonces, si las errorDescriptions definidas en ControllerBasics son conocidas y corregidas (y se requieren en todas las clases derivadas), ¿debo dejarlas estáticas o debería dejarlas protegidas y cada clase derivada tendrá su propio diccionario (es decir, this.errorDescriptions)?

Answer 1

Si solo necesita una instancia del diccionario que sí, cámbiela a estática protegida. También debe usar ConcurrentDictionary lugar de seguridad de subprocesos.

En las clases derivadas accede al campo usando Controller.errorDescription

Answer 2

Solo habría una variable estática, sin importar cuántas subclases tenga. ¿Está destinado a variar por subclase, o es realmente un mapa global? Si es el último, entonces una variable estática es apropiada. Si no ... bueno, hay varias opciones, pero tendrías que decirnos para qué estás usando el mapa.

Answer 3

Bueno, un miembro privado no será visible para tus clases derivadas. Necesitaría un miembro o propiedad protegida para eso. Dentro de la clase, puede referirse a él como errorDescriptions o this.errorDescriptions.

Sería extremadamente cauteloso de tener una variable de miembro estática y protegida que no sea segura para subprocesos y pueda ser modificada por clases derivadas. Eso es solo pedir problemas.