Personality goes a long way
Justin says:"Something I've been messing around with for the past couple of days is Business Rule Validation. Basically stuff like this - when Foo = 1, then Bar had better equal 2. As well as, when I set Quux to false, then I need to set FoobleDate to current date time. Simple stuff. In the world of .NET, you can do this using properties. In the set portion of the property, do the validation as well as side effects. The validation will throw exceptions if necessary (InvalidOperationException). Some people will probably disagree with me about this (including myself). Personally I believe if setting a property has the side-effect of changing other properties, then it should be in a method. " [The Wagner Blog] (emphasis mine)
This reminds me of a pattern I stumbled on about three years ago that I call "Personality". In that case I was consulting on software that drove a complex (and expensive!) piece of scanning equipment that had many possible settings with complex interdependencies. For extra fun the machine worked with $100,000 silicon wafers and expensive optics. Grinding the lens into silicon substrate made for a very bad day. The machine was used to do 5 or 6 different types of measurement jobs, and each job had its own settings and options. Job 1 might involve scanning sideways, where Job 2 might be to scan, rotate, scan again.
I came up with a concept I called "Personality" that worked out pretty nicely. Here's how it works. The object representing the machine held a collection of Personality objects, and a property called Personality. For convenience, the setter for Personality was a string. To set up the machine you'd say something like:
machine.Personality = "ScanSideways"
This would select the "ScanSideways" personality object and as a side effect set up the machine to do the "ScanSideways" job (which involved twiddling a number of settings on the machine). Once you'd done that you could call methods on the Personality object that were specific to how the machine was currently configured, so:
machine.Personality.PerformFirstPass
would do the first pass for the current personality (and throw an exception if the machine was set up wrong).
This pattern worked out well because it was naturally extensible - if a new use was found for the machine you simply authored a new Personality class. This was done in like 2000 so it was all obviouly done with COM. The reflection/attributes abilities of .NET would probably make this pattern even more powerful today. Comments?
11:08:04 AM 
|
