Proxy, Observer, Symbolic Links

Rebecca Chernoff

Proxy Pattern

Intent– Provide a surrogate or placeholder for another

object to control access to it

Other Names– Surrogate

Proxy: Motivations & Applicability

Local representative of object in a different address space.

Defer cost of creation and initialization. Protection via access control. Reference counting Load a persistent object into memory when

first referenced Object locking

Remote Proxy

Virtual Proxy Protection Proxy

Smart Reference

Proxy: Participants

RealSubject– Defines the real object that the proxy represents.

Subject– Defines the common interface for RealSubject

and Proxy.– Allows for a Proxy to be used wherever a

RealSubject is expected.

Proxy: Participants

Proxy– Maintains a reference to the real subject. May

refer to a Subject if the RealSubject and Subject interfaces are the same.

– Identical interface to Subject so the Proxy can be substituted.

– Controls access to the real subject.– May be responsible for creating and deleting the

real subject.

Proxy: Participants

Additional Responsibilities of Proxy– Remote Proxy

Encode and send the request to the real subject in a different address space.

– Virtual Proxy Cache additional information in order to postpone

accessing the real subject.

– Protection Proxy Check access permissions.

Proxy: Structure

Proxy: Consequences

Introduces a level of indirection– Remote Proxy

Hides fact that object resides in a different address space.

– Virtual Proxy Perform optimizations such as creation on demand.

– Protection Proxy and Smart References Allow additional housekeeping tasks when object is

accessed.

Copy-On-Write

Proxy: Related Patterns

Adapter– Provides a different interface to an object, but

since Proxy can refuse to perform a request, the interface is effectively a subset.

Decorator– Similar implementation to proxy, but different

purpose. Decorator adds responsibilities whereas proxy controls access.

Observer Pattern

Intent– Define a one-to-many dependency between

objects so that when one object changes state, all its dependents are notified and updated automatically

Also Known As– Dependents– Publish-Subscribe

Observer: Motivation

Maintain consistency between related objects.– Application Data vs. Presentation

Avoid tightly coupled classes that reduce reusability.

Observer: Applicability

An abstraction has two aspects, one dependent on the other.

A change to one object requires changing others.

An object should be able to notify other objects without making assumptions about the objects.

Observer: Participants

Observer– Defines an interface for objects to be notified

when a subject changes.

Subject– Defines an interface for attaching and detaching

Observer objects.– Unknown number of Observer objects.

Observer: Participants

ConcreteObserver– Implements the Observer interface to keep its state

consistent with the subject’s.– Maintains a reference to the ConcreteSubject– Stores state that should stay consistent with the subject’s.

ConcreteSubject– Implements the Subject interface to update Observers.– Stores state of interest to ConcreteObserver objects.– Sends a notification to its observers when its state changes.

Observer: Structure

Observer: Collaborations

Observer: Consequences

Vary subjects and observers independently. Abstract coupling between Subject and

Observer. Support for broadcast communication. Simple update to Server may cause a

cascade of updates to Observer and its dependent objects.

Observer: Implementation

Mapping subjects to their observers.– Tradeoff between time and space.

Observing more than one subject.– Observer needs to know which Subject is notifying.

Who triggers the update?– Subject: client doesn’t have to remember to update, but

consecutive operations cause multiple updates.– Observer: client can wait to trigger the update, but client must

remember to call update. Dangling references to deleted subjects.

– Notify observers right before deletion. Observers of multiple Subjects can’t be deleted when just one Subject is deleted.

Observer: Implementation

Making sure the Subject state is self-consistent before notification.

– Use TemplateMethod pattern with Notify as last operation.

Avoiding observer-specific update protocols: the push and pull models.

– Push Model: Detailed information sent regardless.– Pull Model: Observers ask for details explicitly.

Specifying modifications of interest explicitly.– Observers register for a specific aspect of interest.

Observer: Implementation

Encapsulating complex update semantics.– Change-Manager

Takes responsibility of maintaining references to observers away from the Subject.

Defines a particular update strategy. Updates all dependent observers at the request of a subject.

Combining the Subject and Observer classes.– When multiple inheritance not supported by language, both

interfaces may reside in one class.

Observer

Related Patterns– Mediator

The ChangeManager encapsulates complex update semantics, thus acting as a mediator between the Subject and its Observers.

– Singleton ChangeManager may be unique and globally

accessible.

But Where Do Surrogates Fit into This?

File System Example Symbolic Links / Aliases / Shortcuts

– Reference to another node in the file system.– Surrogate for a node, not the node itself.– Own access rights.– Edit and save a file.– Add and remove nodes to a directory.

But Where Do Surrogates Fit into This?

How do I find the right design pattern for the task?– Consider how design patterns solve design problems.– Scan the Intent sections for something that sounds right.– Study how patterns interrelate.– Look at patterns whose purpose corresponds to what you’re

trying to do.– Examine a relevant cause of redesign and apply the

patterns that help you avoid it.– Consider what should be variable in your design.

But Where Do Surrogates Fit into This?

Proxy Pattern– Subject => Node– Proxy => Link– Real Subject => ?

But Where Do Surrogates Fit Into This?