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 disadvantages of this approach? In what kind of projects would you want to use the Properties Pattern, and when would you want to avoid it?

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<string,string>. 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> attribute = new ArrayList<Attribute>();

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.

Answer 2

The properties pattern is especially useful (or, it has been for me), when your want to make prototypes of objects or have a development structure that somewhat forces you to have an iterative deployment of your API/Interfaces.

If you start out with an idea of some properties of an object, then you make them. Later on you find (and you have anticipated this finding...) that your understanding of the subject area was not adequate, you make a new object design/behavior based on the prototype of the first object. And so forth. The wiki-page on the subject has a very good description of the subject in conjunction with static typed languages, but I would recommend that you looked into JavaScript or Lua if you're really serious with prototyping development. The properties of prototypes are not mutable in the static typed languages, and this fact will eventually bite you down the road.

Edit: Oh, and I see you link to an excellent post on the subject. Yegges use/explanation of the subject of course does dwarf my own. Please read it through a couple of times and the advantages/implications of the use of the properties pattern in a language like java should be very clear to you.

Edit.2: link to wikipedia article: http://en.wikipedia.org/wiki/Prototype_pattern