The definition of "Off", "Starting" and "Moving" is what i would call a "State". And when you are implying that you are using a "State", it is your "Status". So!
public class Car
{
public enum State
{
Off,
Starting,
Moving
};
State state = State.Off;
public State Status
{
get { return state ; }
set { state= value; DoSomething(); }
}
}
If we take another example from the one stated where you'd like to use the word "Type" such in this case:
public class DataReader
{
public enum Type
{
Sql,
Oracle,
OleDb
}
public Type Type { get; set; } // <===== Won't compile =====
}
You really need to see that there is a difference between enums and enums, right? But when creating a framework or talking about architecture you need to focus on the simillarities, ok lets find them:
When something is set to a State, it's defined as the "things" Status
Example: The Car's Status is in Running State, Stopped State, and so on.
What you want to acheive in the second example is somewhat this:
myDataReader.Type = DataReader.Database.OleDb
You might think that this says against what i've been preaching about to others, that you need to follow a standard. But, you are following a standard! The Sql-case is a specific case aswell and therefore need a somewhat specific solution.
However, the enum would be re-usable within your System.Data
space, and that's what the patterns is all about.
Another case to look at with the "Type" is "Animal" where Type defines the Species.
public class Animal
{
public enum Type
{
Mammal,
Reptile,
JonSkeet
}
public Type Species{ get; set; }
}
This is following a pattern, you don't specificly need to "know" the Object for this and you are not specifing "AnimalType" or "DataReaderType", you can re-use the enums in your namespace of choice.
What is _updatedComponents
? I'm guessing it is a NetworkComponent[]
- which will make things very tricky. I would suggest writing a wrapper type:
public class ComponentsMessage {
public NetworkComponent[] Components {get;set;}
}
Then you can associate the correct attributes. If you need to support ad-hoc attributes on NetworkComponent
you'd still need to use attribute-overrides (hence I haven't decorated the above at all), but ComponentsMessage
should be happy to take the attributes.
Alternately, just write a separate DTO and map the values.
If it is simple, you might just be able to use:
[XmlRoot("components", Namespace = XmlNamespace)]
[XmlType("components", Namespace = XmlNamespace)]
public class ComponentsMessage
{
public const string XmlNamespace = "http://www.example.com/nis/componentsync";
[XmlElement("component")]
public NetworkComponent[] Components { get; set; }
}
Alternatively, if you must use attribute-overrides, I'd still use a wrapper object:
public class ComponentsMessage
{
public NetworkComponent[] Components { get; set; }
}
class Program
{
static void Main()
{
NetworkComponent[] _updatedComponents = new NetworkComponent[2] {
new NetworkComponent{},new NetworkComponent{}
};
const string XmlNamespace = "http://www.example.com/nis/componentsync";
XmlAttributeOverrides ao = new XmlAttributeOverrides();
ao.Add(typeof(ComponentsMessage), new XmlAttributes {
XmlRoot = new XmlRootAttribute("components") { Namespace = XmlNamespace },
XmlType = new XmlTypeAttribute("components") { Namespace = XmlNamespace }
});
ao.Add(typeof(ComponentsMessage), "Components", new XmlAttributes {
XmlElements = {
new XmlElementAttribute("component")
}
});
ComponentsMessage msg = new ComponentsMessage { Components = _updatedComponents };
XmlSerializer serializer = new XmlSerializer(msg.GetType(), ao);
serializer.Serialize(Console.Out, msg);
}
}
Best Answer
The first thing I notice is that
Car.Status
does not exist. Do you meanEngine.Status
?In any case, if those enum types were designed in such a way that they cannot be serialized automatically, you will have to serialize them manually.