Question

I’m designing an API with a specific pattern in mind, but don’t know if this pattern has a name. It’s similar to the Command pattern in GoF (Gang of Four) but not exactly.

One simple example of it I can find is in Eclipse where you manipulate a project (IProject), not by calling methods on the project that change its state, but by this 3 step process:

1. extracting its state into a descriptor object (IProjectDescription) with getDescription
2. setting properties on the descriptor. E.g. setName
3. applying the descriptor back to the original project with setDescription

The general principle seems to be that you have a complex object as part of a framework with many potentially interdependent properties, and rather than working directly on that object, one property at a time, you extract the properties into a simple data object, manipulate that, and apply it back.

It has some of the attributes of the Command pattern, in that the data object encapsulates all of the changes like a Command would – but it’s not really a Command, because you don’t execute it on the object, it’s simply a representation of the state of the object.

It also has some attributes of a Transactional API, in that, by making the changes all in one hit with the set... call, you allow for the entire modification to effectively “roll back” if any one property changes fails. But while that’s an advantage of the approach, it’s not really the main purpose of it. And what’s more, you can achieve the transactional nature without this approach, by simply adding transactional methods to the API (like commit and rollback)

There are two advantages in this pattern that I do want to exploit – although I don’t see them being exploited by the eclipse example above:

1. You can represent the meaningful state of the underlying object while its implementation changes. This is useful for upgrading, or copying state from different types of representations. Say I release a new version of my API where I create an object Foo2 which is a totally new form of my old Foo1, but both have the same basic properties. To upgrade a Foo1 to a Foo2, I can extract those properties as a FooState. foo2.setFooState(foo1.getFooState) as simply as that. The way in which the properties are interpreted and represented is encapsulated in the Foos and can be totally different.

2. I can persist and transmit the state of the underlying object with my simple data object, where persisting the object itself would be much more complex. So I can extract the state of Foo as a FooState, and persist it as a simple XML document then later apply it to some new object by “loading” it and applying it. Or I can transmit the FooState simply to a webservice as a JSON object whereas the Foo itself is too big and complex to transmit. (Or the objects on each end of the service call are entirely different, like Foo1 and Foo2)

Anyway, I can’t find an name or example of this pattern anywhere, neither in the Gang of Four design patterns, nor even in Martin Fowler’s comprehensive “bliki”

Answer 1

Data Transfer Object(DTO) that Martin Fowler describes in his book Principles of Enterprise Application Architecture seems to be for the purpose you describe in point 2.

A DTO is a fairly simple extraction of the more complex Domain Model that it represents.

Fowler describes that the usage of a DTO in combination with an assembler can be used to keep the DTO independent from the actual Domain Object(or Objects) that it is supposed to represent. The assembler knows how to create a DTO from the Domain Object and vice versa. Also he mentions that the DTO needs to be serializable to persist/transmit its state. What you describe in point 2 seems to match this description.

What you’ve described in point 1 though does not seem to be an intended purpose, but definitely seems achievable using this pattern.

I’m not sure if you went through the Pattern catalog of his book or the book itself. The book itself describes this in much greater detail.

You may also want to have a look at Transfer Object definition from Oracle which Fowler says here is what he describes as DTO.