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.