Note that there are some explanatory texts on larger screens.

plurals
  1. POWhat design pattern is used by IProject.setDescription in Eclipse
    text
    copied!<p>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.</p> <p>One simple example of it I can find is in Eclipse where you manipulate a project (<code>IProject</code>), not by calling methods on the project that change its state, but by this 3 step process:</p> <ol> <li><em>extracting</em> its state into a descriptor object (<code>IProjectDescription</code>) with <code>getDescription</code></li> <li><em>setting</em> properties on the descriptor. E.g. <code>setName</code></li> <li><em>applying</em> the descriptor back to the original project with <code>setDescription</code></li> </ol> <p>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.</p> <p>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 <em>execute</em> it on the object, it's simply a representation of the state of the object.</p> <p>It also has some attributes of a Transactional API, in that, by making the changes all in one hit with the <code>set...</code> 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 <code>commit</code> and <code>rollback</code>)</p> <p>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:</p> <ol> <li><p>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.</p></li> <li><p>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)</p></li> </ol> <p>Anyway, I can't find an name or example of this pattern anywhere, neither in <a href="http://en.wikipedia.org/wiki/Design_Patterns">the Gang of Four design patterns</a>, nor even in Martin Fowler's <a href="http://martinfowler.com/tags/API%20design.html">comprehensive "bliki"</a></p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload