Facet Pattern

Intent: Restrict an interface to obtain a smaller interface that provides less authority. Usually the smaller interface has only a subset of the methods, or allows only a subset of parameter values.

Facets are used as a security pattern in CapabilityOrientedProgramming, in order to satisfy the PrincipleOfLeastAuthority. For example, if some client of an object only needs to be able to read information from it, that client should be provided with a read-only facet.

Facets should be implemented in such a way that if methods are added to the original interface, they are not added by default to the facet. The methods to be included in a facet should have to be explicitly indicated (although this could be by metadata or a naming convention).

If it is known in advance which facets of an object will be needed, the object can cache them as an optimization.

Like other SecurityPatterns, FacetPattern can be used to improve robustness or safety, even when security per se is not an issue. It may also be useful in some cases to provide a deterministic or purely functional subset of an interface.

A facet differs from an adapter (AdapterPattern) in that the facet interface is always a subset of the original interface, and the purpose is to restrict authority rather than to translate between incompatible interfaces.

FacetPattern is one of several patterns that use "wrapper objects" or the "handle/body idiom". See HandleBodyPattern.

In <http://www.cap-lore.com/CapTheory/Glossary.html>, use of FacetPattern is referred to as attenuation.

There is a CompactForm definition of the Facet pattern at http://jerry.cs.uiuc.edu/~plop/plop2002/final/plop2002_ecrahen0_0.pdf.

That is not FacetPattern as described here. It appears to be FacadePattern.

See also: AdapterPattern, WrapperPattern, DesignPatterns, CapabilityOrientedProgramming

CategorySecurityPatterns