<< Previous <<         [Session1 Index]            >> Next >>

You can implement a more restricted set of capabilities on an object by using the facade pattern. In the example, a File object has a Read/Write facade that just grants ReadStream and WriteStream access to the File (i.e., you could not get the filename or the pathname, nor actually delete the file, though with Write access you could make it a file of length zero). A "trio" subpattern is quite common in capability-based security systems, with a powerful object separated from a user object by a single facade.

As the diagram depicts, you can also build facades on the facades. If, for example, you have access to the Read/Write Facade, and wish to pass read-only authority to another object (perhaps written by yet another software developer), you can simply construct a Read Authority Facade on the more powerful facade.

Technically, this is not quite a facade as defined in the book Design Patterns. A true facade represents a collection of objects, not a single object. This pattern also looks like an adapter pattern, but the purpose of adapters is to standardize interfaces, not restrict them. In the E language, these capability-restricting objects are frequently called facets to avoid confusion with other patterns. A pure facet  embodies no new features, just a subset of capabilities found in another object.