C# Basics Making Properties Atomic

Question

It's been given by Microsoft as a framework design guideline that properties should be independent of one another and not rely upon being set in any specific order.

Assume you have a triangle class that needs to support dimmensions and an area calculation. How would you model this?

This is of course the design that is considered gauche because Area is dependent on Base and Height being set first:

class Triangle{
    public double Base {get;set;}
    public double Height {get;set;}
    public double Area {
     get{
      return (Base * Height) / 2;
     }
    }
}

Assuming you use a constructor, you can ensure defaults for this case but is this the correct approach?

class Triangle{
    public Triangle(double b, double h){
     Base = b;
     Height = h;
    }

    public double Base {get;set;}
    public double Height {get;set;}
    public double Area {
     get{
      return (Base * Height) / 2;
     }
    }
}

You still have a property that has a dependency on other properties. In order to be a purist I can see only a few approaches (I guess they could be combined):

1. Make Base/Height have readonly members that can only be set in the constructor

2. Make the Area calculation into a method.

3. Use some kind of factory pattern + readonly members to ensure that although the dependency may exist, the values can only be set by the method that instantiates the Triangle class.

Questions:

1. Is the guideline practical (do you have to model a lot of complexity into your classes in order to support it)? [for example, a SqlConnection class allows you to initialize the connection string property but lets you change individual pieces of it such as command timeout]

2. How do you manage keeping your properties independent of each other?

3. Extra for people who use Silverlight / MVVM type architecture, do you accept dependencies in properties because of the way databinding works to a object? For example, binding a triangle instance that shows height, base and area on screen.

Answer 1

Microsoft is really trying to say "Don't design your class in such a way that calling properties in an arbitrary order will cause unexpected behavior." Users of your class do not expect requesting a value (using a property) to have awkward side effects.

This falls under the principle of least surprise.

I think this is a completely practical guideline to follow. Properties should not have unexpected side effects.

You bring up an excellent question: "How do you manage keeping your properties independent of each other?". Very carefully! I eliminate state (and reduce the number of properties accordingly) as much as possible. Also, partitioning state by breaking up classes is another tactic. This would make an excellent question on its own...

In terms of the triangle class, I think both solutions you presented in code are valid. If it were up to me, I would design the triangle so that it would be immutable, and take in the width and height in the constructor.

Answer 2

The simplest way would be to accept the base and height values only on the constructor and then expose all of them as read-only properties:

class Triangle
{
   private double base;
   private double height;

   private Triangle() { }

   public Triangle(double base, double height)
   {
      this.base = base;
      this.height = height;
   }

   public double Base 
   {
      get 
      {
         return this.base;
      }
   }

   public double Height 
   {
      get 
      {
         return this.height;
      }
   }

   public double Area 
   {
      get 
      {
         return (this.base * this.height) / 2;
      }
   }
}

Answer 3

I think I would go for a Triangle class which has a constructor which takes the Base & Height as parameters, since a Triangle cannot exist (imho) without a base or a height.

Offcourse, the Area property has a dependency on Base & Height, but I see no problem in this ? I think that the MS guideline should be interpreted as follows:

properties should be independent of one another and not rely upon being set in any specific order.

Meaning -imho- that you should not have a constraint that you first have to set the Base property, and only when the Base property has been set, you can set the Height property.
I think that this is what is meant by the above guideline.

Next to that, your Area property is not settable, thus there is no problem with it. :)

Answer 4

Some properties will be inherently related and codependent. The point is that setting base first, then height should have the same effect as setting height, then base. Not setting one of these, then checking the area would not make sense.

Answer 5

Choose option 2. Make Area a method and call it CalculateArea. Properties should be used to encapsulate state and not behavior. That Area can be calculated from Base and Height does not mean that it should itself be state; on the contrary, this is a strong argument that Area should not be state.

class Triangle
{
    public Triangle(double b, double h)
    {
        Base = b;
        Height = h;
    }

    public double Base { get; set; }
    public double Height { get; set; }

    public double CalculateArea()
    {
        return (Base * Height) / 2;
    }
}

This lets consumers know that getting the area of the triangle requires real work, rather than simply accessing state.