Jason: I'm never a huge fan of string based designs, primarily because of their lack of compile time validation, etc... however, lets think about modifying your "Personality" pattern to work in .NET...

If you made the data type of "Personality" be a System.Type object, then you could do a reasonable assignment:

machine.Personality = typeof(ScanSideways);

This presents a could of interesting problems. First, you have a compile time dependancy on the ScanSideways class. Easily fixable by a slight change:

machine.Personality = Type.GetType("ScanSideways");

Which you can now parameterize, load from a file, whatever. So far, this is cake. My problem is that we have lots all the type checking. At some point the program will take the type object (even the strongly typed version) and do an Activator.CreateInstance call followed by a cast to the correct data type. Boom.

Personally, I wish there was a way of specifying the constraints of a particular type, some form of validation rules that could be applied (hey, wait! you mentioned that earlier in your post <G>). For example I could say:

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

Which could then give me compile time validation for the first example, and a more deterministic error for the second one. Oh well... can't extend the compiler...

Just to restate (to make sure I understand the pattern); the goals of the Personality pattern is to provide 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.