Consequences

The Resource Decorator pattern has the following consequences:

Benefits

• Attaches additional behavior to any resource— When you think of extending an object's behavior, subclassing and inheritance often come to mind. However, a subclass must relate to a specific superclass and your application cannot dynamically alter this static relationship at runtime. When applications support multiple database drivers, it is not practical to define identical subclasses for each driver. In addition, the object factories common in standard resource interfaces make it difficult to plug in subclasses for resource objects that are constructed within a driver's factory.

  As an alternative, the Resource Decorator pattern defines the relationship between a Decorator object that defines an additional behavior and any driver resource using a dynamic reference that it connects at runtime.

• Requires minimal changes to application code— Assuming that application code is written in terms of generic resource interfaces, replacing resources with decorators that implement the same interfaces only requires changes to application initialization routines. You can hardwire this initialization, but make sure to isolate it in a single component so that it is easy to update. If you plan to let users or administrators alter this behavior, consider allowing them to designate a specific resource implementation in a registry entry, configuration file, or administration console.

• Has combinatorial characteristics— A resource decorator ultimately delegates operations to a driver resource. However, it references any resource implementation. Since decorators themselves meet this criterion, you can set up decorators to attach behavior to other decorators. This enables you to attach multiple, otherwise decoupled behaviors to a single driver resource in any combination.

Drawback

• Requires complete implementations— For a decorator to implement a resource interface completely, it must implement all of the interface's operations. Even though its delegation implementation is trivial, the number of operations that some resource intefaces define is often in the hundreds. It helps to write this code with an editor's cut and paste feature, but it is easy to inject mistakes in the delegation logic. Compilers will find some, but not all, of these errors.