1. Proxy, Observer, Symbolic Links Rebecca Chernoff

2. Proxy Pattern Intent – Provide a surrogate or placeholder for another object to control access to it Other Names – Surrogate

3. 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

4. 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.

5. 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.

6. 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.

7. Proxy: Structure

8. 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

9. 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.

10. 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

11. Observer: Motivation Maintain consistency between related objects. – Application Data vs. Presentation Avoid tightly coupled classes that reduce reusability.

12. 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.

13. 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.

14. 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.

15. Observer: Structure

16. Observer: Collaborations

17. 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.

18. 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.

19. 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.

20. 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.

21. 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.

22. 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.

23. 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.

24. But Where Do Surrogates Fit into This? Proxy Pattern – Subject => Node – Proxy => Link – Real Subject => ?

25. But Where Do Surrogates Fit Into This?