What are the advantages and disadvantages of the Properties Pattern?

Question

Steve Yegge describes the Properties Pattern in a blog post of his.

For someone using a static language like C# or Java, what are the advantages and dis

Answer 1

I've been digging into this pattern quite a bit myself lately, and I can tell you that finding information on it is pretty tough. Yegge calls it prototype or properties, but both of those are pretty heavily overused, and well known as two other, different patterns. Some people refer to systems like the one Yegge proposes as "stringly[sic] typed" so that's another avenue of research.

It's a really neat idea, and one that has a lot of merit in some applications, and a lot of faults in others. What you gain is essentially a very flexible means of building "types" at runtime, but you lose out on a lot of the languages strong-type checking to do it. The easiest way to implement it would be as a Dictionary. Then you have to use casts to get your string values back out as actual values. The key to keeping such a design manageable is to never directly reference a property in code if you can avoid it. Stuff like theProtoObject["owner"] = "protoman" will kill you if the "canonical" name of that slot changes. It can also lead to issues like JavaScript (which uses this pattern underneath as it's object model) where if you misspell the key name, you'll add a new slot.

One very likely upgrade you'd probably make in a production system is to use some kind of specialized types for values, and some kind of "heavy key" for the key, so you can get a bit of extra typing and safety info on your model.

I've seen a few applications that use it. One surprising example hit me recently while looking up open source code in my industry: insurance quoting. OpenQuote is a very flexible project for quoting insurance of any general type. It's written in Java, but if you know C# it should read quite well. At the very heart of it, lies the Type object, which contains this bit of code:

/** A dynamic collection of attributes describing type */
private List attribute = new ArrayList();

And what is an Attribute? This:

* An attribute is defined as "One of numerous aspects, as of a subject". Generally, another
* type will own a (composite) collection of Attributes which help describe it.

So basically Attribute is a kind of key-value pair containing a unique string ID (the field name) and a string value, and an enumeration of types combined with some regex to verify and process the values. In this way, it can store values of many types, and convert them back out into java values, while providing a bit of safety.

It then goes on to build many domain specific model types on top of that core. So an insurance policy object can be treated as having a flexible, extensible list of benefits on it, which can added or removed or modified at runtime. Each benefit can have properties extended or reduced on them as well.

So that's an example of the pattern in use, and a decent use case for it: insurance policies can be very flexible, at the whim of the underwriters up to the moment of sale, so a highly flexible model works well for it.

The downsides are pretty much what Yegge outlines though. Performance can be bad, especially with a naive implementation. Type-checking and safety take a hit, and your objects are more difficult to reason about because you don't know for sure what properties are on them.