Sometimes it is convenient to provide several distinct capabilities, called facets, to the same base object where these capabilities convey different authority or observed behavior. The normal motivation is where there is state that connects these behaviors.
If the base object is shared among different application components, these components may need different access to the base object. One may provide several weaker facets to the object for dissemination to different parts of the application thus providing better protection than the more conventional pattern of just one strong capability per instance. The Keykos data byte supports this efficiently.
A common sub-pattern is for some of the facets to some object to convey various sub-authorities to that object. We call this “attenuation”. In this case it is common that the weaker capability is polymorphic with the base insofar as only the weaker orders (methods) may be invoked. When there is a clear power relationship between the facets, it is common for the facet to provide a method (order) that returns any strictly weaker facet.
The wrapper pattern can be used to implement facets when there is reason not to modify the implementation of the base object. The holder of a wrapper or facet cannot tell the difference.
If the platform does not provide primitive facets a facet may be built by creating an intermediate object access to which is restricted as you would restrict the facet capability. The object merely appends the facet number to the message which it passes on to the real object which is designed assuming facets.
Here is a generator of objects in Scheme, each with two facets, one to increment a counter and another to read the same counter.
(define (cg) (let ((c 0)) (cons (lambda () (set! c (+ c 1))) (lambda () c)))) (let* ((cp (cg))) ((car cp)) ((car cp)) ((cdr cp)))Contrasted with classical methods of objects facets need not have names and facets may be disseminated without disseminating the whole object.