Enjoyable Blog of Possibilities

Jason : I’m ne’er a immense fan of string free-based designs, in the first place because of their lack of compile time validation, etc… however, lets flirt with changing your “Personality” pattern to figure out in.NET…

If you drew the data type of “Personality” be a System.Type object, and then you could do a fairish assignment:

machine.Personality = typeof(ScanSideways);

This stages a could of interesting problems. For the first time, you have a compile time dependancy on the ScanSideways class. Easy fixable by a tenuous change:

machine.Personality = Type.GetType(“ScanSideways”);

Which you can at present parameterize, load from a file, whatever. Thusly far, this is cake. My problem is that we have lots all the type checking. At some point the program will accept the type object (still the powerfully typecast version) and do an Activator.CreateInstance telephone followed by a cast to the right data type. Boom.

In person, I bid there was a way of pining down the constraints of a picky type, some form of validation rules that could be put on (hey, hold back! you named that earliest in your post <G>). For example I could tell:

public class Machine {
    [BaseType(typeof(Personality))]
    Type Personality { catch; set up; }
}

Which could and so gift me hoard time validation for the first example, and a more deterministic error for the second one. Oh well… can’t offer the compiler…

Simply to restate (to make for certain I realize the pattern); the goals of the Personality pattern is to allow a set of property adjustments and validations that are applied on function execution. Kinda like a pre/post condition on methods bundled with a CSS sheet.

Cool.