enumeraciones - Convención de nomenclatura de C#para la enumeración y la propiedad correspondiente

enumeraciones c#

Question

A menudo me encuentro implementando una clase manteniendo algún tipo de propiedad de estado propio como una enumeración: tengo una enumeración de estado y una propiedad de estado de tipo de estado. ¿Cómo debo resolver este conflicto de nombres?

public class Car
{
public enum Status
{
Off,
Starting,
Moving
};
Status status = Status.Off;
public Status Status // <===== Won''t compile =====
{
get { return status; }
set { status = value; DoSomething(); }
}
}

Si la enumeración de estado fuera común a los diferentes tipos, la ubicaría fuera de la clase y el problema se resolvería. Pero Status se aplica a Car solo, por lo tanto, no tiene sentido declarar la enumeración fuera de la clase.

¿Qué convención de nomenclatura usas en este caso?

NB: Esta pregunta fue parcialmente debatida en los comentarios de una respuesta a esta pregunta . Como no era la pregunta principal , no obtuvo mucha visibilidad.

EDITAR: Filip Ekberg sugiere una solución excelente de la OMI para el caso específico de ''Estado''. Sin embargo, sería interesante leer sobre soluciones donde el nombre de la enumeración / propiedad es diferente, como en la respuesta de Michael Prewecki.

EDIT2 (mayo de 2010): Mi solución favorita es la pluralización del nombre de tipo enum, como sugiere Chris S. De acuerdo con las directrices de MS, esto se debe usar solo para enum de banderas. Pero cada vez me gusta más. Ahora lo uso para enums regulares también.

Answer 1

Agregaré mi 1 euro a la discusión, pero probablemente no agregue nada nuevo.

La solución obvia es mover Status de ser un Enum anidado. La mayoría de las enumeraciones .NET (excepto posiblemente algunas en el espacio de nombres Windows.Forms) no están anidadas y es molesto utilizarlas para el desarrollador que consume su API, teniendo que prefijar el nombre de clase.

Una cosa que no se ha mencionado es que las enumeraciones de banderas según las directrices de MSDN deben ser nombres pluralizados que probablemente ya conozcas (el estado es una enumeración simple, por lo que se deben usar sustantivos singulares).

Estado (enum llamado Estados) es el vocativo, "Estado" es el nominativo de un nombre que los ingleses, como la mayoría de nuestro lenguaje, absorbieron del latín. Vocativo es lo que usted nombra un sustantivo para su condición y nominativo es el sujeto del verbo.

Entonces, en otras palabras, cuando el automóvil se está moviendo , ese es el verbo: mover es su estado. Pero el auto no se dispara, su motor sí. Tampoco comienza, el motor sí (probablemente eligió un ejemplo aquí, así que esto podría ser irrelevante).

public class Car
{
VehicleState _vehicleState= VehicleState.Stationary;
public VehicleState VehicleState
{
get { return _vehicleState; }
set { _vehicleState = value; DoSomething(); }
}
}
public enum VehicleState
{
Stationary, Idle, Moving
}

Estado es un sustantivo tan generalizado ¿no sería mejor describir a qué estado se refiere? Como lo hice arriba

El ejemplo de tipo también en mi opinión no se refiere al tipo de lector, sino a su base de datos. Lo preferiría si estuvieras describiendo el producto de la base de datos del lector que no es necesariamente relevante para el tipo de lector (por ejemplo, el tipo de lector podría ser solo reenviado, almacenado en caché, etc.). Asi que

reader.Database = Databases.Oracle;

En realidad, esto nunca sucede ya que se implementan como controladores y una cadena de herencia en lugar de utilizar enumeraciones, por lo que la línea anterior no parece natural.

Answer 2

Cambiaría el nombre de la propiedad a algo así como "CurrentStatus". Rápido y fácil :)

Answer 3

Creo que el problema real aquí es que el estado enum está encapsulado dentro de su clase, de modo que Car.Status es ambiguo tanto para el Status la propiedad como para el Status enum.

Mejor aún, ponga su enumeración fuera de la clase:

public enum Status
{
Off,
Starting,
Moving
}
public class Car
{
public Status Status
{ ... }
}

ACTUALIZAR

Debido a los comentarios a continuación, explicaré mi diseño arriba.

Soy uno que no cree que las enumeraciones o las clases o cualquier otro objeto deben residir dentro de otra clase, a menos que sea totalmente privado dentro de esa clase. Tome el ejemplo anterior, por ejemplo:

public class Car
{
public enum Status
{...}
...
public Status CarStatus { get; set;}
}

