Objects need to contact another object, knowing only the object’s name or the name of the service it provides, but not how to contact it. Provide a service that takes the name of an object, service or role and returns a remote proxy that encapsulates the knowledge of how to contact the named object.

The actual code in XP Studio employs some enhancements. One of them is the use of namespaces so that objects in different projects can use the same name.

Another neat trick is to override the equals() method of both PlanningObjectImpl and Reference to make sure that references and the objects they refer to are regarded as the same, which can greatly simplify some code.

Post navigation

3 thoughts on “The Registry Pattern”

Can you elaborate why you need to use a Reference class between the PlanningObject and your repository? It seems to me you could put your PlanningObject right in the HashMap, and still be able to retrieve it by name. Also, letting the PlanningObject evict another object from registry and plant itself in its place as you set it’s name looks like a bad practice. Have a factory that will assemble your services and put them in the registry instead

The Reference is a level of indirection for handling timing issues. For instance, I can get a reference to an object before the object is published in the registry. In the example of XPML, this happens when you load e.g. an iteration before you load the user stories in it. The Reference also makes it possible to write robust code that doesn’t throw NullPointerException when the referenced object is unavailable.

As for replacing another object, there are use cases where this is required. You may not have such a use case, and that’s fine. The code as shown is just one possible implementation of the Registry Pattern. As always, you should look carefully at your own situation, and use code that behaves well in it. This implementation is just one example that can serve as inspiration.

Subscribe

About

Disclaimer

The opinions expressed here are my personal opinions. Content published here is not read or approved in advance by EMC and does not necessarily reflect the views and opinions of EMC nor does it constitute any official communication of EMC.