CSC/ECE 517 Fall 2012/ch2b 2w39 ka: Difference between revisions
| Line 52: | Line 52: | ||
Let's take a look at the diagram definition before we go into more detail. | Let's take a look at the diagram definition before we go into more detail. | ||
[[File:ProxyDesignPattern.png]] | [[File:ProxyDesignPattern.png|none]] | ||
As usual, when dealing with design patterns we code to interfaces. In this case, the interface that the client knows about is the Subject. Both the Proxy and RealSubject objects implement the Subject interface, but the client may not be able to access the RealSubject without going through the Proxy. It's quite common that the Proxy would handle the creation of the RealSubject object, but it will at least have a reference to it so that it can pass messages along. | As usual, when dealing with design patterns we code to interfaces. In this case, the interface that the client knows about is the Subject. Both the Proxy and RealSubject objects implement the Subject interface, but the client may not be able to access the RealSubject without going through the Proxy. It's quite common that the Proxy would handle the creation of the RealSubject object, but it will at least have a reference to it so that it can pass messages along. | ||
Revision as of 16:40, 17 November 2012
Introduction
Describe what Design pattern is and what are we going to discuss in this article.
Decorator Pattern
brief overview
Intent
Problem
Solution
Example
Implementation
Ruby
brief explanation and Sample Code:
type the code here
Java
brief explanation and Sample Code:
type the code here
Adapter Pattern
brief overview
Intent
Problem
Solution
Example
Implementation
Ruby
brief explanation and Sample Code:
type the code here
Java
brief explanation and Sample Code:
type the code here
Proxy Pattern
Sometimes we need the ability to control the access to an object. For example if we need to use only a few methods of some costly objects we'll initialize those objects when we need them entirely. Until that point we can use some light objects exposing the same interface as the heavy objects. These light objects are called proxies and they will instantiate those heavy objects when they are really need and by then we'll use some light objects instead.
Intent
Provide a surrogate or placeholder for another object to control access to it” is the intent provided by GoF<ref>"Gang of four"</ref>
Problem
You need to support resource-hungry objects, and you do not want to instantiate such objects unless and until they are actually requested by the client.
Solution
Design a surrogate, or proxy, object that: instantiates the real object the first time the client makes a request of the proxy, remembers the identity of this real object, and forwards the instigating request to this real object. Then all subsequent requests are simply forwarded directly to the encapsulated real object.
Let's take a look at the diagram definition before we go into more detail.
As usual, when dealing with design patterns we code to interfaces. In this case, the interface that the client knows about is the Subject. Both the Proxy and RealSubject objects implement the Subject interface, but the client may not be able to access the RealSubject without going through the Proxy. It's quite common that the Proxy would handle the creation of the RealSubject object, but it will at least have a reference to it so that it can pass messages along.
Let's take a look at this in action with a sequence diagram.
Example
Implementation
Ruby
brief explanation and Sample Code:
type the code here
Java
brief explanation and Sample Code:
type the code here
Composite Pattern
brief overview
Intent
Problem
Solution
Example
Implementation
Ruby
brief explanation and Sample Code:
type the code here
Java
brief explanation and Sample Code:
type the code here
Comparison of the Patterns
| Comparison | Decorator | Adapter | Proxy | Composite |
|---|---|---|---|---|
| Supports abc | ||||
| Supports def | ||||
| Supports ghi | ||||
| Supports bla | ||||
| Supports bla |
Conclusion
This article makes an attempt to explain the concept of Reflection in Object Oriented Programming. The article mentions the different approaches to reflection in Ruby and other languages.It mentions the usage of Reflections and the advantages and disadvantages of using Reflection. A follow up to this article would be to study the concept of Metaprogramming.
References
<references />