From http://www.mozilla.org/projects/grendel/arch.html, by TerryWeissman

	One problem that comes from using the javamail API throughout
	is that it makes it difficult to innovate and optimize. For
	example, javamail does not provide an API to get the number of
	undeleted messages in a folder. This is a number we want to
	display in our UIs. We can't just add a new API to our
	subclasses of Folder, because we want to work with third-party
	implementations of Folder as well. And while it's possible to
	determine this number using the existing APIs, it is a very
	slow and expensive process to do so.

	To solve all this, we will define a FolderExtra interface.
	FolderExtra has all the extra APIs we need, like
	getUndeletedMessageCount(). Our implementations of Folder will
	also implement the FolderExtra class.

	When we have code (e.g., our UI code) that is given a Folder
	object and wants to call a method on FolderExtra, it gets a
	FolderExtra object by calling FolderExtraFactory.Get().
	FolderExtraFactory determines if the given Folder directly
	implements FolderExtra. If so, it returns that object. If not,
	it creates a new object which implements all the FolderExtra
 	methods in terms of methods available on Folder.

	This all makes things a bit convoluted for callers. But it
	means we can use our fast code for our own Folders, and be
	assured that things will work (though slower) on Folders
	provided by other parties.

	Similarly, there is a MessageExtra interface and a
	MessageExtraFactory. Other Extra interfaces will be invented
	as necessary.

	It would be nice if we could just use the pk.core.Supports
	interface for this kind of stuff. However, this strategy only
	makes sense if the base Folder object implements Supports.
	Since Supports is one of our own interfaces, and Folder comes
	from javasoft, I can't see this happening.

Beautiful! -- MartinPool

FacetFactory was the best name I could think of; there may be a better or standard one.
-----
''moved from F''''''acetPattern''

A facet is like an interface on an object, except it may actually be a different object that forwards to the real object. This is useful when you want to add an interface to an object, but can't because the implementation of the interface can't be added to the objects code, or because it has different identity semantics.

See FacetFactory for a Java example.
----

This seems similar to the RoleObject pattern: http://www.riehle.org/computer-science-research/1997/plop-1997-role-object.html.

----
CategoryPattern JavaPatterns JavaIdioms