That seems perfectly reasonable to me, although I'd use properties rather than public fields. If you're fetching values from an external device, you may want to consider making the type immutable - pass all the values into the constructor and store them in readonly fields. I find it easier to reason about my code when the types are immutable :)
What sort of efficiency are you concerned about? How many of these values will you have? Even though there aren't many values here, I'd probably still use a class instead of a struct... I very rarely create my own structs. Again, I just find classes easier to reason about (no need to worry about boxing, for example.) Also, this feels like "a collection of values" rather than one indivisible value which is what structs are usually used for (numbers etc). It just doesn't feel like a struct to me.
You will incur an overhead per object, but I wouldn't worry about that unless you have a really good reason to.
EDIT: This seems a trivial point to make, but give everything meaningful names. For example:
public class DeviceReading
{
private readonly DateTime timeStamp;
public DateTime TimeStamp { get { return timeStamp; } }
private readonly double temperature;
public double Temperature { get { return temperature; } }
private readonly double airPressure;
public double AirPressure { get { return airPressure; } }
public DeviceReading (DateTime timeStamp,
double temperature,
double airPressure)
{
this.timeStamp = timeStamp;
this.temperature = temperature;
this.airPressure = airPressure;
}
}
I suspect you'd do so anyway, but I just thought I'd make sure :)
A couple of other things to consider:
Assuming you're using a fairly recent version of .NET, you might want to use DateTimeOffset
rather than DateTime
. The benefit is that DateTiemOffset
unambiguously represents an instant in time, whereas DateTime
can be UTC, local or unspecified.
Depending on the kind of readings you're taking (and how they're communicated) you may want to use decimal
instead of double
. Probably not for temperature and air pressure (or any other "physical" values) but if you're dealing with artificial values like money, decimal
is your friend. Given that this is reading from a device, you're probably dealing with physical quantities, but I thought it worth mentioning.
For dealing with the collections of readings, you really want to look into LINQ. It's lovely :)