Caretaker Pattern

Described in ParadigmRegained.

A variant on the HandleBodyPattern (a.k.a. WrapperPattern); grants a capability by transparently forwarding messages to a specified receiver (the body), for the purpose of making the capability revocable (for example by later setting its reference to the wrapped receiver to null).

For this to work, the client must not be able to discover a pointer to the body object; only to the caretaker object. (Which can be harder to enforce in practice than it sounds).
In this paper (and in many other uses), the wrapping is transparent, and the body object is unaware that the caretaker even exists, and so does not have even a pointer to the caretaker. This is just a clarification, which does not argue with your main point.

Normally the caretaker has an interface separate from its forwarding interface, that is used to trigger the revocation.

If the system uses permission flags, the caretaker can restrict which permissions are allowed rather than supporting only all-or-nothing revocation. This effectively combines the caretaker with the handle object in FacetPattern.

The authors of ParadigmRegained (the esteemed MarkMiller? and JonathanShapiro?) consider CaretakerPattern to invalidate the argument that capability revocation is infeasible.

Originally discussed in D. D. Redell, Naming and Protection in Extendible Operating Systems, Project MAC TR-140, MIT, November 1974. (Ph. D. thesis.)

I've used a variation on the CaretakerPattern...where the purpose is not capability revocation, but client ID. In a project I worked on, there was an architecture similar to ModelViewController, with multiple controllers. It was useful to know which controller was invoking the model; however the model already had a published API that I didn't want to change (at least not in the application code). So I created a set of "client ID" objects which were essentially proxies for the model; each controller had a unique "client ID" object and invoked the API through that. The client ID object, when delegating to the actual model, included a pointer to itself in the API call; so that the model knew which controller was calling it. Different controllers had different access levels, and this also allowed filtering of the callbacks to the associated views.

This is clearly some kind of HandleBodyPattern, but is it actually a CaretakerPattern?

Not sure if that pattern deserves its own name or not.

This approach is also used in capability systems, when you want an object to be separately revocable for different clients.

Is there generally considered to exist a subclass of the CaretakerPattern, called DataAccessObject?

Comment moved to RevokableCapabilities -- has nothing to do with CaretakerPattern that I can see. -- RK

CategorySecurityPatterns