Obiwan Jacobi

I started learning WPF some time ago and the first thing that struck me was the sheer number of properties available on these classes. It turns out that those properties are mainly there to make support for Xaml (declaritive programming) easier/better. But even before WPF, WinForms too had its share of properties on its classes.

So I wondered why would we want to have so many Font-properties on a class in WPF; at least in WinForms its on a Font object and the Form/Control only has a Font property (the answer has probably to do with Xaml -again).

To be more generic: why do we not (in general) design our class properties to be grouped in functional related groups and make these groups class properties themselves?

So instead of (public fields used for clarity):

public class MyClass
{
    public int MinWidth;
    public int MinHeight;
    public int MaxWidth;
    public int MaxHeight;

    // ...more properties
}

Why don't we make code like this:

public class MyClass
{
  public Dimension Dimension = new Dimension();

  public struct Dimension
  {
    public int MinWidth;
    public int MinHeight;
    public int MaxWidth;
    public int MaxHeight;
  }

  // ...more property groups
}

For classes with a lot of properties this would make things a little more navigatable for the user of that class (i would think). When there are several pages of intellisense worth of properties (in the first example) you would be able to reduce that to only a handfull of groups. Note that I propose a property group as a struct: its merely a container for properties and has no functionality of its own.

One of the downsides of this approach could be that accessing the main class from a property implementation in a property group requires passing that reference to all property groups. On the otherhand: most property implementations are pretty simple anyway...

Thoughts?