Is there a design pattern for a measurment/value relationship?

Question

I've to work with a large database that contains measurement targets as well as warning/error areas for the measurement values.

public class Measurement<T>
{
    public T Target { get; set; }

    public float? UpperWarnLimit { get; set; }
    public float? LowerWarnLimit { get; set; }
    public float? UpperErrorLimit { get; set; }
    public float? LowerErrorLimit { get; set; }
}

These measurements are assigned to specifications:

public class Specification
{
    public long Id { get; set; }
    public Measurement<float> Width { get; set; }
    public Measurement<float> Height { get; set; }
    public Measurement<int> AdditionalMeasurement { get; set; }
    // ...
}

So whenever a user does a measurement, the system collects information from various database tables, assembles a specification object and collects the measurement values. In some cases the specification has to be changed:

 public interface IDatabase
 {
     Specification GetSpecification(long id);
     void UpdateSpecification(Specification specification)
 }

Everything looks good so far, but there is also a case where a user has to store the test results in the database and I'm not sure what is the best way to solve this problem.

My initial solution was to alter the measurement and database class like this:

public class Measurement<T>
{
    public T Target { get; set; }
    public T Value { get; set; } // <-- New


public interface IDatabase
{
    void StoreTestResults(Specification specification) // <-- New

But it doesn't feel right, because in fact the user stores a test result and not a specification. I'm looking for a better way to do this.

To clear it up: I want to separate the test results from the specification with the least amount of additional complexity possible.

A typical code scenario with the changes I mentioned:

 var s = GetSpecification(123);
 s.Height.Value = 4;
 if (s.Height.Value > s.Height.Target * s.Height.Target.UpperErrorLimit)
 {
    ...
 }
 StoreTestResults(s);

This is simple and pretty straight forward but there is no clear separation between the test results and the specification itself.

Answer 1

I don't see a problem with your design (although you have given almost no details).

I think your use of the name "specification" may have fooled you into thinking that it is for storing specifications.

If you need to separate specifications from results at the type level (and I urge you not to do so unless necessary), then create a base class with all of the common elements (which may be everything), and inherit from it for specification and result, and use a neutral name.

If you don't need to separate the two concepts, then choose a more neutral name than "specification" and be done.