Si bien algunos comentaristas argumentarían que el Estado no tiene ningún significado fuera del alcance del automóvil de la clase, el hecho de que esté estableciendo una propiedad pública significa que hay otras partes del programa que usarán esa enumeración:

public Car myCar = new Car();
myCar.CarStatus = Car.Status.Off;

Y eso para mí es un olor a código. Si voy a ver ese estado fuera de Car , también podría definirlo fuera .

Como tal, probablemente solo lo cambie de nombre como:

public enum CarStatus
{...}
public class Car
{
...
public CarStatus Status { get; set; }
}

Sin embargo, si esa enumeración se usará dentro y solo dentro de la clase de auto, entonces estoy de acuerdo con declarar allí la enumeración.

Answer 4

La definición de "Desactivado", "Comenzar" y "Mover" es lo que yo llamaría un "Estado". Y cuando insinúa que está usando un "Estado", es su "Estado". ¡Asi que!

public class Car
{
public enum State
{
Off,
Starting,
Moving
};
State state = State.Off;
public State Status
{
get { return state ; }
set { state= value; DoSomething(); }
}
}

Si tomamos otro ejemplo del indicado en el que desea usar la palabra "Tipo", en este caso:

public class DataReader
{
public enum Type
{
Sql,
Oracle,
OleDb
}
public Type Type { get; set; } // <===== Won''t compile =====
}

Realmente necesitas ver que hay una diferencia entre enums y enums, ¿verdad? Pero cuando se crea un marco o se habla de arquitectura, se debe enfocar en las similitudes, ok, vamos a encontrarlas:

Cuando algo se establece en un estado, se define como el estado "cosas"

Ejemplo: el estado del automóvil está en estado de ejecución, estado detenido, etc.

Lo que quieres lograr en el segundo ejemplo es algo así:

myDataReader.Type = DataReader.Database.OleDb

Podrías pensar que esto dice en contra de lo que he estado predicando a otros, que necesitas seguir un estándar. ¡Pero estás siguiendo un estándar! El caso Sql es también un caso específico y, por lo tanto, necesita una solución algo específica.

Sin embargo, la enumeración sería reutilizable dentro de su espacio System.Data , y de eso se tratan los patrones.

Otro caso para mirar con el "Tipo" es "Animal", donde Tipo define la especie.

public class Animal
{
public enum Type
{
Mammal,
Reptile,
JonSkeet
}
public Type Species{ get; set; }
}

Esto sigue un patrón, no necesita "conocer" específicamente el objeto para esto y no está especificando "AnimalType" o "DataReaderType", puede volver a utilizar las enumeraciones en su espacio de nombres de su elección.

Answer 5

Sé que mi sugerencia va en contra de las convenciones de nomenclatura de .NET, pero personalmente prefijo enumeraciones con ''E'' y enum flags con ''F'' (similar a cómo prefijamos las interfaces con ''I''). Realmente no entiendo por qué esta no es la convención. Los Enum / Flags son un caso especial, como interfaces que nunca cambiarán su tipo. No solo deja en claro lo que es, es muy fácil escribir en intellisense ya que el prefijo filtrará la mayoría de los otros tipos / variables / etc., y no tendrá estos conflictos de nombres.

Y eso también resolvería otro problema donde para ejemplos en WPF utilizan clases estáticas como enumeraciones (por ejemplo, FontWeights) que tienen instancias predefinidas de tipos pero no sabría si no las busca. Si acaban prefijos con ''E'', todo lo que tendrías que hacer es escribir el carácter para encontrar estas clases estáticas especiales.

Answer 6

Se condenará a los enemigos de la notación húngara y sus variantes. Utilizo una convención de enumeraciones de sufijos con ... espere, Enum . En consecuencia, nunca tengo el problema que describes, pierdo el tiempo preocupándose por cómo llamarlos y el código es legible y autodescriptivo para arrancar.

public class Car
{
public enum StatusEnum
{
Off,
Starting,
Moving
};
public StatusEnum Status { get; set; }
}

Answer 7

Sugiero agregar "Opción" al nombre del tipo (o Marcar si contiene indicadores de bits), es decir, el tipo es Car.StatusOption y la propiedad es Car.Status.

Comparado con la pluralización, esto evita colisiones de nombres cuando se crean colecciones del tipo enum, donde normalmente se quiere pluralizar la propiedad de la colección, no el tipo enum.

Answer 8

Usualmente prefijo las enumeraciones, p. Ej. CarStatus. Supongo que todo depende del equipo con el que estés trabajando (si tienen reglas / procesos para ese tipo de cosas) y el uso de objetos. Solo mis 2 centavos (: