Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-20T03:33:52Z

Knagar: /* Java */

==Introduction==
In this section we will be discussing about the decorator pattern and its related patterns such as adapter pattern,proxy pattern and composite pattern.

===Decorator Pattern===
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.
We have an instance, and we put another instance inside of it. They both support the same (or similar) interfaces. The one on the outside is a "decorator." We can use the one on the outside. It either masks, changes, or pass-throughs the methods of the instance inside of it. <ref>[http://www.oodesign.com/decorator-pattern.htmlDecorator Pattern]</ref>
===Intent===
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality as provided by Gang of four. <ref>[http://c2.com/cgi/wiki?GangOfFour"Gang of four"]</ref>
===Problem===
The state of an object can be changed at compile time but no change is possible at run time if the language does not permit so.
===Solution===
Add a decorator module , class that acts as a extender for functions at run time such that the calls are delegated to the decorator
to extend the functionality of the objects at run time.
===Implementation===

====Ruby====
The example shows a Coffee class with a method cost defining its cost as 2.
<ref>[http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.htmlDecorator Pattern and more]</ref>
<pre>

If we want to calculate the cost of a cup of coffee. We have Coffee class, which implements a cost() method.

class Coffee
def cost
2
end
end

But what if we want the cost of a coffee with milk? We could have a new class:

class MilkCoffee
def cost
2.4
end
end

But now if we want cream. And sprinkles. Clearly, creating new classes is going to lead to a huge number of classes in our application. It just isn’t realistic to create classes for different combinations of coffee and extras. It could get worse – what if we have different types of coffee? We would then have to have combinations of extras with each different type of coffee.Hence we will use decorator pattern.

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

And thats all you need. You can include this into any class you want to act as a decorator. You can then use that decorator as if it was the object it is decorating; by default all messages sent to the decorator are forwarded on to the decorated object. You can then decorate the methods you need to extend:

class Milk
include Decorator

def cost
@decorated.cost + 0.4
end
end

So how does this solve our original problem? The real power of decorators lies in the fact that they can act like the objects they are decorating. By taking this one step further, you can wrap decorators with other decorators as long as they share the same interface. By creating decorators for our different “extras”, we can create coffees using a combination of decorators and get the total cost of the coffee.

class Whip
include Decorator

def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

</pre>

====Java====
In this java example <ref>[http://java-x.blogspot.com/2007/01/implementing-decorator-pattern-in-java.htmlImplementing Decorator Pattern]</ref>
basicInterface: Defines the interface for objects that can have responsibilities added to them dynamically.
Basic: Defines an object to which additional responsibilities can be attached.
Decorator: maintains a reference to a Basic object and defines an interface that conforms to Basic's interface.
ConcreteDecorator: adds responsibilities to the component.
<pre>

public interface basicInterface {
public void do();
}

public class Basic implements basicInterface{
public void do() {
System.out.println("Do basic stuff");
}
}

public interface Decorator extends basicInterface {
public void addedStuff();
}

public class ConcreteDecorator implements Decorator {

basicInterface basic;

public ConcreteDecorator(basicInterface basic) {
super();
this.basic = basic;
}

public void addedStuff() {
System.out.println("Decorator does other stuff too");

}

public void do() {
basic.do();
addedStuff();
}
}

public class Client {
public static void main(String[] args) {
basicInterface comp = new Basic();
Decorator decorator = new ConcreteDecorator(comp);
decorator.do();
}
}

</pre>

In this way we can add concrete decorator classes to provided the added functionality to the basic class.

==Adapter Pattern==
Adapter pattern acts as a bridge between objects. It adapts to the changing needs of the classes using interface. In real world we have adapters for power supplies, adapters for camera memory cards etc.If a class is expecting some type of object and we have an object offering the same features, but exposing a different interface we want to use both of them so instead of implementing them again and changing existing classes,we can create an adapter.
===Intent===
Match an existing object to a particular interface.
===Problem===
A system has the right data and behavior but the wrong interface. Typically used when you have to make something a
derivative of an abstract class you already have or are defining.
===Solution===
Convert original interface component into another one through an intermediate adapter.Solution: The adapter provides a “wrapper” with the desired
interface
===Implementation===

====Ruby====
The Adapter offers exactly the same interface as the adaptee, but it can override any method or add new ones. In the below code the
adapter code delegates the call to the adaptee and performs operations according to the client requirements by performing additional operation to the results returned by the adaptee.
features
<ref>[http://www.scribd.com/doc/396559/gof-patterns-in-rubyGof Adapter Pattern]</ref>
<pre>
class Adaptee
def talk
puts "I'm Adaptee"
end
def whine
puts "Stop bullying me!"
end
end

class Adapter
def initialize
@adaptee=Adaptee.new
end
def talk
#override
puts "Let me introduce you to Adaptee!"
@adaptee.talk
puts "That was my adaptee"
end
def do_other_stuff
puts "I'm versatile"
end
def method_missing method
if
@adaptee.respond_to? method@adaptee.sendmethod
else
raise NotImplementedError,"This method is not "+\ "available on this interface"
end
end
end
if__FILE__==$0
adapter=Adapter.new
adapter.talk
adapter.whine
adapter.do_other_stuff
end
</pre>

output -
Let me introduce you to Adaptee!
I'm Adaptee
That was my adaptee
Stop bullying me!
I'm versatile

====Java====
The following example shows a simple implementation of the pattern. Consider that we have a third party library that provides sorting functionality through it's NumberSorter class.This is our adaptee, a third party implementation of a number sorter that deals with Lists, not arrays.[http://java.dzone.com/articles/design-patterns-uncovered-0]
<pre>
public class NumberSorter
{
public List<Integer> sort(List<Integer> numbers)
{
//sort and return
return new ArrayList<Integer>();
}
}
</pre>

Our Client deals with primitive arrays rather than Lists. For the sake of this example, lets say we can't change the client to use Lists.
<pre>
int[] numbers = new int[]{34, 2, 4, 12, 1};
Sorter sorter = new SortListAdapter();
sorter.sort(numbers);
</pre>

We've provided a Sorter interface that expects the client input. This is our target.
<pre>
public interface Sorter
{
public int[] sort(int[] numbers);
}
</pre>
Finally, the SortListAdapter implements our target interface and deals with our adaptee, NumberSorter
<pre>
public class SortListAdapter implements Sorter
{
@Override
public int[] sort(int[] numbers)
{
//convert the array to a List
List<Integer> numberList = new ArrayList<Integer>();
//call the adapter
NumberSorter sorter = new NumberSorter();
numberList = sorter.sort(numberList);

//convert the list back to an array and return
return sortedNumbers;
}
}
</pre>

===Difference between Decorator Pattern and Adapter Pattern===
Adapters can be used for decorating but their primary aim is to for enabling classes of different types not able to communicate
because of incompatible interface to interact via a adapter interface.
Inheritance and composition is used to achieve this.Decorators on the other hand are not used to add different methods to all the instances instead they are used to add specific behavior to some specific instances. Though Adapters making use of composition may also be used here, but the intention is different here with what it's in case of a Adapter.
<ref>[http://geekexplains.blogspot.com/2008/09/structural-patterns-adapter-decorator.htmlStructural Patterns]</ref>

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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

===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.
[[File:ProxyDesignPattern.png|none]]

As usual, when dealing with design patterns we code to [http://en.wikipedia.org/wiki/Interface_(computing) 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 [http://en.wikipedia.org/wiki/Sequence_diagram sequence diagram].
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable <ref>[http://java.dzone.com/articles/design-patterns-proxyProxy Pattern]</ref>
.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use [http://en.wikipedia.org/wiki/Tree_structure tree structure] and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern. <ref>[http://www.oodesign.com/composite-pattern.htmlComposite Pattern]</ref>
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
<ref>[http://blog.rubybestpractices.com/posts/gregory/060-issue-26-structural-design-patterns.htmlImplementation in ruby]</ref>
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==Conclusion==
This article makes an attempt to explain the concept of Decorator Pattern and other similar patterns such as Proxy Pattern, Adapter Pattern and Composite Pattern. It also explains how each of these related patterns differ from decorator pattern.

==References==
<references />
==Additional Reading==
*[http://www.oodesign.com/composite-pattern.html Composite Pattern]
*[http://javapapers.com/design-patterns/proxy-design-pattern/ Brief overview of proxy pattern]
*[http://javapapers.com/design-patterns/composite-design-pattern/ Brief overview of Composite Pattern]
*[http://blog.rubybestpractices.com/posts/gregory/060-issue-26-structural-design-patterns.html Patterns in Ruby]
*[http://www.simonecarletti.com/blog/2010/05/understanding-ruby-and-rails-proxy-patter-delegation-and-basicobject/ Proxy pattern in Ruby]
*[http://powerdream5.wordpress.com/2007/11/17/the-differences-between-decorator-pattern-and-proxy-pattern/ Differences between Proxy and Decorator pattern]
*[http://java.dzone.com/articles/design-patterns-composite composite Pattern]
*[http://www.codeproject.com/Articles/29036/Patterns-in-Real-Life Real life examples]
*[http://blog.ashwinraghav.com/2011/03/14/design-patterns-in-ruby-composite-iterator-commandpart-2/ Composite Pattern in Ruby]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-20T03:33:05Z

Knagar: /* Ruby */

==Introduction==
In this section we will be discussing about the decorator pattern and its related patterns such as adapter pattern,proxy pattern and composite pattern.

===Decorator Pattern===
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.
We have an instance, and we put another instance inside of it. They both support the same (or similar) interfaces. The one on the outside is a "decorator." We can use the one on the outside. It either masks, changes, or pass-throughs the methods of the instance inside of it. <ref>[http://www.oodesign.com/decorator-pattern.htmlDecorator Pattern]</ref>
===Intent===
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality as provided by Gang of four. <ref>[http://c2.com/cgi/wiki?GangOfFour"Gang of four"]</ref>
===Problem===
The state of an object can be changed at compile time but no change is possible at run time if the language does not permit so.
===Solution===
Add a decorator module , class that acts as a extender for functions at run time such that the calls are delegated to the decorator
to extend the functionality of the objects at run time.
===Implementation===

====Ruby====
The example shows a Coffee class with a method cost defining its cost as 2.
<ref>[http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.htmlDecorator Pattern and more]</ref>
<pre>

If we want to calculate the cost of a cup of coffee. We have Coffee class, which implements a cost() method.

class Coffee
def cost
2
end
end

But what if we want the cost of a coffee with milk? We could have a new class:

class MilkCoffee
def cost
2.4
end
end

But now if we want cream. And sprinkles. Clearly, creating new classes is going to lead to a huge number of classes in our application. It just isn’t realistic to create classes for different combinations of coffee and extras. It could get worse – what if we have different types of coffee? We would then have to have combinations of extras with each different type of coffee.Hence we will use decorator pattern.

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

And thats all you need. You can include this into any class you want to act as a decorator. You can then use that decorator as if it was the object it is decorating; by default all messages sent to the decorator are forwarded on to the decorated object. You can then decorate the methods you need to extend:

class Milk
include Decorator

def cost
@decorated.cost + 0.4
end
end

So how does this solve our original problem? The real power of decorators lies in the fact that they can act like the objects they are decorating. By taking this one step further, you can wrap decorators with other decorators as long as they share the same interface. By creating decorators for our different “extras”, we can create coffees using a combination of decorators and get the total cost of the coffee.

class Whip
include Decorator

def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

</pre>

====Java====
In this java example <ref>[http://java-x.blogspot.com/2007/01/implementing-decorator-pattern-in-java.htmlImplementing Decorator Pattern]</ref>
basicInterface: Defines the interface for objects that can have responsibilities added to them dynamically.
Basic: Defines an object to which additional responsibilities can be attached.
Decorator: maintains a reference to a Basic object and defines an interface that conforms to Basic's interface.
ConcreteDecorator: adds responsibilities to the component.
<pre>

public interface basicInterface {
public void do();
}

public class Basic implements basicInterface{
public void do() {
System.out.println("Do basic stuff");
}
}

public interface Decorator extends basicInterface {
public void addedStuff();
}

public class ConcreteDecorator implements Decorator {

basicInterface basic;

public ConcreteDecorator(basicInterface basic) {
super();
this.basic = basic;
}

public void addedStuff() {
System.out.println("Decorator does other stuff too");

}

public void do() {
basic.do();
addedStuff();
}
}

public class Client {
public static void main(String[] args) {
basicInterface comp = new Basic();
Decorator decorator = new ConcreteDecorator(comp);
decorator.do();
}
}

</pre>

In this way we can add concrete decorator classes to provided the added functionality to the basic class.

==Adapter Pattern==
Adapter pattern acts as a bridge between objects. It adapts to the changing needs of the classes using interface. In real world we have adapters for power supplies, adapters for camera memory cards etc.If a class is expecting some type of object and we have an object offering the same features, but exposing a different interface we want to use both of them so instead of implementing them again and changing existing classes,we can create an adapter.
===Intent===
Match an existing object to a particular interface.
===Problem===
A system has the right data and behavior but the wrong interface. Typically used when you have to make something a
derivative of an abstract class you already have or are defining.
===Solution===
Convert original interface component into another one through an intermediate adapter.Solution: The adapter provides a “wrapper” with the desired
interface
===Implementation===

====Ruby====
The Adapter offers exactly the same interface as the adaptee, but it can override any method or add new ones. In the below code the
adapter code delegates the call to the adaptee and performs operations according to the client requirements by performing additional operation to the results returned by the adaptee.
features
<ref>[http://www.scribd.com/doc/396559/gof-patterns-in-rubyGof Adapter Pattern]</ref>
<pre>
class Adaptee
def talk
puts "I'm Adaptee"
end
def whine
puts "Stop bullying me!"
end
end

class Adapter
def initialize
@adaptee=Adaptee.new
end
def talk
#override
puts "Let me introduce you to Adaptee!"
@adaptee.talk
puts "That was my adaptee"
end
def do_other_stuff
puts "I'm versatile"
end
def method_missing method
if
@adaptee.respond_to? method@adaptee.sendmethod
else
raise NotImplementedError,"This method is not "+\ "available on this interface"
end
end
end
if__FILE__==$0
adapter=Adapter.new
adapter.talk
adapter.whine
adapter.do_other_stuff
end
</pre>

output -
Let me introduce you to Adaptee!
I'm Adaptee
That was my adaptee
Stop bullying me!
I'm versatile

====Java====
The following example shows a simple implementation of the pattern. Consider that we have a third party library that provides sorting functionality through it's NumberSorter class.This is our adaptee, a third party implementation of a number sorter that deals with Lists, not arrays.[http://java.dzone.com/articles/design-patterns-uncovered-0]
<pre>
public class NumberSorter
{
public List<Integer> sort(List<Integer> numbers)
{
//sort and return
return new ArrayList<Integer>();
}
}
</pre>

Our Client deals with primitive arrays rather than Lists. For the sake of this example, lets say we can't change the client to use Lists.
<pre>
int[] numbers = new int[]{34, 2, 4, 12, 1};
Sorter sorter = new SortListAdapter();
sorter.sort(numbers);
</pre>

We've provided a Sorter interface that expects the client input. This is our target.
//this is our Target interface
<pre>
public interface Sorter
{
public int[] sort(int[] numbers);
}
</pre>
Finally, the SortListAdapter implements our target interface and deals with our adaptee, NumberSorter
<pre>
public class SortListAdapter implements Sorter
{
@Override
public int[] sort(int[] numbers)
{
//convert the array to a List
List<Integer> numberList = new ArrayList<Integer>();
//call the adapter
NumberSorter sorter = new NumberSorter();
numberList = sorter.sort(numberList);

//convert the list back to an array and return
return sortedNumbers;
}
}
</pre>

===Difference between Decorator Pattern and Adapter Pattern===
Adapters can be used for decorating but their primary aim is to for enabling classes of different types not able to communicate
because of incompatible interface to interact via a adapter interface.
Inheritance and composition is used to achieve this.Decorators on the other hand are not used to add different methods to all the instances instead they are used to add specific behavior to some specific instances. Though Adapters making use of composition may also be used here, but the intention is different here with what it's in case of a Adapter.
<ref>[http://geekexplains.blogspot.com/2008/09/structural-patterns-adapter-decorator.htmlStructural Patterns]</ref>

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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

===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.
[[File:ProxyDesignPattern.png|none]]

As usual, when dealing with design patterns we code to [http://en.wikipedia.org/wiki/Interface_(computing) 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 [http://en.wikipedia.org/wiki/Sequence_diagram sequence diagram].
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable <ref>[http://java.dzone.com/articles/design-patterns-proxyProxy Pattern]</ref>
.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use [http://en.wikipedia.org/wiki/Tree_structure tree structure] and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern. <ref>[http://www.oodesign.com/composite-pattern.htmlComposite Pattern]</ref>
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
<ref>[http://blog.rubybestpractices.com/posts/gregory/060-issue-26-structural-design-patterns.htmlImplementation in ruby]</ref>
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==Conclusion==
This article makes an attempt to explain the concept of Decorator Pattern and other similar patterns such as Proxy Pattern, Adapter Pattern and Composite Pattern. It also explains how each of these related patterns differ from decorator pattern.

==References==
<references />
==Additional Reading==
*[http://www.oodesign.com/composite-pattern.html Composite Pattern]
*[http://javapapers.com/design-patterns/proxy-design-pattern/ Brief overview of proxy pattern]
*[http://javapapers.com/design-patterns/composite-design-pattern/ Brief overview of Composite Pattern]
*[http://blog.rubybestpractices.com/posts/gregory/060-issue-26-structural-design-patterns.html Patterns in Ruby]
*[http://www.simonecarletti.com/blog/2010/05/understanding-ruby-and-rails-proxy-patter-delegation-and-basicobject/ Proxy pattern in Ruby]
*[http://powerdream5.wordpress.com/2007/11/17/the-differences-between-decorator-pattern-and-proxy-pattern/ Differences between Proxy and Decorator pattern]
*[http://java.dzone.com/articles/design-patterns-composite composite Pattern]
*[http://www.codeproject.com/Articles/29036/Patterns-in-Real-Life Real life examples]
*[http://blog.ashwinraghav.com/2011/03/14/design-patterns-in-ruby-composite-iterator-commandpart-2/ Composite Pattern in Ruby]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-20T03:32:46Z

Knagar: /* Ruby */

==Introduction==
In this section we will be discussing about the decorator pattern and its related patterns such as adapter pattern,proxy pattern and composite pattern.

===Decorator Pattern===
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.
We have an instance, and we put another instance inside of it. They both support the same (or similar) interfaces. The one on the outside is a "decorator." We can use the one on the outside. It either masks, changes, or pass-throughs the methods of the instance inside of it. <ref>[http://www.oodesign.com/decorator-pattern.htmlDecorator Pattern]</ref>
===Intent===
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality as provided by Gang of four. <ref>[http://c2.com/cgi/wiki?GangOfFour"Gang of four"]</ref>
===Problem===
The state of an object can be changed at compile time but no change is possible at run time if the language does not permit so.
===Solution===
Add a decorator module , class that acts as a extender for functions at run time such that the calls are delegated to the decorator
to extend the functionality of the objects at run time.
===Implementation===

====Ruby====
The example shows a Coffee class with a method cost defining its cost as 4.
<ref>[http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.htmlDecorator Pattern and more]</ref>
<pre>

If we want to calculate the cost of a cup of coffee. We have Coffee class, which implements a cost() method.

class Coffee
def cost
2
end
end

But what if we want the cost of a coffee with milk? We could have a new class:

class MilkCoffee
def cost
2.4
end
end

But now if we want cream. And sprinkles. Clearly, creating new classes is going to lead to a huge number of classes in our application. It just isn’t realistic to create classes for different combinations of coffee and extras. It could get worse – what if we have different types of coffee? We would then have to have combinations of extras with each different type of coffee.Hence we will use decorator pattern.

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

And thats all you need. You can include this into any class you want to act as a decorator. You can then use that decorator as if it was the object it is decorating; by default all messages sent to the decorator are forwarded on to the decorated object. You can then decorate the methods you need to extend:

class Milk
include Decorator

def cost
@decorated.cost + 0.4
end
end

So how does this solve our original problem? The real power of decorators lies in the fact that they can act like the objects they are decorating. By taking this one step further, you can wrap decorators with other decorators as long as they share the same interface. By creating decorators for our different “extras”, we can create coffees using a combination of decorators and get the total cost of the coffee.

class Whip
include Decorator

def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

</pre>

====Java====
In this java example <ref>[http://java-x.blogspot.com/2007/01/implementing-decorator-pattern-in-java.htmlImplementing Decorator Pattern]</ref>
basicInterface: Defines the interface for objects that can have responsibilities added to them dynamically.
Basic: Defines an object to which additional responsibilities can be attached.
Decorator: maintains a reference to a Basic object and defines an interface that conforms to Basic's interface.
ConcreteDecorator: adds responsibilities to the component.
<pre>

public interface basicInterface {
public void do();
}

public class Basic implements basicInterface{
public void do() {
System.out.println("Do basic stuff");
}
}

public interface Decorator extends basicInterface {
public void addedStuff();
}

public class ConcreteDecorator implements Decorator {

basicInterface basic;

public ConcreteDecorator(basicInterface basic) {
super();
this.basic = basic;
}

public void addedStuff() {
System.out.println("Decorator does other stuff too");

}

public void do() {
basic.do();
addedStuff();
}
}

public class Client {
public static void main(String[] args) {
basicInterface comp = new Basic();
Decorator decorator = new ConcreteDecorator(comp);
decorator.do();
}
}

</pre>

In this way we can add concrete decorator classes to provided the added functionality to the basic class.

==Adapter Pattern==
Adapter pattern acts as a bridge between objects. It adapts to the changing needs of the classes using interface. In real world we have adapters for power supplies, adapters for camera memory cards etc.If a class is expecting some type of object and we have an object offering the same features, but exposing a different interface we want to use both of them so instead of implementing them again and changing existing classes,we can create an adapter.
===Intent===
Match an existing object to a particular interface.
===Problem===
A system has the right data and behavior but the wrong interface. Typically used when you have to make something a
derivative of an abstract class you already have or are defining.
===Solution===
Convert original interface component into another one through an intermediate adapter.Solution: The adapter provides a “wrapper” with the desired
interface
===Implementation===

====Ruby====
The Adapter offers exactly the same interface as the adaptee, but it can override any method or add new ones. In the below code the
adapter code delegates the call to the adaptee and performs operations according to the client requirements by performing additional operation to the results returned by the adaptee.
features
<ref>[http://www.scribd.com/doc/396559/gof-patterns-in-rubyGof Adapter Pattern]</ref>
<pre>
class Adaptee
def talk
puts "I'm Adaptee"
end
def whine
puts "Stop bullying me!"
end
end

class Adapter
def initialize
@adaptee=Adaptee.new
end
def talk
#override
puts "Let me introduce you to Adaptee!"
@adaptee.talk
puts "That was my adaptee"
end
def do_other_stuff
puts "I'm versatile"
end
def method_missing method
if
@adaptee.respond_to? method@adaptee.sendmethod
else
raise NotImplementedError,"This method is not "+\ "available on this interface"
end
end
end
if__FILE__==$0
adapter=Adapter.new
adapter.talk
adapter.whine
adapter.do_other_stuff
end
</pre>

output -
Let me introduce you to Adaptee!
I'm Adaptee
That was my adaptee
Stop bullying me!
I'm versatile

====Java====
The following example shows a simple implementation of the pattern. Consider that we have a third party library that provides sorting functionality through it's NumberSorter class.This is our adaptee, a third party implementation of a number sorter that deals with Lists, not arrays.[http://java.dzone.com/articles/design-patterns-uncovered-0]
<pre>
public class NumberSorter
{
public List<Integer> sort(List<Integer> numbers)
{
//sort and return
return new ArrayList<Integer>();
}
}
</pre>

Our Client deals with primitive arrays rather than Lists. For the sake of this example, lets say we can't change the client to use Lists.
<pre>
int[] numbers = new int[]{34, 2, 4, 12, 1};
Sorter sorter = new SortListAdapter();
sorter.sort(numbers);
</pre>

We've provided a Sorter interface that expects the client input. This is our target.
//this is our Target interface
<pre>
public interface Sorter
{
public int[] sort(int[] numbers);
}
</pre>
Finally, the SortListAdapter implements our target interface and deals with our adaptee, NumberSorter
<pre>
public class SortListAdapter implements Sorter
{
@Override
public int[] sort(int[] numbers)
{
//convert the array to a List
List<Integer> numberList = new ArrayList<Integer>();
//call the adapter
NumberSorter sorter = new NumberSorter();
numberList = sorter.sort(numberList);

//convert the list back to an array and return
return sortedNumbers;
}
}
</pre>

===Difference between Decorator Pattern and Adapter Pattern===
Adapters can be used for decorating but their primary aim is to for enabling classes of different types not able to communicate
because of incompatible interface to interact via a adapter interface.
Inheritance and composition is used to achieve this.Decorators on the other hand are not used to add different methods to all the instances instead they are used to add specific behavior to some specific instances. Though Adapters making use of composition may also be used here, but the intention is different here with what it's in case of a Adapter.
<ref>[http://geekexplains.blogspot.com/2008/09/structural-patterns-adapter-decorator.htmlStructural Patterns]</ref>

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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

===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.
[[File:ProxyDesignPattern.png|none]]

As usual, when dealing with design patterns we code to [http://en.wikipedia.org/wiki/Interface_(computing) 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 [http://en.wikipedia.org/wiki/Sequence_diagram sequence diagram].
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable <ref>[http://java.dzone.com/articles/design-patterns-proxyProxy Pattern]</ref>
.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use [http://en.wikipedia.org/wiki/Tree_structure tree structure] and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern. <ref>[http://www.oodesign.com/composite-pattern.htmlComposite Pattern]</ref>
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
<ref>[http://blog.rubybestpractices.com/posts/gregory/060-issue-26-structural-design-patterns.htmlImplementation in ruby]</ref>
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==Conclusion==
This article makes an attempt to explain the concept of Decorator Pattern and other similar patterns such as Proxy Pattern, Adapter Pattern and Composite Pattern. It also explains how each of these related patterns differ from decorator pattern.

==References==
<references />
==Additional Reading==
*[http://www.oodesign.com/composite-pattern.html Composite Pattern]
*[http://javapapers.com/design-patterns/proxy-design-pattern/ Brief overview of proxy pattern]
*[http://javapapers.com/design-patterns/composite-design-pattern/ Brief overview of Composite Pattern]
*[http://blog.rubybestpractices.com/posts/gregory/060-issue-26-structural-design-patterns.html Patterns in Ruby]
*[http://www.simonecarletti.com/blog/2010/05/understanding-ruby-and-rails-proxy-patter-delegation-and-basicobject/ Proxy pattern in Ruby]
*[http://powerdream5.wordpress.com/2007/11/17/the-differences-between-decorator-pattern-and-proxy-pattern/ Differences between Proxy and Decorator pattern]
*[http://java.dzone.com/articles/design-patterns-composite composite Pattern]
*[http://www.codeproject.com/Articles/29036/Patterns-in-Real-Life Real life examples]
*[http://blog.ashwinraghav.com/2011/03/14/design-patterns-in-ruby-composite-iterator-commandpart-2/ Composite Pattern in Ruby]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-20T03:31:59Z

Knagar: /* Introduction */

==Introduction==
In this section we will be discussing about the decorator pattern and its related patterns such as adapter pattern,proxy pattern and composite pattern.

===Decorator Pattern===
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.
We have an instance, and we put another instance inside of it. They both support the same (or similar) interfaces. The one on the outside is a "decorator." We can use the one on the outside. It either masks, changes, or pass-throughs the methods of the instance inside of it. <ref>[http://www.oodesign.com/decorator-pattern.htmlDecorator Pattern]</ref>
===Intent===
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality as provided by Gang of four. <ref>[http://c2.com/cgi/wiki?GangOfFour"Gang of four"]</ref>
===Problem===
The state of an object can be changed at compile time but no change is possible at run time if the language does not permit so.
===Solution===
Add a decorator module , class that acts as a extender for functions at run time such that the calls are delegated to the decorator
to extend the functionality of the objects at run time.
===Implementation===

====Ruby====
The example shows a Tea class with a method cost defining its cost as 4.
<ref>[http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.htmlDecorator Pattern and more]</ref>
<pre>

If we want to calculate the cost of a cup of coffee. We have Coffee class, which implements a cost() method.

class Coffee
def cost
2
end
end

But what if we want the cost of a coffee with milk? We could have a new class:

class MilkCoffee
def cost
2.4
end
end

But now if we want cream. And sprinkles. Clearly, creating new classes is going to lead to a huge number of classes in our application. It just isn’t realistic to create classes for different combinations of coffee and extras. It could get worse – what if we have different types of coffee? We would then have to have combinations of extras with each different type of coffee.Hence we will use decorator pattern.

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

And thats all you need. You can include this into any class you want to act as a decorator. You can then use that decorator as if it was the object it is decorating; by default all messages sent to the decorator are forwarded on to the decorated object. You can then decorate the methods you need to extend:

class Milk
include Decorator

def cost
@decorated.cost + 0.4
end
end

So how does this solve our original problem? The real power of decorators lies in the fact that they can act like the objects they are decorating. By taking this one step further, you can wrap decorators with other decorators as long as they share the same interface. By creating decorators for our different “extras”, we can create coffees using a combination of decorators and get the total cost of the coffee.

class Whip
include Decorator

def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

</pre>

====Java====
In this java example <ref>[http://java-x.blogspot.com/2007/01/implementing-decorator-pattern-in-java.htmlImplementing Decorator Pattern]</ref>
basicInterface: Defines the interface for objects that can have responsibilities added to them dynamically.
Basic: Defines an object to which additional responsibilities can be attached.
Decorator: maintains a reference to a Basic object and defines an interface that conforms to Basic's interface.
ConcreteDecorator: adds responsibilities to the component.
<pre>

public interface basicInterface {
public void do();
}

public class Basic implements basicInterface{
public void do() {
System.out.println("Do basic stuff");
}
}

public interface Decorator extends basicInterface {
public void addedStuff();
}

public class ConcreteDecorator implements Decorator {

basicInterface basic;

public ConcreteDecorator(basicInterface basic) {
super();
this.basic = basic;
}

public void addedStuff() {
System.out.println("Decorator does other stuff too");

}

public void do() {
basic.do();
addedStuff();
}
}

public class Client {
public static void main(String[] args) {
basicInterface comp = new Basic();
Decorator decorator = new ConcreteDecorator(comp);
decorator.do();
}
}

</pre>

In this way we can add concrete decorator classes to provided the added functionality to the basic class.

==Adapter Pattern==
Adapter pattern acts as a bridge between objects. It adapts to the changing needs of the classes using interface. In real world we have adapters for power supplies, adapters for camera memory cards etc.If a class is expecting some type of object and we have an object offering the same features, but exposing a different interface we want to use both of them so instead of implementing them again and changing existing classes,we can create an adapter.
===Intent===
Match an existing object to a particular interface.
===Problem===
A system has the right data and behavior but the wrong interface. Typically used when you have to make something a
derivative of an abstract class you already have or are defining.
===Solution===
Convert original interface component into another one through an intermediate adapter.Solution: The adapter provides a “wrapper” with the desired
interface
===Implementation===

====Ruby====
The Adapter offers exactly the same interface as the adaptee, but it can override any method or add new ones. In the below code the
adapter code delegates the call to the adaptee and performs operations according to the client requirements by performing additional operation to the results returned by the adaptee.
features
<ref>[http://www.scribd.com/doc/396559/gof-patterns-in-rubyGof Adapter Pattern]</ref>
<pre>
class Adaptee
def talk
puts "I'm Adaptee"
end
def whine
puts "Stop bullying me!"
end
end

class Adapter
def initialize
@adaptee=Adaptee.new
end
def talk
#override
puts "Let me introduce you to Adaptee!"
@adaptee.talk
puts "That was my adaptee"
end
def do_other_stuff
puts "I'm versatile"
end
def method_missing method
if
@adaptee.respond_to? method@adaptee.sendmethod
else
raise NotImplementedError,"This method is not "+\ "available on this interface"
end
end
end
if__FILE__==$0
adapter=Adapter.new
adapter.talk
adapter.whine
adapter.do_other_stuff
end
</pre>

output -
Let me introduce you to Adaptee!
I'm Adaptee
That was my adaptee
Stop bullying me!
I'm versatile

====Java====
The following example shows a simple implementation of the pattern. Consider that we have a third party library that provides sorting functionality through it's NumberSorter class.This is our adaptee, a third party implementation of a number sorter that deals with Lists, not arrays.[http://java.dzone.com/articles/design-patterns-uncovered-0]
<pre>
public class NumberSorter
{
public List<Integer> sort(List<Integer> numbers)
{
//sort and return
return new ArrayList<Integer>();
}
}
</pre>

Our Client deals with primitive arrays rather than Lists. For the sake of this example, lets say we can't change the client to use Lists.
<pre>
int[] numbers = new int[]{34, 2, 4, 12, 1};
Sorter sorter = new SortListAdapter();
sorter.sort(numbers);
</pre>

We've provided a Sorter interface that expects the client input. This is our target.
//this is our Target interface
<pre>
public interface Sorter
{
public int[] sort(int[] numbers);
}
</pre>
Finally, the SortListAdapter implements our target interface and deals with our adaptee, NumberSorter
<pre>
public class SortListAdapter implements Sorter
{
@Override
public int[] sort(int[] numbers)
{
//convert the array to a List
List<Integer> numberList = new ArrayList<Integer>();
//call the adapter
NumberSorter sorter = new NumberSorter();
numberList = sorter.sort(numberList);

//convert the list back to an array and return
return sortedNumbers;
}
}
</pre>

===Difference between Decorator Pattern and Adapter Pattern===
Adapters can be used for decorating but their primary aim is to for enabling classes of different types not able to communicate
because of incompatible interface to interact via a adapter interface.
Inheritance and composition is used to achieve this.Decorators on the other hand are not used to add different methods to all the instances instead they are used to add specific behavior to some specific instances. Though Adapters making use of composition may also be used here, but the intention is different here with what it's in case of a Adapter.
<ref>[http://geekexplains.blogspot.com/2008/09/structural-patterns-adapter-decorator.htmlStructural Patterns]</ref>

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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

===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.
[[File:ProxyDesignPattern.png|none]]

As usual, when dealing with design patterns we code to [http://en.wikipedia.org/wiki/Interface_(computing) 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 [http://en.wikipedia.org/wiki/Sequence_diagram sequence diagram].
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable <ref>[http://java.dzone.com/articles/design-patterns-proxyProxy Pattern]</ref>
.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use [http://en.wikipedia.org/wiki/Tree_structure tree structure] and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern. <ref>[http://www.oodesign.com/composite-pattern.htmlComposite Pattern]</ref>
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
<ref>[http://blog.rubybestpractices.com/posts/gregory/060-issue-26-structural-design-patterns.htmlImplementation in ruby]</ref>
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==Conclusion==
This article makes an attempt to explain the concept of Decorator Pattern and other similar patterns such as Proxy Pattern, Adapter Pattern and Composite Pattern. It also explains how each of these related patterns differ from decorator pattern.

==References==
<references />
==Additional Reading==
*[http://www.oodesign.com/composite-pattern.html Composite Pattern]
*[http://javapapers.com/design-patterns/proxy-design-pattern/ Brief overview of proxy pattern]
*[http://javapapers.com/design-patterns/composite-design-pattern/ Brief overview of Composite Pattern]
*[http://blog.rubybestpractices.com/posts/gregory/060-issue-26-structural-design-patterns.html Patterns in Ruby]
*[http://www.simonecarletti.com/blog/2010/05/understanding-ruby-and-rails-proxy-patter-delegation-and-basicobject/ Proxy pattern in Ruby]
*[http://powerdream5.wordpress.com/2007/11/17/the-differences-between-decorator-pattern-and-proxy-pattern/ Differences between Proxy and Decorator pattern]
*[http://java.dzone.com/articles/design-patterns-composite composite Pattern]
*[http://www.codeproject.com/Articles/29036/Patterns-in-Real-Life Real life examples]
*[http://blog.ashwinraghav.com/2011/03/14/design-patterns-in-ruby-composite-iterator-commandpart-2/ Composite Pattern in Ruby]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-20T03:30:26Z

Knagar:

==Introduction==
In this section we will be discussing about the decorator pattern and its related patterns such as adapter,proxy and composite.

===Decorator Pattern===
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.
We have an instance, and we put another instance inside of it. They both support the same (or similar) interfaces. The one on the outside is a "decorator." We can use the one on the outside. It either masks, changes, or pass-throughs the methods of the instance inside of it. <ref>[http://www.oodesign.com/decorator-pattern.htmlDecorator Pattern]</ref>
===Intent===
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality as provided by Gang of four. <ref>[http://c2.com/cgi/wiki?GangOfFour"Gang of four"]</ref>
===Problem===
The state of an object can be changed at compile time but no change is possible at run time if the language does not permit so.
===Solution===
Add a decorator module , class that acts as a extender for functions at run time such that the calls are delegated to the decorator
to extend the functionality of the objects at run time.
===Implementation===

====Ruby====
The example shows a Tea class with a method cost defining its cost as 4.
<ref>[http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.htmlDecorator Pattern and more]</ref>
<pre>

If we want to calculate the cost of a cup of coffee. We have Coffee class, which implements a cost() method.

class Coffee
def cost
2
end
end

But what if we want the cost of a coffee with milk? We could have a new class:

class MilkCoffee
def cost
2.4
end
end

But now if we want cream. And sprinkles. Clearly, creating new classes is going to lead to a huge number of classes in our application. It just isn’t realistic to create classes for different combinations of coffee and extras. It could get worse – what if we have different types of coffee? We would then have to have combinations of extras with each different type of coffee.Hence we will use decorator pattern.

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

And thats all you need. You can include this into any class you want to act as a decorator. You can then use that decorator as if it was the object it is decorating; by default all messages sent to the decorator are forwarded on to the decorated object. You can then decorate the methods you need to extend:

class Milk
include Decorator

def cost
@decorated.cost + 0.4
end
end

So how does this solve our original problem? The real power of decorators lies in the fact that they can act like the objects they are decorating. By taking this one step further, you can wrap decorators with other decorators as long as they share the same interface. By creating decorators for our different “extras”, we can create coffees using a combination of decorators and get the total cost of the coffee.

class Whip
include Decorator

def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

</pre>

====Java====
In this java example <ref>[http://java-x.blogspot.com/2007/01/implementing-decorator-pattern-in-java.htmlImplementing Decorator Pattern]</ref>
basicInterface: Defines the interface for objects that can have responsibilities added to them dynamically.
Basic: Defines an object to which additional responsibilities can be attached.
Decorator: maintains a reference to a Basic object and defines an interface that conforms to Basic's interface.
ConcreteDecorator: adds responsibilities to the component.
<pre>

public interface basicInterface {
public void do();
}

public class Basic implements basicInterface{
public void do() {
System.out.println("Do basic stuff");
}
}

public interface Decorator extends basicInterface {
public void addedStuff();
}

public class ConcreteDecorator implements Decorator {

basicInterface basic;

public ConcreteDecorator(basicInterface basic) {
super();
this.basic = basic;
}

public void addedStuff() {
System.out.println("Decorator does other stuff too");

}

public void do() {
basic.do();
addedStuff();
}
}

public class Client {
public static void main(String[] args) {
basicInterface comp = new Basic();
Decorator decorator = new ConcreteDecorator(comp);
decorator.do();
}
}

</pre>

In this way we can add concrete decorator classes to provided the added functionality to the basic class.

==Adapter Pattern==
Adapter pattern acts as a bridge between objects. It adapts to the changing needs of the classes using interface. In real world we have adapters for power supplies, adapters for camera memory cards etc.If a class is expecting some type of object and we have an object offering the same features, but exposing a different interface we want to use both of them so instead of implementing them again and changing existing classes,we can create an adapter.
===Intent===
Match an existing object to a particular interface.
===Problem===
A system has the right data and behavior but the wrong interface. Typically used when you have to make something a
derivative of an abstract class you already have or are defining.
===Solution===
Convert original interface component into another one through an intermediate adapter.Solution: The adapter provides a “wrapper” with the desired
interface
===Implementation===

====Ruby====
The Adapter offers exactly the same interface as the adaptee, but it can override any method or add new ones. In the below code the
adapter code delegates the call to the adaptee and performs operations according to the client requirements by performing additional operation to the results returned by the adaptee.
features
<ref>[http://www.scribd.com/doc/396559/gof-patterns-in-rubyGof Adapter Pattern]</ref>
<pre>
class Adaptee
def talk
puts "I'm Adaptee"
end
def whine
puts "Stop bullying me!"
end
end

class Adapter
def initialize
@adaptee=Adaptee.new
end
def talk
#override
puts "Let me introduce you to Adaptee!"
@adaptee.talk
puts "That was my adaptee"
end
def do_other_stuff
puts "I'm versatile"
end
def method_missing method
if
@adaptee.respond_to? method@adaptee.sendmethod
else
raise NotImplementedError,"This method is not "+\ "available on this interface"
end
end
end
if__FILE__==$0
adapter=Adapter.new
adapter.talk
adapter.whine
adapter.do_other_stuff
end
</pre>

output -
Let me introduce you to Adaptee!
I'm Adaptee
That was my adaptee
Stop bullying me!
I'm versatile

====Java====
The following example shows a simple implementation of the pattern. Consider that we have a third party library that provides sorting functionality through it's NumberSorter class.This is our adaptee, a third party implementation of a number sorter that deals with Lists, not arrays.[http://java.dzone.com/articles/design-patterns-uncovered-0]
<pre>
public class NumberSorter
{
public List<Integer> sort(List<Integer> numbers)
{
//sort and return
return new ArrayList<Integer>();
}
}
</pre>

Our Client deals with primitive arrays rather than Lists. For the sake of this example, lets say we can't change the client to use Lists.
<pre>
int[] numbers = new int[]{34, 2, 4, 12, 1};
Sorter sorter = new SortListAdapter();
sorter.sort(numbers);
</pre>

We've provided a Sorter interface that expects the client input. This is our target.
//this is our Target interface
<pre>
public interface Sorter
{
public int[] sort(int[] numbers);
}
</pre>
Finally, the SortListAdapter implements our target interface and deals with our adaptee, NumberSorter
<pre>
public class SortListAdapter implements Sorter
{
@Override
public int[] sort(int[] numbers)
{
//convert the array to a List
List<Integer> numberList = new ArrayList<Integer>();
//call the adapter
NumberSorter sorter = new NumberSorter();
numberList = sorter.sort(numberList);

//convert the list back to an array and return
return sortedNumbers;
}
}
</pre>

===Difference between Decorator Pattern and Adapter Pattern===
Adapters can be used for decorating but their primary aim is to for enabling classes of different types not able to communicate
because of incompatible interface to interact via a adapter interface.
Inheritance and composition is used to achieve this.Decorators on the other hand are not used to add different methods to all the instances instead they are used to add specific behavior to some specific instances. Though Adapters making use of composition may also be used here, but the intention is different here with what it's in case of a Adapter.
<ref>[http://geekexplains.blogspot.com/2008/09/structural-patterns-adapter-decorator.htmlStructural Patterns]</ref>

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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

===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.
[[File:ProxyDesignPattern.png|none]]

As usual, when dealing with design patterns we code to [http://en.wikipedia.org/wiki/Interface_(computing) 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 [http://en.wikipedia.org/wiki/Sequence_diagram sequence diagram].
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable <ref>[http://java.dzone.com/articles/design-patterns-proxyProxy Pattern]</ref>
.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use [http://en.wikipedia.org/wiki/Tree_structure tree structure] and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern. <ref>[http://www.oodesign.com/composite-pattern.htmlComposite Pattern]</ref>
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
<ref>[http://blog.rubybestpractices.com/posts/gregory/060-issue-26-structural-design-patterns.htmlImplementation in ruby]</ref>
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==Conclusion==
This article makes an attempt to explain the concept of Decorator Pattern and other similar patterns such as Proxy Pattern, Adapter Pattern and Composite Pattern. It also explains how each of these related patterns differ from decorator pattern.

==References==
<references />
==Additional Reading==
*[http://www.oodesign.com/composite-pattern.html Composite Pattern]
*[http://javapapers.com/design-patterns/proxy-design-pattern/ Brief overview of proxy pattern]
*[http://javapapers.com/design-patterns/composite-design-pattern/ Brief overview of Composite Pattern]
*[http://blog.rubybestpractices.com/posts/gregory/060-issue-26-structural-design-patterns.html Patterns in Ruby]
*[http://www.simonecarletti.com/blog/2010/05/understanding-ruby-and-rails-proxy-patter-delegation-and-basicobject/ Proxy pattern in Ruby]
*[http://powerdream5.wordpress.com/2007/11/17/the-differences-between-decorator-pattern-and-proxy-pattern/ Differences between Proxy and Decorator pattern]
*[http://java.dzone.com/articles/design-patterns-composite composite Pattern]
*[http://www.codeproject.com/Articles/29036/Patterns-in-Real-Life Real life examples]
*[http://blog.ashwinraghav.com/2011/03/14/design-patterns-in-ruby-composite-iterator-commandpart-2/ Composite Pattern in Ruby]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-20T03:29:57Z

Knagar:

===Decorator and Related Patterns===
==Introduction==
In this section we will be discussing about the decorator pattern and its related patterns such as adapter,proxy and composite.

===Decorator Pattern===
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.
We have an instance, and we put another instance inside of it. They both support the same (or similar) interfaces. The one on the outside is a "decorator." We can use the one on the outside. It either masks, changes, or pass-throughs the methods of the instance inside of it. <ref>[http://www.oodesign.com/decorator-pattern.htmlDecorator Pattern]</ref>
===Intent===
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality as provided by Gang of four. <ref>[http://c2.com/cgi/wiki?GangOfFour"Gang of four"]</ref>
===Problem===
The state of an object can be changed at compile time but no change is possible at run time if the language does not permit so.
===Solution===
Add a decorator module , class that acts as a extender for functions at run time such that the calls are delegated to the decorator
to extend the functionality of the objects at run time.
===Implementation===

====Ruby====
The example shows a Tea class with a method cost defining its cost as 4.
<ref>[http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.htmlDecorator Pattern and more]</ref>
<pre>

If we want to calculate the cost of a cup of coffee. We have Coffee class, which implements a cost() method.

class Coffee
def cost
2
end
end

But what if we want the cost of a coffee with milk? We could have a new class:

class MilkCoffee
def cost
2.4
end
end

But now if we want cream. And sprinkles. Clearly, creating new classes is going to lead to a huge number of classes in our application. It just isn’t realistic to create classes for different combinations of coffee and extras. It could get worse – what if we have different types of coffee? We would then have to have combinations of extras with each different type of coffee.Hence we will use decorator pattern.

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

And thats all you need. You can include this into any class you want to act as a decorator. You can then use that decorator as if it was the object it is decorating; by default all messages sent to the decorator are forwarded on to the decorated object. You can then decorate the methods you need to extend:

class Milk
include Decorator

def cost
@decorated.cost + 0.4
end
end

So how does this solve our original problem? The real power of decorators lies in the fact that they can act like the objects they are decorating. By taking this one step further, you can wrap decorators with other decorators as long as they share the same interface. By creating decorators for our different “extras”, we can create coffees using a combination of decorators and get the total cost of the coffee.

class Whip
include Decorator

def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

</pre>

====Java====
In this java example <ref>[http://java-x.blogspot.com/2007/01/implementing-decorator-pattern-in-java.htmlImplementing Decorator Pattern]</ref>
basicInterface: Defines the interface for objects that can have responsibilities added to them dynamically.
Basic: Defines an object to which additional responsibilities can be attached.
Decorator: maintains a reference to a Basic object and defines an interface that conforms to Basic's interface.
ConcreteDecorator: adds responsibilities to the component.
<pre>

public interface basicInterface {
public void do();
}

public class Basic implements basicInterface{
public void do() {
System.out.println("Do basic stuff");
}
}

public interface Decorator extends basicInterface {
public void addedStuff();
}

public class ConcreteDecorator implements Decorator {

basicInterface basic;

public ConcreteDecorator(basicInterface basic) {
super();
this.basic = basic;
}

public void addedStuff() {
System.out.println("Decorator does other stuff too");

}

public void do() {
basic.do();
addedStuff();
}
}

public class Client {
public static void main(String[] args) {
basicInterface comp = new Basic();
Decorator decorator = new ConcreteDecorator(comp);
decorator.do();
}
}

</pre>

In this way we can add concrete decorator classes to provided the added functionality to the basic class.

==Adapter Pattern==
Adapter pattern acts as a bridge between objects. It adapts to the changing needs of the classes using interface. In real world we have adapters for power supplies, adapters for camera memory cards etc.If a class is expecting some type of object and we have an object offering the same features, but exposing a different interface we want to use both of them so instead of implementing them again and changing existing classes,we can create an adapter.
===Intent===
Match an existing object to a particular interface.
===Problem===
A system has the right data and behavior but the wrong interface. Typically used when you have to make something a
derivative of an abstract class you already have or are defining.
===Solution===
Convert original interface component into another one through an intermediate adapter.Solution: The adapter provides a “wrapper” with the desired
interface
===Implementation===

====Ruby====
The Adapter offers exactly the same interface as the adaptee, but it can override any method or add new ones. In the below code the
adapter code delegates the call to the adaptee and performs operations according to the client requirements by performing additional operation to the results returned by the adaptee.
features
<ref>[http://www.scribd.com/doc/396559/gof-patterns-in-rubyGof Adapter Pattern]</ref>
<pre>
class Adaptee
def talk
puts "I'm Adaptee"
end
def whine
puts "Stop bullying me!"
end
end

class Adapter
def initialize
@adaptee=Adaptee.new
end
def talk
#override
puts "Let me introduce you to Adaptee!"
@adaptee.talk
puts "That was my adaptee"
end
def do_other_stuff
puts "I'm versatile"
end
def method_missing method
if
@adaptee.respond_to? method@adaptee.sendmethod
else
raise NotImplementedError,"This method is not "+\ "available on this interface"
end
end
end
if__FILE__==$0
adapter=Adapter.new
adapter.talk
adapter.whine
adapter.do_other_stuff
end
</pre>

output -
Let me introduce you to Adaptee!
I'm Adaptee
That was my adaptee
Stop bullying me!
I'm versatile

====Java====
The following example shows a simple implementation of the pattern. Consider that we have a third party library that provides sorting functionality through it's NumberSorter class.This is our adaptee, a third party implementation of a number sorter that deals with Lists, not arrays.[http://java.dzone.com/articles/design-patterns-uncovered-0]
<pre>
public class NumberSorter
{
public List<Integer> sort(List<Integer> numbers)
{
//sort and return
return new ArrayList<Integer>();
}
}
</pre>

Our Client deals with primitive arrays rather than Lists. For the sake of this example, lets say we can't change the client to use Lists.
<pre>
int[] numbers = new int[]{34, 2, 4, 12, 1};
Sorter sorter = new SortListAdapter();
sorter.sort(numbers);
</pre>

We've provided a Sorter interface that expects the client input. This is our target.
//this is our Target interface
<pre>
public interface Sorter
{
public int[] sort(int[] numbers);
}
</pre>
Finally, the SortListAdapter implements our target interface and deals with our adaptee, NumberSorter
<pre>
public class SortListAdapter implements Sorter
{
@Override
public int[] sort(int[] numbers)
{
//convert the array to a List
List<Integer> numberList = new ArrayList<Integer>();
//call the adapter
NumberSorter sorter = new NumberSorter();
numberList = sorter.sort(numberList);

//convert the list back to an array and return
return sortedNumbers;
}
}
</pre>

===Difference between Decorator Pattern and Adapter Pattern===
Adapters can be used for decorating but their primary aim is to for enabling classes of different types not able to communicate
because of incompatible interface to interact via a adapter interface.
Inheritance and composition is used to achieve this.Decorators on the other hand are not used to add different methods to all the instances instead they are used to add specific behavior to some specific instances. Though Adapters making use of composition may also be used here, but the intention is different here with what it's in case of a Adapter.
<ref>[http://geekexplains.blogspot.com/2008/09/structural-patterns-adapter-decorator.htmlStructural Patterns]</ref>

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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

===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.
[[File:ProxyDesignPattern.png|none]]

As usual, when dealing with design patterns we code to [http://en.wikipedia.org/wiki/Interface_(computing) 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 [http://en.wikipedia.org/wiki/Sequence_diagram sequence diagram].
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable <ref>[http://java.dzone.com/articles/design-patterns-proxyProxy Pattern]</ref>
.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use [http://en.wikipedia.org/wiki/Tree_structure tree structure] and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern. <ref>[http://www.oodesign.com/composite-pattern.htmlComposite Pattern]</ref>
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
<ref>[http://blog.rubybestpractices.com/posts/gregory/060-issue-26-structural-design-patterns.htmlImplementation in ruby]</ref>
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==Conclusion==
This article makes an attempt to explain the concept of Decorator Pattern and other similar patterns such as Proxy Pattern, Adapter Pattern and Composite Pattern. It also explains how each of these related patterns differ from decorator pattern.

==References==
<references />
==Additional Reading==
*[http://www.oodesign.com/composite-pattern.html Composite Pattern]
*[http://javapapers.com/design-patterns/proxy-design-pattern/ Brief overview of proxy pattern]
*[http://javapapers.com/design-patterns/composite-design-pattern/ Brief overview of Composite Pattern]
*[http://blog.rubybestpractices.com/posts/gregory/060-issue-26-structural-design-patterns.html Patterns in Ruby]
*[http://www.simonecarletti.com/blog/2010/05/understanding-ruby-and-rails-proxy-patter-delegation-and-basicobject/ Proxy pattern in Ruby]
*[http://powerdream5.wordpress.com/2007/11/17/the-differences-between-decorator-pattern-and-proxy-pattern/ Differences between Proxy and Decorator pattern]
*[http://java.dzone.com/articles/design-patterns-composite composite Pattern]
*[http://www.codeproject.com/Articles/29036/Patterns-in-Real-Life Real life examples]
*[http://blog.ashwinraghav.com/2011/03/14/design-patterns-in-ruby-composite-iterator-commandpart-2/ Composite Pattern in Ruby]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-18T03:24:17Z

Knagar: /* Intent */

==Introduction==
In this section we will be discussing about the decorator pattern and its related patterns such as adapter,proxy and composite.

===Decorator Pattern===
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.
We have an instance, and we put another instance inside of it. They both support the same (or similar) interfaces. The one on the outside is a "decorator." We can use the one on the outside. It either masks, changes, or pass-throughs the methods of the instance inside of it. <ref>[http://www.oodesign.com/decorator-pattern.htmlDecorator Pattern]</ref>
===Intent===
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality as provided by Gang of four. <ref>[http://c2.com/cgi/wiki?GangOfFour"Gang of four"]</ref>
===Problem===
The state of an object can be changed at compile time but no change is possible at run time if the language does not permit so.
===Solution===
Add a decorator module , class that acts as a extender for functions at run time such that the calls are delegated to the decorator
to extend the functionality of the objects at run time.
===Implementation===

====Ruby====
The example shows a Tea class with a method cost defining its cost as 4.
<ref>[http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.htmlDecorator Pattern and more]</ref>
<pre>

If we want to calculate the cost of a cup of coffee. We have Coffee class, which implements a cost() method.

class Coffee
def cost
2
end
end

But what if we want the cost of a coffee with milk? We could have a new class:

class MilkCoffee
def cost
2.4
end
end

But now if we want cream. And sprinkles. Clearly, creating new classes is going to lead to a huge number of classes in our application. It just isn’t realistic to create classes for different combinations of coffee and extras. It could get worse – what if we have different types of coffee? We would then have to have combinations of extras with each different type of coffee.Hence we will use decorator pattern.

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

And thats all you need. You can include this into any class you want to act as a decorator. You can then use that decorator as if it was the object it is decorating; by default all messages sent to the decorator are forwarded on to the decorated object. You can then decorate the methods you need to extend:

class Milk
include Decorator

def cost
@decorated.cost + 0.4
end
end

So how does this solve our original problem? The real power of decorators lies in the fact that they can act like the objects they are decorating. By taking this one step further, you can wrap decorators with other decorators as long as they share the same interface. By creating decorators for our different “extras”, we can create coffees using a combination of decorators and get the total cost of the coffee.

class Whip
include Decorator

def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

</pre>

====Java====
In this java example <ref>[http://java-x.blogspot.com/2007/01/implementing-decorator-pattern-in-java.htmlImplementing Decorator Pattern]</ref>
basicInterface: Defines the interface for objects that can have responsibilities added to them dynamically.
Basic: Defines an object to which additional responsibilities can be attached.
Decorator: maintains a reference to a Basic object and defines an interface that conforms to Basic's interface.
ConcreteDecorator: adds responsibilities to the component.
<pre>

public interface basicInterface {
public void do();
}

public class Basic implements basicInterface{
public void do() {
System.out.println("Do basic stuff");
}
}

public interface Decorator extends basicInterface {
public void addedStuff();
}

public class ConcreteDecorator implements Decorator {

basicInterface basic;

public ConcreteDecorator(basicInterface basic) {
super();
this.basic = basic;
}

public void addedStuff() {
System.out.println("Decorator does other stuff too");

}

public void do() {
basic.do();
addedStuff();
}
}

public class Client {
public static void main(String[] args) {
basicInterface comp = new Basic();
Decorator decorator = new ConcreteDecorator(comp);
decorator.do();
}
}

</pre>

In this way we can add concrete decorator classes to provided the added functionality to the basic class.

==Adapter Pattern==
Adapter pattern acts as a bridge between objects. It adapts to the changing needs of the classes using interface. In real world we have adapters for power supplies, adapters for camera memory cards etc.If a class is expecting some type of object and we have an object offering the same features, but exposing a different interface we want to use both of them so instead of implementing them again and changing existing classes,we can create an adapter.
===Intent===
Match an existing object to a particular interface.
===Problem===
A system has the right data and behavior but the wrong interface. Typically used when you have to make something a
derivative of an abstract class you already have or are defining.
===Solution===
Convert original interface component into another one through an intermediate adapter.Solution: The adapter provides a “wrapper” with the desired
interface
===Implementation===

====Ruby====
The Adapter offers exactly the same interface as the adaptee, but it can override any method or add new ones. In the below code the
adapter code delegates the call to the adaptee and performs operations according to the client requirements by performing additional operation to the results returned by the adaptee.
features
<ref>[http://www.scribd.com/doc/396559/gof-patterns-in-rubyGof Adapter Pattern]</ref>
<pre>
class Adaptee
def talk
puts "I'm Adaptee"
end
def whine
puts "Stop bullying me!"
end
end

class Adapter
def initialize
@adaptee=Adaptee.new
end
def talk
#override
puts "Let me introduce you to Adaptee!"
@adaptee.talk
puts "That was my adaptee"
end
def do_other_stuff
puts "I'm versatile"
end
def method_missing method
if
@adaptee.respond_to? method@adaptee.sendmethod
else
raise NotImplementedError,"This method is not "+\ "available on this interface"
end
end
end
if__FILE__==$0
adapter=Adapter.new
adapter.talk
adapter.whine
adapter.do_other_stuff
end
</pre>

output -
Let me introduce you to Adaptee!
I'm Adaptee
That was my adaptee
Stop bullying me!
I'm versatile

====Java====
The following example shows a simple implementation of the pattern. Consider that we have a third party library that provides sorting functionality through it's NumberSorter class.This is our adaptee, a third party implementation of a number sorter that deals with Lists, not arrays.[http://java.dzone.com/articles/design-patterns-uncovered-0]
<pre>
public class NumberSorter
{
public List<Integer> sort(List<Integer> numbers)
{
//sort and return
return new ArrayList<Integer>();
}
}
</pre>

Our Client deals with primitive arrays rather than Lists. For the sake of this example, lets say we can't change the client to use Lists.
<pre>
int[] numbers = new int[]{34, 2, 4, 12, 1};
Sorter sorter = new SortListAdapter();
sorter.sort(numbers);
</pre>

We've provided a Sorter interface that expects the client input. This is our target.
//this is our Target interface
<pre>
public interface Sorter
{
public int[] sort(int[] numbers);
}
</pre>
Finally, the SortListAdapter implements our target interface and deals with our adaptee, NumberSorter
<pre>
public class SortListAdapter implements Sorter
{
@Override
public int[] sort(int[] numbers)
{
//convert the array to a List
List<Integer> numberList = new ArrayList<Integer>();
//call the adapter
NumberSorter sorter = new NumberSorter();
numberList = sorter.sort(numberList);

//convert the list back to an array and return
return sortedNumbers;
}
}
</pre>

===Difference between Decorator Pattern and Adapter Pattern===
Adapters can be used for decorating but their primary aim is to for enabling classes of different types not able to communicate
because of incompatible interface to interact via a adapter interface.
Inheritance and composition is used to achieve this.Decorators on the other hand are not used to add different methods to all the instances instead they are used to add specific behavior to some specific instances. Though Adapters making use of composition may also be used here, but the intention is different here with what it's in case of a Adapter.
<ref>[http://geekexplains.blogspot.com/2008/09/structural-patterns-adapter-decorator.htmlStructural Patterns]</ref>

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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

===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.
[[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.

Let's take a look at this in action with a sequence diagram.
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use tree structure and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern.
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==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 [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references />
==Additional Reading==
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]
*[http://www.slideshare.net/MarcusDenker/behavioral-reflection Behavioral reflection]
*[http://msdn.microsoft.com/en-us/library/67ef8sbd(v=vs.80).aspx C# Basics]
*[http://msdn.microsoft.com/en-us/library/ms173183(v=vs.80).aspx C# Reflection basics]
*[http://www.codeguru.com/csharp/csharp/cs_misc/reflection/article.php/c4257/An-Introduction-to-Reflection-in-C.htm Introduction to C# Reflection]
*[http://oreilly.com/catalog/progcsharp/chapter/ch18.html C# Attributes and Reflection]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-18T03:23:38Z

Knagar: /* Intent */

==Introduction==
In this section we will be discussing about the decorator pattern and its related patterns such as adapter,proxy and composite.

===Decorator Pattern===
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.
We have an instance, and we put another instance inside of it. They both support the same (or similar) interfaces. The one on the outside is a "decorator." We can use the one on the outside. It either masks, changes, or pass-throughs the methods of the instance inside of it. <ref>[http://www.oodesign.com/decorator-pattern.htmlDecorator Pattern]</ref>
===Intent===
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality as provided by Gang of four. <ref>[http://c2.com/cgi/wiki?GangOfFour"Gang of four"]</ref>
===Problem===
The state of an object can be changed at compile time but no change is possible at run time if the language does not permit so.
===Solution===
Add a decorator module , class that acts as a extender for functions at run time such that the calls are delegated to the decorator
to extend the functionality of the objects at run time.
===Implementation===

====Ruby====
The example shows a Tea class with a method cost defining its cost as 4.
<ref>[http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.htmlDecorator Pattern and more]</ref>
<pre>

If we want to calculate the cost of a cup of coffee. We have Coffee class, which implements a cost() method.

class Coffee
def cost
2
end
end

But what if we want the cost of a coffee with milk? We could have a new class:

class MilkCoffee
def cost
2.4
end
end

But now if we want cream. And sprinkles. Clearly, creating new classes is going to lead to a huge number of classes in our application. It just isn’t realistic to create classes for different combinations of coffee and extras. It could get worse – what if we have different types of coffee? We would then have to have combinations of extras with each different type of coffee.Hence we will use decorator pattern.

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

And thats all you need. You can include this into any class you want to act as a decorator. You can then use that decorator as if it was the object it is decorating; by default all messages sent to the decorator are forwarded on to the decorated object. You can then decorate the methods you need to extend:

class Milk
include Decorator

def cost
@decorated.cost + 0.4
end
end

So how does this solve our original problem? The real power of decorators lies in the fact that they can act like the objects they are decorating. By taking this one step further, you can wrap decorators with other decorators as long as they share the same interface. By creating decorators for our different “extras”, we can create coffees using a combination of decorators and get the total cost of the coffee.

class Whip
include Decorator

def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

</pre>

====Java====
In this java example <ref>[http://java-x.blogspot.com/2007/01/implementing-decorator-pattern-in-java.htmlImplementing Decorator Pattern]</ref>
basicInterface: Defines the interface for objects that can have responsibilities added to them dynamically.
Basic: Defines an object to which additional responsibilities can be attached.
Decorator: maintains a reference to a Basic object and defines an interface that conforms to Basic's interface.
ConcreteDecorator: adds responsibilities to the component.
<pre>

public interface basicInterface {
public void do();
}

public class Basic implements basicInterface{
public void do() {
System.out.println("Do basic stuff");
}
}

public interface Decorator extends basicInterface {
public void addedStuff();
}

public class ConcreteDecorator implements Decorator {

basicInterface basic;

public ConcreteDecorator(basicInterface basic) {
super();
this.basic = basic;
}

public void addedStuff() {
System.out.println("Decorator does other stuff too");

}

public void do() {
basic.do();
addedStuff();
}
}

public class Client {
public static void main(String[] args) {
basicInterface comp = new Basic();
Decorator decorator = new ConcreteDecorator(comp);
decorator.do();
}
}

</pre>

In this way we can add concrete decorator classes to provided the added functionality to the basic class.

==Adapter Pattern==
Adapter pattern acts as a bridge between objects. It adapts to the changing needs of the classes using interface. In real world we have adapters for power supplies, adapters for camera memory cards etc.If a class is expecting some type of object and we have an object offering the same features, but exposing a different interface we want to use both of them so instead of implementing them again and changing existing classes,we can create an adapter.
===Intent===
Match an existing object to a particular interface.
===Problem===
A system has the right data and behavior but the wrong interface. Typically used when you have to make something a
derivative of an abstract class you already have or are defining.
===Solution===
Convert original interface component into another one through an intermediate adapter.Solution: The adapter provides a “wrapper” with the desired
interface
===Implementation===

====Ruby====
The Adapter offers exactly the same interface as the adaptee, but it can override any method or add new ones. In the below code the
adapter code delegates the call to the adaptee and performs operations according to the client requirements by performing additional operation to the results returned by the adaptee.
features
<ref>[http://www.scribd.com/doc/396559/gof-patterns-in-rubyGof Adapter Pattern]</ref>
<pre>
class Adaptee
def talk
puts "I'm Adaptee"
end
def whine
puts "Stop bullying me!"
end
end

class Adapter
def initialize
@adaptee=Adaptee.new
end
def talk
#override
puts "Let me introduce you to Adaptee!"
@adaptee.talk
puts "That was my adaptee"
end
def do_other_stuff
puts "I'm versatile"
end
def method_missing method
if
@adaptee.respond_to? method@adaptee.sendmethod
else
raise NotImplementedError,"This method is not "+\ "available on this interface"
end
end
end
if__FILE__==$0
adapter=Adapter.new
adapter.talk
adapter.whine
adapter.do_other_stuff
end
</pre>

output -
Let me introduce you to Adaptee!
I'm Adaptee
That was my adaptee
Stop bullying me!
I'm versatile

====Java====
The following example shows a simple implementation of the pattern. Consider that we have a third party library that provides sorting functionality through it's NumberSorter class.This is our adaptee, a third party implementation of a number sorter that deals with Lists, not arrays.[http://java.dzone.com/articles/design-patterns-uncovered-0]
<pre>
public class NumberSorter
{
public List<Integer> sort(List<Integer> numbers)
{
//sort and return
return new ArrayList<Integer>();
}
}
</pre>

Our Client deals with primitive arrays rather than Lists. For the sake of this example, lets say we can't change the client to use Lists.
<pre>
int[] numbers = new int[]{34, 2, 4, 12, 1};
Sorter sorter = new SortListAdapter();
sorter.sort(numbers);
</pre>

We've provided a Sorter interface that expects the client input. This is our target.
//this is our Target interface
<pre>
public interface Sorter
{
public int[] sort(int[] numbers);
}
</pre>
Finally, the SortListAdapter implements our target interface and deals with our adaptee, NumberSorter
<pre>
public class SortListAdapter implements Sorter
{
@Override
public int[] sort(int[] numbers)
{
//convert the array to a List
List<Integer> numberList = new ArrayList<Integer>();
//call the adapter
NumberSorter sorter = new NumberSorter();
numberList = sorter.sort(numberList);

//convert the list back to an array and return
return sortedNumbers;
}
}
</pre>

===Difference between Decorator Pattern and Adapter Pattern===
Adapters can be used for decorating but their primary aim is to for enabling classes of different types not able to communicate
because of incompatible interface to interact via a adapter interface.
Inheritance and composition is used to achieve this.Decorators on the other hand are not used to add different methods to all the instances instead they are used to add specific behavior to some specific instances. Though Adapters making use of composition may also be used here, but the intention is different here with what it's in case of a Adapter.
<ref>[http://geekexplains.blogspot.com/2008/09/structural-patterns-adapter-decorator.htmlStructural Patterns]</ref>

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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.
[[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.

Let's take a look at this in action with a sequence diagram.
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use tree structure and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern.
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==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 [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references />
==Additional Reading==
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]
*[http://www.slideshare.net/MarcusDenker/behavioral-reflection Behavioral reflection]
*[http://msdn.microsoft.com/en-us/library/67ef8sbd(v=vs.80).aspx C# Basics]
*[http://msdn.microsoft.com/en-us/library/ms173183(v=vs.80).aspx C# Reflection basics]
*[http://www.codeguru.com/csharp/csharp/cs_misc/reflection/article.php/c4257/An-Introduction-to-Reflection-in-C.htm Introduction to C# Reflection]
*[http://oreilly.com/catalog/progcsharp/chapter/ch18.html C# Attributes and Reflection]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-18T03:23:02Z

Knagar: /* Decorator Pattern */

==Introduction==
In this section we will be discussing about the decorator pattern and its related patterns such as adapter,proxy and composite.

===Decorator Pattern===
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.
We have an instance, and we put another instance inside of it. They both support the same (or similar) interfaces. The one on the outside is a "decorator." We can use the one on the outside. It either masks, changes, or pass-throughs the methods of the instance inside of it. <ref>[http://www.oodesign.com/decorator-pattern.htmlDecorator Pattern]</ref>
===Intent===
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality as provided by Gang of four. <ref>[http://c2.com/cgi/wiki?GangOfFour"Gang of four"]</ref>
===Problem===
The state of an object can be changed at compile time but no change is possible at run time if the language does not permit so.
===Solution===
Add a decorator module , class that acts as a extender for functions at run time such that the calls are delegated to the decorator
to extend the functionality of the objects at run time.
===Implementation===

====Ruby====
The example shows a Tea class with a method cost defining its cost as 4.
<ref>[http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.htmlDecorator Pattern and more]</ref>
<pre>

If we want to calculate the cost of a cup of coffee. We have Coffee class, which implements a cost() method.

class Coffee
def cost
2
end
end

But what if we want the cost of a coffee with milk? We could have a new class:

class MilkCoffee
def cost
2.4
end
end

But now if we want cream. And sprinkles. Clearly, creating new classes is going to lead to a huge number of classes in our application. It just isn’t realistic to create classes for different combinations of coffee and extras. It could get worse – what if we have different types of coffee? We would then have to have combinations of extras with each different type of coffee.Hence we will use decorator pattern.

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

And thats all you need. You can include this into any class you want to act as a decorator. You can then use that decorator as if it was the object it is decorating; by default all messages sent to the decorator are forwarded on to the decorated object. You can then decorate the methods you need to extend:

class Milk
include Decorator

def cost
@decorated.cost + 0.4
end
end

So how does this solve our original problem? The real power of decorators lies in the fact that they can act like the objects they are decorating. By taking this one step further, you can wrap decorators with other decorators as long as they share the same interface. By creating decorators for our different “extras”, we can create coffees using a combination of decorators and get the total cost of the coffee.

class Whip
include Decorator

def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

</pre>

====Java====
In this java example <ref>[http://java-x.blogspot.com/2007/01/implementing-decorator-pattern-in-java.htmlImplementing Decorator Pattern]</ref>
basicInterface: Defines the interface for objects that can have responsibilities added to them dynamically.
Basic: Defines an object to which additional responsibilities can be attached.
Decorator: maintains a reference to a Basic object and defines an interface that conforms to Basic's interface.
ConcreteDecorator: adds responsibilities to the component.
<pre>

public interface basicInterface {
public void do();
}

public class Basic implements basicInterface{
public void do() {
System.out.println("Do basic stuff");
}
}

public interface Decorator extends basicInterface {
public void addedStuff();
}

public class ConcreteDecorator implements Decorator {

basicInterface basic;

public ConcreteDecorator(basicInterface basic) {
super();
this.basic = basic;
}

public void addedStuff() {
System.out.println("Decorator does other stuff too");

}

public void do() {
basic.do();
addedStuff();
}
}

public class Client {
public static void main(String[] args) {
basicInterface comp = new Basic();
Decorator decorator = new ConcreteDecorator(comp);
decorator.do();
}
}

</pre>

In this way we can add concrete decorator classes to provided the added functionality to the basic class.

==Adapter Pattern==
Adapter pattern acts as a bridge between objects. It adapts to the changing needs of the classes using interface. In real world we have adapters for power supplies, adapters for camera memory cards etc.If a class is expecting some type of object and we have an object offering the same features, but exposing a different interface we want to use both of them so instead of implementing them again and changing existing classes,we can create an adapter.
===Intent===
Match an existing object to a particular interface.
===Problem===
A system has the right data and behavior but the wrong interface. Typically used when you have to make something a
derivative of an abstract class you already have or are defining.
===Solution===
Convert original interface component into another one through an intermediate adapter.Solution: The adapter provides a “wrapper” with the desired
interface
===Implementation===

====Ruby====
The Adapter offers exactly the same interface as the adaptee, but it can override any method or add new ones. In the below code the
adapter code delegates the call to the adaptee and performs operations according to the client requirements by performing additional operation to the results returned by the adaptee.
features
<ref>[http://www.scribd.com/doc/396559/gof-patterns-in-rubyGof Adapter Pattern]</ref>
<pre>
class Adaptee
def talk
puts "I'm Adaptee"
end
def whine
puts "Stop bullying me!"
end
end

class Adapter
def initialize
@adaptee=Adaptee.new
end
def talk
#override
puts "Let me introduce you to Adaptee!"
@adaptee.talk
puts "That was my adaptee"
end
def do_other_stuff
puts "I'm versatile"
end
def method_missing method
if
@adaptee.respond_to? method@adaptee.sendmethod
else
raise NotImplementedError,"This method is not "+\ "available on this interface"
end
end
end
if__FILE__==$0
adapter=Adapter.new
adapter.talk
adapter.whine
adapter.do_other_stuff
end
</pre>

output -
Let me introduce you to Adaptee!
I'm Adaptee
That was my adaptee
Stop bullying me!
I'm versatile

====Java====
The following example shows a simple implementation of the pattern. Consider that we have a third party library that provides sorting functionality through it's NumberSorter class.This is our adaptee, a third party implementation of a number sorter that deals with Lists, not arrays.[http://java.dzone.com/articles/design-patterns-uncovered-0]
<pre>
public class NumberSorter
{
public List<Integer> sort(List<Integer> numbers)
{
//sort and return
return new ArrayList<Integer>();
}
}
</pre>

Our Client deals with primitive arrays rather than Lists. For the sake of this example, lets say we can't change the client to use Lists.
<pre>
int[] numbers = new int[]{34, 2, 4, 12, 1};
Sorter sorter = new SortListAdapter();
sorter.sort(numbers);
</pre>

We've provided a Sorter interface that expects the client input. This is our target.
//this is our Target interface
<pre>
public interface Sorter
{
public int[] sort(int[] numbers);
}
</pre>
Finally, the SortListAdapter implements our target interface and deals with our adaptee, NumberSorter
<pre>
public class SortListAdapter implements Sorter
{
@Override
public int[] sort(int[] numbers)
{
//convert the array to a List
List<Integer> numberList = new ArrayList<Integer>();
//call the adapter
NumberSorter sorter = new NumberSorter();
numberList = sorter.sort(numberList);

//convert the list back to an array and return
return sortedNumbers;
}
}
</pre>

===Difference between Decorator Pattern and Adapter Pattern===
Adapters can be used for decorating but their primary aim is to for enabling classes of different types not able to communicate
because of incompatible interface to interact via a adapter interface.
Inheritance and composition is used to achieve this.Decorators on the other hand are not used to add different methods to all the instances instead they are used to add specific behavior to some specific instances. Though Adapters making use of composition may also be used here, but the intention is different here with what it's in case of a Adapter.
<ref>[http://geekexplains.blogspot.com/2008/09/structural-patterns-adapter-decorator.htmlStructural Patterns]</ref>

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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>[http://c2.com/cgi/wiki?GangOfFour"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.
[[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.

Let's take a look at this in action with a sequence diagram.
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use tree structure and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern.
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==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 [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references />
==Additional Reading==
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]
*[http://www.slideshare.net/MarcusDenker/behavioral-reflection Behavioral reflection]
*[http://msdn.microsoft.com/en-us/library/67ef8sbd(v=vs.80).aspx C# Basics]
*[http://msdn.microsoft.com/en-us/library/ms173183(v=vs.80).aspx C# Reflection basics]
*[http://www.codeguru.com/csharp/csharp/cs_misc/reflection/article.php/c4257/An-Introduction-to-Reflection-in-C.htm Introduction to C# Reflection]
*[http://oreilly.com/catalog/progcsharp/chapter/ch18.html C# Attributes and Reflection]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-18T03:18:20Z

Knagar: /* Difference between Decorator Pattern and Adapter Pattern */

==Introduction==
In this section we will be discussing about the decorator pattern and its related patterns such as adapter,proxy and composite.

==Decorator Pattern==
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.
We have an instance, and we put another instance inside of it. They both support the same (or similar) interfaces. The one on the outside is a "decorator." We can use the one on the outside. It either masks, changes, or pass-throughs the methods of the instance inside of it. <ref>[http://www.oodesign.com/decorator-pattern.htmlDecorator Pattern]</ref>
===Intent===
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality as provided by Gang of four. <ref>[http://c2.com/cgi/wiki?GangOfFour"Gang of four"]</ref>
===Problem===
The state of an object can be changed at compile time but no change is possible at run time if the language does not permit so.
===Solution===
Add a decorator module , class that acts as a extender for functions at run time such that the calls are delegated to the decorator
to extend the functionality of the objects at run time.
===Implementation===

====Ruby====
The example shows a Tea class with a method cost defining its cost as 4.
<ref>[http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.htmlDecorator Pattern and more]</ref>
<pre>

If we want to calculate the cost of a cup of coffee. We have Coffee class, which implements a cost() method.

class Coffee
def cost
2
end
end

But what if we want the cost of a coffee with milk? We could have a new class:

class MilkCoffee
def cost
2.4
end
end

But now if we want cream. And sprinkles. Clearly, creating new classes is going to lead to a huge number of classes in our application. It just isn’t realistic to create classes for different combinations of coffee and extras. It could get worse – what if we have different types of coffee? We would then have to have combinations of extras with each different type of coffee.Hence we will use decorator pattern.

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

And thats all you need. You can include this into any class you want to act as a decorator. You can then use that decorator as if it was the object it is decorating; by default all messages sent to the decorator are forwarded on to the decorated object. You can then decorate the methods you need to extend:

class Milk
include Decorator

def cost
@decorated.cost + 0.4
end
end

So how does this solve our original problem? The real power of decorators lies in the fact that they can act like the objects they are decorating. By taking this one step further, you can wrap decorators with other decorators as long as they share the same interface. By creating decorators for our different “extras”, we can create coffees using a combination of decorators and get the total cost of the coffee.

class Whip
include Decorator

def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

</pre>

====Java====
In this java example <ref>[http://java-x.blogspot.com/2007/01/implementing-decorator-pattern-in-java.htmlImplementing Decorator Pattern]</ref>
basicInterface: Defines the interface for objects that can have responsibilities added to them dynamically.
Basic: Defines an object to which additional responsibilities can be attached.
Decorator: maintains a reference to a Basic object and defines an interface that conforms to Basic's interface.
ConcreteDecorator: adds responsibilities to the component.
<pre>

public interface basicInterface {
public void do();
}

public class Basic implements basicInterface{
public void do() {
System.out.println("Do basic stuff");
}
}

public interface Decorator extends basicInterface {
public void addedStuff();
}

public class ConcreteDecorator implements Decorator {

basicInterface basic;

public ConcreteDecorator(basicInterface basic) {
super();
this.basic = basic;
}

public void addedStuff() {
System.out.println("Decorator does other stuff too");

}

public void do() {
basic.do();
addedStuff();
}
}

public class Client {
public static void main(String[] args) {
basicInterface comp = new Basic();
Decorator decorator = new ConcreteDecorator(comp);
decorator.do();
}
}

</pre>

In this way we can add concrete decorator classes to provided the added functionality to the basic class.

==Adapter Pattern==
Adapter pattern acts as a bridge between objects. It adapts to the changing needs of the classes using interface. In real world we have adapters for power supplies, adapters for camera memory cards etc.If a class is expecting some type of object and we have an object offering the same features, but exposing a different interface we want to use both of them so instead of implementing them again and changing existing classes,we can create an adapter.
===Intent===
Match an existing object to a particular interface.
===Problem===
A system has the right data and behavior but the wrong interface. Typically used when you have to make something a
derivative of an abstract class you already have or are defining.
===Solution===
Convert original interface component into another one through an intermediate adapter.Solution: The adapter provides a “wrapper” with the desired
interface
===Implementation===

====Ruby====
The Adapter offers exactly the same interface as the adaptee, but it can override any method or add new ones. In the below code the
adapter code delegates the call to the adaptee and performs operations according to the client requirements by performing additional operation to the results returned by the adaptee.
features
<ref>[http://www.scribd.com/doc/396559/gof-patterns-in-rubyGof Adapter Pattern]</ref>
<pre>
class Adaptee
def talk
puts "I'm Adaptee"
end
def whine
puts "Stop bullying me!"
end
end

class Adapter
def initialize
@adaptee=Adaptee.new
end
def talk
#override
puts "Let me introduce you to Adaptee!"
@adaptee.talk
puts "That was my adaptee"
end
def do_other_stuff
puts "I'm versatile"
end
def method_missing method
if
@adaptee.respond_to? method@adaptee.sendmethod
else
raise NotImplementedError,"This method is not "+\ "available on this interface"
end
end
end
if__FILE__==$0
adapter=Adapter.new
adapter.talk
adapter.whine
adapter.do_other_stuff
end
</pre>

output -
Let me introduce you to Adaptee!
I'm Adaptee
That was my adaptee
Stop bullying me!
I'm versatile

====Java====
The following example shows a simple implementation of the pattern. Consider that we have a third party library that provides sorting functionality through it's NumberSorter class.This is our adaptee, a third party implementation of a number sorter that deals with Lists, not arrays.[http://java.dzone.com/articles/design-patterns-uncovered-0]
<pre>
public class NumberSorter
{
public List<Integer> sort(List<Integer> numbers)
{
//sort and return
return new ArrayList<Integer>();
}
}
</pre>

Our Client deals with primitive arrays rather than Lists. For the sake of this example, lets say we can't change the client to use Lists.
<pre>
int[] numbers = new int[]{34, 2, 4, 12, 1};
Sorter sorter = new SortListAdapter();
sorter.sort(numbers);
</pre>

We've provided a Sorter interface that expects the client input. This is our target.
//this is our Target interface
<pre>
public interface Sorter
{
public int[] sort(int[] numbers);
}
</pre>
Finally, the SortListAdapter implements our target interface and deals with our adaptee, NumberSorter
<pre>
public class SortListAdapter implements Sorter
{
@Override
public int[] sort(int[] numbers)
{
//convert the array to a List
List<Integer> numberList = new ArrayList<Integer>();
//call the adapter
NumberSorter sorter = new NumberSorter();
numberList = sorter.sort(numberList);

//convert the list back to an array and return
return sortedNumbers;
}
}
</pre>

===Difference between Decorator Pattern and Adapter Pattern===
Adapters can be used for decorating but their primary aim is to for enabling classes of different types not able to communicate
because of incompatible interface to interact via a adapter interface.
Inheritance and composition is used to achieve this.Decorators on the other hand are not used to add different methods to all the instances instead they are used to add specific behavior to some specific instances. Though Adapters making use of composition may also be used here, but the intention is different here with what it's in case of a Adapter.
<ref>[http://geekexplains.blogspot.com/2008/09/structural-patterns-adapter-decorator.htmlStructural Patterns]</ref>

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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>[http://c2.com/cgi/wiki?GangOfFour"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.
[[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.

Let's take a look at this in action with a sequence diagram.
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use tree structure and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern.
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==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 [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references />
==Additional Reading==
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]
*[http://www.slideshare.net/MarcusDenker/behavioral-reflection Behavioral reflection]
*[http://msdn.microsoft.com/en-us/library/67ef8sbd(v=vs.80).aspx C# Basics]
*[http://msdn.microsoft.com/en-us/library/ms173183(v=vs.80).aspx C# Reflection basics]
*[http://www.codeguru.com/csharp/csharp/cs_misc/reflection/article.php/c4257/An-Introduction-to-Reflection-in-C.htm Introduction to C# Reflection]
*[http://oreilly.com/catalog/progcsharp/chapter/ch18.html C# Attributes and Reflection]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-18T03:17:14Z

Knagar: /* Ruby */

==Introduction==
In this section we will be discussing about the decorator pattern and its related patterns such as adapter,proxy and composite.

==Decorator Pattern==
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.
We have an instance, and we put another instance inside of it. They both support the same (or similar) interfaces. The one on the outside is a "decorator." We can use the one on the outside. It either masks, changes, or pass-throughs the methods of the instance inside of it. <ref>[http://www.oodesign.com/decorator-pattern.htmlDecorator Pattern]</ref>
===Intent===
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality as provided by Gang of four. <ref>[http://c2.com/cgi/wiki?GangOfFour"Gang of four"]</ref>
===Problem===
The state of an object can be changed at compile time but no change is possible at run time if the language does not permit so.
===Solution===
Add a decorator module , class that acts as a extender for functions at run time such that the calls are delegated to the decorator
to extend the functionality of the objects at run time.
===Implementation===

====Ruby====
The example shows a Tea class with a method cost defining its cost as 4.
<ref>[http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.htmlDecorator Pattern and more]</ref>
<pre>

If we want to calculate the cost of a cup of coffee. We have Coffee class, which implements a cost() method.

class Coffee
def cost
2
end
end

But what if we want the cost of a coffee with milk? We could have a new class:

class MilkCoffee
def cost
2.4
end
end

But now if we want cream. And sprinkles. Clearly, creating new classes is going to lead to a huge number of classes in our application. It just isn’t realistic to create classes for different combinations of coffee and extras. It could get worse – what if we have different types of coffee? We would then have to have combinations of extras with each different type of coffee.Hence we will use decorator pattern.

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

And thats all you need. You can include this into any class you want to act as a decorator. You can then use that decorator as if it was the object it is decorating; by default all messages sent to the decorator are forwarded on to the decorated object. You can then decorate the methods you need to extend:

class Milk
include Decorator

def cost
@decorated.cost + 0.4
end
end

So how does this solve our original problem? The real power of decorators lies in the fact that they can act like the objects they are decorating. By taking this one step further, you can wrap decorators with other decorators as long as they share the same interface. By creating decorators for our different “extras”, we can create coffees using a combination of decorators and get the total cost of the coffee.

class Whip
include Decorator

def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

</pre>

====Java====
In this java example <ref>[http://java-x.blogspot.com/2007/01/implementing-decorator-pattern-in-java.htmlImplementing Decorator Pattern]</ref>
basicInterface: Defines the interface for objects that can have responsibilities added to them dynamically.
Basic: Defines an object to which additional responsibilities can be attached.
Decorator: maintains a reference to a Basic object and defines an interface that conforms to Basic's interface.
ConcreteDecorator: adds responsibilities to the component.
<pre>

public interface basicInterface {
public void do();
}

public class Basic implements basicInterface{
public void do() {
System.out.println("Do basic stuff");
}
}

public interface Decorator extends basicInterface {
public void addedStuff();
}

public class ConcreteDecorator implements Decorator {

basicInterface basic;

public ConcreteDecorator(basicInterface basic) {
super();
this.basic = basic;
}

public void addedStuff() {
System.out.println("Decorator does other stuff too");

}

public void do() {
basic.do();
addedStuff();
}
}

public class Client {
public static void main(String[] args) {
basicInterface comp = new Basic();
Decorator decorator = new ConcreteDecorator(comp);
decorator.do();
}
}

</pre>

In this way we can add concrete decorator classes to provided the added functionality to the basic class.

==Adapter Pattern==
Adapter pattern acts as a bridge between objects. It adapts to the changing needs of the classes using interface. In real world we have adapters for power supplies, adapters for camera memory cards etc.If a class is expecting some type of object and we have an object offering the same features, but exposing a different interface we want to use both of them so instead of implementing them again and changing existing classes,we can create an adapter.
===Intent===
Match an existing object to a particular interface.
===Problem===
A system has the right data and behavior but the wrong interface. Typically used when you have to make something a
derivative of an abstract class you already have or are defining.
===Solution===
Convert original interface component into another one through an intermediate adapter.Solution: The adapter provides a “wrapper” with the desired
interface
===Implementation===

====Ruby====
The Adapter offers exactly the same interface as the adaptee, but it can override any method or add new ones. In the below code the
adapter code delegates the call to the adaptee and performs operations according to the client requirements by performing additional operation to the results returned by the adaptee.
features
<ref>[http://www.scribd.com/doc/396559/gof-patterns-in-rubyGof Adapter Pattern]</ref>
<pre>
class Adaptee
def talk
puts "I'm Adaptee"
end
def whine
puts "Stop bullying me!"
end
end

class Adapter
def initialize
@adaptee=Adaptee.new
end
def talk
#override
puts "Let me introduce you to Adaptee!"
@adaptee.talk
puts "That was my adaptee"
end
def do_other_stuff
puts "I'm versatile"
end
def method_missing method
if
@adaptee.respond_to? method@adaptee.sendmethod
else
raise NotImplementedError,"This method is not "+\ "available on this interface"
end
end
end
if__FILE__==$0
adapter=Adapter.new
adapter.talk
adapter.whine
adapter.do_other_stuff
end
</pre>

output -
Let me introduce you to Adaptee!
I'm Adaptee
That was my adaptee
Stop bullying me!
I'm versatile

====Java====
The following example shows a simple implementation of the pattern. Consider that we have a third party library that provides sorting functionality through it's NumberSorter class.This is our adaptee, a third party implementation of a number sorter that deals with Lists, not arrays.[http://java.dzone.com/articles/design-patterns-uncovered-0]
<pre>
public class NumberSorter
{
public List<Integer> sort(List<Integer> numbers)
{
//sort and return
return new ArrayList<Integer>();
}
}
</pre>

Our Client deals with primitive arrays rather than Lists. For the sake of this example, lets say we can't change the client to use Lists.
<pre>
int[] numbers = new int[]{34, 2, 4, 12, 1};
Sorter sorter = new SortListAdapter();
sorter.sort(numbers);
</pre>

We've provided a Sorter interface that expects the client input. This is our target.
//this is our Target interface
<pre>
public interface Sorter
{
public int[] sort(int[] numbers);
}
</pre>
Finally, the SortListAdapter implements our target interface and deals with our adaptee, NumberSorter
<pre>
public class SortListAdapter implements Sorter
{
@Override
public int[] sort(int[] numbers)
{
//convert the array to a List
List<Integer> numberList = new ArrayList<Integer>();
//call the adapter
NumberSorter sorter = new NumberSorter();
numberList = sorter.sort(numberList);

//convert the list back to an array and return
return sortedNumbers;
}
}
</pre>

===Difference between Decorator Pattern and Adapter Pattern===
Adapters can be used for decorating but their primary aim is to for enabling classes of different types not able to communicate
because of incompatible interface to interact via a adapter interface.
Inheritance and composition is used to achieve this.Decorators on the other hand are not used to add different methods to all the instances instead they are used to add specific behavior to some specific instances. Though Adapters making use of composition may also be used here, but the intention is different here with what it's in case of a Adapter.
<ref>[http://geekexplains.blogspot.com/2008/09/structural-patterns-adapter-decorator.html]</ref>

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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>[http://c2.com/cgi/wiki?GangOfFour"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.
[[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.

Let's take a look at this in action with a sequence diagram.
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use tree structure and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern.
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==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 [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references />
==Additional Reading==
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]
*[http://www.slideshare.net/MarcusDenker/behavioral-reflection Behavioral reflection]
*[http://msdn.microsoft.com/en-us/library/67ef8sbd(v=vs.80).aspx C# Basics]
*[http://msdn.microsoft.com/en-us/library/ms173183(v=vs.80).aspx C# Reflection basics]
*[http://www.codeguru.com/csharp/csharp/cs_misc/reflection/article.php/c4257/An-Introduction-to-Reflection-in-C.htm Introduction to C# Reflection]
*[http://oreilly.com/catalog/progcsharp/chapter/ch18.html C# Attributes and Reflection]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-18T03:15:41Z

Knagar: /* Java */

==Introduction==
In this section we will be discussing about the decorator pattern and its related patterns such as adapter,proxy and composite.

==Decorator Pattern==
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.
We have an instance, and we put another instance inside of it. They both support the same (or similar) interfaces. The one on the outside is a "decorator." We can use the one on the outside. It either masks, changes, or pass-throughs the methods of the instance inside of it. <ref>[http://www.oodesign.com/decorator-pattern.htmlDecorator Pattern]</ref>
===Intent===
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality as provided by Gang of four. <ref>[http://c2.com/cgi/wiki?GangOfFour"Gang of four"]</ref>
===Problem===
The state of an object can be changed at compile time but no change is possible at run time if the language does not permit so.
===Solution===
Add a decorator module , class that acts as a extender for functions at run time such that the calls are delegated to the decorator
to extend the functionality of the objects at run time.
===Implementation===

====Ruby====
The example shows a Tea class with a method cost defining its cost as 4.
<ref>[http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.htmlDecorator Pattern and more]</ref>
<pre>

If we want to calculate the cost of a cup of coffee. We have Coffee class, which implements a cost() method.

class Coffee
def cost
2
end
end

But what if we want the cost of a coffee with milk? We could have a new class:

class MilkCoffee
def cost
2.4
end
end

But now if we want cream. And sprinkles. Clearly, creating new classes is going to lead to a huge number of classes in our application. It just isn’t realistic to create classes for different combinations of coffee and extras. It could get worse – what if we have different types of coffee? We would then have to have combinations of extras with each different type of coffee.Hence we will use decorator pattern.

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

And thats all you need. You can include this into any class you want to act as a decorator. You can then use that decorator as if it was the object it is decorating; by default all messages sent to the decorator are forwarded on to the decorated object. You can then decorate the methods you need to extend:

class Milk
include Decorator

def cost
@decorated.cost + 0.4
end
end

So how does this solve our original problem? The real power of decorators lies in the fact that they can act like the objects they are decorating. By taking this one step further, you can wrap decorators with other decorators as long as they share the same interface. By creating decorators for our different “extras”, we can create coffees using a combination of decorators and get the total cost of the coffee.

class Whip
include Decorator

def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

</pre>

====Java====
In this java example <ref>[http://java-x.blogspot.com/2007/01/implementing-decorator-pattern-in-java.htmlImplementing Decorator Pattern]</ref>
basicInterface: Defines the interface for objects that can have responsibilities added to them dynamically.
Basic: Defines an object to which additional responsibilities can be attached.
Decorator: maintains a reference to a Basic object and defines an interface that conforms to Basic's interface.
ConcreteDecorator: adds responsibilities to the component.
<pre>

public interface basicInterface {
public void do();
}

public class Basic implements basicInterface{
public void do() {
System.out.println("Do basic stuff");
}
}

public interface Decorator extends basicInterface {
public void addedStuff();
}

public class ConcreteDecorator implements Decorator {

basicInterface basic;

public ConcreteDecorator(basicInterface basic) {
super();
this.basic = basic;
}

public void addedStuff() {
System.out.println("Decorator does other stuff too");

}

public void do() {
basic.do();
addedStuff();
}
}

public class Client {
public static void main(String[] args) {
basicInterface comp = new Basic();
Decorator decorator = new ConcreteDecorator(comp);
decorator.do();
}
}

</pre>

In this way we can add concrete decorator classes to provided the added functionality to the basic class.

==Adapter Pattern==
Adapter pattern acts as a bridge between objects. It adapts to the changing needs of the classes using interface. In real world we have adapters for power supplies, adapters for camera memory cards etc.If a class is expecting some type of object and we have an object offering the same features, but exposing a different interface we want to use both of them so instead of implementing them again and changing existing classes,we can create an adapter.
===Intent===
Match an existing object to a particular interface.
===Problem===
A system has the right data and behavior but the wrong interface. Typically used when you have to make something a
derivative of an abstract class you already have or are defining.
===Solution===
Convert original interface component into another one through an intermediate adapter.Solution: The adapter provides a “wrapper” with the desired
interface
===Implementation===

====Ruby====
The Adapter offers exactly the same interface as the adaptee, but it can override any method or add new ones. In the below code the
adapter code delegates the call to the adaptee and performs operations according to the client requirements by performing additional operation to the results returned by the adaptee.
features
<ref>[http://www.scribd.com/doc/396559/gof-patterns-in-ruby]</ref>
<pre>
class Adaptee
def talk
puts "I'm Adaptee"
end
def whine
puts "Stop bullying me!"
end
end

class Adapter
def initialize
@adaptee=Adaptee.new
end
def talk
#override
puts "Let me introduce you to Adaptee!"
@adaptee.talk
puts "That was my adaptee"
end
def do_other_stuff
puts "I'm versatile"
end
def method_missing method
if
@adaptee.respond_to? method@adaptee.sendmethod
else
raise NotImplementedError,"This method is not "+\ "available on this interface"
end
end
end
if__FILE__==$0
adapter=Adapter.new
adapter.talk
adapter.whine
adapter.do_other_stuff
end
</pre>

output -
Let me introduce you to Adaptee!
I'm Adaptee
That was my adaptee
Stop bullying me!
I'm versatile

====Java====
The following example shows a simple implementation of the pattern. Consider that we have a third party library that provides sorting functionality through it's NumberSorter class.This is our adaptee, a third party implementation of a number sorter that deals with Lists, not arrays.[http://java.dzone.com/articles/design-patterns-uncovered-0]
<pre>
public class NumberSorter
{
public List<Integer> sort(List<Integer> numbers)
{
//sort and return
return new ArrayList<Integer>();
}
}
</pre>

Our Client deals with primitive arrays rather than Lists. For the sake of this example, lets say we can't change the client to use Lists.
<pre>
int[] numbers = new int[]{34, 2, 4, 12, 1};
Sorter sorter = new SortListAdapter();
sorter.sort(numbers);
</pre>

We've provided a Sorter interface that expects the client input. This is our target.
//this is our Target interface
<pre>
public interface Sorter
{
public int[] sort(int[] numbers);
}
</pre>
Finally, the SortListAdapter implements our target interface and deals with our adaptee, NumberSorter
<pre>
public class SortListAdapter implements Sorter
{
@Override
public int[] sort(int[] numbers)
{
//convert the array to a List
List<Integer> numberList = new ArrayList<Integer>();
//call the adapter
NumberSorter sorter = new NumberSorter();
numberList = sorter.sort(numberList);

//convert the list back to an array and return
return sortedNumbers;
}
}
</pre>

===Difference between Decorator Pattern and Adapter Pattern===
Adapters can be used for decorating but their primary aim is to for enabling classes of different types not able to communicate
because of incompatible interface to interact via a adapter interface.
Inheritance and composition is used to achieve this.Decorators on the other hand are not used to add different methods to all the instances instead they are used to add specific behavior to some specific instances. Though Adapters making use of composition may also be used here, but the intention is different here with what it's in case of a Adapter.
<ref>[http://geekexplains.blogspot.com/2008/09/structural-patterns-adapter-decorator.html]</ref>

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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>[http://c2.com/cgi/wiki?GangOfFour"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.
[[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.

Let's take a look at this in action with a sequence diagram.
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use tree structure and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern.
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==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 [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references />
==Additional Reading==
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]
*[http://www.slideshare.net/MarcusDenker/behavioral-reflection Behavioral reflection]
*[http://msdn.microsoft.com/en-us/library/67ef8sbd(v=vs.80).aspx C# Basics]
*[http://msdn.microsoft.com/en-us/library/ms173183(v=vs.80).aspx C# Reflection basics]
*[http://www.codeguru.com/csharp/csharp/cs_misc/reflection/article.php/c4257/An-Introduction-to-Reflection-in-C.htm Introduction to C# Reflection]
*[http://oreilly.com/catalog/progcsharp/chapter/ch18.html C# Attributes and Reflection]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-18T03:13:57Z

Knagar: /* Ruby */

==Introduction==
In this section we will be discussing about the decorator pattern and its related patterns such as adapter,proxy and composite.

==Decorator Pattern==
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.
We have an instance, and we put another instance inside of it. They both support the same (or similar) interfaces. The one on the outside is a "decorator." We can use the one on the outside. It either masks, changes, or pass-throughs the methods of the instance inside of it. <ref>[http://www.oodesign.com/decorator-pattern.htmlDecorator Pattern]</ref>
===Intent===
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality as provided by Gang of four. <ref>[http://c2.com/cgi/wiki?GangOfFour"Gang of four"]</ref>
===Problem===
The state of an object can be changed at compile time but no change is possible at run time if the language does not permit so.
===Solution===
Add a decorator module , class that acts as a extender for functions at run time such that the calls are delegated to the decorator
to extend the functionality of the objects at run time.
===Implementation===

====Ruby====
The example shows a Tea class with a method cost defining its cost as 4.
<ref>[http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.htmlDecorator Pattern and more]</ref>
<pre>

If we want to calculate the cost of a cup of coffee. We have Coffee class, which implements a cost() method.

class Coffee
def cost
2
end
end

But what if we want the cost of a coffee with milk? We could have a new class:

class MilkCoffee
def cost
2.4
end
end

But now if we want cream. And sprinkles. Clearly, creating new classes is going to lead to a huge number of classes in our application. It just isn’t realistic to create classes for different combinations of coffee and extras. It could get worse – what if we have different types of coffee? We would then have to have combinations of extras with each different type of coffee.Hence we will use decorator pattern.

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

And thats all you need. You can include this into any class you want to act as a decorator. You can then use that decorator as if it was the object it is decorating; by default all messages sent to the decorator are forwarded on to the decorated object. You can then decorate the methods you need to extend:

class Milk
include Decorator

def cost
@decorated.cost + 0.4
end
end

So how does this solve our original problem? The real power of decorators lies in the fact that they can act like the objects they are decorating. By taking this one step further, you can wrap decorators with other decorators as long as they share the same interface. By creating decorators for our different “extras”, we can create coffees using a combination of decorators and get the total cost of the coffee.

class Whip
include Decorator

def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

</pre>

====Java====
In this java example <ref>[http://java-x.blogspot.com/2007/01/implementing-decorator-pattern-in-java.html]</ref>
basicInterface: Defines the interface for objects that can have responsibilities added to them dynamically.
Basic: Defines an object to which additional responsibilities can be attached.
Decorator: maintains a reference to a Basic object and defines an interface that conforms to Basic's interface.
ConcreteDecorator: adds responsibilities to the component.
<pre>

public interface basicInterface {
public void do();
}

public class Basic implements basicInterface{
public void do() {
System.out.println("Do basic stuff");
}
}

public interface Decorator extends basicInterface {
public void addedStuff();
}

public class ConcreteDecorator implements Decorator {

basicInterface basic;

public ConcreteDecorator(basicInterface basic) {
super();
this.basic = basic;
}

public void addedStuff() {
System.out.println("Decorator does other stuff too");

}

public void do() {
basic.do();
addedStuff();
}
}

public class Client {
public static void main(String[] args) {
basicInterface comp = new Basic();
Decorator decorator = new ConcreteDecorator(comp);
decorator.do();
}
}

</pre>

In this way we can add concrete decorator classes to provided the added functionality to the basic class.

==Adapter Pattern==
Adapter pattern acts as a bridge between objects. It adapts to the changing needs of the classes using interface. In real world we have adapters for power supplies, adapters for camera memory cards etc.If a class is expecting some type of object and we have an object offering the same features, but exposing a different interface we want to use both of them so instead of implementing them again and changing existing classes,we can create an adapter.
===Intent===
Match an existing object to a particular interface.
===Problem===
A system has the right data and behavior but the wrong interface. Typically used when you have to make something a
derivative of an abstract class you already have or are defining.
===Solution===
Convert original interface component into another one through an intermediate adapter.Solution: The adapter provides a “wrapper” with the desired
interface
===Implementation===

====Ruby====
The Adapter offers exactly the same interface as the adaptee, but it can override any method or add new ones. In the below code the
adapter code delegates the call to the adaptee and performs operations according to the client requirements by performing additional operation to the results returned by the adaptee.
features
<ref>[http://www.scribd.com/doc/396559/gof-patterns-in-ruby]</ref>
<pre>
class Adaptee
def talk
puts "I'm Adaptee"
end
def whine
puts "Stop bullying me!"
end
end

class Adapter
def initialize
@adaptee=Adaptee.new
end
def talk
#override
puts "Let me introduce you to Adaptee!"
@adaptee.talk
puts "That was my adaptee"
end
def do_other_stuff
puts "I'm versatile"
end
def method_missing method
if
@adaptee.respond_to? method@adaptee.sendmethod
else
raise NotImplementedError,"This method is not "+\ "available on this interface"
end
end
end
if__FILE__==$0
adapter=Adapter.new
adapter.talk
adapter.whine
adapter.do_other_stuff
end
</pre>

output -
Let me introduce you to Adaptee!
I'm Adaptee
That was my adaptee
Stop bullying me!
I'm versatile

====Java====
The following example shows a simple implementation of the pattern. Consider that we have a third party library that provides sorting functionality through it's NumberSorter class.This is our adaptee, a third party implementation of a number sorter that deals with Lists, not arrays.[http://java.dzone.com/articles/design-patterns-uncovered-0]
<pre>
public class NumberSorter
{
public List<Integer> sort(List<Integer> numbers)
{
//sort and return
return new ArrayList<Integer>();
}
}
</pre>

Our Client deals with primitive arrays rather than Lists. For the sake of this example, lets say we can't change the client to use Lists.
<pre>
int[] numbers = new int[]{34, 2, 4, 12, 1};
Sorter sorter = new SortListAdapter();
sorter.sort(numbers);
</pre>

We've provided a Sorter interface that expects the client input. This is our target.
//this is our Target interface
<pre>
public interface Sorter
{
public int[] sort(int[] numbers);
}
</pre>
Finally, the SortListAdapter implements our target interface and deals with our adaptee, NumberSorter
<pre>
public class SortListAdapter implements Sorter
{
@Override
public int[] sort(int[] numbers)
{
//convert the array to a List
List<Integer> numberList = new ArrayList<Integer>();
//call the adapter
NumberSorter sorter = new NumberSorter();
numberList = sorter.sort(numberList);

//convert the list back to an array and return
return sortedNumbers;
}
}
</pre>

===Difference between Decorator Pattern and Adapter Pattern===
Adapters can be used for decorating but their primary aim is to for enabling classes of different types not able to communicate
because of incompatible interface to interact via a adapter interface.
Inheritance and composition is used to achieve this.Decorators on the other hand are not used to add different methods to all the instances instead they are used to add specific behavior to some specific instances. Though Adapters making use of composition may also be used here, but the intention is different here with what it's in case of a Adapter.
<ref>[http://geekexplains.blogspot.com/2008/09/structural-patterns-adapter-decorator.html]</ref>

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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>[http://c2.com/cgi/wiki?GangOfFour"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.
[[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.

Let's take a look at this in action with a sequence diagram.
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use tree structure and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern.
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==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 [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references />
==Additional Reading==
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]
*[http://www.slideshare.net/MarcusDenker/behavioral-reflection Behavioral reflection]
*[http://msdn.microsoft.com/en-us/library/67ef8sbd(v=vs.80).aspx C# Basics]
*[http://msdn.microsoft.com/en-us/library/ms173183(v=vs.80).aspx C# Reflection basics]
*[http://www.codeguru.com/csharp/csharp/cs_misc/reflection/article.php/c4257/An-Introduction-to-Reflection-in-C.htm Introduction to C# Reflection]
*[http://oreilly.com/catalog/progcsharp/chapter/ch18.html C# Attributes and Reflection]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-18T03:13:16Z

Knagar: /* Ruby */

==Introduction==
In this section we will be discussing about the decorator pattern and its related patterns such as adapter,proxy and composite.

==Decorator Pattern==
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.
We have an instance, and we put another instance inside of it. They both support the same (or similar) interfaces. The one on the outside is a "decorator." We can use the one on the outside. It either masks, changes, or pass-throughs the methods of the instance inside of it. <ref>[http://www.oodesign.com/decorator-pattern.htmlDecorator Pattern]</ref>
===Intent===
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality as provided by Gang of four. <ref>[http://c2.com/cgi/wiki?GangOfFour"Gang of four"]</ref>
===Problem===
The state of an object can be changed at compile time but no change is possible at run time if the language does not permit so.
===Solution===
Add a decorator module , class that acts as a extender for functions at run time such that the calls are delegated to the decorator
to extend the functionality of the objects at run time.
===Implementation===

====Ruby====
The example shows a Tea class with a method cost defining its cost as 4.
<ref>[http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.htmlExample of Decorator Pattern]</ref>
<pre>

If we want to calculate the cost of a cup of coffee. We have Coffee class, which implements a cost() method.

class Coffee
def cost
2
end
end

But what if we want the cost of a coffee with milk? We could have a new class:

class MilkCoffee
def cost
2.4
end
end

But now if we want cream. And sprinkles. Clearly, creating new classes is going to lead to a huge number of classes in our application. It just isn’t realistic to create classes for different combinations of coffee and extras. It could get worse – what if we have different types of coffee? We would then have to have combinations of extras with each different type of coffee.Hence we will use decorator pattern.

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

And thats all you need. You can include this into any class you want to act as a decorator. You can then use that decorator as if it was the object it is decorating; by default all messages sent to the decorator are forwarded on to the decorated object. You can then decorate the methods you need to extend:

class Milk
include Decorator

def cost
@decorated.cost + 0.4
end
end

So how does this solve our original problem? The real power of decorators lies in the fact that they can act like the objects they are decorating. By taking this one step further, you can wrap decorators with other decorators as long as they share the same interface. By creating decorators for our different “extras”, we can create coffees using a combination of decorators and get the total cost of the coffee.

class Whip
include Decorator

def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

</pre>

====Java====
In this java example <ref>[http://java-x.blogspot.com/2007/01/implementing-decorator-pattern-in-java.html]</ref>
basicInterface: Defines the interface for objects that can have responsibilities added to them dynamically.
Basic: Defines an object to which additional responsibilities can be attached.
Decorator: maintains a reference to a Basic object and defines an interface that conforms to Basic's interface.
ConcreteDecorator: adds responsibilities to the component.
<pre>

public interface basicInterface {
public void do();
}

public class Basic implements basicInterface{
public void do() {
System.out.println("Do basic stuff");
}
}

public interface Decorator extends basicInterface {
public void addedStuff();
}

public class ConcreteDecorator implements Decorator {

basicInterface basic;

public ConcreteDecorator(basicInterface basic) {
super();
this.basic = basic;
}

public void addedStuff() {
System.out.println("Decorator does other stuff too");

}

public void do() {
basic.do();
addedStuff();
}
}

public class Client {
public static void main(String[] args) {
basicInterface comp = new Basic();
Decorator decorator = new ConcreteDecorator(comp);
decorator.do();
}
}

</pre>

In this way we can add concrete decorator classes to provided the added functionality to the basic class.

==Adapter Pattern==
Adapter pattern acts as a bridge between objects. It adapts to the changing needs of the classes using interface. In real world we have adapters for power supplies, adapters for camera memory cards etc.If a class is expecting some type of object and we have an object offering the same features, but exposing a different interface we want to use both of them so instead of implementing them again and changing existing classes,we can create an adapter.
===Intent===
Match an existing object to a particular interface.
===Problem===
A system has the right data and behavior but the wrong interface. Typically used when you have to make something a
derivative of an abstract class you already have or are defining.
===Solution===
Convert original interface component into another one through an intermediate adapter.Solution: The adapter provides a “wrapper” with the desired
interface
===Implementation===

====Ruby====
The Adapter offers exactly the same interface as the adaptee, but it can override any method or add new ones. In the below code the
adapter code delegates the call to the adaptee and performs operations according to the client requirements by performing additional operation to the results returned by the adaptee.
features
<ref>[http://www.scribd.com/doc/396559/gof-patterns-in-ruby]</ref>
<pre>
class Adaptee
def talk
puts "I'm Adaptee"
end
def whine
puts "Stop bullying me!"
end
end

class Adapter
def initialize
@adaptee=Adaptee.new
end
def talk
#override
puts "Let me introduce you to Adaptee!"
@adaptee.talk
puts "That was my adaptee"
end
def do_other_stuff
puts "I'm versatile"
end
def method_missing method
if
@adaptee.respond_to? method@adaptee.sendmethod
else
raise NotImplementedError,"This method is not "+\ "available on this interface"
end
end
end
if__FILE__==$0
adapter=Adapter.new
adapter.talk
adapter.whine
adapter.do_other_stuff
end
</pre>

output -
Let me introduce you to Adaptee!
I'm Adaptee
That was my adaptee
Stop bullying me!
I'm versatile

====Java====
The following example shows a simple implementation of the pattern. Consider that we have a third party library that provides sorting functionality through it's NumberSorter class.This is our adaptee, a third party implementation of a number sorter that deals with Lists, not arrays.[http://java.dzone.com/articles/design-patterns-uncovered-0]
<pre>
public class NumberSorter
{
public List<Integer> sort(List<Integer> numbers)
{
//sort and return
return new ArrayList<Integer>();
}
}
</pre>

Our Client deals with primitive arrays rather than Lists. For the sake of this example, lets say we can't change the client to use Lists.
<pre>
int[] numbers = new int[]{34, 2, 4, 12, 1};
Sorter sorter = new SortListAdapter();
sorter.sort(numbers);
</pre>

We've provided a Sorter interface that expects the client input. This is our target.
//this is our Target interface
<pre>
public interface Sorter
{
public int[] sort(int[] numbers);
}
</pre>
Finally, the SortListAdapter implements our target interface and deals with our adaptee, NumberSorter
<pre>
public class SortListAdapter implements Sorter
{
@Override
public int[] sort(int[] numbers)
{
//convert the array to a List
List<Integer> numberList = new ArrayList<Integer>();
//call the adapter
NumberSorter sorter = new NumberSorter();
numberList = sorter.sort(numberList);

//convert the list back to an array and return
return sortedNumbers;
}
}
</pre>

===Difference between Decorator Pattern and Adapter Pattern===
Adapters can be used for decorating but their primary aim is to for enabling classes of different types not able to communicate
because of incompatible interface to interact via a adapter interface.
Inheritance and composition is used to achieve this.Decorators on the other hand are not used to add different methods to all the instances instead they are used to add specific behavior to some specific instances. Though Adapters making use of composition may also be used here, but the intention is different here with what it's in case of a Adapter.
<ref>[http://geekexplains.blogspot.com/2008/09/structural-patterns-adapter-decorator.html]</ref>

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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>[http://c2.com/cgi/wiki?GangOfFour"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.
[[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.

Let's take a look at this in action with a sequence diagram.
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use tree structure and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern.
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==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 [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references />
==Additional Reading==
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]
*[http://www.slideshare.net/MarcusDenker/behavioral-reflection Behavioral reflection]
*[http://msdn.microsoft.com/en-us/library/67ef8sbd(v=vs.80).aspx C# Basics]
*[http://msdn.microsoft.com/en-us/library/ms173183(v=vs.80).aspx C# Reflection basics]
*[http://www.codeguru.com/csharp/csharp/cs_misc/reflection/article.php/c4257/An-Introduction-to-Reflection-in-C.htm Introduction to C# Reflection]
*[http://oreilly.com/catalog/progcsharp/chapter/ch18.html C# Attributes and Reflection]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-18T03:11:39Z

Knagar: /* Decorator Pattern */

==Introduction==
In this section we will be discussing about the decorator pattern and its related patterns such as adapter,proxy and composite.

==Decorator Pattern==
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.
We have an instance, and we put another instance inside of it. They both support the same (or similar) interfaces. The one on the outside is a "decorator." We can use the one on the outside. It either masks, changes, or pass-throughs the methods of the instance inside of it. <ref>[http://www.oodesign.com/decorator-pattern.htmlDecorator Pattern]</ref>
===Intent===
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality as provided by Gang of four. <ref>[http://c2.com/cgi/wiki?GangOfFour"Gang of four"]</ref>
===Problem===
The state of an object can be changed at compile time but no change is possible at run time if the language does not permit so.
===Solution===
Add a decorator module , class that acts as a extender for functions at run time such that the calls are delegated to the decorator
to extend the functionality of the objects at run time.
===Implementation===

====Ruby====
The example shows a Tea class with a method cost defining its cost as 4.
<ref>[http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html]</ref>
<pre>

If we want to calculate the cost of a cup of coffee. We have Coffee class, which implements a cost() method.

class Coffee
def cost
2
end
end

But what if we want the cost of a coffee with milk? We could have a new class:

class MilkCoffee
def cost
2.4
end
end

But now if we want cream. And sprinkles. Clearly, creating new classes is going to lead to a huge number of classes in our application. It just isn’t realistic to create classes for different combinations of coffee and extras. It could get worse – what if we have different types of coffee? We would then have to have combinations of extras with each different type of coffee.Hence we will use decorator pattern.

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

And thats all you need. You can include this into any class you want to act as a decorator. You can then use that decorator as if it was the object it is decorating; by default all messages sent to the decorator are forwarded on to the decorated object. You can then decorate the methods you need to extend:

class Milk
include Decorator

def cost
@decorated.cost + 0.4
end
end

So how does this solve our original problem? The real power of decorators lies in the fact that they can act like the objects they are decorating. By taking this one step further, you can wrap decorators with other decorators as long as they share the same interface. By creating decorators for our different “extras”, we can create coffees using a combination of decorators and get the total cost of the coffee.

class Whip
include Decorator

def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

</pre>

====Java====
In this java example <ref>[http://java-x.blogspot.com/2007/01/implementing-decorator-pattern-in-java.html]</ref>
basicInterface: Defines the interface for objects that can have responsibilities added to them dynamically.
Basic: Defines an object to which additional responsibilities can be attached.
Decorator: maintains a reference to a Basic object and defines an interface that conforms to Basic's interface.
ConcreteDecorator: adds responsibilities to the component.
<pre>

public interface basicInterface {
public void do();
}

public class Basic implements basicInterface{
public void do() {
System.out.println("Do basic stuff");
}
}

public interface Decorator extends basicInterface {
public void addedStuff();
}

public class ConcreteDecorator implements Decorator {

basicInterface basic;

public ConcreteDecorator(basicInterface basic) {
super();
this.basic = basic;
}

public void addedStuff() {
System.out.println("Decorator does other stuff too");

}

public void do() {
basic.do();
addedStuff();
}
}

public class Client {
public static void main(String[] args) {
basicInterface comp = new Basic();
Decorator decorator = new ConcreteDecorator(comp);
decorator.do();
}
}

</pre>

In this way we can add concrete decorator classes to provided the added functionality to the basic class.

==Adapter Pattern==
Adapter pattern acts as a bridge between objects. It adapts to the changing needs of the classes using interface. In real world we have adapters for power supplies, adapters for camera memory cards etc.If a class is expecting some type of object and we have an object offering the same features, but exposing a different interface we want to use both of them so instead of implementing them again and changing existing classes,we can create an adapter.
===Intent===
Match an existing object to a particular interface.
===Problem===
A system has the right data and behavior but the wrong interface. Typically used when you have to make something a
derivative of an abstract class you already have or are defining.
===Solution===
Convert original interface component into another one through an intermediate adapter.Solution: The adapter provides a “wrapper” with the desired
interface
===Implementation===

====Ruby====
The Adapter offers exactly the same interface as the adaptee, but it can override any method or add new ones. In the below code the
adapter code delegates the call to the adaptee and performs operations according to the client requirements by performing additional operation to the results returned by the adaptee.
features
<ref>[http://www.scribd.com/doc/396559/gof-patterns-in-ruby]</ref>
<pre>
class Adaptee
def talk
puts "I'm Adaptee"
end
def whine
puts "Stop bullying me!"
end
end

class Adapter
def initialize
@adaptee=Adaptee.new
end
def talk
#override
puts "Let me introduce you to Adaptee!"
@adaptee.talk
puts "That was my adaptee"
end
def do_other_stuff
puts "I'm versatile"
end
def method_missing method
if
@adaptee.respond_to? method@adaptee.sendmethod
else
raise NotImplementedError,"This method is not "+\ "available on this interface"
end
end
end
if__FILE__==$0
adapter=Adapter.new
adapter.talk
adapter.whine
adapter.do_other_stuff
end
</pre>

output -
Let me introduce you to Adaptee!
I'm Adaptee
That was my adaptee
Stop bullying me!
I'm versatile

====Java====
The following example shows a simple implementation of the pattern. Consider that we have a third party library that provides sorting functionality through it's NumberSorter class.This is our adaptee, a third party implementation of a number sorter that deals with Lists, not arrays.[http://java.dzone.com/articles/design-patterns-uncovered-0]
<pre>
public class NumberSorter
{
public List<Integer> sort(List<Integer> numbers)
{
//sort and return
return new ArrayList<Integer>();
}
}
</pre>

Our Client deals with primitive arrays rather than Lists. For the sake of this example, lets say we can't change the client to use Lists.
<pre>
int[] numbers = new int[]{34, 2, 4, 12, 1};
Sorter sorter = new SortListAdapter();
sorter.sort(numbers);
</pre>

We've provided a Sorter interface that expects the client input. This is our target.
//this is our Target interface
<pre>
public interface Sorter
{
public int[] sort(int[] numbers);
}
</pre>
Finally, the SortListAdapter implements our target interface and deals with our adaptee, NumberSorter
<pre>
public class SortListAdapter implements Sorter
{
@Override
public int[] sort(int[] numbers)
{
//convert the array to a List
List<Integer> numberList = new ArrayList<Integer>();
//call the adapter
NumberSorter sorter = new NumberSorter();
numberList = sorter.sort(numberList);

//convert the list back to an array and return
return sortedNumbers;
}
}
</pre>

===Difference between Decorator Pattern and Adapter Pattern===
Adapters can be used for decorating but their primary aim is to for enabling classes of different types not able to communicate
because of incompatible interface to interact via a adapter interface.
Inheritance and composition is used to achieve this.Decorators on the other hand are not used to add different methods to all the instances instead they are used to add specific behavior to some specific instances. Though Adapters making use of composition may also be used here, but the intention is different here with what it's in case of a Adapter.
<ref>[http://geekexplains.blogspot.com/2008/09/structural-patterns-adapter-decorator.html]</ref>

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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>[http://c2.com/cgi/wiki?GangOfFour"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.
[[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.

Let's take a look at this in action with a sequence diagram.
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use tree structure and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern.
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==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 [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references />
==Additional Reading==
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]
*[http://www.slideshare.net/MarcusDenker/behavioral-reflection Behavioral reflection]
*[http://msdn.microsoft.com/en-us/library/67ef8sbd(v=vs.80).aspx C# Basics]
*[http://msdn.microsoft.com/en-us/library/ms173183(v=vs.80).aspx C# Reflection basics]
*[http://www.codeguru.com/csharp/csharp/cs_misc/reflection/article.php/c4257/An-Introduction-to-Reflection-in-C.htm Introduction to C# Reflection]
*[http://oreilly.com/catalog/progcsharp/chapter/ch18.html C# Attributes and Reflection]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-18T03:10:45Z

Knagar:

==Introduction==
In this section we will be discussing about the decorator pattern and its related patterns such as adapter,proxy and composite.

==Decorator Pattern==
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.
We have an instance, and we put another instance inside of it. They both support the same (or similar) interfaces. The one on the outside is a "decorator." We can use the one on the outside. It either masks, changes, or pass-throughs the methods of the instance inside of it. <ref>[Decorator Patternhttp://www.oodesign.com/decorator-pattern.html]</ref>
===Intent===
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality as provided by Gang of four. <ref>[http://c2.com/cgi/wiki?GangOfFour"Gang of four"]</ref>
===Problem===
The state of an object can be changed at compile time but no change is possible at run time if the language does not permit so.
===Solution===
Add a decorator module , class that acts as a extender for functions at run time such that the calls are delegated to the decorator
to extend the functionality of the objects at run time.
===Implementation===

====Ruby====
The example shows a Tea class with a method cost defining its cost as 4.
<ref>[http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html]</ref>
<pre>

If we want to calculate the cost of a cup of coffee. We have Coffee class, which implements a cost() method.

class Coffee
def cost
2
end
end

But what if we want the cost of a coffee with milk? We could have a new class:

class MilkCoffee
def cost
2.4
end
end

But now if we want cream. And sprinkles. Clearly, creating new classes is going to lead to a huge number of classes in our application. It just isn’t realistic to create classes for different combinations of coffee and extras. It could get worse – what if we have different types of coffee? We would then have to have combinations of extras with each different type of coffee.Hence we will use decorator pattern.

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

And thats all you need. You can include this into any class you want to act as a decorator. You can then use that decorator as if it was the object it is decorating; by default all messages sent to the decorator are forwarded on to the decorated object. You can then decorate the methods you need to extend:

class Milk
include Decorator

def cost
@decorated.cost + 0.4
end
end

So how does this solve our original problem? The real power of decorators lies in the fact that they can act like the objects they are decorating. By taking this one step further, you can wrap decorators with other decorators as long as they share the same interface. By creating decorators for our different “extras”, we can create coffees using a combination of decorators and get the total cost of the coffee.

class Whip
include Decorator

def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

</pre>

====Java====
In this java example <ref>[http://java-x.blogspot.com/2007/01/implementing-decorator-pattern-in-java.html]</ref>
basicInterface: Defines the interface for objects that can have responsibilities added to them dynamically.
Basic: Defines an object to which additional responsibilities can be attached.
Decorator: maintains a reference to a Basic object and defines an interface that conforms to Basic's interface.
ConcreteDecorator: adds responsibilities to the component.
<pre>

public interface basicInterface {
public void do();
}

public class Basic implements basicInterface{
public void do() {
System.out.println("Do basic stuff");
}
}

public interface Decorator extends basicInterface {
public void addedStuff();
}

public class ConcreteDecorator implements Decorator {

basicInterface basic;

public ConcreteDecorator(basicInterface basic) {
super();
this.basic = basic;
}

public void addedStuff() {
System.out.println("Decorator does other stuff too");

}

public void do() {
basic.do();
addedStuff();
}
}

public class Client {
public static void main(String[] args) {
basicInterface comp = new Basic();
Decorator decorator = new ConcreteDecorator(comp);
decorator.do();
}
}

</pre>

In this way we can add concrete decorator classes to provided the added functionality to the basic class.

==Adapter Pattern==
Adapter pattern acts as a bridge between objects. It adapts to the changing needs of the classes using interface. In real world we have adapters for power supplies, adapters for camera memory cards etc.If a class is expecting some type of object and we have an object offering the same features, but exposing a different interface we want to use both of them so instead of implementing them again and changing existing classes,we can create an adapter.
===Intent===
Match an existing object to a particular interface.
===Problem===
A system has the right data and behavior but the wrong interface. Typically used when you have to make something a
derivative of an abstract class you already have or are defining.
===Solution===
Convert original interface component into another one through an intermediate adapter.Solution: The adapter provides a “wrapper” with the desired
interface
===Implementation===

====Ruby====
The Adapter offers exactly the same interface as the adaptee, but it can override any method or add new ones. In the below code the
adapter code delegates the call to the adaptee and performs operations according to the client requirements by performing additional operation to the results returned by the adaptee.
features
<ref>[http://www.scribd.com/doc/396559/gof-patterns-in-ruby]</ref>
<pre>
class Adaptee
def talk
puts "I'm Adaptee"
end
def whine
puts "Stop bullying me!"
end
end

class Adapter
def initialize
@adaptee=Adaptee.new
end
def talk
#override
puts "Let me introduce you to Adaptee!"
@adaptee.talk
puts "That was my adaptee"
end
def do_other_stuff
puts "I'm versatile"
end
def method_missing method
if
@adaptee.respond_to? method@adaptee.sendmethod
else
raise NotImplementedError,"This method is not "+\ "available on this interface"
end
end
end
if__FILE__==$0
adapter=Adapter.new
adapter.talk
adapter.whine
adapter.do_other_stuff
end
</pre>

output -
Let me introduce you to Adaptee!
I'm Adaptee
That was my adaptee
Stop bullying me!
I'm versatile

====Java====
The following example shows a simple implementation of the pattern. Consider that we have a third party library that provides sorting functionality through it's NumberSorter class.This is our adaptee, a third party implementation of a number sorter that deals with Lists, not arrays.[http://java.dzone.com/articles/design-patterns-uncovered-0]
<pre>
public class NumberSorter
{
public List<Integer> sort(List<Integer> numbers)
{
//sort and return
return new ArrayList<Integer>();
}
}
</pre>

Our Client deals with primitive arrays rather than Lists. For the sake of this example, lets say we can't change the client to use Lists.
<pre>
int[] numbers = new int[]{34, 2, 4, 12, 1};
Sorter sorter = new SortListAdapter();
sorter.sort(numbers);
</pre>

We've provided a Sorter interface that expects the client input. This is our target.
//this is our Target interface
<pre>
public interface Sorter
{
public int[] sort(int[] numbers);
}
</pre>
Finally, the SortListAdapter implements our target interface and deals with our adaptee, NumberSorter
<pre>
public class SortListAdapter implements Sorter
{
@Override
public int[] sort(int[] numbers)
{
//convert the array to a List
List<Integer> numberList = new ArrayList<Integer>();
//call the adapter
NumberSorter sorter = new NumberSorter();
numberList = sorter.sort(numberList);

//convert the list back to an array and return
return sortedNumbers;
}
}
</pre>

===Difference between Decorator Pattern and Adapter Pattern===
Adapters can be used for decorating but their primary aim is to for enabling classes of different types not able to communicate
because of incompatible interface to interact via a adapter interface.
Inheritance and composition is used to achieve this.Decorators on the other hand are not used to add different methods to all the instances instead they are used to add specific behavior to some specific instances. Though Adapters making use of composition may also be used here, but the intention is different here with what it's in case of a Adapter.
<ref>[http://geekexplains.blogspot.com/2008/09/structural-patterns-adapter-decorator.html]</ref>

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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>[http://c2.com/cgi/wiki?GangOfFour"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.
[[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.

Let's take a look at this in action with a sequence diagram.
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use tree structure and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern.
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==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 [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references />
==Additional Reading==
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]
*[http://www.slideshare.net/MarcusDenker/behavioral-reflection Behavioral reflection]
*[http://msdn.microsoft.com/en-us/library/67ef8sbd(v=vs.80).aspx C# Basics]
*[http://msdn.microsoft.com/en-us/library/ms173183(v=vs.80).aspx C# Reflection basics]
*[http://www.codeguru.com/csharp/csharp/cs_misc/reflection/article.php/c4257/An-Introduction-to-Reflection-in-C.htm Introduction to C# Reflection]
*[http://oreilly.com/catalog/progcsharp/chapter/ch18.html C# Attributes and Reflection]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-18T03:07:40Z

Knagar: /* Decorator Pattern */

==Introduction==
In this section we will be discussing about the decorator pattern and its related patterns such as adapter,proxy and composite.

==Decorator Pattern==
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.
We have an instance, and we put another instance inside of it. They both support the same (or similar) interfaces. The one on the outside is a "decorator." We can use the one on the outside. It either masks, changes, or pass-throughs the methods of the instance inside of it. <ref>Decorator Pattern[http://www.oodesign.com/decorator-pattern.html]</ref>
===Intent===
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality as provided by Gang of four. <ref>[http://c2.com/cgi/wiki?GangOfFour"Gang of four"]</ref>
===Problem===
The state of an object can be changed at compile time but no change is possible at run time if the language does not permit so.
===Solution===
Add a decorator module , class that acts as a extender for functions at run time such that the calls are delegated to the decorator
to extend the functionality of the objects at run time.
===Implementation===

====Ruby====
The example shows a Tea class with a method cost defining its cost as 4.
<ref>[http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html]</ref>
<pre>

If we want to calculate the cost of a cup of coffee. We have Coffee class, which implements a cost() method.

class Coffee
def cost
2
end
end

But what if we want the cost of a coffee with milk? We could have a new class:

class MilkCoffee
def cost
2.4
end
end

But now if we want cream. And sprinkles. Clearly, creating new classes is going to lead to a huge number of classes in our application. It just isn’t realistic to create classes for different combinations of coffee and extras. It could get worse – what if we have different types of coffee? We would then have to have combinations of extras with each different type of coffee.Hence we will use decorator pattern.

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

And thats all you need. You can include this into any class you want to act as a decorator. You can then use that decorator as if it was the object it is decorating; by default all messages sent to the decorator are forwarded on to the decorated object. You can then decorate the methods you need to extend:

class Milk
include Decorator

def cost
@decorated.cost + 0.4
end
end

So how does this solve our original problem? The real power of decorators lies in the fact that they can act like the objects they are decorating. By taking this one step further, you can wrap decorators with other decorators as long as they share the same interface. By creating decorators for our different “extras”, we can create coffees using a combination of decorators and get the total cost of the coffee.

class Whip
include Decorator

def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

</pre>

====Java====
In this java example <ref>[http://java-x.blogspot.com/2007/01/implementing-decorator-pattern-in-java.html]</ref>
basicInterface: Defines the interface for objects that can have responsibilities added to them dynamically.
Basic: Defines an object to which additional responsibilities can be attached.
Decorator: maintains a reference to a Basic object and defines an interface that conforms to Basic's interface.
ConcreteDecorator: adds responsibilities to the component.
<pre>

public interface basicInterface {
public void do();
}

public class Basic implements basicInterface{
public void do() {
System.out.println("Do basic stuff");
}
}

public interface Decorator extends basicInterface {
public void addedStuff();
}

public class ConcreteDecorator implements Decorator {

basicInterface basic;

public ConcreteDecorator(basicInterface basic) {
super();
this.basic = basic;
}

public void addedStuff() {
System.out.println("Decorator does other stuff too");

}

public void do() {
basic.do();
addedStuff();
}
}

public class Client {
public static void main(String[] args) {
basicInterface comp = new Basic();
Decorator decorator = new ConcreteDecorator(comp);
decorator.do();
}
}

</pre>

In this way we can add concrete decorator classes to provided the added functionality to the basic class.

==Adapter Pattern==
Adapter pattern acts as a bridge between objects. It adapts to the changing needs of the classes using interface. In real world we have adapters for power supplies, adapters for camera memory cards etc.If a class is expecting some type of object and we have an object offering the same features, but exposing a different interface we want to use both of them so instead of implementing them again and changing existing classes,we can create an adapter.
===Intent===
Match an existing object to a particular interface.
===Problem===
A system has the right data and behavior but the wrong interface. Typically used when you have to make something a
derivative of an abstract class you already have or are defining.
===Solution===
Convert original interface component into another one through an intermediate adapter.Solution: The adapter provides a “wrapper” with the desired
interface
===Implementation===

====Ruby====
The Adapter offers exactly the same interface as the adaptee, but it can override any method or add new ones. In the below code the
adapter code delegates the call to the adaptee and performs operations according to the client requirements by performing additional operation to the results returned by the adaptee.
features
<ref>[http://www.scribd.com/doc/396559/gof-patterns-in-ruby]</ref>
<pre>
class Adaptee
def talk
puts "I'm Adaptee"
end
def whine
puts "Stop bullying me!"
end
end

class Adapter
def initialize
@adaptee=Adaptee.new
end
def talk
#override
puts "Let me introduce you to Adaptee!"
@adaptee.talk
puts "That was my adaptee"
end
def do_other_stuff
puts "I'm versatile"
end
def method_missing method
if
@adaptee.respond_to? method@adaptee.sendmethod
else
raise NotImplementedError,"This method is not "+\ "available on this interface"
end
end
end
if__FILE__==$0
adapter=Adapter.new
adapter.talk
adapter.whine
adapter.do_other_stuff
end
</pre>

output -
Let me introduce you to Adaptee!
I'm Adaptee
That was my adaptee
Stop bullying me!
I'm versatile

====Java====
The following example shows a simple implementation of the pattern. Consider that we have a third party library that provides sorting functionality through it's NumberSorter class.This is our adaptee, a third party implementation of a number sorter that deals with Lists, not arrays.[http://java.dzone.com/articles/design-patterns-uncovered-0]
<pre>
public class NumberSorter
{
public List<Integer> sort(List<Integer> numbers)
{
//sort and return
return new ArrayList<Integer>();
}
}
</pre>

Our Client deals with primitive arrays rather than Lists. For the sake of this example, lets say we can't change the client to use Lists.
<pre>
int[] numbers = new int[]{34, 2, 4, 12, 1};
Sorter sorter = new SortListAdapter();
sorter.sort(numbers);
</pre>

We've provided a Sorter interface that expects the client input. This is our target.
//this is our Target interface
<pre>
public interface Sorter
{
public int[] sort(int[] numbers);
}
</pre>
Finally, the SortListAdapter implements our target interface and deals with our adaptee, NumberSorter
<pre>
public class SortListAdapter implements Sorter
{
@Override
public int[] sort(int[] numbers)
{
//convert the array to a List
List<Integer> numberList = new ArrayList<Integer>();
//call the adapter
NumberSorter sorter = new NumberSorter();
numberList = sorter.sort(numberList);

//convert the list back to an array and return
return sortedNumbers;
}
}
</pre>

===Difference between Decorator Pattern and Adapter Pattern===
Adapters can be used for decorating but their primary aim is to for enabling classes of different types not able to communicate
because of incompatible interface to interact via a adapter interface.
Inheritance and composition is used to achieve this.Decorators on the other hand are not used to add different methods to all the instances instead they are used to add specific behavior to some specific instances. Though Adapters making use of composition may also be used here, but the intention is different here with what it's in case of a Adapter.
<ref>[http://geekexplains.blogspot.com/2008/09/structural-patterns-adapter-decorator.html]</ref>

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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>[http://c2.com/cgi/wiki?GangOfFour"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.
[[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.

Let's take a look at this in action with a sequence diagram.
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use tree structure and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern.
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==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 [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references />
==Additional Reading==
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]
*[http://www.slideshare.net/MarcusDenker/behavioral-reflection Behavioral reflection]
*[http://msdn.microsoft.com/en-us/library/67ef8sbd(v=vs.80).aspx C# Basics]
*[http://msdn.microsoft.com/en-us/library/ms173183(v=vs.80).aspx C# Reflection basics]
*[http://www.codeguru.com/csharp/csharp/cs_misc/reflection/article.php/c4257/An-Introduction-to-Reflection-in-C.htm Introduction to C# Reflection]
*[http://oreilly.com/catalog/progcsharp/chapter/ch18.html C# Attributes and Reflection]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-18T02:50:41Z

Knagar: /* Ruby */

==Introduction==
In this section we will be discussing about the decorator pattern and its related patterns such as adapter,proxy and composite.

==Decorator Pattern==
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.
We have an instance, and we put another instance inside of it. They both support the same (or similar) interfaces. The one on the outside is a "decorator." We can use the one on the outside. It either masks, changes, or pass-throughs the methods of the instance inside of it. <ref>[http://www.oodesign.com/decorator-pattern.html]</ref>
===Intent===
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality as provided by Gang of four. <ref>[http://c2.com/cgi/wiki?GangOfFour"Gang of four"]</ref>
===Problem===
The state of an object can be changed at compile time but no change is possible at run time if the language does not permit so.
===Solution===
Add a decorator module , class that acts as a extender for functions at run time such that the calls are delegated to the decorator
to extend the functionality of the objects at run time.
===Implementation===

====Ruby====
The example shows a Tea class with a method cost defining its cost as 4.
<ref>[http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html]</ref>
<pre>

If we want to calculate the cost of a cup of coffee. We have Coffee class, which implements a cost() method.

class Coffee
def cost
2
end
end

But what if we want the cost of a coffee with milk? We could have a new class:

class MilkCoffee
def cost
2.4
end
end

But now if we want cream. And sprinkles. Clearly, creating new classes is going to lead to a huge number of classes in our application. It just isn’t realistic to create classes for different combinations of coffee and extras. It could get worse – what if we have different types of coffee? We would then have to have combinations of extras with each different type of coffee.Hence we will use decorator pattern.

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

And thats all you need. You can include this into any class you want to act as a decorator. You can then use that decorator as if it was the object it is decorating; by default all messages sent to the decorator are forwarded on to the decorated object. You can then decorate the methods you need to extend:

class Milk
include Decorator

def cost
@decorated.cost + 0.4
end
end

So how does this solve our original problem? The real power of decorators lies in the fact that they can act like the objects they are decorating. By taking this one step further, you can wrap decorators with other decorators as long as they share the same interface. By creating decorators for our different “extras”, we can create coffees using a combination of decorators and get the total cost of the coffee.

class Whip
include Decorator

def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

</pre>

====Java====
In this java example <ref>[http://java-x.blogspot.com/2007/01/implementing-decorator-pattern-in-java.html]</ref>
basicInterface: Defines the interface for objects that can have responsibilities added to them dynamically.
Basic: Defines an object to which additional responsibilities can be attached.
Decorator: maintains a reference to a Basic object and defines an interface that conforms to Basic's interface.
ConcreteDecorator: adds responsibilities to the component.
<pre>

public interface basicInterface {
public void do();
}

public class Basic implements basicInterface{
public void do() {
System.out.println("Do basic stuff");
}
}

public interface Decorator extends basicInterface {
public void addedStuff();
}

public class ConcreteDecorator implements Decorator {

basicInterface basic;

public ConcreteDecorator(basicInterface basic) {
super();
this.basic = basic;
}

public void addedStuff() {
System.out.println("Decorator does other stuff too");

}

public void do() {
basic.do();
addedStuff();
}
}

public class Client {
public static void main(String[] args) {
basicInterface comp = new Basic();
Decorator decorator = new ConcreteDecorator(comp);
decorator.do();
}
}

</pre>

In this way we can add concrete decorator classes to provided the added functionality to the basic class.

==Adapter Pattern==
Adapter pattern acts as a bridge between objects. It adapts to the changing needs of the classes using interface. In real world we have adapters for power supplies, adapters for camera memory cards etc.If a class is expecting some type of object and we have an object offering the same features, but exposing a different interface we want to use both of them so instead of implementing them again and changing existing classes,we can create an adapter.
===Intent===
Match an existing object to a particular interface.
===Problem===
A system has the right data and behavior but the wrong interface. Typically used when you have to make something a
derivative of an abstract class you already have or are defining.
===Solution===
Convert original interface component into another one through an intermediate adapter.Solution: The adapter provides a “wrapper” with the desired
interface
===Implementation===

====Ruby====
The Adapter offers exactly the same interface as the adaptee, but it can override any method or add new ones. In the below code the
adapter code delegates the call to the adaptee and performs operations according to the client requirements by performing additional operation to the results returned by the adaptee.
features
<ref>[http://www.scribd.com/doc/396559/gof-patterns-in-ruby]</ref>
<pre>
class Adaptee
def talk
puts "I'm Adaptee"
end
def whine
puts "Stop bullying me!"
end
end

class Adapter
def initialize
@adaptee=Adaptee.new
end
def talk
#override
puts "Let me introduce you to Adaptee!"
@adaptee.talk
puts "That was my adaptee"
end
def do_other_stuff
puts "I'm versatile"
end
def method_missing method
if
@adaptee.respond_to? method@adaptee.sendmethod
else
raise NotImplementedError,"This method is not "+\ "available on this interface"
end
end
end
if__FILE__==$0
adapter=Adapter.new
adapter.talk
adapter.whine
adapter.do_other_stuff
end
</pre>

output -
Let me introduce you to Adaptee!
I'm Adaptee
That was my adaptee
Stop bullying me!
I'm versatile

====Java====
The following example shows a simple implementation of the pattern. Consider that we have a third party library that provides sorting functionality through it's NumberSorter class.This is our adaptee, a third party implementation of a number sorter that deals with Lists, not arrays.[http://java.dzone.com/articles/design-patterns-uncovered-0]
<pre>
public class NumberSorter
{
public List<Integer> sort(List<Integer> numbers)
{
//sort and return
return new ArrayList<Integer>();
}
}
</pre>

Our Client deals with primitive arrays rather than Lists. For the sake of this example, lets say we can't change the client to use Lists.
<pre>
int[] numbers = new int[]{34, 2, 4, 12, 1};
Sorter sorter = new SortListAdapter();
sorter.sort(numbers);
</pre>

We've provided a Sorter interface that expects the client input. This is our target.
//this is our Target interface
<pre>
public interface Sorter
{
public int[] sort(int[] numbers);
}
</pre>
Finally, the SortListAdapter implements our target interface and deals with our adaptee, NumberSorter
<pre>
public class SortListAdapter implements Sorter
{
@Override
public int[] sort(int[] numbers)
{
//convert the array to a List
List<Integer> numberList = new ArrayList<Integer>();
//call the adapter
NumberSorter sorter = new NumberSorter();
numberList = sorter.sort(numberList);

//convert the list back to an array and return
return sortedNumbers;
}
}
</pre>

===Difference between Decorator Pattern and Adapter Pattern===
Adapters can be used for decorating but their primary aim is to for enabling classes of different types not able to communicate
because of incompatible interface to interact via a adapter interface.
Inheritance and composition is used to achieve this.Decorators on the other hand are not used to add different methods to all the instances instead they are used to add specific behavior to some specific instances. Though Adapters making use of composition may also be used here, but the intention is different here with what it's in case of a Adapter.
<ref>[http://geekexplains.blogspot.com/2008/09/structural-patterns-adapter-decorator.html]</ref>

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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>[http://c2.com/cgi/wiki?GangOfFour"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.
[[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.

Let's take a look at this in action with a sequence diagram.
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use tree structure and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern.
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==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 [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references />
==Additional Reading==
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]
*[http://www.slideshare.net/MarcusDenker/behavioral-reflection Behavioral reflection]
*[http://msdn.microsoft.com/en-us/library/67ef8sbd(v=vs.80).aspx C# Basics]
*[http://msdn.microsoft.com/en-us/library/ms173183(v=vs.80).aspx C# Reflection basics]
*[http://www.codeguru.com/csharp/csharp/cs_misc/reflection/article.php/c4257/An-Introduction-to-Reflection-in-C.htm Introduction to C# Reflection]
*[http://oreilly.com/catalog/progcsharp/chapter/ch18.html C# Attributes and Reflection]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-18T02:47:00Z

Knagar: /* Java */

==Introduction==
In this section we will be discussing about the decorator pattern and its related patterns such as adapter,proxy and composite.

==Decorator Pattern==
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.
We have an instance, and we put another instance inside of it. They both support the same (or similar) interfaces. The one on the outside is a "decorator." We can use the one on the outside. It either masks, changes, or pass-throughs the methods of the instance inside of it. <ref>[http://www.oodesign.com/decorator-pattern.html]</ref>
===Intent===
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality as provided by Gang of four. <ref>[http://c2.com/cgi/wiki?GangOfFour"Gang of four"]</ref>
===Problem===
The state of an object can be changed at compile time but no change is possible at run time if the language does not permit so.
===Solution===
Add a decorator module , class that acts as a extender for functions at run time such that the calls are delegated to the decorator
to extend the functionality of the objects at run time.
===Implementation===

====Ruby====
The example shows a Tea class with a method cost defining its cost as 4.
<ref>[http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html]</ref>
<pre>

If we want to calculate the cost of a cup of coffee. We have Coffee class, which implements a cost() method.

class Coffee
def cost
2
end
end

But what if we want the cost of a coffee with milk? We could have a new class:

class MilkCoffee
def cost
2.4
end
end

But now if we want cream. And sprinkles. Clearly, creating new classes is going to lead to a huge number of classes in our application. It just isn’t realistic to create classes for different combinations of coffee and extras. It could get worse – what if we have different types of coffee? We would then have to have combinations of extras with each different type of coffee.Hence we will use decorator pattern.

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

And thats all you need. You can include this into any class you want to act as a decorator. You can then use that decorator as if it was the object it is decorating; by default all messages sent to the decorator are forwarded on to the decorated object. You can then decorate the methods you need to extend:

class Milk
include Decorator

def cost
@decorated.cost + 0.4
end
end

So how does this solve our original problem? The real power of decorators lies in the fact that they can act like the objects they are decorating. By taking this one step further, you can wrap decorators with other decorators as long as they share the same interface. By creating decorators for our different “extras”, we can create coffees using a combination of decorators and get the total cost of the coffee.

class Whip
include Decorator

def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

</pre>

====Java====
In this java example <ref>[http://java-x.blogspot.com/2007/01/implementing-decorator-pattern-in-java.html]</ref>
basicInterface: Defines the interface for objects that can have responsibilities added to them dynamically.
Basic: Defines an object to which additional responsibilities can be attached.
Decorator: maintains a reference to a Basic object and defines an interface that conforms to Basic's interface.
ConcreteDecorator: adds responsibilities to the component.
<pre>

public interface basicInterface {
public void do();
}

public class Basic implements basicInterface{
public void do() {
System.out.println("Do basic stuff");
}
}

public interface Decorator extends basicInterface {
public void addedStuff();
}

public class ConcreteDecorator implements Decorator {

basicInterface basic;

public ConcreteDecorator(basicInterface basic) {
super();
this.basic = basic;
}

public void addedStuff() {
System.out.println("Decorator does other stuff too");

}

public void do() {
basic.do();
addedStuff();
}
}

public class Client {
public static void main(String[] args) {
basicInterface comp = new Basic();
Decorator decorator = new ConcreteDecorator(comp);
decorator.do();
}
}

</pre>

In this way we can add concrete decorator classes to provided the added functionality to the basic class.

==Adapter Pattern==
Adapter pattern acts as a bridge between objects. It adapts to the changing needs of the classes using interface. In real world we have adapters for power supplies, adapters for camera memory cards etc.If a class is expecting some type of object and we have an object offering the same features, but exposing a different interface we want to use both of them so instead of implementing them again and changing existing classes,we can create an adapter.
===Intent===
Match an existing object to a particular interface.
===Problem===
A system has the right data and behavior but the wrong interface. Typically used when you have to make something a
derivative of an abstract class you already have or are defining.
===Solution===
Convert original interface component into another one through an intermediate adapter.Solution: The adapter provides a “wrapper” with the desired
interface
===Implementation===

====Ruby====
The Adapter offers exactly the same interface as the adaptee, but it can override any method or add new ones.
<ref>[http://www.scribd.com/doc/396559/gof-patterns-in-ruby]</ref>
<pre>
class Adaptee
def talk
puts "I'm Adaptee"
end
def whine
puts "Stop bullying me!"
end
end

class Adapter
def initialize
@adaptee=Adaptee.new
end
def talk
#override
puts "Let me introduce you to Adaptee!"
@adaptee.talk
puts "That was my adaptee"
end
def do_other_stuff
puts "I'm versatile"
end
def method_missing method
if
@adaptee.respond_to? method@adaptee.sendmethod
else
raise NotImplementedError,"This method is not "+\ "available on this interface"
end
end
end
if__FILE__==$0
adapter=Adapter.new
adapter.talk
adapter.whine
adapter.do_other_stuff
end
</pre>

output -
Let me introduce you to Adaptee!
I'm Adaptee
That was my adaptee
Stop bullying me!
I'm versatile

====Java====
The following example shows a simple implementation of the pattern. Consider that we have a third party library that provides sorting functionality through it's NumberSorter class.This is our adaptee, a third party implementation of a number sorter that deals with Lists, not arrays.[http://java.dzone.com/articles/design-patterns-uncovered-0]
<pre>
public class NumberSorter
{
public List<Integer> sort(List<Integer> numbers)
{
//sort and return
return new ArrayList<Integer>();
}
}
</pre>

Our Client deals with primitive arrays rather than Lists. For the sake of this example, lets say we can't change the client to use Lists.
<pre>
int[] numbers = new int[]{34, 2, 4, 12, 1};
Sorter sorter = new SortListAdapter();
sorter.sort(numbers);
</pre>

We've provided a Sorter interface that expects the client input. This is our target.
//this is our Target interface
<pre>
public interface Sorter
{
public int[] sort(int[] numbers);
}
</pre>
Finally, the SortListAdapter implements our target interface and deals with our adaptee, NumberSorter
<pre>
public class SortListAdapter implements Sorter
{
@Override
public int[] sort(int[] numbers)
{
//convert the array to a List
List<Integer> numberList = new ArrayList<Integer>();
//call the adapter
NumberSorter sorter = new NumberSorter();
numberList = sorter.sort(numberList);

//convert the list back to an array and return
return sortedNumbers;
}
}
</pre>

===Difference between Decorator Pattern and Adapter Pattern===
Adapters can be used for decorating but their primary aim is to for enabling classes of different types not able to communicate
because of incompatible interface to interact via a adapter interface.
Inheritance and composition is used to achieve this.Decorators on the other hand are not used to add different methods to all the instances instead they are used to add specific behavior to some specific instances. Though Adapters making use of composition may also be used here, but the intention is different here with what it's in case of a Adapter.
<ref>[http://geekexplains.blogspot.com/2008/09/structural-patterns-adapter-decorator.html]</ref>

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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>[http://c2.com/cgi/wiki?GangOfFour"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.
[[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.

Let's take a look at this in action with a sequence diagram.
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use tree structure and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern.
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==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 [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references />
==Additional Reading==
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]
*[http://www.slideshare.net/MarcusDenker/behavioral-reflection Behavioral reflection]
*[http://msdn.microsoft.com/en-us/library/67ef8sbd(v=vs.80).aspx C# Basics]
*[http://msdn.microsoft.com/en-us/library/ms173183(v=vs.80).aspx C# Reflection basics]
*[http://www.codeguru.com/csharp/csharp/cs_misc/reflection/article.php/c4257/An-Introduction-to-Reflection-in-C.htm Introduction to C# Reflection]
*[http://oreilly.com/catalog/progcsharp/chapter/ch18.html C# Attributes and Reflection]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-18T02:46:00Z

Knagar: /* Ruby */

==Introduction==
In this section we will be discussing about the decorator pattern and its related patterns such as adapter,proxy and composite.

==Decorator Pattern==
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.
We have an instance, and we put another instance inside of it. They both support the same (or similar) interfaces. The one on the outside is a "decorator." We can use the one on the outside. It either masks, changes, or pass-throughs the methods of the instance inside of it. <ref>[http://www.oodesign.com/decorator-pattern.html]</ref>
===Intent===
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality as provided by Gang of four. <ref>[http://c2.com/cgi/wiki?GangOfFour"Gang of four"]</ref>
===Problem===
The state of an object can be changed at compile time but no change is possible at run time if the language does not permit so.
===Solution===
Add a decorator module , class that acts as a extender for functions at run time such that the calls are delegated to the decorator
to extend the functionality of the objects at run time.
===Implementation===

====Ruby====
The example shows a Tea class with a method cost defining its cost as 4.
<ref>[http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html]</ref>
<pre>

If we want to calculate the cost of a cup of coffee. We have Coffee class, which implements a cost() method.

class Coffee
def cost
2
end
end

But what if we want the cost of a coffee with milk? We could have a new class:

class MilkCoffee
def cost
2.4
end
end

But now if we want cream. And sprinkles. Clearly, creating new classes is going to lead to a huge number of classes in our application. It just isn’t realistic to create classes for different combinations of coffee and extras. It could get worse – what if we have different types of coffee? We would then have to have combinations of extras with each different type of coffee.Hence we will use decorator pattern.

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

And thats all you need. You can include this into any class you want to act as a decorator. You can then use that decorator as if it was the object it is decorating; by default all messages sent to the decorator are forwarded on to the decorated object. You can then decorate the methods you need to extend:

class Milk
include Decorator

def cost
@decorated.cost + 0.4
end
end

So how does this solve our original problem? The real power of decorators lies in the fact that they can act like the objects they are decorating. By taking this one step further, you can wrap decorators with other decorators as long as they share the same interface. By creating decorators for our different “extras”, we can create coffees using a combination of decorators and get the total cost of the coffee.

class Whip
include Decorator

def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

</pre>

====Java====
In this java example <ref>[http://java-x.blogspot.com/2007/01/implementing-decorator-pattern-in-java.html]</ref>
basicInterface: Defines the interface for objects that can have responsibilities added to them dynamically.
Basic: Defines an object to which additional responsibilities can be attached.
Decorator: maintains a reference to a Basic object and defines an interface that conforms to Basic's interface.
ConcreteDecorator: adds responsibilities to the component.
<pre>

public interface basicInterface {
public void do();
}

public class Basic implements basicInterface{
public void do() {
System.out.println("Do basic stuff");
}
}

public interface Decorator extends basicInterface {
public void addedStuff();
}

public class ConcreteDecorator implements Decorator {

basicInterface basic;

public ConcreteDecorator(basicInterface basic) {
super();
this.basic = basic;
}

public void addedStuff() {
System.out.println("Decorator does other stuff too");

}

public void do() {
basic.do();
addedStuff();
}
}

public class Client {
public static void main(String[] args) {
basicInterface comp = new Basic();
Decorator decorator = new ConcreteDecorator(comp);
decorator.do();
}
}

</pre>

In this way we can add concrete decorator classes to provided the added functionality to the basic class.

==Adapter Pattern==
Adapter pattern acts as a bridge between objects. It adapts to the changing needs of the classes using interface. In real world we have adapters for power supplies, adapters for camera memory cards etc.If a class is expecting some type of object and we have an object offering the same features, but exposing a different interface we want to use both of them so instead of implementing them again and changing existing classes,we can create an adapter.
===Intent===
Match an existing object to a particular interface.
===Problem===
A system has the right data and behavior but the wrong interface. Typically used when you have to make something a
derivative of an abstract class you already have or are defining.
===Solution===
Convert original interface component into another one through an intermediate adapter.Solution: The adapter provides a “wrapper” with the desired
interface
===Implementation===

====Ruby====
The Adapter offers exactly the same interface as the adaptee, but it can override any method or add new ones.
<ref>[http://www.scribd.com/doc/396559/gof-patterns-in-ruby]</ref>
<pre>
class Adaptee
def talk
puts "I'm Adaptee"
end
def whine
puts "Stop bullying me!"
end
end

class Adapter
def initialize
@adaptee=Adaptee.new
end
def talk
#override
puts "Let me introduce you to Adaptee!"
@adaptee.talk
puts "That was my adaptee"
end
def do_other_stuff
puts "I'm versatile"
end
def method_missing method
if
@adaptee.respond_to? method@adaptee.sendmethod
else
raise NotImplementedError,"This method is not "+\ "available on this interface"
end
end
end
if__FILE__==$0
adapter=Adapter.new
adapter.talk
adapter.whine
adapter.do_other_stuff
end
</pre>

output -
Let me introduce you to Adaptee!
I'm Adaptee
That was my adaptee
Stop bullying me!
I'm versatile

====Java====
The following example shows a simple implementation of the pattern. Consider that we have a third party library that provides sorting functionality through it's NumberSorter class. This is our Adaptee.This is our adaptee, a third party implementation of a number sorter that deals with Lists, not arrays.[http://java.dzone.com/articles/design-patterns-uncovered-0]
<pre>
public class NumberSorter
{
public List<Integer> sort(List<Integer> numbers)
{
//sort and return
return new ArrayList<Integer>();
}
}
</pre>

Our Client deals with primitive arrays rather than Lists. For the sake of this example, lets say we can't change the client to use Lists.
<pre>
int[] numbers = new int[]{34, 2, 4, 12, 1};
Sorter sorter = new SortListAdapter();
sorter.sort(numbers);
</pre>

We've provided a Sorter interface that expects the client input. This is our target.
//this is our Target interface
<pre>
public interface Sorter
{
public int[] sort(int[] numbers);
}
</pre>
Finally, the SortListAdapter implements our target interface and deals with our adaptee, NumberSorter
<pre>
public class SortListAdapter implements Sorter
{
@Override
public int[] sort(int[] numbers)
{
//convert the array to a List
List<Integer> numberList = new ArrayList<Integer>();
//call the adapter
NumberSorter sorter = new NumberSorter();
numberList = sorter.sort(numberList);

//convert the list back to an array and return
return sortedNumbers;
}
}
</pre>

===Difference between Decorator Pattern and Adapter Pattern===
Adapters can be used for decorating but their primary aim is to for enabling classes of different types not able to communicate
because of incompatible interface to interact via a adapter interface.
Inheritance and composition is used to achieve this.Decorators on the other hand are not used to add different methods to all the instances instead they are used to add specific behavior to some specific instances. Though Adapters making use of composition may also be used here, but the intention is different here with what it's in case of a Adapter.
<ref>[http://geekexplains.blogspot.com/2008/09/structural-patterns-adapter-decorator.html]</ref>

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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>[http://c2.com/cgi/wiki?GangOfFour"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.
[[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.

Let's take a look at this in action with a sequence diagram.
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use tree structure and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern.
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==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 [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references />
==Additional Reading==
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]
*[http://www.slideshare.net/MarcusDenker/behavioral-reflection Behavioral reflection]
*[http://msdn.microsoft.com/en-us/library/67ef8sbd(v=vs.80).aspx C# Basics]
*[http://msdn.microsoft.com/en-us/library/ms173183(v=vs.80).aspx C# Reflection basics]
*[http://www.codeguru.com/csharp/csharp/cs_misc/reflection/article.php/c4257/An-Introduction-to-Reflection-in-C.htm Introduction to C# Reflection]
*[http://oreilly.com/catalog/progcsharp/chapter/ch18.html C# Attributes and Reflection]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-18T02:44:52Z

Knagar: /* Ruby */

==Introduction==
In this section we will be discussing about the decorator pattern and its related patterns such as adapter,proxy and composite.

==Decorator Pattern==
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.
We have an instance, and we put another instance inside of it. They both support the same (or similar) interfaces. The one on the outside is a "decorator." We can use the one on the outside. It either masks, changes, or pass-throughs the methods of the instance inside of it. <ref>[http://www.oodesign.com/decorator-pattern.html]</ref>
===Intent===
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality as provided by Gang of four. <ref>[http://c2.com/cgi/wiki?GangOfFour"Gang of four"]</ref>
===Problem===
The state of an object can be changed at compile time but no change is possible at run time if the language does not permit so.
===Solution===
Add a decorator module , class that acts as a extender for functions at run time such that the calls are delegated to the decorator
to extend the functionality of the objects at run time.
===Implementation===

====Ruby====
The example shows a Tea class with a method cost defining its cost as 4.
<ref>[http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html]</ref>
<pre>

If we want to calculate the cost of a cup of coffee. We have Coffee class, which implements a cost() method.

class Coffee
def cost
2
end
end

But what if we want the cost of a coffee with milk? We could have a new class:

class MilkCoffee
def cost
2.4
end
end

But now if we want cream. And sprinkles. Clearly, creating new classes is going to lead to a huge number of classes in our application. It just isn’t realistic to create classes for different combinations of coffee and extras. It could get worse – what if we have different types of coffee? We would then have to have combinations of extras with each different type of coffee.Hence we will use decorator pattern.

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

And thats all you need. You can include this into any class you want to act as a decorator. You can then use that decorator as if it was the object it is decorating; by default all messages sent to the decorator are forwarded on to the decorated object. You can then decorate the methods you need to extend:

class Milk
include Decorator

def cost
@decorated.cost + 0.4
end
end

So how does this solve our original problem? The real power of decorators lies in the fact that they can act like the objects they are decorating. By taking this one step further, you can wrap decorators with other decorators as long as they share the same interface. By creating decorators for our different “extras”, we can create coffees using a combination of decorators and get the total cost of the coffee.

class Whip
include Decorator

def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

</pre>

====Java====
In this java example <ref>[http://java-x.blogspot.com/2007/01/implementing-decorator-pattern-in-java.html]</ref>
basicInterface: Defines the interface for objects that can have responsibilities added to them dynamically.
Basic: Defines an object to which additional responsibilities can be attached.
Decorator: maintains a reference to a Basic object and defines an interface that conforms to Basic's interface.
ConcreteDecorator: adds responsibilities to the component.
<pre>

public interface basicInterface {
public void do();
}

public class Basic implements basicInterface{
public void do() {
System.out.println("Do basic stuff");
}
}

public interface Decorator extends basicInterface {
public void addedStuff();
}

public class ConcreteDecorator implements Decorator {

basicInterface basic;

public ConcreteDecorator(basicInterface basic) {
super();
this.basic = basic;
}

public void addedStuff() {
System.out.println("Decorator does other stuff too");

}

public void do() {
basic.do();
addedStuff();
}
}

public class Client {
public static void main(String[] args) {
basicInterface comp = new Basic();
Decorator decorator = new ConcreteDecorator(comp);
decorator.do();
}
}

</pre>

In this way we can add concrete decorator classes to provided the added functionality to the basic class.

==Adapter Pattern==
Adapter pattern acts as a bridge between objects. It adapts to the changing needs of the classes using interface. In real world we have adapters for power supplies, adapters for camera memory cards etc.If a class is expecting some type of object and we have an object offering the same features, but exposing a different interface we want to use both of them so instead of implementing them again and changing existing classes,we can create an adapter.
===Intent===
Match an existing object to a particular interface.
===Problem===
A system has the right data and behavior but the wrong interface. Typically used when you have to make something a
derivative of an abstract class you already have or are defining.
===Solution===
Convert original interface component into another one through an intermediate adapter.Solution: The adapter provides a “wrapper” with the desired
interface
===Implementation===

====Ruby====
The Adapter offers exactly the same interface as the adaptee, but it can override any method or add new ones.
<pre>
class Adaptee
def talk
puts "I'm Adaptee"
end
def whine
puts "Stop bullying me!"
end
end

class Adapter
def initialize
@adaptee=Adaptee.new
end
def talk
#override
puts "Let me introduce you to Adaptee!"
@adaptee.talk
puts "That was my adaptee"
end
def do_other_stuff
puts "I'm versatile"
end
def method_missing method
if
@adaptee.respond_to? method@adaptee.sendmethod
else
raise NotImplementedError,"This method is not "+\ "available on this interface"
end
end
end
if__FILE__==$0
adapter=Adapter.new
adapter.talk
adapter.whine
adapter.do_other_stuff
end
</pre>

output -
Let me introduce you to Adaptee!
I'm Adaptee
That was my adaptee
Stop bullying me!
I'm versatile

====Java====
The following example shows a simple implementation of the pattern. Consider that we have a third party library that provides sorting functionality through it's NumberSorter class. This is our Adaptee.This is our adaptee, a third party implementation of a number sorter that deals with Lists, not arrays.[http://java.dzone.com/articles/design-patterns-uncovered-0]
<pre>
public class NumberSorter
{
public List<Integer> sort(List<Integer> numbers)
{
//sort and return
return new ArrayList<Integer>();
}
}
</pre>

Our Client deals with primitive arrays rather than Lists. For the sake of this example, lets say we can't change the client to use Lists.
<pre>
int[] numbers = new int[]{34, 2, 4, 12, 1};
Sorter sorter = new SortListAdapter();
sorter.sort(numbers);
</pre>

We've provided a Sorter interface that expects the client input. This is our target.
//this is our Target interface
<pre>
public interface Sorter
{
public int[] sort(int[] numbers);
}
</pre>
Finally, the SortListAdapter implements our target interface and deals with our adaptee, NumberSorter
<pre>
public class SortListAdapter implements Sorter
{
@Override
public int[] sort(int[] numbers)
{
//convert the array to a List
List<Integer> numberList = new ArrayList<Integer>();
//call the adapter
NumberSorter sorter = new NumberSorter();
numberList = sorter.sort(numberList);

//convert the list back to an array and return
return sortedNumbers;
}
}
</pre>

===Difference between Decorator Pattern and Adapter Pattern===
Adapters can be used for decorating but their primary aim is to for enabling classes of different types not able to communicate
because of incompatible interface to interact via a adapter interface.
Inheritance and composition is used to achieve this.Decorators on the other hand are not used to add different methods to all the instances instead they are used to add specific behavior to some specific instances. Though Adapters making use of composition may also be used here, but the intention is different here with what it's in case of a Adapter.
<ref>[http://geekexplains.blogspot.com/2008/09/structural-patterns-adapter-decorator.html]</ref>

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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>[http://c2.com/cgi/wiki?GangOfFour"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.
[[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.

Let's take a look at this in action with a sequence diagram.
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use tree structure and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern.
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==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 [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references />
==Additional Reading==
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]
*[http://www.slideshare.net/MarcusDenker/behavioral-reflection Behavioral reflection]
*[http://msdn.microsoft.com/en-us/library/67ef8sbd(v=vs.80).aspx C# Basics]
*[http://msdn.microsoft.com/en-us/library/ms173183(v=vs.80).aspx C# Reflection basics]
*[http://www.codeguru.com/csharp/csharp/cs_misc/reflection/article.php/c4257/An-Introduction-to-Reflection-in-C.htm Introduction to C# Reflection]
*[http://oreilly.com/catalog/progcsharp/chapter/ch18.html C# Attributes and Reflection]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-18T02:39:10Z

Knagar: /* Ruby */

==Introduction==
In this section we will be discussing about the decorator pattern and its related patterns such as adapter,proxy and composite.

==Decorator Pattern==
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.
We have an instance, and we put another instance inside of it. They both support the same (or similar) interfaces. The one on the outside is a "decorator." We can use the one on the outside. It either masks, changes, or pass-throughs the methods of the instance inside of it. <ref>[http://www.oodesign.com/decorator-pattern.html]</ref>
===Intent===
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality as provided by Gang of four. <ref>[http://c2.com/cgi/wiki?GangOfFour"Gang of four"]</ref>
===Problem===
The state of an object can be changed at compile time but no change is possible at run time if the language does not permit so.
===Solution===
Add a decorator module , class that acts as a extender for functions at run time such that the calls are delegated to the decorator
to extend the functionality of the objects at run time.
===Implementation===

====Ruby====
The example shows a Tea class with a method cost defining its cost as 4.
<ref>[http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html]</ref>
<pre>

If we want to calculate the cost of a cup of coffee. We have Coffee class, which implements a cost() method.

class Coffee
def cost
2
end
end

But what if we want the cost of a coffee with milk? We could have a new class:

class MilkCoffee
def cost
2.4
end
end

But now if we want cream. And sprinkles. Clearly, creating new classes is going to lead to a huge number of classes in our application. It just isn’t realistic to create classes for different combinations of coffee and extras. It could get worse – what if we have different types of coffee? We would then have to have combinations of extras with each different type of coffee.Hence we will use decorator pattern.

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

And thats all you need. You can include this into any class you want to act as a decorator. You can then use that decorator as if it was the object it is decorating; by default all messages sent to the decorator are forwarded on to the decorated object. You can then decorate the methods you need to extend:

class Milk
include Decorator

def cost
@decorated.cost + 0.4
end
end

So how does this solve our original problem? The real power of decorators lies in the fact that they can act like the objects they are decorating. By taking this one step further, you can wrap decorators with other decorators as long as they share the same interface. By creating decorators for our different “extras”, we can create coffees using a combination of decorators and get the total cost of the coffee.

class Whip
include Decorator

def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

</pre>

====Java====
In this java example <ref>[http://java-x.blogspot.com/2007/01/implementing-decorator-pattern-in-java.html]</ref>
basicInterface: Defines the interface for objects that can have responsibilities added to them dynamically.
Basic: Defines an object to which additional responsibilities can be attached.
Decorator: maintains a reference to a Basic object and defines an interface that conforms to Basic's interface.
ConcreteDecorator: adds responsibilities to the component.
<pre>

public interface basicInterface {
public void do();
}

public class Basic implements basicInterface{
public void do() {
System.out.println("Do basic stuff");
}
}

public interface Decorator extends basicInterface {
public void addedStuff();
}

public class ConcreteDecorator implements Decorator {

basicInterface basic;

public ConcreteDecorator(basicInterface basic) {
super();
this.basic = basic;
}

public void addedStuff() {
System.out.println("Decorator does other stuff too");

}

public void do() {
basic.do();
addedStuff();
}
}

public class Client {
public static void main(String[] args) {
basicInterface comp = new Basic();
Decorator decorator = new ConcreteDecorator(comp);
decorator.do();
}
}

</pre>

In this way we can add concrete decorator classes to provided the added functionality to the basic class.

==Adapter Pattern==
Adapter pattern acts as a bridge between objects. It adapts to the changing needs of the classes using interface. In real world we have adapters for power supplies, adapters for camera memory cards etc.If a class is expecting some type of object and we have an object offering the same features, but exposing a different interface we want to use both of them so instead of implementing them again and changing existing classes,we can create an adapter.
===Intent===
Match an existing object to a particular interface.
===Problem===
A system has the right data and behavior but the wrong interface. Typically used when you have to make something a
derivative of an abstract class you already have or are defining.
===Solution===
Convert original interface component into another one through an intermediate adapter.Solution: The adapter provides a “wrapper” with the desired
interface
===Implementation===

====Ruby====
The Adapter offers exactly the same interface as the adaptee, but it can override any method or add new ones.
<pre>
class Adaptee
def talk
puts "I'm Adaptee"
end
def whine
puts "Stop bullying me!"
end
end

class Adapter
def initialize
@adaptee=Adaptee.new
end
def talk
#override
puts "Let me introduce you to Adaptee!"
@adaptee.talk
puts "That was my adaptee"
end
def do_other_stuff
puts "I'm versatile"
end
def method_missing method
if
@adaptee.respond_to? method@adaptee.sendmethod
else
raise NotImplementedError,"This method is not "+\ "available on this interface"
end
end
end
if__FILE__==$0
adapter=Adapter.newadapter.talkadapter.whineadapter.do_other_stuff
end
</pre>

====Java====
The following example shows a simple implementation of the pattern. Consider that we have a third party library that provides sorting functionality through it's NumberSorter class. This is our Adaptee.This is our adaptee, a third party implementation of a number sorter that deals with Lists, not arrays.[http://java.dzone.com/articles/design-patterns-uncovered-0]
<pre>
public class NumberSorter
{
public List<Integer> sort(List<Integer> numbers)
{
//sort and return
return new ArrayList<Integer>();
}
}
</pre>

Our Client deals with primitive arrays rather than Lists. For the sake of this example, lets say we can't change the client to use Lists.
<pre>
int[] numbers = new int[]{34, 2, 4, 12, 1};
Sorter sorter = new SortListAdapter();
sorter.sort(numbers);
</pre>

We've provided a Sorter interface that expects the client input. This is our target.
//this is our Target interface
<pre>
public interface Sorter
{
public int[] sort(int[] numbers);
}
</pre>
Finally, the SortListAdapter implements our target interface and deals with our adaptee, NumberSorter
<pre>
public class SortListAdapter implements Sorter
{
@Override
public int[] sort(int[] numbers)
{
//convert the array to a List
List<Integer> numberList = new ArrayList<Integer>();
//call the adapter
NumberSorter sorter = new NumberSorter();
numberList = sorter.sort(numberList);

//convert the list back to an array and return
return sortedNumbers;
}
}
</pre>

===Difference between Decorator Pattern and Adapter Pattern===
Adapters can be used for decorating but their primary aim is to for enabling classes of different types not able to communicate
because of incompatible interface to interact via a adapter interface.
Inheritance and composition is used to achieve this.Decorators on the other hand are not used to add different methods to all the instances instead they are used to add specific behavior to some specific instances. Though Adapters making use of composition may also be used here, but the intention is different here with what it's in case of a Adapter.
<ref>[http://geekexplains.blogspot.com/2008/09/structural-patterns-adapter-decorator.html]</ref>

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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>[http://c2.com/cgi/wiki?GangOfFour"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.
[[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.

Let's take a look at this in action with a sequence diagram.
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use tree structure and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern.
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==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 [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references />
==Additional Reading==
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]
*[http://www.slideshare.net/MarcusDenker/behavioral-reflection Behavioral reflection]
*[http://msdn.microsoft.com/en-us/library/67ef8sbd(v=vs.80).aspx C# Basics]
*[http://msdn.microsoft.com/en-us/library/ms173183(v=vs.80).aspx C# Reflection basics]
*[http://www.codeguru.com/csharp/csharp/cs_misc/reflection/article.php/c4257/An-Introduction-to-Reflection-in-C.htm Introduction to C# Reflection]
*[http://oreilly.com/catalog/progcsharp/chapter/ch18.html C# Attributes and Reflection]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-18T02:38:26Z

Knagar: /* Ruby */

==Introduction==
In this section we will be discussing about the decorator pattern and its related patterns such as adapter,proxy and composite.

==Decorator Pattern==
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.
We have an instance, and we put another instance inside of it. They both support the same (or similar) interfaces. The one on the outside is a "decorator." We can use the one on the outside. It either masks, changes, or pass-throughs the methods of the instance inside of it. <ref>[http://www.oodesign.com/decorator-pattern.html]</ref>
===Intent===
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality as provided by Gang of four. <ref>[http://c2.com/cgi/wiki?GangOfFour"Gang of four"]</ref>
===Problem===
The state of an object can be changed at compile time but no change is possible at run time if the language does not permit so.
===Solution===
Add a decorator module , class that acts as a extender for functions at run time such that the calls are delegated to the decorator
to extend the functionality of the objects at run time.
===Implementation===

====Ruby====
The example shows a Tea class with a method cost defining its cost as 4.
<ref>[http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html]</ref>
<pre>

If we want to calculate the cost of a cup of coffee. We have Coffee class, which implements a cost() method.

class Coffee
def cost
2
end
end

But what if we want the cost of a coffee with milk? We could have a new class:

class MilkCoffee
def cost
2.4
end
end

But now if we want cream. And sprinkles. Clearly, creating new classes is going to lead to a huge number of classes in our application. It just isn’t realistic to create classes for different combinations of coffee and extras. It could get worse – what if we have different types of coffee? We would then have to have combinations of extras with each different type of coffee.Hence we will use decorator pattern.

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

And thats all you need. You can include this into any class you want to act as a decorator. You can then use that decorator as if it was the object it is decorating; by default all messages sent to the decorator are forwarded on to the decorated object. You can then decorate the methods you need to extend:

class Milk
include Decorator

def cost
@decorated.cost + 0.4
end
end

So how does this solve our original problem? The real power of decorators lies in the fact that they can act like the objects they are decorating. By taking this one step further, you can wrap decorators with other decorators as long as they share the same interface. By creating decorators for our different “extras”, we can create coffees using a combination of decorators and get the total cost of the coffee.

class Whip
include Decorator

def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

</pre>

====Java====
In this java example <ref>[http://java-x.blogspot.com/2007/01/implementing-decorator-pattern-in-java.html]</ref>
basicInterface: Defines the interface for objects that can have responsibilities added to them dynamically.
Basic: Defines an object to which additional responsibilities can be attached.
Decorator: maintains a reference to a Basic object and defines an interface that conforms to Basic's interface.
ConcreteDecorator: adds responsibilities to the component.
<pre>

public interface basicInterface {
public void do();
}

public class Basic implements basicInterface{
public void do() {
System.out.println("Do basic stuff");
}
}

public interface Decorator extends basicInterface {
public void addedStuff();
}

public class ConcreteDecorator implements Decorator {

basicInterface basic;

public ConcreteDecorator(basicInterface basic) {
super();
this.basic = basic;
}

public void addedStuff() {
System.out.println("Decorator does other stuff too");

}

public void do() {
basic.do();
addedStuff();
}
}

public class Client {
public static void main(String[] args) {
basicInterface comp = new Basic();
Decorator decorator = new ConcreteDecorator(comp);
decorator.do();
}
}

</pre>

In this way we can add concrete decorator classes to provided the added functionality to the basic class.

==Adapter Pattern==
Adapter pattern acts as a bridge between objects. It adapts to the changing needs of the classes using interface. In real world we have adapters for power supplies, adapters for camera memory cards etc.If a class is expecting some type of object and we have an object offering the same features, but exposing a different interface we want to use both of them so instead of implementing them again and changing existing classes,we can create an adapter.
===Intent===
Match an existing object to a particular interface.
===Problem===
A system has the right data and behavior but the wrong interface. Typically used when you have to make something a
derivative of an abstract class you already have or are defining.
===Solution===
Convert original interface component into another one through an intermediate adapter.Solution: The adapter provides a “wrapper” with the desired
interface
===Implementation===

====Ruby====
The Adapter offers exactly the same interface as the adaptee, but it can override any method or add new ones.
<pre>
class Adaptee
def talk
puts "I'm Adaptee"
end
def whine
puts "Stop bullying me!"
end
end

class Adapter
def initialize
@adaptee=Adaptee.new
end
def talk
#override
puts "Let me introduce you to Adaptee!"
@adaptee.talk
puts "That was my adaptee"
end
def do_other_stuff
puts "I'm versatile"
end
def method_missing method
if
@adaptee.respond_to? method@adaptee.sendmethod
else
raise NotImplementedError,"This method is not "+\ "available on this interface"
end
end
end
if__FILE__==$0
adapter=Adapter.newadapter.talkadapter.whineadapter.do_other_stuff
end
</pre>

Output------
GoF patterns in Ruby8/33
Let me introduce you to Adaptee! I'm Adaptee That was my adaptee Stop bullying me!I'm versatile
GoF patterns in Ruby9/33

====Java====
The following example shows a simple implementation of the pattern. Consider that we have a third party library that provides sorting functionality through it's NumberSorter class. This is our Adaptee.This is our adaptee, a third party implementation of a number sorter that deals with Lists, not arrays.[http://java.dzone.com/articles/design-patterns-uncovered-0]
<pre>
public class NumberSorter
{
public List<Integer> sort(List<Integer> numbers)
{
//sort and return
return new ArrayList<Integer>();
}
}
</pre>

Our Client deals with primitive arrays rather than Lists. For the sake of this example, lets say we can't change the client to use Lists.
<pre>
int[] numbers = new int[]{34, 2, 4, 12, 1};
Sorter sorter = new SortListAdapter();
sorter.sort(numbers);
</pre>

We've provided a Sorter interface that expects the client input. This is our target.
//this is our Target interface
<pre>
public interface Sorter
{
public int[] sort(int[] numbers);
}
</pre>
Finally, the SortListAdapter implements our target interface and deals with our adaptee, NumberSorter
<pre>
public class SortListAdapter implements Sorter
{
@Override
public int[] sort(int[] numbers)
{
//convert the array to a List
List<Integer> numberList = new ArrayList<Integer>();
//call the adapter
NumberSorter sorter = new NumberSorter();
numberList = sorter.sort(numberList);

//convert the list back to an array and return
return sortedNumbers;
}
}
</pre>

===Difference between Decorator Pattern and Adapter Pattern===
Adapters can be used for decorating but their primary aim is to for enabling classes of different types not able to communicate
because of incompatible interface to interact via a adapter interface.
Inheritance and composition is used to achieve this.Decorators on the other hand are not used to add different methods to all the instances instead they are used to add specific behavior to some specific instances. Though Adapters making use of composition may also be used here, but the intention is different here with what it's in case of a Adapter.
<ref>[http://geekexplains.blogspot.com/2008/09/structural-patterns-adapter-decorator.html]</ref>

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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>[http://c2.com/cgi/wiki?GangOfFour"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.
[[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.

Let's take a look at this in action with a sequence diagram.
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use tree structure and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern.
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==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 [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references />
==Additional Reading==
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]
*[http://www.slideshare.net/MarcusDenker/behavioral-reflection Behavioral reflection]
*[http://msdn.microsoft.com/en-us/library/67ef8sbd(v=vs.80).aspx C# Basics]
*[http://msdn.microsoft.com/en-us/library/ms173183(v=vs.80).aspx C# Reflection basics]
*[http://www.codeguru.com/csharp/csharp/cs_misc/reflection/article.php/c4257/An-Introduction-to-Reflection-in-C.htm Introduction to C# Reflection]
*[http://oreilly.com/catalog/progcsharp/chapter/ch18.html C# Attributes and Reflection]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-18T02:36:50Z

Knagar: /* Ruby */

==Introduction==
In this section we will be discussing about the decorator pattern and its related patterns such as adapter,proxy and composite.

==Decorator Pattern==
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.
We have an instance, and we put another instance inside of it. They both support the same (or similar) interfaces. The one on the outside is a "decorator." We can use the one on the outside. It either masks, changes, or pass-throughs the methods of the instance inside of it. <ref>[http://www.oodesign.com/decorator-pattern.html]</ref>
===Intent===
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality as provided by Gang of four. <ref>[http://c2.com/cgi/wiki?GangOfFour"Gang of four"]</ref>
===Problem===
The state of an object can be changed at compile time but no change is possible at run time if the language does not permit so.
===Solution===
Add a decorator module , class that acts as a extender for functions at run time such that the calls are delegated to the decorator
to extend the functionality of the objects at run time.
===Implementation===

====Ruby====
The example shows a Tea class with a method cost defining its cost as 4.
<ref>[http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html]</ref>
<pre>

If we want to calculate the cost of a cup of coffee. We have Coffee class, which implements a cost() method.

class Coffee
def cost
2
end
end

But what if we want the cost of a coffee with milk? We could have a new class:

class MilkCoffee
def cost
2.4
end
end

But now if we want cream. And sprinkles. Clearly, creating new classes is going to lead to a huge number of classes in our application. It just isn’t realistic to create classes for different combinations of coffee and extras. It could get worse – what if we have different types of coffee? We would then have to have combinations of extras with each different type of coffee.Hence we will use decorator pattern.

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

And thats all you need. You can include this into any class you want to act as a decorator. You can then use that decorator as if it was the object it is decorating; by default all messages sent to the decorator are forwarded on to the decorated object. You can then decorate the methods you need to extend:

class Milk
include Decorator

def cost
@decorated.cost + 0.4
end
end

So how does this solve our original problem? The real power of decorators lies in the fact that they can act like the objects they are decorating. By taking this one step further, you can wrap decorators with other decorators as long as they share the same interface. By creating decorators for our different “extras”, we can create coffees using a combination of decorators and get the total cost of the coffee.

class Whip
include Decorator

def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

</pre>

====Java====
In this java example <ref>[http://java-x.blogspot.com/2007/01/implementing-decorator-pattern-in-java.html]</ref>
basicInterface: Defines the interface for objects that can have responsibilities added to them dynamically.
Basic: Defines an object to which additional responsibilities can be attached.
Decorator: maintains a reference to a Basic object and defines an interface that conforms to Basic's interface.
ConcreteDecorator: adds responsibilities to the component.
<pre>

public interface basicInterface {
public void do();
}

public class Basic implements basicInterface{
public void do() {
System.out.println("Do basic stuff");
}
}

public interface Decorator extends basicInterface {
public void addedStuff();
}

public class ConcreteDecorator implements Decorator {

basicInterface basic;

public ConcreteDecorator(basicInterface basic) {
super();
this.basic = basic;
}

public void addedStuff() {
System.out.println("Decorator does other stuff too");

}

public void do() {
basic.do();
addedStuff();
}
}

public class Client {
public static void main(String[] args) {
basicInterface comp = new Basic();
Decorator decorator = new ConcreteDecorator(comp);
decorator.do();
}
}

</pre>

In this way we can add concrete decorator classes to provided the added functionality to the basic class.

==Adapter Pattern==
Adapter pattern acts as a bridge between objects. It adapts to the changing needs of the classes using interface. In real world we have adapters for power supplies, adapters for camera memory cards etc.If a class is expecting some type of object and we have an object offering the same features, but exposing a different interface we want to use both of them so instead of implementing them again and changing existing classes,we can create an adapter.
===Intent===
Match an existing object to a particular interface.
===Problem===
A system has the right data and behavior but the wrong interface. Typically used when you have to make something a
derivative of an abstract class you already have or are defining.
===Solution===
Convert original interface component into another one through an intermediate adapter.Solution: The adapter provides a “wrapper” with the desired
interface
===Implementation===

====Ruby====
The Adapter offers exactly the same interface as the adaptee, but it can override any method or add new ones.
<pre>
class Adaptee
def talk
puts "I'm Adaptee"
end
def whine
puts "Stop bullying me!"
end
end

class Adapter
def initialize
@adaptee=Adaptee.new
end
def talk
#override
puts "Let me introduce you to Adaptee!"@adaptee.talk
puts "That was my adaptee"
end
def do_other_stuff
puts "I'm versatile"
end
def method_missing method
if
@adaptee.respond_to? method@adaptee.sendmethod
else
raise NotImplementedError,"This method is not "+\ "available on this interface"
end
end
end
if__FILE__==$0
adapter=Adapter.newadapter.talkadapter.whineadapter.do_other_stuff
end
</pre>

Output------
GoF patterns in Ruby8/33
Let me introduce you to Adaptee!I'm AdapteeThat was my adapteeStop bullying me!I'm versatile
GoF patterns in Ruby9/33

====Java====
The following example shows a simple implementation of the pattern. Consider that we have a third party library that provides sorting functionality through it's NumberSorter class. This is our Adaptee.This is our adaptee, a third party implementation of a number sorter that deals with Lists, not arrays.[http://java.dzone.com/articles/design-patterns-uncovered-0]
<pre>
public class NumberSorter
{
public List<Integer> sort(List<Integer> numbers)
{
//sort and return
return new ArrayList<Integer>();
}
}
</pre>

Our Client deals with primitive arrays rather than Lists. For the sake of this example, lets say we can't change the client to use Lists.
<pre>
int[] numbers = new int[]{34, 2, 4, 12, 1};
Sorter sorter = new SortListAdapter();
sorter.sort(numbers);
</pre>

We've provided a Sorter interface that expects the client input. This is our target.
//this is our Target interface
<pre>
public interface Sorter
{
public int[] sort(int[] numbers);
}
</pre>
Finally, the SortListAdapter implements our target interface and deals with our adaptee, NumberSorter
<pre>
public class SortListAdapter implements Sorter
{
@Override
public int[] sort(int[] numbers)
{
//convert the array to a List
List<Integer> numberList = new ArrayList<Integer>();
//call the adapter
NumberSorter sorter = new NumberSorter();
numberList = sorter.sort(numberList);

//convert the list back to an array and return
return sortedNumbers;
}
}
</pre>

===Difference between Decorator Pattern and Adapter Pattern===
Adapters can be used for decorating but their primary aim is to for enabling classes of different types not able to communicate
because of incompatible interface to interact via a adapter interface.
Inheritance and composition is used to achieve this.Decorators on the other hand are not used to add different methods to all the instances instead they are used to add specific behavior to some specific instances. Though Adapters making use of composition may also be used here, but the intention is different here with what it's in case of a Adapter.
<ref>[http://geekexplains.blogspot.com/2008/09/structural-patterns-adapter-decorator.html]</ref>

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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>[http://c2.com/cgi/wiki?GangOfFour"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.
[[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.

Let's take a look at this in action with a sequence diagram.
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use tree structure and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern.
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==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 [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references />
==Additional Reading==
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]
*[http://www.slideshare.net/MarcusDenker/behavioral-reflection Behavioral reflection]
*[http://msdn.microsoft.com/en-us/library/67ef8sbd(v=vs.80).aspx C# Basics]
*[http://msdn.microsoft.com/en-us/library/ms173183(v=vs.80).aspx C# Reflection basics]
*[http://www.codeguru.com/csharp/csharp/cs_misc/reflection/article.php/c4257/An-Introduction-to-Reflection-in-C.htm Introduction to C# Reflection]
*[http://oreilly.com/catalog/progcsharp/chapter/ch18.html C# Attributes and Reflection]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-18T02:35:07Z

Knagar: /* Ruby */

==Introduction==
In this section we will be discussing about the decorator pattern and its related patterns such as adapter,proxy and composite.

==Decorator Pattern==
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.
We have an instance, and we put another instance inside of it. They both support the same (or similar) interfaces. The one on the outside is a "decorator." We can use the one on the outside. It either masks, changes, or pass-throughs the methods of the instance inside of it. <ref>[http://www.oodesign.com/decorator-pattern.html]</ref>
===Intent===
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality as provided by Gang of four. <ref>[http://c2.com/cgi/wiki?GangOfFour"Gang of four"]</ref>
===Problem===
The state of an object can be changed at compile time but no change is possible at run time if the language does not permit so.
===Solution===
Add a decorator module , class that acts as a extender for functions at run time such that the calls are delegated to the decorator
to extend the functionality of the objects at run time.
===Implementation===

====Ruby====
The example shows a Tea class with a method cost defining its cost as 4.
<ref>[http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html]</ref>
<pre>

If we want to calculate the cost of a cup of coffee. We have Coffee class, which implements a cost() method.

class Coffee
def cost
2
end
end

But what if we want the cost of a coffee with milk? We could have a new class:

class MilkCoffee
def cost
2.4
end
end

But now if we want cream. And sprinkles. Clearly, creating new classes is going to lead to a huge number of classes in our application. It just isn’t realistic to create classes for different combinations of coffee and extras. It could get worse – what if we have different types of coffee? We would then have to have combinations of extras with each different type of coffee.Hence we will use decorator pattern.

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

And thats all you need. You can include this into any class you want to act as a decorator. You can then use that decorator as if it was the object it is decorating; by default all messages sent to the decorator are forwarded on to the decorated object. You can then decorate the methods you need to extend:

class Milk
include Decorator

def cost
@decorated.cost + 0.4
end
end

So how does this solve our original problem? The real power of decorators lies in the fact that they can act like the objects they are decorating. By taking this one step further, you can wrap decorators with other decorators as long as they share the same interface. By creating decorators for our different “extras”, we can create coffees using a combination of decorators and get the total cost of the coffee.

class Whip
include Decorator

def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

</pre>

====Java====
In this java example <ref>[http://java-x.blogspot.com/2007/01/implementing-decorator-pattern-in-java.html]</ref>
basicInterface: Defines the interface for objects that can have responsibilities added to them dynamically.
Basic: Defines an object to which additional responsibilities can be attached.
Decorator: maintains a reference to a Basic object and defines an interface that conforms to Basic's interface.
ConcreteDecorator: adds responsibilities to the component.
<pre>

public interface basicInterface {
public void do();
}

public class Basic implements basicInterface{
public void do() {
System.out.println("Do basic stuff");
}
}

public interface Decorator extends basicInterface {
public void addedStuff();
}

public class ConcreteDecorator implements Decorator {

basicInterface basic;

public ConcreteDecorator(basicInterface basic) {
super();
this.basic = basic;
}

public void addedStuff() {
System.out.println("Decorator does other stuff too");

}

public void do() {
basic.do();
addedStuff();
}
}

public class Client {
public static void main(String[] args) {
basicInterface comp = new Basic();
Decorator decorator = new ConcreteDecorator(comp);
decorator.do();
}
}

</pre>

In this way we can add concrete decorator classes to provided the added functionality to the basic class.

==Adapter Pattern==
Adapter pattern acts as a bridge between objects. It adapts to the changing needs of the classes using interface. In real world we have adapters for power supplies, adapters for camera memory cards etc.If a class is expecting some type of object and we have an object offering the same features, but exposing a different interface we want to use both of them so instead of implementing them again and changing existing classes,we can create an adapter.
===Intent===
Match an existing object to a particular interface.
===Problem===
A system has the right data and behavior but the wrong interface. Typically used when you have to make something a
derivative of an abstract class you already have or are defining.
===Solution===
Convert original interface component into another one through an intermediate adapter.Solution: The adapter provides a “wrapper” with the desired
interface
===Implementation===

====Ruby====
## The GoF Adapter pattern# written by Matthieu Tanguay-Carel## The Adapter offers exactly the same interface as the adaptee, but it can# override any method or add new ones.##

<pre>
class Adapteedeftalk
puts "I'm Adaptee"
end
def
whine
puts "Stop bullying me!"
end
end

classAdapterdefinitialize
@adaptee=Adaptee.new
end
def talk
#override
puts "Let me introduce you to Adaptee!"@adaptee.talk
puts "That was my adaptee"
end
def do_other_stuff
puts "I'm versatile"
end
def method_missing method
if
@adaptee.respond_to? method@adaptee.sendmethod
else
raise NotImplementedError,"This method is not "+\ "available on this interface"
end
end
end
if__FILE__==$0
adapter=Adapter.newadapter.talkadapter.whineadapter.do_other_stuff
end
</pre>

Output------
GoF patterns in Ruby8/33
Let me introduce you to Adaptee!I'm AdapteeThat was my adapteeStop bullying me!I'm versatile
GoF patterns in Ruby9/33

====Java====
The following example shows a simple implementation of the pattern. Consider that we have a third party library that provides sorting functionality through it's NumberSorter class. This is our Adaptee.This is our adaptee, a third party implementation of a number sorter that deals with Lists, not arrays.[http://java.dzone.com/articles/design-patterns-uncovered-0]
<pre>
public class NumberSorter
{
public List<Integer> sort(List<Integer> numbers)
{
//sort and return
return new ArrayList<Integer>();
}
}
</pre>

Our Client deals with primitive arrays rather than Lists. For the sake of this example, lets say we can't change the client to use Lists.
<pre>
int[] numbers = new int[]{34, 2, 4, 12, 1};
Sorter sorter = new SortListAdapter();
sorter.sort(numbers);
</pre>

We've provided a Sorter interface that expects the client input. This is our target.
//this is our Target interface
<pre>
public interface Sorter
{
public int[] sort(int[] numbers);
}
</pre>
Finally, the SortListAdapter implements our target interface and deals with our adaptee, NumberSorter
<pre>
public class SortListAdapter implements Sorter
{
@Override
public int[] sort(int[] numbers)
{
//convert the array to a List
List<Integer> numberList = new ArrayList<Integer>();
//call the adapter
NumberSorter sorter = new NumberSorter();
numberList = sorter.sort(numberList);

//convert the list back to an array and return
return sortedNumbers;
}
}
</pre>

===Difference between Decorator Pattern and Adapter Pattern===
Adapters can be used for decorating but their primary aim is to for enabling classes of different types not able to communicate
because of incompatible interface to interact via a adapter interface.
Inheritance and composition is used to achieve this.Decorators on the other hand are not used to add different methods to all the instances instead they are used to add specific behavior to some specific instances. Though Adapters making use of composition may also be used here, but the intention is different here with what it's in case of a Adapter.
<ref>[http://geekexplains.blogspot.com/2008/09/structural-patterns-adapter-decorator.html]</ref>

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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>[http://c2.com/cgi/wiki?GangOfFour"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.
[[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.

Let's take a look at this in action with a sequence diagram.
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use tree structure and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern.
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==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 [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references />
==Additional Reading==
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]
*[http://www.slideshare.net/MarcusDenker/behavioral-reflection Behavioral reflection]
*[http://msdn.microsoft.com/en-us/library/67ef8sbd(v=vs.80).aspx C# Basics]
*[http://msdn.microsoft.com/en-us/library/ms173183(v=vs.80).aspx C# Reflection basics]
*[http://www.codeguru.com/csharp/csharp/cs_misc/reflection/article.php/c4257/An-Introduction-to-Reflection-in-C.htm Introduction to C# Reflection]
*[http://oreilly.com/catalog/progcsharp/chapter/ch18.html C# Attributes and Reflection]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-18T02:26:06Z

Knagar: /* Difference between Decorator Pattern and Adapter Pattern */

==Introduction==
In this section we will be discussing about the decorator pattern and its related patterns such as adapter,proxy and composite.

==Decorator Pattern==
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.
We have an instance, and we put another instance inside of it. They both support the same (or similar) interfaces. The one on the outside is a "decorator." We can use the one on the outside. It either masks, changes, or pass-throughs the methods of the instance inside of it. <ref>[http://www.oodesign.com/decorator-pattern.html]</ref>
===Intent===
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality as provided by Gang of four. <ref>[http://c2.com/cgi/wiki?GangOfFour"Gang of four"]</ref>
===Problem===
The state of an object can be changed at compile time but no change is possible at run time if the language does not permit so.
===Solution===
Add a decorator module , class that acts as a extender for functions at run time such that the calls are delegated to the decorator
to extend the functionality of the objects at run time.
===Implementation===

====Ruby====
The example shows a Tea class with a method cost defining its cost as 4.
<ref>[http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html]</ref>
<pre>

If we want to calculate the cost of a cup of coffee. We have Coffee class, which implements a cost() method.

class Coffee
def cost
2
end
end

But what if we want the cost of a coffee with milk? We could have a new class:

class MilkCoffee
def cost
2.4
end
end

But now if we want cream. And sprinkles. Clearly, creating new classes is going to lead to a huge number of classes in our application. It just isn’t realistic to create classes for different combinations of coffee and extras. It could get worse – what if we have different types of coffee? We would then have to have combinations of extras with each different type of coffee.Hence we will use decorator pattern.

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

And thats all you need. You can include this into any class you want to act as a decorator. You can then use that decorator as if it was the object it is decorating; by default all messages sent to the decorator are forwarded on to the decorated object. You can then decorate the methods you need to extend:

class Milk
include Decorator

def cost
@decorated.cost + 0.4
end
end

So how does this solve our original problem? The real power of decorators lies in the fact that they can act like the objects they are decorating. By taking this one step further, you can wrap decorators with other decorators as long as they share the same interface. By creating decorators for our different “extras”, we can create coffees using a combination of decorators and get the total cost of the coffee.

class Whip
include Decorator

def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

</pre>

====Java====
In this java example <ref>[http://java-x.blogspot.com/2007/01/implementing-decorator-pattern-in-java.html]</ref>
basicInterface: Defines the interface for objects that can have responsibilities added to them dynamically.
Basic: Defines an object to which additional responsibilities can be attached.
Decorator: maintains a reference to a Basic object and defines an interface that conforms to Basic's interface.
ConcreteDecorator: adds responsibilities to the component.
<pre>

public interface basicInterface {
public void do();
}

public class Basic implements basicInterface{
public void do() {
System.out.println("Do basic stuff");
}
}

public interface Decorator extends basicInterface {
public void addedStuff();
}

public class ConcreteDecorator implements Decorator {

basicInterface basic;

public ConcreteDecorator(basicInterface basic) {
super();
this.basic = basic;
}

public void addedStuff() {
System.out.println("Decorator does other stuff too");

}

public void do() {
basic.do();
addedStuff();
}
}

public class Client {
public static void main(String[] args) {
basicInterface comp = new Basic();
Decorator decorator = new ConcreteDecorator(comp);
decorator.do();
}
}

</pre>

In this way we can add concrete decorator classes to provided the added functionality to the basic class.

==Adapter Pattern==
Adapter pattern acts as a bridge between objects. It adapts to the changing needs of the classes using interface. In real world we have adapters for power supplies, adapters for camera memory cards etc.If a class is expecting some type of object and we have an object offering the same features, but exposing a different interface we want to use both of them so instead of implementing them again and changing existing classes,we can create an adapter.
===Intent===
Match an existing object to a particular interface.
===Problem===
A system has the right data and behavior but the wrong interface. Typically used when you have to make something a
derivative of an abstract class you already have or are defining.
===Solution===
Convert original interface component into another one through an intermediate adapter.Solution: The adapter provides a “wrapper” with the desired
interface
===Implementation===

====Ruby====
brief explanation and Sample Code:
<pre>
type the code here
</pre>

====Java====
The following example shows a simple implementation of the pattern. Consider that we have a third party library that provides sorting functionality through it's NumberSorter class. This is our Adaptee.This is our adaptee, a third party implementation of a number sorter that deals with Lists, not arrays.[http://java.dzone.com/articles/design-patterns-uncovered-0]
<pre>
public class NumberSorter
{
public List<Integer> sort(List<Integer> numbers)
{
//sort and return
return new ArrayList<Integer>();
}
}
</pre>

Our Client deals with primitive arrays rather than Lists. For the sake of this example, lets say we can't change the client to use Lists.
<pre>
int[] numbers = new int[]{34, 2, 4, 12, 1};
Sorter sorter = new SortListAdapter();
sorter.sort(numbers);
</pre>

We've provided a Sorter interface that expects the client input. This is our target.
//this is our Target interface
<pre>
public interface Sorter
{
public int[] sort(int[] numbers);
}
</pre>
Finally, the SortListAdapter implements our target interface and deals with our adaptee, NumberSorter
<pre>
public class SortListAdapter implements Sorter
{
@Override
public int[] sort(int[] numbers)
{
//convert the array to a List
List<Integer> numberList = new ArrayList<Integer>();
//call the adapter
NumberSorter sorter = new NumberSorter();
numberList = sorter.sort(numberList);

//convert the list back to an array and return
return sortedNumbers;
}
}
</pre>

===Difference between Decorator Pattern and Adapter Pattern===
Adapters can be used for decorating but their primary aim is to for enabling classes of different types not able to communicate
because of incompatible interface to interact via a adapter interface.
Inheritance and composition is used to achieve this.Decorators on the other hand are not used to add different methods to all the instances instead they are used to add specific behavior to some specific instances. Though Adapters making use of composition may also be used here, but the intention is different here with what it's in case of a Adapter.
<ref>[http://geekexplains.blogspot.com/2008/09/structural-patterns-adapter-decorator.html]</ref>

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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>[http://c2.com/cgi/wiki?GangOfFour"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.
[[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.

Let's take a look at this in action with a sequence diagram.
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use tree structure and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern.
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==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 [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references />
==Additional Reading==
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]
*[http://www.slideshare.net/MarcusDenker/behavioral-reflection Behavioral reflection]
*[http://msdn.microsoft.com/en-us/library/67ef8sbd(v=vs.80).aspx C# Basics]
*[http://msdn.microsoft.com/en-us/library/ms173183(v=vs.80).aspx C# Reflection basics]
*[http://www.codeguru.com/csharp/csharp/cs_misc/reflection/article.php/c4257/An-Introduction-to-Reflection-in-C.htm Introduction to C# Reflection]
*[http://oreilly.com/catalog/progcsharp/chapter/ch18.html C# Attributes and Reflection]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-18T02:25:24Z

Knagar: /* Difference between Decorator Pattern and Adapter Pattern */

==Introduction==
In this section we will be discussing about the decorator pattern and its related patterns such as adapter,proxy and composite.

==Decorator Pattern==
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.
We have an instance, and we put another instance inside of it. They both support the same (or similar) interfaces. The one on the outside is a "decorator." We can use the one on the outside. It either masks, changes, or pass-throughs the methods of the instance inside of it. <ref>[http://www.oodesign.com/decorator-pattern.html]</ref>
===Intent===
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality as provided by Gang of four. <ref>[http://c2.com/cgi/wiki?GangOfFour"Gang of four"]</ref>
===Problem===
The state of an object can be changed at compile time but no change is possible at run time if the language does not permit so.
===Solution===
Add a decorator module , class that acts as a extender for functions at run time such that the calls are delegated to the decorator
to extend the functionality of the objects at run time.
===Implementation===

====Ruby====
The example shows a Tea class with a method cost defining its cost as 4.
<ref>[http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html]</ref>
<pre>

If we want to calculate the cost of a cup of coffee. We have Coffee class, which implements a cost() method.

class Coffee
def cost
2
end
end

But what if we want the cost of a coffee with milk? We could have a new class:

class MilkCoffee
def cost
2.4
end
end

But now if we want cream. And sprinkles. Clearly, creating new classes is going to lead to a huge number of classes in our application. It just isn’t realistic to create classes for different combinations of coffee and extras. It could get worse – what if we have different types of coffee? We would then have to have combinations of extras with each different type of coffee.Hence we will use decorator pattern.

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

And thats all you need. You can include this into any class you want to act as a decorator. You can then use that decorator as if it was the object it is decorating; by default all messages sent to the decorator are forwarded on to the decorated object. You can then decorate the methods you need to extend:

class Milk
include Decorator

def cost
@decorated.cost + 0.4
end
end

So how does this solve our original problem? The real power of decorators lies in the fact that they can act like the objects they are decorating. By taking this one step further, you can wrap decorators with other decorators as long as they share the same interface. By creating decorators for our different “extras”, we can create coffees using a combination of decorators and get the total cost of the coffee.

class Whip
include Decorator

def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

</pre>

====Java====
In this java example <ref>[http://java-x.blogspot.com/2007/01/implementing-decorator-pattern-in-java.html]</ref>
basicInterface: Defines the interface for objects that can have responsibilities added to them dynamically.
Basic: Defines an object to which additional responsibilities can be attached.
Decorator: maintains a reference to a Basic object and defines an interface that conforms to Basic's interface.
ConcreteDecorator: adds responsibilities to the component.
<pre>

public interface basicInterface {
public void do();
}

public class Basic implements basicInterface{
public void do() {
System.out.println("Do basic stuff");
}
}

public interface Decorator extends basicInterface {
public void addedStuff();
}

public class ConcreteDecorator implements Decorator {

basicInterface basic;

public ConcreteDecorator(basicInterface basic) {
super();
this.basic = basic;
}

public void addedStuff() {
System.out.println("Decorator does other stuff too");

}

public void do() {
basic.do();
addedStuff();
}
}

public class Client {
public static void main(String[] args) {
basicInterface comp = new Basic();
Decorator decorator = new ConcreteDecorator(comp);
decorator.do();
}
}

</pre>

In this way we can add concrete decorator classes to provided the added functionality to the basic class.

==Adapter Pattern==
Adapter pattern acts as a bridge between objects. It adapts to the changing needs of the classes using interface. In real world we have adapters for power supplies, adapters for camera memory cards etc.If a class is expecting some type of object and we have an object offering the same features, but exposing a different interface we want to use both of them so instead of implementing them again and changing existing classes,we can create an adapter.
===Intent===
Match an existing object to a particular interface.
===Problem===
A system has the right data and behavior but the wrong interface. Typically used when you have to make something a
derivative of an abstract class you already have or are defining.
===Solution===
Convert original interface component into another one through an intermediate adapter.Solution: The adapter provides a “wrapper” with the desired
interface
===Implementation===

====Ruby====
brief explanation and Sample Code:
<pre>
type the code here
</pre>

====Java====
The following example shows a simple implementation of the pattern. Consider that we have a third party library that provides sorting functionality through it's NumberSorter class. This is our Adaptee.This is our adaptee, a third party implementation of a number sorter that deals with Lists, not arrays.[http://java.dzone.com/articles/design-patterns-uncovered-0]
<pre>
public class NumberSorter
{
public List<Integer> sort(List<Integer> numbers)
{
//sort and return
return new ArrayList<Integer>();
}
}
</pre>

Our Client deals with primitive arrays rather than Lists. For the sake of this example, lets say we can't change the client to use Lists.
<pre>
int[] numbers = new int[]{34, 2, 4, 12, 1};
Sorter sorter = new SortListAdapter();
sorter.sort(numbers);
</pre>

We've provided a Sorter interface that expects the client input. This is our target.
//this is our Target interface
<pre>
public interface Sorter
{
public int[] sort(int[] numbers);
}
</pre>
Finally, the SortListAdapter implements our target interface and deals with our adaptee, NumberSorter
<pre>
public class SortListAdapter implements Sorter
{
@Override
public int[] sort(int[] numbers)
{
//convert the array to a List
List<Integer> numberList = new ArrayList<Integer>();
//call the adapter
NumberSorter sorter = new NumberSorter();
numberList = sorter.sort(numberList);

//convert the list back to an array and return
return sortedNumbers;
}
}
</pre>

===Difference between Decorator Pattern and Adapter Pattern===
Adapters can be used for decorating but their primary aim is to for enabling classes of different types not able to communicate
because of incompatible interface to interact via a adapter interface.
Inheritance and composition is used to achieve this.Decorators on the other hand are not used to add different methods to all the instances instead they are used to add specific behavior to some specific instances. Though Adapters making use of composition may also be used here, but the intention is different here with what it's in case of a Adapter.

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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>[http://c2.com/cgi/wiki?GangOfFour"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.
[[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.

Let's take a look at this in action with a sequence diagram.
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use tree structure and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern.
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==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 [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references />
==Additional Reading==
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]
*[http://www.slideshare.net/MarcusDenker/behavioral-reflection Behavioral reflection]
*[http://msdn.microsoft.com/en-us/library/67ef8sbd(v=vs.80).aspx C# Basics]
*[http://msdn.microsoft.com/en-us/library/ms173183(v=vs.80).aspx C# Reflection basics]
*[http://www.codeguru.com/csharp/csharp/cs_misc/reflection/article.php/c4257/An-Introduction-to-Reflection-in-C.htm Introduction to C# Reflection]
*[http://oreilly.com/catalog/progcsharp/chapter/ch18.html C# Attributes and Reflection]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-18T02:16:35Z

Knagar: /* Java */

==Introduction==
In this section we will be discussing about the decorator pattern and its related patterns such as adapter,proxy and composite.

==Decorator Pattern==
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.
We have an instance, and we put another instance inside of it. They both support the same (or similar) interfaces. The one on the outside is a "decorator." We can use the one on the outside. It either masks, changes, or pass-throughs the methods of the instance inside of it. <ref>[http://www.oodesign.com/decorator-pattern.html]</ref>
===Intent===
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality as provided by Gang of four. <ref>[http://c2.com/cgi/wiki?GangOfFour"Gang of four"]</ref>
===Problem===
The state of an object can be changed at compile time but no change is possible at run time if the language does not permit so.
===Solution===
Add a decorator module , class that acts as a extender for functions at run time such that the calls are delegated to the decorator
to extend the functionality of the objects at run time.
===Implementation===

====Ruby====
The example shows a Tea class with a method cost defining its cost as 4.
<ref>[http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html]</ref>
<pre>

If we want to calculate the cost of a cup of coffee. We have Coffee class, which implements a cost() method.

class Coffee
def cost
2
end
end

But what if we want the cost of a coffee with milk? We could have a new class:

class MilkCoffee
def cost
2.4
end
end

But now if we want cream. And sprinkles. Clearly, creating new classes is going to lead to a huge number of classes in our application. It just isn’t realistic to create classes for different combinations of coffee and extras. It could get worse – what if we have different types of coffee? We would then have to have combinations of extras with each different type of coffee.Hence we will use decorator pattern.

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

And thats all you need. You can include this into any class you want to act as a decorator. You can then use that decorator as if it was the object it is decorating; by default all messages sent to the decorator are forwarded on to the decorated object. You can then decorate the methods you need to extend:

class Milk
include Decorator

def cost
@decorated.cost + 0.4
end
end

So how does this solve our original problem? The real power of decorators lies in the fact that they can act like the objects they are decorating. By taking this one step further, you can wrap decorators with other decorators as long as they share the same interface. By creating decorators for our different “extras”, we can create coffees using a combination of decorators and get the total cost of the coffee.

class Whip
include Decorator

def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

</pre>

====Java====
In this java example <ref>[http://java-x.blogspot.com/2007/01/implementing-decorator-pattern-in-java.html]</ref>
basicInterface: Defines the interface for objects that can have responsibilities added to them dynamically.
Basic: Defines an object to which additional responsibilities can be attached.
Decorator: maintains a reference to a Basic object and defines an interface that conforms to Basic's interface.
ConcreteDecorator: adds responsibilities to the component.
<pre>

public interface basicInterface {
public void do();
}

public class Basic implements basicInterface{
public void do() {
System.out.println("Do basic stuff");
}
}

public interface Decorator extends basicInterface {
public void addedStuff();
}

public class ConcreteDecorator implements Decorator {

basicInterface basic;

public ConcreteDecorator(basicInterface basic) {
super();
this.basic = basic;
}

public void addedStuff() {
System.out.println("Decorator does other stuff too");

}

public void do() {
basic.do();
addedStuff();
}
}

public class Client {
public static void main(String[] args) {
basicInterface comp = new Basic();
Decorator decorator = new ConcreteDecorator(comp);
decorator.do();
}
}

</pre>

In this way we can add concrete decorator classes to provided the added functionality to the basic class.

==Adapter Pattern==
Adapter pattern acts as a bridge between objects. It adapts to the changing needs of the classes using interface. In real world we have adapters for power supplies, adapters for camera memory cards etc.If a class is expecting some type of object and we have an object offering the same features, but exposing a different interface we want to use both of them so instead of implementing them again and changing existing classes,we can create an adapter.
===Intent===
Match an existing object to a particular interface.
===Problem===
A system has the right data and behavior but the wrong interface. Typically used when you have to make something a
derivative of an abstract class you already have or are defining.
===Solution===
Convert original interface component into another one through an intermediate adapter.Solution: The adapter provides a “wrapper” with the desired
interface
===Implementation===

====Ruby====
brief explanation and Sample Code:
<pre>
type the code here
</pre>

====Java====
The following example shows a simple implementation of the pattern. Consider that we have a third party library that provides sorting functionality through it's NumberSorter class. This is our Adaptee.This is our adaptee, a third party implementation of a number sorter that deals with Lists, not arrays.[http://java.dzone.com/articles/design-patterns-uncovered-0]
<pre>
public class NumberSorter
{
public List<Integer> sort(List<Integer> numbers)
{
//sort and return
return new ArrayList<Integer>();
}
}
</pre>

Our Client deals with primitive arrays rather than Lists. For the sake of this example, lets say we can't change the client to use Lists.
<pre>
int[] numbers = new int[]{34, 2, 4, 12, 1};
Sorter sorter = new SortListAdapter();
sorter.sort(numbers);
</pre>

We've provided a Sorter interface that expects the client input. This is our target.
//this is our Target interface
<pre>
public interface Sorter
{
public int[] sort(int[] numbers);
}
</pre>
Finally, the SortListAdapter implements our target interface and deals with our adaptee, NumberSorter
<pre>
public class SortListAdapter implements Sorter
{
@Override
public int[] sort(int[] numbers)
{
//convert the array to a List
List<Integer> numberList = new ArrayList<Integer>();
//call the adapter
NumberSorter sorter = new NumberSorter();
numberList = sorter.sort(numberList);

//convert the list back to an array and return
return sortedNumbers;
}
}
</pre>

===Difference between Decorator Pattern and Adapter Pattern===

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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>[http://c2.com/cgi/wiki?GangOfFour"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.
[[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.

Let's take a look at this in action with a sequence diagram.
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use tree structure and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern.
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==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 [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references />
==Additional Reading==
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]
*[http://www.slideshare.net/MarcusDenker/behavioral-reflection Behavioral reflection]
*[http://msdn.microsoft.com/en-us/library/67ef8sbd(v=vs.80).aspx C# Basics]
*[http://msdn.microsoft.com/en-us/library/ms173183(v=vs.80).aspx C# Reflection basics]
*[http://www.codeguru.com/csharp/csharp/cs_misc/reflection/article.php/c4257/An-Introduction-to-Reflection-in-C.htm Introduction to C# Reflection]
*[http://oreilly.com/catalog/progcsharp/chapter/ch18.html C# Attributes and Reflection]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-18T02:15:57Z

Knagar: /* Java */

==Introduction==
In this section we will be discussing about the decorator pattern and its related patterns such as adapter,proxy and composite.

==Decorator Pattern==
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.
We have an instance, and we put another instance inside of it. They both support the same (or similar) interfaces. The one on the outside is a "decorator." We can use the one on the outside. It either masks, changes, or pass-throughs the methods of the instance inside of it. <ref>[http://www.oodesign.com/decorator-pattern.html]</ref>
===Intent===
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality as provided by Gang of four. <ref>[http://c2.com/cgi/wiki?GangOfFour"Gang of four"]</ref>
===Problem===
The state of an object can be changed at compile time but no change is possible at run time if the language does not permit so.
===Solution===
Add a decorator module , class that acts as a extender for functions at run time such that the calls are delegated to the decorator
to extend the functionality of the objects at run time.
===Implementation===

====Ruby====
The example shows a Tea class with a method cost defining its cost as 4.
<ref>[http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html]</ref>
<pre>

If we want to calculate the cost of a cup of coffee. We have Coffee class, which implements a cost() method.

class Coffee
def cost
2
end
end

But what if we want the cost of a coffee with milk? We could have a new class:

class MilkCoffee
def cost
2.4
end
end

But now if we want cream. And sprinkles. Clearly, creating new classes is going to lead to a huge number of classes in our application. It just isn’t realistic to create classes for different combinations of coffee and extras. It could get worse – what if we have different types of coffee? We would then have to have combinations of extras with each different type of coffee.Hence we will use decorator pattern.

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

And thats all you need. You can include this into any class you want to act as a decorator. You can then use that decorator as if it was the object it is decorating; by default all messages sent to the decorator are forwarded on to the decorated object. You can then decorate the methods you need to extend:

class Milk
include Decorator

def cost
@decorated.cost + 0.4
end
end

So how does this solve our original problem? The real power of decorators lies in the fact that they can act like the objects they are decorating. By taking this one step further, you can wrap decorators with other decorators as long as they share the same interface. By creating decorators for our different “extras”, we can create coffees using a combination of decorators and get the total cost of the coffee.

class Whip
include Decorator

def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

</pre>

====Java====
In this java example <ref>[http://java-x.blogspot.com/2007/01/implementing-decorator-pattern-in-java.html]</ref>
basicInterface: Defines the interface for objects that can have responsibilities added to them dynamically.
Basic: Defines an object to which additional responsibilities can be attached.
Decorator: maintains a reference to a Basic object and defines an interface that conforms to Basic's interface.
ConcreteDecorator: adds responsibilities to the component.
<pre>

public interface basicInterface {
public void do();
}

public class Basic implements basicInterface{
public void do() {
System.out.println("Do basic stuff");
}
}

public interface Decorator extends basicInterface {
public void addedStuff();
}

public class ConcreteDecorator implements Decorator {

basicInterface basic;

public ConcreteDecorator(basicInterface basic) {
super();
this.basic = basic;
}

public void addedStuff() {
System.out.println("Decorator does other stuff too");

}

public void do() {
basic.do();
addedStuff();
}
}

public class Client {
public static void main(String[] args) {
basicInterface comp = new Basic();
Decorator decorator = new ConcreteDecorator(comp);
decorator.do();
}
}

</pre>

In this way we can add concrete decorator classes to provided the added functionality to the basic class.

==Adapter Pattern==
Adapter pattern acts as a bridge between objects. It adapts to the changing needs of the classes using interface. In real world we have adapters for power supplies, adapters for camera memory cards etc.If a class is expecting some type of object and we have an object offering the same features, but exposing a different interface we want to use both of them so instead of implementing them again and changing existing classes,we can create an adapter.
===Intent===
Match an existing object to a particular interface.
===Problem===
A system has the right data and behavior but the wrong interface. Typically used when you have to make something a
derivative of an abstract class you already have or are defining.
===Solution===
Convert original interface component into another one through an intermediate adapter.Solution: The adapter provides a “wrapper” with the desired
interface
===Implementation===

====Ruby====
brief explanation and Sample Code:
<pre>
type the code here
</pre>

====Java====
The following example shows a simple implementation of the pattern. Consider that we have a third party library that provides sorting functionality through it's NumberSorter class. This is our Adaptee.This is our adaptee, a third party implementation of a number sorter that deals with Lists, not arrays. <pre>[http://java.dzone.com/articles/design-patterns-uncovered-0]
<pre>
public class NumberSorter
{
public List<Integer> sort(List<Integer> numbers)
{
//sort and return
return new ArrayList<Integer>();
}
}
</pre>

Our Client deals with primitive arrays rather than Lists. For the sake of this example, lets say we can't change the client to use Lists.
<pre>
int[] numbers = new int[]{34, 2, 4, 12, 1};
Sorter sorter = new SortListAdapter();
sorter.sort(numbers);
</pre>

We've provided a Sorter interface that expects the client input. This is our target.
//this is our Target interface
<pre>
public interface Sorter
{
public int[] sort(int[] numbers);
}
</pre>
Finally, the SortListAdapter implements our target interface and deals with our adaptee, NumberSorter
<pre>
public class SortListAdapter implements Sorter
{
@Override
public int[] sort(int[] numbers)
{
//convert the array to a List
List<Integer> numberList = new ArrayList<Integer>();
//call the adapter
NumberSorter sorter = new NumberSorter();
numberList = sorter.sort(numberList);

//convert the list back to an array and return
return sortedNumbers;
}
}
</pre>

===Difference between Decorator Pattern and Adapter Pattern===

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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>[http://c2.com/cgi/wiki?GangOfFour"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.
[[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.

Let's take a look at this in action with a sequence diagram.
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use tree structure and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern.
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==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 [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references />
==Additional Reading==
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]
*[http://www.slideshare.net/MarcusDenker/behavioral-reflection Behavioral reflection]
*[http://msdn.microsoft.com/en-us/library/67ef8sbd(v=vs.80).aspx C# Basics]
*[http://msdn.microsoft.com/en-us/library/ms173183(v=vs.80).aspx C# Reflection basics]
*[http://www.codeguru.com/csharp/csharp/cs_misc/reflection/article.php/c4257/An-Introduction-to-Reflection-in-C.htm Introduction to C# Reflection]
*[http://oreilly.com/catalog/progcsharp/chapter/ch18.html C# Attributes and Reflection]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-18T02:07:44Z

Knagar:

==Introduction==
In this section we will be discussing about the decorator pattern and its related patterns such as adapter,proxy and composite.

==Decorator Pattern==
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.
We have an instance, and we put another instance inside of it. They both support the same (or similar) interfaces. The one on the outside is a "decorator." We can use the one on the outside. It either masks, changes, or pass-throughs the methods of the instance inside of it. <ref>[http://www.oodesign.com/decorator-pattern.html]</ref>
===Intent===
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality as provided by Gang of four. <ref>[http://c2.com/cgi/wiki?GangOfFour"Gang of four"]</ref>
===Problem===
The state of an object can be changed at compile time but no change is possible at run time if the language does not permit so.
===Solution===
Add a decorator module , class that acts as a extender for functions at run time such that the calls are delegated to the decorator
to extend the functionality of the objects at run time.
===Implementation===

====Ruby====
The example shows a Tea class with a method cost defining its cost as 4.
<ref>[http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html]</ref>
<pre>

If we want to calculate the cost of a cup of coffee. We have Coffee class, which implements a cost() method.

class Coffee
def cost
2
end
end

But what if we want the cost of a coffee with milk? We could have a new class:

class MilkCoffee
def cost
2.4
end
end

But now if we want cream. And sprinkles. Clearly, creating new classes is going to lead to a huge number of classes in our application. It just isn’t realistic to create classes for different combinations of coffee and extras. It could get worse – what if we have different types of coffee? We would then have to have combinations of extras with each different type of coffee.Hence we will use decorator pattern.

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

And thats all you need. You can include this into any class you want to act as a decorator. You can then use that decorator as if it was the object it is decorating; by default all messages sent to the decorator are forwarded on to the decorated object. You can then decorate the methods you need to extend:

class Milk
include Decorator

def cost
@decorated.cost + 0.4
end
end

So how does this solve our original problem? The real power of decorators lies in the fact that they can act like the objects they are decorating. By taking this one step further, you can wrap decorators with other decorators as long as they share the same interface. By creating decorators for our different “extras”, we can create coffees using a combination of decorators and get the total cost of the coffee.

class Whip
include Decorator

def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

</pre>

====Java====
In this java example <ref>[http://java-x.blogspot.com/2007/01/implementing-decorator-pattern-in-java.html]</ref>
basicInterface: Defines the interface for objects that can have responsibilities added to them dynamically.
Basic: Defines an object to which additional responsibilities can be attached.
Decorator: maintains a reference to a Basic object and defines an interface that conforms to Basic's interface.
ConcreteDecorator: adds responsibilities to the component.
<pre>

public interface basicInterface {
public void do();
}

public class Basic implements basicInterface{
public void do() {
System.out.println("Do basic stuff");
}
}

public interface Decorator extends basicInterface {
public void addedStuff();
}

public class ConcreteDecorator implements Decorator {

basicInterface basic;

public ConcreteDecorator(basicInterface basic) {
super();
this.basic = basic;
}

public void addedStuff() {
System.out.println("Decorator does other stuff too");

}

public void do() {
basic.do();
addedStuff();
}
}

public class Client {
public static void main(String[] args) {
basicInterface comp = new Basic();
Decorator decorator = new ConcreteDecorator(comp);
decorator.do();
}
}

</pre>

In this way we can add concrete decorator classes to provided the added functionality to the basic class.

==Adapter Pattern==
Adapter pattern acts as a bridge between objects. It adapts to the changing needs of the classes using interface. In real world we have adapters for power supplies, adapters for camera memory cards etc.If a class is expecting some type of object and we have an object offering the same features, but exposing a different interface we want to use both of them so instead of implementing them again and changing existing classes,we can create an adapter.
===Intent===
Match an existing object to a particular interface.
===Problem===
A system has the right data and behavior but the wrong interface. Typically used when you have to make something a
derivative of an abstract class you already have or are defining.
===Solution===
Convert original interface component into another one through an intermediate adapter.Solution: The adapter provides a “wrapper” with the desired
interface
===Implementation===

====Ruby====
brief explanation and Sample Code:
<pre>
type the code here
</pre>

====Java====
<pre>
The following example shows a simple implementation of the pattern. Consider that we have a third party library that provides sorting functionality through it's NumberSorter class. This is our Adaptee.This is our adaptee, a third party implementation of a number sorter that deals with Lists, not arrays. <pre>[http://java.dzone.com/articles/design-patterns-uncovered-0]</pre>

public class NumberSorter
{
public List<Integer> sort(List<Integer> numbers)
{
//sort and return
return new ArrayList<Integer>();
}
}

Our Client deals with primitive arrays rather than Lists. For the sake of this example, lets say we can't change the client to use Lists.

int[] numbers = new int[]{34, 2, 4, 12, 1};
Sorter sorter = new SortListAdapter();
sorter.sort(numbers);

We've provided a Sorter interface that expects the client input. This is our target.
//this is our Target interface
public interface Sorter
{
public int[] sort(int[] numbers);
}

Finally, the SortListAdapter implements our target interface and deals with our adaptee, NumberSorter

public class SortListAdapter implements Sorter
{
@Override
public int[] sort(int[] numbers)
{
//convert the array to a List
List<Integer> numberList = new ArrayList<Integer>();
//call the adapter
NumberSorter sorter = new NumberSorter();
numberList = sorter.sort(numberList);

//convert the list back to an array and return
return sortedNumbers;
}
}
</pre>

===Difference between Decorator Pattern and Adapter Pattern===

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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>[http://c2.com/cgi/wiki?GangOfFour"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.
[[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.

Let's take a look at this in action with a sequence diagram.
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use tree structure and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern.
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==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 [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references />
==Additional Reading==
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]
*[http://www.slideshare.net/MarcusDenker/behavioral-reflection Behavioral reflection]
*[http://msdn.microsoft.com/en-us/library/67ef8sbd(v=vs.80).aspx C# Basics]
*[http://msdn.microsoft.com/en-us/library/ms173183(v=vs.80).aspx C# Reflection basics]
*[http://www.codeguru.com/csharp/csharp/cs_misc/reflection/article.php/c4257/An-Introduction-to-Reflection-in-C.htm Introduction to C# Reflection]
*[http://oreilly.com/catalog/progcsharp/chapter/ch18.html C# Attributes and Reflection]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-18T01:55:18Z

Knagar: /* Example */

==Introduction==
In this section we will be discussing about the decorator pattern and its related patterns such as adapter,proxy and composite.

==Decorator Pattern==
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.
We have an instance, and we put another instance inside of it. They both support the same (or similar) interfaces. The one on the outside is a "decorator." We can use the one on the outside. It either masks, changes, or pass-throughs the methods of the instance inside of it. <ref>[http://www.oodesign.com/decorator-pattern.html]</ref>
===Intent===
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality as provided by Gang of four. <ref>[http://c2.com/cgi/wiki?GangOfFour"Gang of four"]</ref>
===Problem===
The state of an object can be changed at compile time but no change is possible at run time if the language does not permit so.
===Solution===
Add a decorator module , class that acts as a extender for functions at run time such that the calls are delegated to the decorator
to extend the functionality of the objects at run time.
===Implementation===

====Ruby====
The example shows a Tea class with a method cost defining its cost as 4.
<ref>[http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html]</ref>
<pre>

If we want to calculate the cost of a cup of coffee. We have Coffee class, which implements a cost() method.

class Coffee
def cost
2
end
end

But what if we want the cost of a coffee with milk? We could have a new class:

class MilkCoffee
def cost
2.4
end
end

But now if we want cream. And sprinkles. Clearly, creating new classes is going to lead to a huge number of classes in our application. It just isn’t realistic to create classes for different combinations of coffee and extras. It could get worse – what if we have different types of coffee? We would then have to have combinations of extras with each different type of coffee.Hence we will use decorator pattern.

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

And thats all you need. You can include this into any class you want to act as a decorator. You can then use that decorator as if it was the object it is decorating; by default all messages sent to the decorator are forwarded on to the decorated object. You can then decorate the methods you need to extend:

class Milk
include Decorator

def cost
@decorated.cost + 0.4
end
end

So how does this solve our original problem? The real power of decorators lies in the fact that they can act like the objects they are decorating. By taking this one step further, you can wrap decorators with other decorators as long as they share the same interface. By creating decorators for our different “extras”, we can create coffees using a combination of decorators and get the total cost of the coffee.

class Whip
include Decorator

def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

</pre>

====Java====
In this java example <ref>[http://java-x.blogspot.com/2007/01/implementing-decorator-pattern-in-java.html]</ref>
basicInterface: Defines the interface for objects that can have responsibilities added to them dynamically.
Basic: Defines an object to which additional responsibilities can be attached.
Decorator: maintains a reference to a Basic object and defines an interface that conforms to Basic's interface.
ConcreteDecorator: adds responsibilities to the component.
<pre>

public interface basicInterface {
public void do();
}

public class Basic implements basicInterface{
public void do() {
System.out.println("Do basic stuff");
}
}

public interface Decorator extends basicInterface {
public void addedStuff();
}

public class ConcreteDecorator implements Decorator {

basicInterface basic;

public ConcreteDecorator(basicInterface basic) {
super();
this.basic = basic;
}

public void addedStuff() {
System.out.println("Decorator does other stuff too");

}

public void do() {
basic.do();
addedStuff();
}
}

public class Client {
public static void main(String[] args) {
basicInterface comp = new Basic();
Decorator decorator = new ConcreteDecorator(comp);
decorator.do();
}
}

</pre>

In this way we can add concrete decorator classes to provided the added functionality to the basic class.

==Adapter Pattern==
Adapter pattern acts as a bridge between objects. It adapts to the changing needs of the classes using interface. In real world we have adapters for power supplies, adapters for camera memory cards etc.If a class is expecting some type of object and we have an object offering the same features, but exposing a different interface we want to use both of them so instead of implementing them again and changing existing classes,we can create an adapter.
===Intent===
Match an existing object to a particular interface.
===Problem===
A system has the right data and behavior but the wrong interface. Typically used when you have to make something a
derivative of an abstract class you already have or are defining.
===Solution===
Convert original interface component into another one through an intermediate adapter.Solution: The adapter provides a “wrapper” with the desired
interface
===Example===
===Implementation===

====Ruby====
brief explanation and Sample Code:
<pre>
type the code here
</pre>

====Java====
brief explanation and Sample Code:
<pre>
type the code here
</pre>

===Difference between Decorator Pattern and Adapter Pattern===

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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>[http://c2.com/cgi/wiki?GangOfFour"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.
[[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.

Let's take a look at this in action with a sequence diagram.
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use tree structure and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern.
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==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 [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references />
==Additional Reading==
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]
*[http://www.slideshare.net/MarcusDenker/behavioral-reflection Behavioral reflection]
*[http://msdn.microsoft.com/en-us/library/67ef8sbd(v=vs.80).aspx C# Basics]
*[http://msdn.microsoft.com/en-us/library/ms173183(v=vs.80).aspx C# Reflection basics]
*[http://www.codeguru.com/csharp/csharp/cs_misc/reflection/article.php/c4257/An-Introduction-to-Reflection-in-C.htm Introduction to C# Reflection]
*[http://oreilly.com/catalog/progcsharp/chapter/ch18.html C# Attributes and Reflection]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-18T01:54:02Z

Knagar:

==Introduction==
In this section we will be discussing about the decorator pattern and its related patterns such as adapter,proxy and composite.

==Decorator Pattern==
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.
We have an instance, and we put another instance inside of it. They both support the same (or similar) interfaces. The one on the outside is a "decorator." We can use the one on the outside. It either masks, changes, or pass-throughs the methods of the instance inside of it. <ref>[http://www.oodesign.com/decorator-pattern.html]</ref>
===Intent===
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality as provided by Gang of four. <ref>[http://c2.com/cgi/wiki?GangOfFour"Gang of four"]</ref>
===Problem===
The state of an object can be changed at compile time but no change is possible at run time if the language does not permit so.
===Solution===
Add a decorator module , class that acts as a extender for functions at run time such that the calls are delegated to the decorator
to extend the functionality of the objects at run time.
===Example===
===Implementation===

====Ruby====
The example shows a Tea class with a method cost defining its cost as 4.
<ref>[http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html]</ref>
<pre>

If we want to calculate the cost of a cup of coffee. We have Coffee class, which implements a cost() method.

class Coffee
def cost
2
end
end

But what if we want the cost of a coffee with milk? We could have a new class:

class MilkCoffee
def cost
2.4
end
end

But now if we want cream. And sprinkles. Clearly, creating new classes is going to lead to a huge number of classes in our application. It just isn’t realistic to create classes for different combinations of coffee and extras. It could get worse – what if we have different types of coffee? We would then have to have combinations of extras with each different type of coffee.Hence we will use decorator pattern.

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

And thats all you need. You can include this into any class you want to act as a decorator. You can then use that decorator as if it was the object it is decorating; by default all messages sent to the decorator are forwarded on to the decorated object. You can then decorate the methods you need to extend:

class Milk
include Decorator

def cost
@decorated.cost + 0.4
end
end

So how does this solve our original problem? The real power of decorators lies in the fact that they can act like the objects they are decorating. By taking this one step further, you can wrap decorators with other decorators as long as they share the same interface. By creating decorators for our different “extras”, we can create coffees using a combination of decorators and get the total cost of the coffee.

class Whip
include Decorator

def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

</pre>

====Java====
In this java example <ref>[http://java-x.blogspot.com/2007/01/implementing-decorator-pattern-in-java.html]</ref>
basicInterface: Defines the interface for objects that can have responsibilities added to them dynamically.
Basic: Defines an object to which additional responsibilities can be attached.
Decorator: maintains a reference to a Basic object and defines an interface that conforms to Basic's interface.
ConcreteDecorator: adds responsibilities to the component.
<pre>

public interface basicInterface {
public void do();
}

public class Basic implements basicInterface{
public void do() {
System.out.println("Do basic stuff");
}
}

public interface Decorator extends basicInterface {
public void addedStuff();
}

public class ConcreteDecorator implements Decorator {

basicInterface basic;

public ConcreteDecorator(basicInterface basic) {
super();
this.basic = basic;
}

public void addedStuff() {
System.out.println("Decorator does other stuff too");

}

public void do() {
basic.do();
addedStuff();
}
}

public class Client {
public static void main(String[] args) {
basicInterface comp = new Basic();
Decorator decorator = new ConcreteDecorator(comp);
decorator.do();
}
}

</pre>

In this way we can add concrete decorator classes to provided the added functionality to the basic class.

==Adapter Pattern==
Adapter pattern acts as a bridge between objects. It adapts to the changing needs of the classes using interface. In real world we have adapters for power supplies, adapters for camera memory cards etc.If a class is expecting some type of object and we have an object offering the same features, but exposing a different interface we want to use both of them so instead of implementing them again and changing existing classes,we can create an adapter.
===Intent===
Match an existing object to a particular interface.
===Problem===
A system has the right data and behavior but the wrong interface. Typically used when you have to make something a
derivative of an abstract class you already have or are defining.
===Solution===
Convert original interface component into another one through an intermediate adapter.Solution: The adapter provides a “wrapper” with the desired
interface
===Example===
===Implementation===

====Ruby====
brief explanation and Sample Code:
<pre>
type the code here
</pre>

====Java====
brief explanation and Sample Code:
<pre>
type the code here
</pre>

===Difference between Decorator Pattern and Adapter Pattern===

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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>[http://c2.com/cgi/wiki?GangOfFour"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.
[[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.

Let's take a look at this in action with a sequence diagram.
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use tree structure and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern.
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==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 [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references />
==Additional Reading==
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]
*[http://www.slideshare.net/MarcusDenker/behavioral-reflection Behavioral reflection]
*[http://msdn.microsoft.com/en-us/library/67ef8sbd(v=vs.80).aspx C# Basics]
*[http://msdn.microsoft.com/en-us/library/ms173183(v=vs.80).aspx C# Reflection basics]
*[http://www.codeguru.com/csharp/csharp/cs_misc/reflection/article.php/c4257/An-Introduction-to-Reflection-in-C.htm Introduction to C# Reflection]
*[http://oreilly.com/catalog/progcsharp/chapter/ch18.html C# Attributes and Reflection]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-18T01:39:40Z

Knagar:

==Introduction==
In this section we will be discussing about the decorator pattern and its related patterns such as adapter,proxy and composite.

==Decorator Pattern==
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.
We have an instance, and we put another instance inside of it. They both support the same (or similar) interfaces. The one on the outside is a "decorator." We can use the one on the outside. It either masks, changes, or pass-throughs the methods of the instance inside of it. <ref>[http://www.oodesign.com/decorator-pattern.html]</ref>
===Intent===
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality as provided by Gang of four. <ref>[http://c2.com/cgi/wiki?GangOfFour"Gang of four"]</ref>
===Problem===
The state of an object can be changed at compile time but no change is possible at run time if the language does not permit so.
===Solution===
Add a decorator module , class that acts as a extender for functions at run time such that the calls are delegated to the decorator
to extend the functionality of the objects at run time.
===Example===
===Implementation===

====Ruby====
The example shows a Tea class with a method cost defining its cost as 4.
<ref>[http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html]</ref>
<pre>

If we want to calculate the cost of a cup of coffee. We have Coffee class, which implements a cost() method.

class Coffee
def cost
2
end
end

But what if we want the cost of a coffee with milk? We could have a new class:

class MilkCoffee
def cost
2.4
end
end

But now if we want cream. And sprinkles. Clearly, creating new classes is going to lead to a huge number of classes in our application. It just isn’t realistic to create classes for different combinations of coffee and extras. It could get worse – what if we have different types of coffee? We would then have to have combinations of extras with each different type of coffee.Hence we will use decorator pattern.

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

And thats all you need. You can include this into any class you want to act as a decorator. You can then use that decorator as if it was the object it is decorating; by default all messages sent to the decorator are forwarded on to the decorated object. You can then decorate the methods you need to extend:

class Milk
include Decorator

def cost
@decorated.cost + 0.4
end
end

So how does this solve our original problem? The real power of decorators lies in the fact that they can act like the objects they are decorating. By taking this one step further, you can wrap decorators with other decorators as long as they share the same interface. By creating decorators for our different “extras”, we can create coffees using a combination of decorators and get the total cost of the coffee.

class Whip
include Decorator

def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

</pre>

====Java====
In this java example <ref>[http://java-x.blogspot.com/2007/01/implementing-decorator-pattern-in-java.html]</ref>
basicInterface: Defines the interface for objects that can have responsibilities added to them dynamically.
Basic: Defines an object to which additional responsibilities can be attached.
Decorator: maintains a reference to a Basic object and defines an interface that conforms to Basic's interface.
ConcreteDecorator: adds responsibilities to the component.
<pre>

public interface basicInterface {
public void do();
}

public class Basic implements basicInterface{
public void do() {
System.out.println("Do basic stuff");
}
}

public interface Decorator extends basicInterface {
public void addedStuff();
}

public class ConcreteDecorator implements Decorator {

basicInterface basic;

public ConcreteDecorator(basicInterface basic) {
super();
this.basic = basic;
}

public void addedStuff() {
System.out.println("Decorator does other stuff too");

}

public void do() {
basic.do();
addedStuff();
}
}

public class Client {
public static void main(String[] args) {
basicInterface comp = new Basic();
Decorator decorator = new ConcreteDecorator(comp);
decorator.do();
}
}

</pre>

In this way we can add concrete decorator classes to provided the added functionality to the basic class.

==Adapter Pattern==
brief overview
===Intent===
===Problem===
How to resolve incompatible interfaces or provide a stable interface to similar components with different interfaces?
===Solution===
Convert original interface component into another one through an intermediate adapter.
===Example===
===Implementation===

====Ruby====
brief explanation and Sample Code:
<pre>
type the code here
</pre>

====Java====
brief explanation and Sample Code:
<pre>
type the code here
</pre>

===Difference between Decorator Pattern and Adapter Pattern===

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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>[http://c2.com/cgi/wiki?GangOfFour"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.
[[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.

Let's take a look at this in action with a sequence diagram.
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use tree structure and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern.
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==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 [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references />
==Additional Reading==
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]
*[http://www.slideshare.net/MarcusDenker/behavioral-reflection Behavioral reflection]
*[http://msdn.microsoft.com/en-us/library/67ef8sbd(v=vs.80).aspx C# Basics]
*[http://msdn.microsoft.com/en-us/library/ms173183(v=vs.80).aspx C# Reflection basics]
*[http://www.codeguru.com/csharp/csharp/cs_misc/reflection/article.php/c4257/An-Introduction-to-Reflection-in-C.htm Introduction to C# Reflection]
*[http://oreilly.com/catalog/progcsharp/chapter/ch18.html C# Attributes and Reflection]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-18T01:35:44Z

Knagar:

==Introduction==
In this section we will be discussing about the decorator pattern and its related patterns such as adapter,proxy and composite.

==Decorator Pattern==
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.
We have an instance, and we put another instance inside of it. They both support the same (or similar) interfaces. The one on the outside is a "decorator." We can use the one on the outside. It either masks, changes, or pass-throughs the methods of the instance inside of it. <ref>[http://www.oodesign.com/decorator-pattern.html]</ref>
===Intent===
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality as provided by Gang of four. <ref>[http://c2.com/cgi/wiki?GangOfFour"Gang of four"]</ref>
===Problem===
The state of an object can be changed at compile time but no change is possible at run time if the language does not permit so.
===Solution===
Add a decorator module , class that acts as a extender for functions at run time such that the calls are delegated to the decorator
to extend the functionality of the objects at run time.
===Example===
===Implementation===

====Ruby====
The example shows a Tea class with a method cost defining its cost as 4.
<ref>[http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html]</ref>
<pre>

If we want to calculate the cost of a cup of coffee. We have Coffee class, which implements a cost() method.

class Coffee
def cost
2
end
end

But what if we want the cost of a coffee with milk? We could have a new class:

class MilkCoffee
def cost
2.4
end
end

But now if we want cream. And sprinkles. Clearly, creating new classes is going to lead to a huge number of classes in our application. It just isn’t realistic to create classes for different combinations of coffee and extras. It could get worse – what if we have different types of coffee? We would then have to have combinations of extras with each different type of coffee.Hence we will use decorator pattern.

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

And thats all you need. You can include this into any class you want to act as a decorator. You can then use that decorator as if it was the object it is decorating; by default all messages sent to the decorator are forwarded on to the decorated object. You can then decorate the methods you need to extend:

class Milk
include Decorator

def cost
@decorated.cost + 0.4
end
end

So how does this solve our original problem? The real power of decorators lies in the fact that they can act like the objects they are decorating. By taking this one step further, you can wrap decorators with other decorators as long as they share the same interface. By creating decorators for our different “extras”, we can create coffees using a combination of decorators and get the total cost of the coffee.

class Whip
include Decorator

def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

</pre>

====Java====
In this java example <ref>[http://java-x.blogspot.com/2007/01/implementing-decorator-pattern-in-java.html]</ref>
basicInterface: Defines the interface for objects that can have responsibilities added to them dynamically.
Basic: Defines an object to which additional responsibilities can be attached.
Decorator: maintains a reference to a Basic object and defines an interface that conforms to Basic's interface.
ConcreteDecorator: adds responsibilities to the component.
<pre>

public interface basicInterface {
public void do();
}

public class Basic implements basicInterface{
public void do() {
System.out.println("Do basic stuff");
}
}

public interface Decorator extends basicInterface {
public void addedStuff();
}

public class ConcreteDecorator implements Decorator {

basicInterface basic;

public ConcreteDecorator(basicInterface basic) {
super();
this.basic = basic;
}

public void addedStuff() {
System.out.println("Decorator does other stuff too");

}

public void do() {
basic.do();
addedStuff();
}
}

public class Client {
public static void main(String[] args) {
basicInterface comp = new Basic();
Decorator decorator = new ConcreteDecorator(comp);
decorator.do();
}
}

</pre>

In this way we can add concrete decorator classes to provided the added functionality to the basic class.

==Adapter Pattern==
brief overview
===Intent===
===Problem===
===Solution===
===Example===
===Implementation===

====Ruby====
brief explanation and Sample Code:
<pre>
type the code here
</pre>

====Java====
brief explanation and Sample Code:
<pre>
type the code here
</pre>

===Difference between Decorator Pattern and Adapter Pattern===

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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>[http://c2.com/cgi/wiki?GangOfFour"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.
[[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.

Let's take a look at this in action with a sequence diagram.
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use tree structure and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern.
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==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 [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references />
==Additional Reading==
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]
*[http://www.slideshare.net/MarcusDenker/behavioral-reflection Behavioral reflection]
*[http://msdn.microsoft.com/en-us/library/67ef8sbd(v=vs.80).aspx C# Basics]
*[http://msdn.microsoft.com/en-us/library/ms173183(v=vs.80).aspx C# Reflection basics]
*[http://www.codeguru.com/csharp/csharp/cs_misc/reflection/article.php/c4257/An-Introduction-to-Reflection-in-C.htm Introduction to C# Reflection]
*[http://oreilly.com/catalog/progcsharp/chapter/ch18.html C# Attributes and Reflection]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-18T01:31:39Z

Knagar:

==Introduction==
In this section we will be discussing about the decorator pattern and its related patterns such as adapter,proxy and composite.

==Decorator Pattern==
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.
We have an instance, and we put another instance inside of it. They both support the same (or similar) interfaces. The one on the outside is a "decorator." We can use the one on the outside. It either masks, changes, or pass-throughs the methods of the instance inside of it. <ref>[http://www.oodesign.com/decorator-pattern.html]</ref>
===Intent===
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality as provided by Gang of four. <ref>[http://c2.com/cgi/wiki?GangOfFour"Gang of four"]</ref>
===Problem===
The state of an object can be changed at compile time but no change is possible at run time if the language does not permit so.
===Solution===
Add a decorator module , class that acts as a extender for functions at run time such that the calls are delegated to the decorator
to extend the functionality of the objects at run time.
===Example===
===Implementation===

====Ruby====
The example shows a Tea class with a method cost defining its cost as 4.
<ref>[http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html]</ref>
<pre>

If we want to calculate the cost of a cup of coffee. We have Coffee class, which implements a cost() method.

class Coffee
def cost
2
end
end

But what if we want the cost of a coffee with milk? We could have a new class:

class MilkCoffee
def cost
2.4
end
end

But now if we want cream. And sprinkles. Clearly, creating new classes is going to lead to a huge number of classes in our application. It just isn’t realistic to create classes for different combinations of coffee and extras. It could get worse – what if we have different types of coffee? We would then have to have combinations of extras with each different type of coffee.Hence we will use decorator pattern.

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

And thats all you need. You can include this into any class you want to act as a decorator. You can then use that decorator as if it was the object it is decorating; by default all messages sent to the decorator are forwarded on to the decorated object. You can then decorate the methods you need to extend:

class Milk
include Decorator

def cost
@decorated.cost + 0.4
end
end

So how does this solve our original problem? The real power of decorators lies in the fact that they can act like the objects they are decorating. By taking this one step further, you can wrap decorators with other decorators as long as they share the same interface. By creating decorators for our different “extras”, we can create coffees using a combination of decorators and get the total cost of the coffee.

class Whip
include Decorator

def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

</pre>

====Java====
In this java example
basicInterface: Defines the interface for objects that can have responsibilities added to them dynamically.
Basic: Defines an object to which additional responsibilities can be attached.
Decorator: maintains a reference to a Basic object and defines an interface that conforms to Basic's interface.
ConcreteDecorator: adds responsibilities to the component.
<pre>

public interface basicInterface {
public void do();
}

public class Basic implements basicInterface{
public void do() {
System.out.println("Do basic stuff");
}
}

public interface Decorator extends basicInterface {
public void addedStuff();
}

public class ConcreteDecorator implements Decorator {

basicInterface basic;

public ConcreteDecorator(basicInterface basic) {
super();
this.basic = basic;
}

public void addedStuff() {
System.out.println("Decorator does other stuff too");

}

public void do() {
basic.do();
addedStuff();
}
}

public class Client {
public static void main(String[] args) {
basicInterface comp = new Basic();
Decorator decorator = new ConcreteDecorator(comp);
decorator.do();
}
}

</pre>

In this way we can add concrete decorator classes to provided the added functionality to the basic class.

==Adapter Pattern==
brief overview
===Intent===
===Problem===
===Solution===
===Example===
===Implementation===

====Ruby====
brief explanation and Sample Code:
<pre>
type the code here
</pre>

====Java====
brief explanation and Sample Code:
<pre>
type the code here
</pre>

===Difference between Decorator Pattern and Adapter Pattern===

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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>[http://c2.com/cgi/wiki?GangOfFour"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.
[[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.

Let's take a look at this in action with a sequence diagram.
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use tree structure and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern.
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==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 [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references />
==Additional Reading==
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]
*[http://www.slideshare.net/MarcusDenker/behavioral-reflection Behavioral reflection]
*[http://msdn.microsoft.com/en-us/library/67ef8sbd(v=vs.80).aspx C# Basics]
*[http://msdn.microsoft.com/en-us/library/ms173183(v=vs.80).aspx C# Reflection basics]
*[http://www.codeguru.com/csharp/csharp/cs_misc/reflection/article.php/c4257/An-Introduction-to-Reflection-in-C.htm Introduction to C# Reflection]
*[http://oreilly.com/catalog/progcsharp/chapter/ch18.html C# Attributes and Reflection]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-18T01:27:44Z

Knagar:

==Introduction==
In this section we will be discussing about the decorator pattern and compare it with related patterns such as adapter,proxy and composite pattern.w.

==Decorator Pattern==
brief overview
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.
We have an instance, and we put another instance inside of it. They both support the same (or similar) interfaces. The one on the outside is a "decorator." We can use the one on the outside. It either masks, changes, or pass-throughs the methods of the instance inside of it. <ref>[http://www.oodesign.com/decorator-pattern.html]</ref>

Consider the typical example of a graphical window. To extend the functionality of the graphical window for example by adding a frame to the window, would require extending the window class to create a Framed Window class. To create a framed window it is necessary to create an object of the Framed Window class. However it would be impossible to start with a plain window and to extend its functionality at run time to become a framed
window.<ref>[http://www.oodesign.com/decorator-pattern.html]</ref>

===Intent===
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality as provided by Gang of four. <ref>[http://c2.com/cgi/wiki?GangOfFour"Gang of four"]</ref>
===Problem===
The state of an object can be changed at compile time but no change is possible at run time if the language does not permit so.
===Solution===
Add a decorator module , class that acts as a extender for functions at run time such that the calls are delegated to the decorator
to extend the functionality of the objects at run time.
===Example===
===Implementation===

====Ruby====
The example shows a Tea class with a method cost defining its cost as 4.
<ref>[http://lukeredpath.co.uk/blog/decorator-pattern-with-ruby-in-8-lines.html]</ref>
<pre>

If we want to calculate the cost of a cup of coffee. We have Coffee class, which implements a cost() method.

class Coffee
def cost
2
end
end

But what if we want the cost of a coffee with milk? We could have a new class:

class MilkCoffee
def cost
2.4
end
end

But now if we want cream. And sprinkles. Clearly, creating new classes is going to lead to a huge number of classes in our application. It just isn’t realistic to create classes for different combinations of coffee and extras. It could get worse – what if we have different types of coffee? We would then have to have combinations of extras with each different type of coffee.Hence we will use decorator pattern.

module Decorator
def initialize(decorated)
@decorated = decorated
end

def method_missing(method, *args)
args.empty? ? @decorated.send(method) : @decorated.send(method, args)
end
end

And thats all you need. You can include this into any class you want to act as a decorator. You can then use that decorator as if it was the object it is decorating; by default all messages sent to the decorator are forwarded on to the decorated object. You can then decorate the methods you need to extend:

class Milk
include Decorator

def cost
@decorated.cost + 0.4
end
end

So how does this solve our original problem? The real power of decorators lies in the fact that they can act like the objects they are decorating. By taking this one step further, you can wrap decorators with other decorators as long as they share the same interface. By creating decorators for our different “extras”, we can create coffees using a combination of decorators and get the total cost of the coffee.

class Whip
include Decorator

def cost
@decorated.cost + 0.2
end
end

class Sprinkles
include Decorator

def cost
@decorated.cost + 0.3
end
end

Whip.new(Coffee.new).cost
#=> 2.2
Sprinkles.new(Whip.new(Milk.new(Coffee.new))).cost
#=> 2.9

</pre>

====Java====
In this java example
basicInterface: Defines the interface for objects that can have responsibilities added to them dynamically.
Basic: Defines an object to which additional responsibilities can be attached.
Decorator: maintains a reference to a Basic object and defines an interface that conforms to Basic's interface.
ConcreteDecorator: adds responsibilities to the component.
<pre>

public interface basicInterface {
public void do();
}

public class Basic implements basicInterface{
public void do() {
System.out.println("Do basic stuff");
}
}

public interface Decorator extends basicInterface {
public void addedStuff();
}

public class ConcreteDecorator implements Decorator {

basicInterface basic;

public ConcreteDecorator(basicInterface basic) {
super();
this.basic = basic;
}

public void addedStuff() {
System.out.println("Decorator does other stuff too");

}

public void do() {
basic.do();
addedStuff();
}
}

public class Client {
public static void main(String[] args) {
basicInterface comp = new Basic();
Decorator decorator = new ConcreteDecorator(comp);
decorator.do();
}
}

</pre>

==Adapter Pattern==
brief overview
===Intent===
===Problem===
===Solution===
===Example===
===Implementation===

====Ruby====
brief explanation and Sample Code:
<pre>
type the code here
</pre>

====Java====
brief explanation and Sample Code:
<pre>
type the code here
</pre>

===Difference between Decorator Pattern and Adapter Pattern===

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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>[http://c2.com/cgi/wiki?GangOfFour"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.
[[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.

Let's take a look at this in action with a sequence diagram.
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use tree structure and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern.
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==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 [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references />
==Additional Reading==
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]
*[http://www.slideshare.net/MarcusDenker/behavioral-reflection Behavioral reflection]
*[http://msdn.microsoft.com/en-us/library/67ef8sbd(v=vs.80).aspx C# Basics]
*[http://msdn.microsoft.com/en-us/library/ms173183(v=vs.80).aspx C# Reflection basics]
*[http://www.codeguru.com/csharp/csharp/cs_misc/reflection/article.php/c4257/An-Introduction-to-Reflection-in-C.htm Introduction to C# Reflection]
*[http://oreilly.com/catalog/progcsharp/chapter/ch18.html C# Attributes and Reflection]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-18T00:12:37Z

Knagar:

==Introduction==
In this section we will be discussing about the decorator pattern and compare it with related patterns such as adapter,proxy and composite pattern.w.

==Decorator Pattern==
brief overview
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.

<ref>[http://www.oodesign.com/decorator-pattern.html]</ref>
Consider the typical example of a graphical window. To extend the functionality of the graphical window for example by adding a frame to the window, would require extending the window class to create a Framed Window class. To create a framed window it is necessary to create an object of the Framed Window class. However it would be impossible to start with a plain window and to extend its functionality at run time to become a framed
window.

===Intent===
An
===Problem===
===Solution===
===Example===
===Implementation===

====Ruby====
brief explanation and Sample Code:
<pre>
type the code here
</pre>

====Java====
brief explanation and Sample Code:
<pre>
type the code here
</pre>

==Adapter Pattern==
brief overview
===Intent===
===Problem===
===Solution===
===Example===
===Implementation===

====Ruby====
brief explanation and Sample Code:
<pre>
type the code here
</pre>

====Java====
brief explanation and Sample Code:
<pre>
type the code here
</pre>

===Difference between Decorator Pattern and Adapter Pattern===

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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>[http://c2.com/cgi/wiki?GangOfFour"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.
[[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.

Let's take a look at this in action with a sequence diagram.
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use tree structure and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern.
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==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 [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references />
==Additional Reading==
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]
*[http://www.slideshare.net/MarcusDenker/behavioral-reflection Behavioral reflection]
*[http://msdn.microsoft.com/en-us/library/67ef8sbd(v=vs.80).aspx C# Basics]
*[http://msdn.microsoft.com/en-us/library/ms173183(v=vs.80).aspx C# Reflection basics]
*[http://www.codeguru.com/csharp/csharp/cs_misc/reflection/article.php/c4257/An-Introduction-to-Reflection-in-C.htm Introduction to C# Reflection]
*[http://oreilly.com/catalog/progcsharp/chapter/ch18.html C# Attributes and Reflection]

CSC/ECE 517 Fall 2012/ch2b 2w39 ka

2012-11-18T00:10:41Z

Knagar:

==Introduction==
In this section we will be discussing about the decorator pattern and compare it with related patterns such as adapter,proxy and composite pattern.w.

==Decorator Pattern==
brief overview
An object's state can be changed at compile time and not at run time. The change of state can be accomplished at compile time by using inheritance, however we might want to change the state of the object at run time. This can be achieved by decorator pattern.

[http://www.oodesign.com/decorator-pattern.html]Consider the typical example of a graphical window. To extend the functionality of the graphical window for example by adding a frame to the window, would require extending the window class to create a Framed Window class. To create a framed window it is necessary to create an object of the Framed Window class. However it would be impossible to start with a plain window and to extend its functionality at run time to become a framed
window.

===Intent===
An
===Problem===
===Solution===
===Example===
===Implementation===

====Ruby====
brief explanation and Sample Code:
<pre>
type the code here
</pre>

====Java====
brief explanation and Sample Code:
<pre>
type the code here
</pre>

==Adapter Pattern==
brief overview
===Intent===
===Problem===
===Solution===
===Example===
===Implementation===

====Ruby====
brief explanation and Sample Code:
<pre>
type the code here
</pre>

====Java====
brief explanation and Sample Code:
<pre>
type the code here
</pre>

===Difference between Decorator Pattern and Adapter Pattern===

==Proxy Pattern==
Sometimes we need the ability to control the access to an [http://en.wikipedia.org/wiki/Object_(computer_science) object]. For example if we need to use only a few methods of some costly objects we'll [http://www.geom.uiuc.edu/~daeron/docs/javaguide/java/anatomy/creating.html 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>[http://c2.com/cgi/wiki?GangOfFour"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.
[[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.

Let's take a look at this in action with a sequence diagram.
[[File:SequenceDiagramForProxy.png|none]]

As you can see it's quite simple - the Proxy is providing a barrier between the client and the real implementation.

There are many different flavours of Proxy, depending on it's purpose. You may have a protection proxy, to control access rights to an object. A virtual proxy handles the case where an object might be expensive to create, and a remote proxy controls access to a remote object.

You'll have noticed that this is very similar to the Adapter pattern. However, the main difference between bot is that the adapter will expose a different interface to allow interoperability. The Proxy exposes the same interface, but gets in the way to save processing time or memory.

===Example===
There are four common situations in which the Proxy pattern is applicable.

*A virtual proxy is a placeholder for “expensive to create” objects.
The real object is only created when a client first requests/accesses the object. In place of a complex or heavy object use a skeleton representation. When an underlying image is huge in size, just represent it using a virtual proxy object and on demand load the real object. You feel that the real object is expensive in terms of instantiation and so without the real need we are not going to use the real object. Until the need arises we will use the virtual proxy.

*A remote proxy provides a local representative for an object that resides in a different address space.
This is what the “stub” code in RPC and CORBA provides. Think of an ATM implementation, it will hold proxy objects for bank information that exists in the remote server. RMI is an example of proxy implmenetation for this type in java.

*A protective proxy controls access to a sensitive master object.
The “surrogate” object checks that the caller has the access permissions required prior to forwarding the request. You might be well aware of the proxy server that provides you internet. Saying more than provides, the right word is censores internet. The management feels its better to censor some content and provide only work related web pages. Proxy server does that job. This is a type of proxy design pattern. Lighter part of censor is, we search for something critical in Google and click the result and you get this page is blocked by proxy server. You never know why this page is blocked and you feel this is genuine. How do you overcome that, over a period you learn to live with it.

*A smart proxy interposes additional actions when an object is accessed. Typical uses include:
**Counting the number of references to the real object so that it can be freed automatically when there are no more references (aka smart pointer),
**Loading a persistent object into memory when it’s first referenced,
**Checking that the real object is locked before it is accessed to ensure that no other object can change it.

===Implementation===

====Ruby====
Let’s assume you need to log all method calls made to a bank Account object without changing the original Account definition. You can create a new class to wrap the Account object, log any method call then forward the request to the target object.
Here’s a super simple bank Account.
<pre>
class Account

def initialize(amount)
@amount = amount
end

def deposit(amount)
@amount += amount
end

def withdraw(amount)
@amount -= amount
end

def balance
@amount
end

def inspect
puts "Amount: #{@amount}"
end

end
</pre>

and here’s our AccountLogger class.
<pre>
class AccountLogger < BasicObject

def initialize(amount)
@operations = []

@target = Account.new(amount)
@operations << [:initialize, [amount]]
end

def method_missing(method, *args, &block)
@operations << [method, args]
@target.send(method, *args, &block)
end

def operations
@operations
end

end
</pre>
The AccountLogger is our Proxy object. It doesn’t know anything about the target object, in fact it limits itself to log method calls and forward the request to the underlying @target using the method_missing hook.BasicObject actually prevents this issue by exposing a limited set of instance methods. Simply put, it copes with the problem from a different point of view: instead of taking a rich object and removing all the unnecessary methods, take a poor object and only define what you actually need.

====Java====
From JDK 1.3 java has direct support for implementing proxy design pattern. We need not worry on mainting the reference and object creation. Java provides us the needed utilities. Following example implementation explains on how to use java’s api for proxy design pattern.
<pre>
public interface Animal {

public void getSound();

}
</pre>

<pre>
public class Lion implements Animal {

public void getSound() {
System.out.println("Roar");
}

}
</pre>

<pre>
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class AnimalInvocationHandler implements InvocationHandler {
public AnimalInvocationHandler(Object realSubject) {
this.realSubject = realSubject;
}

public Object invoke(Object proxy, Method m, Object[] args) {
Object result = null;
try {
result = m.invoke(realSubject, args);
} catch (Exception ex) {
ex.printStackTrace();
}
return result;
}

private Object realSubject = null;
}
</pre>
<pre>
import java.lang.reflect.Proxy;

public class ProxyExample {

public static void main(String[] args) {
Animal realSubject = new Lion();
Animal proxy = (Animal) Proxy.newProxyInstance(realSubject.getClass()
.getClassLoader(), realSubject.getClass().getInterfaces(),
new AnimalInvocationHandler(realSubject));
proxy.getSound();
}
}
</pre>

We have created a proxy handler that will be able to get the sound depending on the type of animal.

===Difference between Decorator Pattern and Proxy Pattern===
The two UML diagrams may confuse us. The two design patterns looks the same with each other. With Decorator Pattern, the decorator and the decoratee implement the same interfaces. With Proxy Pattern, the proxy class and the real class delegated implement the same interfaces. Furthermore, no matter which pattern is used, it is easy to add functions before or after the method of the real object.
However, in fact, there are some differences between Decorator Pattern and Proxy Pattern. Decorator Pattern focuses on dynamically adding functions to an object, while Proxy Pattern focuses on controlling access to an object. In other words, with Proxy Pattern, the proxy class can hide the detail information of an object from its client. Therefore, when using Proxy Pattern, we usually create an instance of object inside the proxy class. And when using Decorator Pattern, we typically pass the original object as a parameter to the constructor of the decorator.We can use another sentence to conclude thire differences:
<pre>
With the Proxy pattern, the relationship between a proxy and the real subject is typically set at compile time, whereas decorators can be recursively
constructed at runtime.
</pre>

==Composite Pattern==
When we want to represent part-whole hierarchy, use tree structure and compose objects. We know tree structure what a tree structure is and some of us don’t know what a part-whole hierarchy is. A system consists of subsystems or components. Components can further be divided into smaller components. Further smaller components can be divided into smaller elements. This is a part-whole hierarchy.
Everything around us can be a candidate for part-whole hierarchy. Human body, a car, a computer, lego structure, etc. A car is made up of engine, tyre,etc. Engine is made up of electrical components, valves, etc. Electrical components is made up of chips, transistor,etc. Like this a component is part of a whole system. This hierarchy can be represented as a tree structure using composite design pattern.
===Intent===
“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.” is the intent by GoF.
===Problem===
Application needs to manipulate a hierarchical collection of “primitive” and “composite” objects. Processing of a primitive object is handled one way, and processing of a composite object is handled differently. Having to query the “type” of each object before attempting to process it is not desirable.
===Solution===
The figure below shows a UML class diagram for the Composite Pattern:
[[File:Composite.png|none]]

*Component - Component is the abstraction for leafs and composites. It defines the interface that must be implemented by the objects in the composition. For example a file system resource defines move, copy, rename, and getSize methods for files and folders.
*Leaf - Leafs are objects that have no children. They implement services described by the Component interface. For example a file object implements move, copy, rename, as well as getSize methods which are related to the Component interface.
*Composite - A Composite stores child components in addition to implementing methods defined by the component interface. Composites implement methods defined in the Component interface by delegating to child components. In addition composites provide additional methods for adding, removing, as well as getting components.
*Client - The client manipulates objects in the hierarchy using the component interface.

A client has a reference to a tree data structure and needs to perform operations on all nodes independent of the fact that a node might be a branch or a leaf. The client simply obtains reference to the required node using the component interface, and deals with the node using this interface; it doesn't matter if the node is a composite or a leaf.

===Example===
*GUI toolkits:
For example, Java SWT (Standard Widget Toolkit). If you want to apply a theme for a dialog, you need to apply the theme for the dialog and all its child components. A child can be a composite or a widget itself. If it is a widget, there is no child for that, and the theme needs to be applied only for the widget. But if it is a composite, we need to apply the theme for all its children. Now again, a child can be a widget or a composite. The loop continues until it covers all child widgets.

*Destruction of objects in C++:
Take any OO language without a garbage collector. Just imagine you have a data structure like tree. Each object has a reference only to his children and the client is aware of only the root node object. How will you destroy all the objects, leaving no memory leak? It is only a couple of lines of code that takes to destroy the complete code.
Kill a node = Kill all its children and then kill yourself.
Since the children are also of type node, the loop continues till it goes to the lowest level where there are no children.

In both the above mentioned cases using a composite pattern based recursion is a wise approach.

===Implementation===

====Ruby====
Use this in cases where your design seems to have a hierarchy. The hierarchy can be established by data/logic i.e Tasks & SubTasks, Parts & SubParts.
<pre>
class Part
def initialize name
@name = name
end
def weight
0
end
end

class Hand < Part
def initialize
super("Hand")
@children = []
5.times {add_child Finger.new}
end

def weight #component object
weight  = 5
@children.each { |c| weight += c.weight }
weight
end

def add_child child
@children << child
end
end

class Finger < Part
def initialize
super("Finger")
end

def weight #Leaf object
1
end
end
hand = Hand.new
puts hand.weight #7
</pre>
Note here that the complex weight methods have been implemented in the component class and not the leaf class.

====Java====
Here is the sample code that implements composite pattern.
<pre>
public class Block implements Group {

public void assemble() {
System.out.println("Block");
}
}
</pre>

<pre>
public interface Group {
public void assemble();
}
</pre>

<pre>
import java.util.ArrayList;
import java.util.List;

public class Structure implements Group {
// Collection of child groups.
private List<Group> groups = new ArrayList<Group>();

public void assemble() {
for (Group group : groups) {
group.assemble();
}
}

// Adds the group to the structure.
public void add(Group group) {
groups.add(group);
}

// Removes the group from the structure.
public void remove(Group group) {
groups.remove(group);
}
}
</pre>

<pre>
public class ImplementComposite {
public static void main(String[] args) {
//Initialize three blocks
Block block1 = new Block();
Block block2 = new Block();
Block block3 = new Block();

//Initialize three structure
Structure structure = new Structure();
Structure structure1 = new Structure();
Structure structure2 = new Structure();

//Composes the groups
structure1.add(block1);
structure1.add(block2);

structure2.add(block3);

structure.add(structure1);
structure.add(structure2);

structure.assemble();
}
}
</pre>

===Difference between Decorator Pattern and Composite Pattern===
They usually go hand in and hand. In that using the composite pattern often leads to also using the decorator pattern.
The composite pattern allows you to build a hierarchical structure (such as a tree of elements) in a way that allows your external code to view the entire structure as a single entity. So the interface to a leaf entity is exactly the same as the entity for a compound entity. Essence is that all elements in your composite structure have the same interface even though some are leafs and others are entire structures. User interfaces often use this approach to allow easy composability.
However, The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity. This allows the decorator to modify the behavior and/or content of whatever it is encapsulating without changing the outward appearance of the entity. For example, you might use a decorator to add logging output on the usage of the contained element without changing any behavior of the contained element.

==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 [http://en.wikipedia.org/wiki/Metaprogramming Metaprogramming].

==References==
<references />
==Additional Reading==
*[http://tutorials.jenkov.com/java-reflection/classes.html Java Reflection]
*[http://www.slideshare.net/CiaranMcHale/java-reflection-explained-simply Java reflection basics]
*[http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html A Tutorial on Behavioral Reflection and its Implementation]
*[http://www.quora.com/Computer-Programming/How-is-reflection-useful Uses of reflection]
*[http://download.oracle.com/javase/tutorial/reflect/index.html Java reflection official website]
*[http://ruby-doc.org/docs/ProgrammingRuby/html/builtins.html Ruby Documentation]
*[http://www.slideshare.net/MarcusDenker/behavioral-reflection Behavioral reflection]
*[http://msdn.microsoft.com/en-us/library/67ef8sbd(v=vs.80).aspx C# Basics]
*[http://msdn.microsoft.com/en-us/library/ms173183(v=vs.80).aspx C# Reflection basics]
*[http://www.codeguru.com/csharp/csharp/cs_misc/reflection/article.php/c4257/An-Introduction-to-Reflection-in-C.htm Introduction to C# Reflection]
*[http://oreilly.com/catalog/progcsharp/chapter/ch18.html C# Attributes and Reflection]

CSC/ECE 517 Fall 2012/ch1b 1w67 ks

2012-10-04T03:00:36Z

Knagar: /* Example - Session/Flash */

= Overview/Introduction =
 Redirection refers to redirection of incoming request from one page to another. HTTP is stateless, hence redirection with session/flash makes it stateful.As the http requests are stateless,it leads to losing the state of the previous request. Thus Rails provides hash called Flash which persist until the end of the next request received and Session hash, which unlike flash persists forever. <ref>http://www.youtube.com/watch?v=0m8lmRwS7E0</ref>.

= Flash in Ruby =
Flash in ruby helps to remember the state until the end of the next request. It is basically used to store error messages as warnings and information as notice in the hash. It is used in views to print the error messages or notice. Along with notice and warnings, we can also define user defined hash and print its value in the view as we did for the notice and warnings. Basically it helps in flashing messages on the views. It stores values in the form of hash table. It is particularly useful to show messages after a redirect.Whenever we want to display any kind of status message or error message "Your email id is updated" or "Invalid Password" etc, flash is used to store that message.
Rails loads the flash when we set it in your controller code and it is displayed in your view. Rails discards the value when it is rendered on the client. The Flash values set in either notice/error or any user defined message in the controller can be accessed in the views to display the result of the action taken place in the controller.

= Session in Ruby =
Most applications need to keep track of certain state of a particular user. Examples include shopping cart for online shopping account or the user id of the currently logged in user. Without the idea of sessions, the user would have to identify, and probably authenticate, on every request. Rails will create a new session automatically if a new user accesses the application. It will load an existing session if the user has already used the application.

A session usually consists of a hash of values and a session id, to identify the hash. Every cookie sent to the client’s browser includes the session id. And the other way round, the browser will send it to the server on every request from the client.

In Ruby session persists forever and is stored in the browser cookies by default. The session data can thus be deleted by clearing content of the cookies. Session is useful when we have to remember the state for a long time. Examples include Authentication where the user enters its login id and password that needs to be available for the complete session that the user is logged in. There are some alternative storage modes for session such as Storage table, No SQL data structure etc.<ref name="ref5"> http://www.tutorialspoint.com/ruby-on-rails/rails-session-cookies.htm/ </ref>

= How it works =

== Session ==
Session stores small amount of data that persists between requests. The session is only available in the controller and the view and can use one of a number of different storage mechanisms such as cookies, tables, cache, memcache etc.
The session stores session id in cookies as it is insecure when embedded in the url.This unique id is used to look up the session data on its storage locations such as cookies, database tables, no sql data structure, cache etc.The data storage in cookies by default makes the session lightweight and easy to access and it does not requires calls to the storage locations for accessing the session data. The cookies can store atmost 4 kb data and hence leads to cookie overflow exception if the data in the session exceeds the 4 kb limit.The cookie data is not encrypted but it cannot be edited as well though it is visible in the url. <ref name="ref1"> http://guides.rubyonrails.org/security.html#sessions/ </ref>
Session values are stored in a key,value pair.

1. To add a session attribute we say
session[:username]=params[:username].
Here we assign the username received from the user to the session variable.
2. To delete a session attribute value, just assign the key to nil.
eg: session[:username]=nil.
Here we are deleting the session attribute username.
3. The session can also be reset
reset_session
This will reset the complete session hash

== Flash ==

The flash is a special part of the session which is cleared with each request. This means that values stored there will only be available in the next request, which is useful for storing error messages etc. It is accessed in much the same way as the session, like a hash. Flash is used by the controller to pass messages to the view. The controller can pass messages about the success or failure of the desired action. In Ruby,we can also pass the flash message as part of the redirection informing the view about the state of the action performed when redirecting. The user can also pass user defined messages and also pass messages for debugging purposes.The layout that receives the flash has to decide the action to be performed on the basis of the message received from the flash.<ref name="ref4">http://guides.rubyonrails.org/action_controller_overview.html#the-flash </ref>

1. To set a flash value as a notice <ref name="ref3">http://pupeno.com/2009/11/19/ensuring-the-displaying-of-flash-messages-in-ruby-on-rails/ </ref>
flash[:notice]= "User logged in successfully"
The flash message sets the notice value. This flashes the notice on the form when the user successfully logs into the system.

2. To set a flash value as a warning <ref name="ref3">http://pupeno.com/2009/11/19/ensuring-the-displaying-of-flash-messages-in-ruby-on-rails/ </ref>
flash[:error]= "Please provide the username and password"
The flash message sets the error value. This automatically flashes the notice saying that the user did not provide the username and password.

3. To set flash message as part of redirection
redirect_to( posts_show, :notice => "Post successfully created" )
The above statement redirects the method call to the appropriate url and displays a notice there automatically saying the post was successfully
created.

4. The value of flash to be saved for the subsequent requests
flash.keep
The above statement keeps all values of flash, that resulted from the redirection, to be used in the subsequent requests.

5. The value of flash to be saved in the current request
flash.now
The above statement keeps the values of flash, that resulted from the redirection, to be used for the current request.

= Example - Session/Flash =

:Class ExamplesController < ApplicationController 
::def index
::'''session[:example_name]=params[:example][:name]'''
::...
::end
::def update
:::@example = Example.find(params[:id])
:::respond_to do |format|
::::if @example.update_attributes(params[:type])
:::::format.html {redirect_to(@example, '''flash[:notice] => 'Example was successfully updated.'''')}
::::else
:::::format.html { render :action => "edit" }
::::end
:::end
::end
::def
::....
::end
:end


'''In the show(@example) view, we can make use of session and flash as- '''

'''<%=notice%>'''
'''<%=session[:example_name]%>'''

In the above code, the ExampleController class has a index method that sets the session for the user and
update method sets the flash variable ,we set the session variable with the name of the example obtained from
the user stored in the params hash, we can access it in any view in that session.In the update method, flash is used to set
the notice to a desired value. Then it is used in the view to display the message.

= Advantages/Disadvantages =

== Session <ref name="ref6"> http://ruby.railstutorial.org/chapters/sign-in-sign-out#sec:sessions_controller </ref> ==

'''Session Advantages:'''


1.A session object helps us store useful information about the application like the session_id, currently logged in user details. 
2.It is similar to hash and helps us take advantages of the hash functionalities in Ruby. 
3.Since, it persists forever, the session variables can be used to perform authentication,server side validation and take care of the security aspects
of the application. 


'''Session Disadvantages:'''

1. The session object is a heavy weight object as it is used to store a lot of application related information. 
2. we have to be careful while dealing with session variables as it is subject to malicious attacks and sensitive information can be divulged if not
taken care of while programming. 
3. As the session variables persists forever, it is the programmers responsibility to reset the information of the application when the application goes
out of the current scope logically. 
4. Too many session variable manipulation and storage can make the code inefficient and can cause unexpected behaviour if not programmed carefully.


== Flash ==

'''Flash Advantages:'''

1. A lightweight object that helps us store the information of the state the application is in. 
2. Since flash is similar to hash, it helps us abuse the advantages of hash. 
3. Any key can be passed into the flash object and the user is responsible for extracting the information from the corresponding object 
4. It is less tedious to manage as its lifetime persists only until the next request. 


'''Disadvantages:'''

1. As the information stored in the flash object persists only until the next request, it is not useful for providing security related capabilities to
the application. 
2. It has limited capabilities and used for displaying simple error messages, notices or warnings in the application. 
3. It cannot store dynamic information. 


= Conclusion/Summary =

HTTP is a stateless protocol and the web applications require saving of the application state frequently. Based on the application state, certain actions are taken. This is possible in RUBY using redirection flash object. The redirection flash object persists for a short duration and helps us store simple information about the application. Another flash like object that provides us very rich capabilities in terms of information storge, authentication and security is the session object. We have seen the differences between the two. It is the programmers responsibility to appropriately use the flash or the session object depending on what needs to be achieved.

= References =
<references />

CSC/ECE 517 Fall 2012/ch1b 1w67 ks

2012-10-04T02:59:05Z

Knagar: /* Flash */

= Overview/Introduction =
 Redirection refers to redirection of incoming request from one page to another. HTTP is stateless, hence redirection with session/flash makes it stateful.As the http requests are stateless,it leads to losing the state of the previous request. Thus Rails provides hash called Flash which persist until the end of the next request received and Session hash, which unlike flash persists forever. <ref>http://www.youtube.com/watch?v=0m8lmRwS7E0</ref>.

= Flash in Ruby =
Flash in ruby helps to remember the state until the end of the next request. It is basically used to store error messages as warnings and information as notice in the hash. It is used in views to print the error messages or notice. Along with notice and warnings, we can also define user defined hash and print its value in the view as we did for the notice and warnings. Basically it helps in flashing messages on the views. It stores values in the form of hash table. It is particularly useful to show messages after a redirect.Whenever we want to display any kind of status message or error message "Your email id is updated" or "Invalid Password" etc, flash is used to store that message.
Rails loads the flash when we set it in your controller code and it is displayed in your view. Rails discards the value when it is rendered on the client. The Flash values set in either notice/error or any user defined message in the controller can be accessed in the views to display the result of the action taken place in the controller.

= Session in Ruby =
Most applications need to keep track of certain state of a particular user. Examples include shopping cart for online shopping account or the user id of the currently logged in user. Without the idea of sessions, the user would have to identify, and probably authenticate, on every request. Rails will create a new session automatically if a new user accesses the application. It will load an existing session if the user has already used the application.

A session usually consists of a hash of values and a session id, to identify the hash. Every cookie sent to the client’s browser includes the session id. And the other way round, the browser will send it to the server on every request from the client.

In Ruby session persists forever and is stored in the browser cookies by default. The session data can thus be deleted by clearing content of the cookies. Session is useful when we have to remember the state for a long time. Examples include Authentication where the user enters its login id and password that needs to be available for the complete session that the user is logged in. There are some alternative storage modes for session such as Storage table, No SQL data structure etc.<ref name="ref5"> http://www.tutorialspoint.com/ruby-on-rails/rails-session-cookies.htm/ </ref>

= How it works =

== Session ==
Session stores small amount of data that persists between requests. The session is only available in the controller and the view and can use one of a number of different storage mechanisms such as cookies, tables, cache, memcache etc.
The session stores session id in cookies as it is insecure when embedded in the url.This unique id is used to look up the session data on its storage locations such as cookies, database tables, no sql data structure, cache etc.The data storage in cookies by default makes the session lightweight and easy to access and it does not requires calls to the storage locations for accessing the session data. The cookies can store atmost 4 kb data and hence leads to cookie overflow exception if the data in the session exceeds the 4 kb limit.The cookie data is not encrypted but it cannot be edited as well though it is visible in the url. <ref name="ref1"> http://guides.rubyonrails.org/security.html#sessions/ </ref>
Session values are stored in a key,value pair.

1. To add a session attribute we say
session[:username]=params[:username].
Here we assign the username received from the user to the session variable.
2. To delete a session attribute value, just assign the key to nil.
eg: session[:username]=nil.
Here we are deleting the session attribute username.
3. The session can also be reset
reset_session
This will reset the complete session hash

== Flash ==

The flash is a special part of the session which is cleared with each request. This means that values stored there will only be available in the next request, which is useful for storing error messages etc. It is accessed in much the same way as the session, like a hash. Flash is used by the controller to pass messages to the view. The controller can pass messages about the success or failure of the desired action. In Ruby,we can also pass the flash message as part of the redirection informing the view about the state of the action performed when redirecting. The user can also pass user defined messages and also pass messages for debugging purposes.The layout that receives the flash has to decide the action to be performed on the basis of the message received from the flash.<ref name="ref4">http://guides.rubyonrails.org/action_controller_overview.html#the-flash </ref>

1. To set a flash value as a notice <ref name="ref3">http://pupeno.com/2009/11/19/ensuring-the-displaying-of-flash-messages-in-ruby-on-rails/ </ref>
flash[:notice]= "User logged in successfully"
The flash message sets the notice value. This flashes the notice on the form when the user successfully logs into the system.

2. To set a flash value as a warning <ref name="ref3">http://pupeno.com/2009/11/19/ensuring-the-displaying-of-flash-messages-in-ruby-on-rails/ </ref>
flash[:error]= "Please provide the username and password"
The flash message sets the error value. This automatically flashes the notice saying that the user did not provide the username and password.

3. To set flash message as part of redirection
redirect_to( posts_show, :notice => "Post successfully created" )
The above statement redirects the method call to the appropriate url and displays a notice there automatically saying the post was successfully
created.

4. The value of flash to be saved for the subsequent requests
flash.keep
The above statement keeps all values of flash, that resulted from the redirection, to be used in the subsequent requests.

5. The value of flash to be saved in the current request
flash.now
The above statement keeps the values of flash, that resulted from the redirection, to be used for the current request.

= Example - Session/Flash =

:Class ExamplesController < ApplicationController 
::def index
::'''session[:example_name]=params[:example][:name]'''
::...
::end
::def update
:::@example = Example.find(params[:id])
:::respond_to do |format|
::::if @example.update_attributes(params[:type])
:::::format.html {redirect_to(@example, '''flash[:notice] => 'Example was successfully updated.'''')}
::::else
:::::format.html { render :action => "edit" }
::::end
:::end
::end
::def
::....
::end
:end


'''In the show(@example) view, we can make use of session and flash as- '''

'''<%=notice%>'''
'''<%=session[:example_name]%>'''

In the above code, the ExampleController class has a index method that sets the session for the user and
update method that sets the flash variable ,we set the session variable with the name of the example obtained from
the user stored in the params hash, we can access it in any view in that session.In the update method, flash is used to set
the notice to a desired value. Then it is used in the view to display the message.

= Advantages/Disadvantages =

== Session <ref name="ref6"> http://ruby.railstutorial.org/chapters/sign-in-sign-out#sec:sessions_controller </ref> ==

'''Session Advantages:'''


1.A session object helps us store useful information about the application like the session_id, currently logged in user details. 
2.It is similar to hash and helps us take advantages of the hash functionalities in Ruby. 
3.Since, it persists forever, the session variables can be used to perform authentication,server side validation and take care of the security aspects
of the application. 


'''Session Disadvantages:'''

1. The session object is a heavy weight object as it is used to store a lot of application related information. 
2. we have to be careful while dealing with session variables as it is subject to malicious attacks and sensitive information can be divulged if not
taken care of while programming. 
3. As the session variables persists forever, it is the programmers responsibility to reset the information of the application when the application goes
out of the current scope logically. 
4. Too many session variable manipulation and storage can make the code inefficient and can cause unexpected behaviour if not programmed carefully.


== Flash ==

'''Flash Advantages:'''

1. A lightweight object that helps us store the information of the state the application is in. 
2. Since flash is similar to hash, it helps us abuse the advantages of hash. 
3. Any key can be passed into the flash object and the user is responsible for extracting the information from the corresponding object 
4. It is less tedious to manage as its lifetime persists only until the next request. 


'''Disadvantages:'''

1. As the information stored in the flash object persists only until the next request, it is not useful for providing security related capabilities to
the application. 
2. It has limited capabilities and used for displaying simple error messages, notices or warnings in the application. 
3. It cannot store dynamic information. 


= Conclusion/Summary =

HTTP is a stateless protocol and the web applications require saving of the application state frequently. Based on the application state, certain actions are taken. This is possible in RUBY using redirection flash object. The redirection flash object persists for a short duration and helps us store simple information about the application. Another flash like object that provides us very rich capabilities in terms of information storge, authentication and security is the session object. We have seen the differences between the two. It is the programmers responsibility to appropriately use the flash or the session object depending on what needs to be achieved.

= References =
<references />

CSC/ECE 517 Fall 2012/ch1b 1w67 ks

2012-10-04T02:56:32Z

Knagar: /* Session */

= Overview/Introduction =
 Redirection refers to redirection of incoming request from one page to another. HTTP is stateless, hence redirection with session/flash makes it stateful.As the http requests are stateless,it leads to losing the state of the previous request. Thus Rails provides hash called Flash which persist until the end of the next request received and Session hash, which unlike flash persists forever. <ref>http://www.youtube.com/watch?v=0m8lmRwS7E0</ref>.

= Flash in Ruby =
Flash in ruby helps to remember the state until the end of the next request. It is basically used to store error messages as warnings and information as notice in the hash. It is used in views to print the error messages or notice. Along with notice and warnings, we can also define user defined hash and print its value in the view as we did for the notice and warnings. Basically it helps in flashing messages on the views. It stores values in the form of hash table. It is particularly useful to show messages after a redirect.Whenever we want to display any kind of status message or error message "Your email id is updated" or "Invalid Password" etc, flash is used to store that message.
Rails loads the flash when we set it in your controller code and it is displayed in your view. Rails discards the value when it is rendered on the client. The Flash values set in either notice/error or any user defined message in the controller can be accessed in the views to display the result of the action taken place in the controller.

= Session in Ruby =
Most applications need to keep track of certain state of a particular user. Examples include shopping cart for online shopping account or the user id of the currently logged in user. Without the idea of sessions, the user would have to identify, and probably authenticate, on every request. Rails will create a new session automatically if a new user accesses the application. It will load an existing session if the user has already used the application.

A session usually consists of a hash of values and a session id, to identify the hash. Every cookie sent to the client’s browser includes the session id. And the other way round, the browser will send it to the server on every request from the client.

In Ruby session persists forever and is stored in the browser cookies by default. The session data can thus be deleted by clearing content of the cookies. Session is useful when we have to remember the state for a long time. Examples include Authentication where the user enters its login id and password that needs to be available for the complete session that the user is logged in. There are some alternative storage modes for session such as Storage table, No SQL data structure etc.<ref name="ref5"> http://www.tutorialspoint.com/ruby-on-rails/rails-session-cookies.htm/ </ref>

= How it works =

== Session ==
Session stores small amount of data that persists between requests. The session is only available in the controller and the view and can use one of a number of different storage mechanisms such as cookies, tables, cache, memcache etc.
The session stores session id in cookies as it is insecure when embedded in the url.This unique id is used to look up the session data on its storage locations such as cookies, database tables, no sql data structure, cache etc.The data storage in cookies by default makes the session lightweight and easy to access and it does not requires calls to the storage locations for accessing the session data. The cookies can store atmost 4 kb data and hence leads to cookie overflow exception if the data in the session exceeds the 4 kb limit.The cookie data is not encrypted but it cannot be edited as well though it is visible in the url. <ref name="ref1"> http://guides.rubyonrails.org/security.html#sessions/ </ref>
Session values are stored in a key,value pair.

1. To add a session attribute we say
session[:username]=params[:username].
Here we assign the username received from the user to the session variable.
2. To delete a session attribute value, just assign the key to nil.
eg: session[:username]=nil.
Here we are deleting the session attribute username.
3. The session can also be reset
reset_session
This will reset the complete session hash

== Flash ==

The flash is a special part of the session which is cleared with each request. This means that values stored there will only be available in the next request, which is useful for storing error messages etc. It is accessed in much the same way as the session, like a hash. Flash is used by the controller to pass messages to the view. The controller can pass messages about the success or failure of the desired action. In Ruby,w e can also pass the flash message as part of the redirection again informing the view about the state of the action performed when redirecting. The user can also pass user defined messages and also pass messages for debugging purposes. The flash message displayed on the form/view is now taken care by the next request. The layout that receives the flash has to decide the action to be performed on the basis of the message received from the flash.<ref name="ref4">http://guides.rubyonrails.org/action_controller_overview.html#the-flash </ref>

1. To set a flash value as a notice <ref name="ref3">http://pupeno.com/2009/11/19/ensuring-the-displaying-of-flash-messages-in-ruby-on-rails/ </ref>
flash[:notice]= "User logged in successfully"
The flash message sets the notice value. This flashes the notice on the form when the user successfully logs into the system.

2. To set a flash value as a warning <ref name="ref3">http://pupeno.com/2009/11/19/ensuring-the-displaying-of-flash-messages-in-ruby-on-rails/ </ref>
flash[:error]= "Please provide the username and password"
The flash message sets the error value. This automatically flashes the notice saying that the user did not provide the username and password.

3. To set flash message as part of redirection
redirect_to( posts_show, :notice => "Post successfully created" )
The above statement redirects the method call to the appropriate url and displays a notice there automatically saying the post was successfully
created.

4. The value of flash to be saved for the subsequent requests
flash.keep
The above statement keeps all values of flash, that resulted from the redirection, to be used in the subsequent requests.

5. The value of flash to be saved in the current request
flash.now
The above statement keeps the values of flash, that resulted from the redirection, to be used for the current request.

= Example - Session/Flash =

:Class ExamplesController < ApplicationController 
::def index
::'''session[:example_name]=params[:example][:name]'''
::...
::end
::def update
:::@example = Example.find(params[:id])
:::respond_to do |format|
::::if @example.update_attributes(params[:type])
:::::format.html {redirect_to(@example, '''flash[:notice] => 'Example was successfully updated.'''')}
::::else
:::::format.html { render :action => "edit" }
::::end
:::end
::end
::def
::....
::end
:end


'''In the show(@example) view, we can make use of session and flash as- '''

'''<%=notice%>'''
'''<%=session[:example_name]%>'''

In the above code, the ExampleController class has a index method that sets the session for the user and
update method that sets the flash variable ,we set the session variable with the name of the example obtained from
the user stored in the params hash, we can access it in any view in that session.In the update method, flash is used to set
the notice to a desired value. Then it is used in the view to display the message.

= Advantages/Disadvantages =

== Session <ref name="ref6"> http://ruby.railstutorial.org/chapters/sign-in-sign-out#sec:sessions_controller </ref> ==

'''Session Advantages:'''


1.A session object helps us store useful information about the application like the session_id, currently logged in user details. 
2.It is similar to hash and helps us take advantages of the hash functionalities in Ruby. 
3.Since, it persists forever, the session variables can be used to perform authentication,server side validation and take care of the security aspects
of the application. 


'''Session Disadvantages:'''

1. The session object is a heavy weight object as it is used to store a lot of application related information. 
2. we have to be careful while dealing with session variables as it is subject to malicious attacks and sensitive information can be divulged if not
taken care of while programming. 
3. As the session variables persists forever, it is the programmers responsibility to reset the information of the application when the application goes
out of the current scope logically. 
4. Too many session variable manipulation and storage can make the code inefficient and can cause unexpected behaviour if not programmed carefully.


== Flash ==

'''Flash Advantages:'''

1. A lightweight object that helps us store the information of the state the application is in. 
2. Since flash is similar to hash, it helps us abuse the advantages of hash. 
3. Any key can be passed into the flash object and the user is responsible for extracting the information from the corresponding object 
4. It is less tedious to manage as its lifetime persists only until the next request. 


'''Disadvantages:'''

1. As the information stored in the flash object persists only until the next request, it is not useful for providing security related capabilities to
the application. 
2. It has limited capabilities and used for displaying simple error messages, notices or warnings in the application. 
3. It cannot store dynamic information. 


= Conclusion/Summary =

HTTP is a stateless protocol and the web applications require saving of the application state frequently. Based on the application state, certain actions are taken. This is possible in RUBY using redirection flash object. The redirection flash object persists for a short duration and helps us store simple information about the application. Another flash like object that provides us very rich capabilities in terms of information storge, authentication and security is the session object. We have seen the differences between the two. It is the programmers responsibility to appropriately use the flash or the session object depending on what needs to be achieved.

= References =
<references />

CSC/ECE 517 Fall 2012/ch1b 1w67 ks

2012-10-04T02:53:49Z

Knagar: /* Session in Ruby */

= Overview/Introduction =
 Redirection refers to redirection of incoming request from one page to another. HTTP is stateless, hence redirection with session/flash makes it stateful.As the http requests are stateless,it leads to losing the state of the previous request. Thus Rails provides hash called Flash which persist until the end of the next request received and Session hash, which unlike flash persists forever. <ref>http://www.youtube.com/watch?v=0m8lmRwS7E0</ref>.

= Flash in Ruby =
Flash in ruby helps to remember the state until the end of the next request. It is basically used to store error messages as warnings and information as notice in the hash. It is used in views to print the error messages or notice. Along with notice and warnings, we can also define user defined hash and print its value in the view as we did for the notice and warnings. Basically it helps in flashing messages on the views. It stores values in the form of hash table. It is particularly useful to show messages after a redirect.Whenever we want to display any kind of status message or error message "Your email id is updated" or "Invalid Password" etc, flash is used to store that message.
Rails loads the flash when we set it in your controller code and it is displayed in your view. Rails discards the value when it is rendered on the client. The Flash values set in either notice/error or any user defined message in the controller can be accessed in the views to display the result of the action taken place in the controller.

= Session in Ruby =
Most applications need to keep track of certain state of a particular user. Examples include shopping cart for online shopping account or the user id of the currently logged in user. Without the idea of sessions, the user would have to identify, and probably authenticate, on every request. Rails will create a new session automatically if a new user accesses the application. It will load an existing session if the user has already used the application.

A session usually consists of a hash of values and a session id, to identify the hash. Every cookie sent to the client’s browser includes the session id. And the other way round, the browser will send it to the server on every request from the client.

In Ruby session persists forever and is stored in the browser cookies by default. The session data can thus be deleted by clearing content of the cookies. Session is useful when we have to remember the state for a long time. Examples include Authentication where the user enters its login id and password that needs to be available for the complete session that the user is logged in. There are some alternative storage modes for session such as Storage table, No SQL data structure etc.<ref name="ref5"> http://www.tutorialspoint.com/ruby-on-rails/rails-session-cookies.htm/ </ref>

= How it works =

== Session ==
Session stores small amount of data that persists between requests. The session is only available in the controller and the view and can use one of a number of different storage mechanisms such as cookies, tables, cache, memcache etc.
The session stores session id in cookies as it is insecure when embedded in the url.This unique id is used to look up the session data on its storage locations such as cookies, database tables, no sql data structure, cache etc.The data storage in cookies by default makes the session lightweight and easy to access and it does not requires calls to the storage locations for accessing the session data. The cookies can store atmost 4 kb data and hence gives cookie overflow exception if the data in the session exceeds the 4 kb limit.The cookie data is not encrypted but it cannot be edited by being visible in the url. <ref name="ref1"> http://guides.rubyonrails.org/security.html#sessions/ </ref>
Session values are stored in a key,value pair. In Ruby we store it like a hash.

1. To add a session attribute we say
session[:username]=params[:username].
Here we assign the username received from the user to the session variable.
2. To delete a session attribute value, just assign the key to nil.
eg: session[:username]=nil.
Here we are deleting the session attribute username.
3. The session can also be reset
reset_session
This will reset the complete session hash

== Flash ==

The flash is a special part of the session which is cleared with each request. This means that values stored there will only be available in the next request, which is useful for storing error messages etc. It is accessed in much the same way as the session, like a hash. Flash is used by the controller to pass messages to the view. The controller can pass messages about the success or failure of the desired action. In Ruby,w e can also pass the flash message as part of the redirection again informing the view about the state of the action performed when redirecting. The user can also pass user defined messages and also pass messages for debugging purposes. The flash message displayed on the form/view is now taken care by the next request. The layout that receives the flash has to decide the action to be performed on the basis of the message received from the flash.<ref name="ref4">http://guides.rubyonrails.org/action_controller_overview.html#the-flash </ref>

1. To set a flash value as a notice <ref name="ref3">http://pupeno.com/2009/11/19/ensuring-the-displaying-of-flash-messages-in-ruby-on-rails/ </ref>
flash[:notice]= "User logged in successfully"
The flash message sets the notice value. This flashes the notice on the form when the user successfully logs into the system.

2. To set a flash value as a warning <ref name="ref3">http://pupeno.com/2009/11/19/ensuring-the-displaying-of-flash-messages-in-ruby-on-rails/ </ref>
flash[:error]= "Please provide the username and password"
The flash message sets the error value. This automatically flashes the notice saying that the user did not provide the username and password.

3. To set flash message as part of redirection
redirect_to( posts_show, :notice => "Post successfully created" )
The above statement redirects the method call to the appropriate url and displays a notice there automatically saying the post was successfully
created.

4. The value of flash to be saved for the subsequent requests
flash.keep
The above statement keeps all values of flash, that resulted from the redirection, to be used in the subsequent requests.

5. The value of flash to be saved in the current request
flash.now
The above statement keeps the values of flash, that resulted from the redirection, to be used for the current request.

= Example - Session/Flash =

:Class ExamplesController < ApplicationController 
::def index
::'''session[:example_name]=params[:example][:name]'''
::...
::end
::def update
:::@example = Example.find(params[:id])
:::respond_to do |format|
::::if @example.update_attributes(params[:type])
:::::format.html {redirect_to(@example, '''flash[:notice] => 'Example was successfully updated.'''')}
::::else
:::::format.html { render :action => "edit" }
::::end
:::end
::end
::def
::....
::end
:end


'''In the show(@example) view, we can make use of session and flash as- '''

'''<%=notice%>'''
'''<%=session[:example_name]%>'''

In the above code, the ExampleController class has a index method that sets the session for the user and
update method that sets the flash variable ,we set the session variable with the name of the example obtained from
the user stored in the params hash, we can access it in any view in that session.In the update method, flash is used to set
the notice to a desired value. Then it is used in the view to display the message.

= Advantages/Disadvantages =

== Session <ref name="ref6"> http://ruby.railstutorial.org/chapters/sign-in-sign-out#sec:sessions_controller </ref> ==

'''Session Advantages:'''


1.A session object helps us store useful information about the application like the session_id, currently logged in user details. 
2.It is similar to hash and helps us take advantages of the hash functionalities in Ruby. 
3.Since, it persists forever, the session variables can be used to perform authentication,server side validation and take care of the security aspects
of the application. 


'''Session Disadvantages:'''

1. The session object is a heavy weight object as it is used to store a lot of application related information. 
2. we have to be careful while dealing with session variables as it is subject to malicious attacks and sensitive information can be divulged if not
taken care of while programming. 
3. As the session variables persists forever, it is the programmers responsibility to reset the information of the application when the application goes
out of the current scope logically. 
4. Too many session variable manipulation and storage can make the code inefficient and can cause unexpected behaviour if not programmed carefully.


== Flash ==

'''Flash Advantages:'''

1. A lightweight object that helps us store the information of the state the application is in. 
2. Since flash is similar to hash, it helps us abuse the advantages of hash. 
3. Any key can be passed into the flash object and the user is responsible for extracting the information from the corresponding object 
4. It is less tedious to manage as its lifetime persists only until the next request. 


'''Disadvantages:'''

1. As the information stored in the flash object persists only until the next request, it is not useful for providing security related capabilities to
the application. 
2. It has limited capabilities and used for displaying simple error messages, notices or warnings in the application. 
3. It cannot store dynamic information. 


= Conclusion/Summary =

HTTP is a stateless protocol and the web applications require saving of the application state frequently. Based on the application state, certain actions are taken. This is possible in RUBY using redirection flash object. The redirection flash object persists for a short duration and helps us store simple information about the application. Another flash like object that provides us very rich capabilities in terms of information storge, authentication and security is the session object. We have seen the differences between the two. It is the programmers responsibility to appropriately use the flash or the session object depending on what needs to be achieved.

= References =
<references />

CSC/ECE 517 Fall 2012/ch1b 1w67 ks

2012-10-04T02:52:12Z

Knagar: /* Flash in Ruby */

= Overview/Introduction =
 Redirection refers to redirection of incoming request from one page to another. HTTP is stateless, hence redirection with session/flash makes it stateful.As the http requests are stateless,it leads to losing the state of the previous request. Thus Rails provides hash called Flash which persist until the end of the next request received and Session hash, which unlike flash persists forever. <ref>http://www.youtube.com/watch?v=0m8lmRwS7E0</ref>.

= Flash in Ruby =
Flash in ruby helps to remember the state until the end of the next request. It is basically used to store error messages as warnings and information as notice in the hash. It is used in views to print the error messages or notice. Along with notice and warnings, we can also define user defined hash and print its value in the view as we did for the notice and warnings. Basically it helps in flashing messages on the views. It stores values in the form of hash table. It is particularly useful to show messages after a redirect.Whenever we want to display any kind of status message or error message "Your email id is updated" or "Invalid Password" etc, flash is used to store that message.
Rails loads the flash when we set it in your controller code and it is displayed in your view. Rails discards the value when it is rendered on the client. The Flash values set in either notice/error or any user defined message in the controller can be accessed in the views to display the result of the action taken place in the controller.

= Session in Ruby =
Most applications need to keep track of certain state of a particular user. Examples include shopping cart for online shopping account or the user id of the currently logged in user. Without the idea of sessions, the user would have to identify, and probably authenticate, on every request. Rails will create a new session automatically if a new user accesses the application. It will load an existing session if the user has already used the application.

A session usually consists of a hash of values and a session id, usually a 32-character string, to identify the hash. Every cookie sent to the client’s browser includes the session id. And the other way round, the browser will send it to the server on every request from the client.

In Ruby session persists forever and is stored in the browser cookies by default. The session data can thus be deleted by clearing content of the cookies. Session is useful when we have to remember the state for a long time. Examples include Authentication where the user enters its login id and password that needs to be available for the whole session that the user is logged in. There are some alternative storage modes for session such as Storage table or No SQL data structure.<ref name="ref5"> http://www.tutorialspoint.com/ruby-on-rails/rails-session-cookies.htm/ </ref>

= How it works =

== Session ==
Session stores small amount of data that persists between requests. The session is only available in the controller and the view and can use one of a number of different storage mechanisms such as cookies, tables, cache, memcache etc.
The session stores session id in cookies as it is insecure when embedded in the url.This unique id is used to look up the session data on its storage locations such as cookies, database tables, no sql data structure, cache etc.The data storage in cookies by default makes the session lightweight and easy to access and it does not requires calls to the storage locations for accessing the session data. The cookies can store atmost 4 kb data and hence gives cookie overflow exception if the data in the session exceeds the 4 kb limit.The cookie data is not encrypted but it cannot be edited by being visible in the url. <ref name="ref1"> http://guides.rubyonrails.org/security.html#sessions/ </ref>
Session values are stored in a key,value pair. In Ruby we store it like a hash.

1. To add a session attribute we say
session[:username]=params[:username].
Here we assign the username received from the user to the session variable.
2. To delete a session attribute value, just assign the key to nil.
eg: session[:username]=nil.
Here we are deleting the session attribute username.
3. The session can also be reset
reset_session
This will reset the complete session hash

== Flash ==

The flash is a special part of the session which is cleared with each request. This means that values stored there will only be available in the next request, which is useful for storing error messages etc. It is accessed in much the same way as the session, like a hash. Flash is used by the controller to pass messages to the view. The controller can pass messages about the success or failure of the desired action. In Ruby,w e can also pass the flash message as part of the redirection again informing the view about the state of the action performed when redirecting. The user can also pass user defined messages and also pass messages for debugging purposes. The flash message displayed on the form/view is now taken care by the next request. The layout that receives the flash has to decide the action to be performed on the basis of the message received from the flash.<ref name="ref4">http://guides.rubyonrails.org/action_controller_overview.html#the-flash </ref>

1. To set a flash value as a notice <ref name="ref3">http://pupeno.com/2009/11/19/ensuring-the-displaying-of-flash-messages-in-ruby-on-rails/ </ref>
flash[:notice]= "User logged in successfully"
The flash message sets the notice value. This flashes the notice on the form when the user successfully logs into the system.

2. To set a flash value as a warning <ref name="ref3">http://pupeno.com/2009/11/19/ensuring-the-displaying-of-flash-messages-in-ruby-on-rails/ </ref>
flash[:error]= "Please provide the username and password"
The flash message sets the error value. This automatically flashes the notice saying that the user did not provide the username and password.

3. To set flash message as part of redirection
redirect_to( posts_show, :notice => "Post successfully created" )
The above statement redirects the method call to the appropriate url and displays a notice there automatically saying the post was successfully
created.

4. The value of flash to be saved for the subsequent requests
flash.keep
The above statement keeps all values of flash, that resulted from the redirection, to be used in the subsequent requests.

5. The value of flash to be saved in the current request
flash.now
The above statement keeps the values of flash, that resulted from the redirection, to be used for the current request.

= Example - Session/Flash =

:Class ExamplesController < ApplicationController 
::def index
::'''session[:example_name]=params[:example][:name]'''
::...
::end
::def update
:::@example = Example.find(params[:id])
:::respond_to do |format|
::::if @example.update_attributes(params[:type])
:::::format.html {redirect_to(@example, '''flash[:notice] => 'Example was successfully updated.'''')}
::::else
:::::format.html { render :action => "edit" }
::::end
:::end
::end
::def
::....
::end
:end


'''In the show(@example) view, we can make use of session and flash as- '''

'''<%=notice%>'''
'''<%=session[:example_name]%>'''

In the above code, the ExampleController class has a index method that sets the session for the user and
update method that sets the flash variable ,we set the session variable with the name of the example obtained from
the user stored in the params hash, we can access it in any view in that session.In the update method, flash is used to set
the notice to a desired value. Then it is used in the view to display the message.

= Advantages/Disadvantages =

== Session <ref name="ref6"> http://ruby.railstutorial.org/chapters/sign-in-sign-out#sec:sessions_controller </ref> ==

'''Session Advantages:'''


1.A session object helps us store useful information about the application like the session_id, currently logged in user details. 
2.It is similar to hash and helps us take advantages of the hash functionalities in Ruby. 
3.Since, it persists forever, the session variables can be used to perform authentication,server side validation and take care of the security aspects
of the application. 


'''Session Disadvantages:'''

1. The session object is a heavy weight object as it is used to store a lot of application related information. 
2. we have to be careful while dealing with session variables as it is subject to malicious attacks and sensitive information can be divulged if not
taken care of while programming. 
3. As the session variables persists forever, it is the programmers responsibility to reset the information of the application when the application goes
out of the current scope logically. 
4. Too many session variable manipulation and storage can make the code inefficient and can cause unexpected behaviour if not programmed carefully.


== Flash ==

'''Flash Advantages:'''

1. A lightweight object that helps us store the information of the state the application is in. 
2. Since flash is similar to hash, it helps us abuse the advantages of hash. 
3. Any key can be passed into the flash object and the user is responsible for extracting the information from the corresponding object 
4. It is less tedious to manage as its lifetime persists only until the next request. 


'''Disadvantages:'''

1. As the information stored in the flash object persists only until the next request, it is not useful for providing security related capabilities to
the application. 
2. It has limited capabilities and used for displaying simple error messages, notices or warnings in the application. 
3. It cannot store dynamic information. 


= Conclusion/Summary =

HTTP is a stateless protocol and the web applications require saving of the application state frequently. Based on the application state, certain actions are taken. This is possible in RUBY using redirection flash object. The redirection flash object persists for a short duration and helps us store simple information about the application. Another flash like object that provides us very rich capabilities in terms of information storge, authentication and security is the session object. We have seen the differences between the two. It is the programmers responsibility to appropriately use the flash or the session object depending on what needs to be achieved.

= References =
<references />

CSC/ECE 517 Fall 2012/ch1b 1w67 ks

2012-10-04T02:49:47Z

Knagar: /* Overview/Introduction */

= Overview/Introduction =
 Redirection refers to redirection of incoming request from one page to another. HTTP is stateless, hence redirection with session/flash makes it stateful.As the http requests are stateless,it leads to losing the state of the previous request. Thus Rails provides hash called Flash which persist until the end of the next request received and Session hash, which unlike flash persists forever. <ref>http://www.youtube.com/watch?v=0m8lmRwS7E0</ref>.

= Flash in Ruby =
Flash in ruby helps to remember the state until the end of the next request. It is basically used to store error messages as warnings and information as notice in the hash. This is used in views to print the error messages or notice. Instead of notice or warnings, we can define user defined hash and print its value in the view as we did for the notice and warnings. Basically it helps in flashing messages on the views. It stores values in the form of hash table. It is particularly useful to show messages after a redirect.Whenever you want to display any kind of status message or error message "Your email id is updated" or "Invalid Password" etc.
Rails loads it when you set it in your controller code and it is displayed in your view (if you have it set to display in the view). Rails discards the value when it is rendered on the client. The Flash values set in either notice/error or any user defined message in the controller can be accessed in the views to display the result of the action taken place in the controller.

= Session in Ruby =
Most applications need to keep track of certain state of a particular user. Examples include shopping cart for online shopping account or the user id of the currently logged in user. Without the idea of sessions, the user would have to identify, and probably authenticate, on every request. Rails will create a new session automatically if a new user accesses the application. It will load an existing session if the user has already used the application.

A session usually consists of a hash of values and a session id, usually a 32-character string, to identify the hash. Every cookie sent to the client’s browser includes the session id. And the other way round, the browser will send it to the server on every request from the client.

In Ruby session persists forever and is stored in the browser cookies by default. The session data can thus be deleted by clearing content of the cookies. Session is useful when we have to remember the state for a long time. Examples include Authentication where the user enters its login id and password that needs to be available for the whole session that the user is logged in. There are some alternative storage modes for session such as Storage table or No SQL data structure.<ref name="ref5"> http://www.tutorialspoint.com/ruby-on-rails/rails-session-cookies.htm/ </ref>

= How it works =

== Session ==
Session stores small amount of data that persists between requests. The session is only available in the controller and the view and can use one of a number of different storage mechanisms such as cookies, tables, cache, memcache etc.
The session stores session id in cookies as it is insecure when embedded in the url.This unique id is used to look up the session data on its storage locations such as cookies, database tables, no sql data structure, cache etc.The data storage in cookies by default makes the session lightweight and easy to access and it does not requires calls to the storage locations for accessing the session data. The cookies can store atmost 4 kb data and hence gives cookie overflow exception if the data in the session exceeds the 4 kb limit.The cookie data is not encrypted but it cannot be edited by being visible in the url. <ref name="ref1"> http://guides.rubyonrails.org/security.html#sessions/ </ref>
Session values are stored in a key,value pair. In Ruby we store it like a hash.

1. To add a session attribute we say
session[:username]=params[:username].
Here we assign the username received from the user to the session variable.
2. To delete a session attribute value, just assign the key to nil.
eg: session[:username]=nil.
Here we are deleting the session attribute username.
3. The session can also be reset
reset_session
This will reset the complete session hash

== Flash ==

The flash is a special part of the session which is cleared with each request. This means that values stored there will only be available in the next request, which is useful for storing error messages etc. It is accessed in much the same way as the session, like a hash. Flash is used by the controller to pass messages to the view. The controller can pass messages about the success or failure of the desired action. In Ruby,w e can also pass the flash message as part of the redirection again informing the view about the state of the action performed when redirecting. The user can also pass user defined messages and also pass messages for debugging purposes. The flash message displayed on the form/view is now taken care by the next request. The layout that receives the flash has to decide the action to be performed on the basis of the message received from the flash.<ref name="ref4">http://guides.rubyonrails.org/action_controller_overview.html#the-flash </ref>

1. To set a flash value as a notice <ref name="ref3">http://pupeno.com/2009/11/19/ensuring-the-displaying-of-flash-messages-in-ruby-on-rails/ </ref>
flash[:notice]= "User logged in successfully"
The flash message sets the notice value. This flashes the notice on the form when the user successfully logs into the system.

2. To set a flash value as a warning <ref name="ref3">http://pupeno.com/2009/11/19/ensuring-the-displaying-of-flash-messages-in-ruby-on-rails/ </ref>
flash[:error]= "Please provide the username and password"
The flash message sets the error value. This automatically flashes the notice saying that the user did not provide the username and password.

3. To set flash message as part of redirection
redirect_to( posts_show, :notice => "Post successfully created" )
The above statement redirects the method call to the appropriate url and displays a notice there automatically saying the post was successfully
created.

4. The value of flash to be saved for the subsequent requests
flash.keep
The above statement keeps all values of flash, that resulted from the redirection, to be used in the subsequent requests.

5. The value of flash to be saved in the current request
flash.now
The above statement keeps the values of flash, that resulted from the redirection, to be used for the current request.

= Example - Session/Flash =

:Class ExamplesController < ApplicationController 
::def index
::'''session[:example_name]=params[:example][:name]'''
::...
::end
::def update
:::@example = Example.find(params[:id])
:::respond_to do |format|
::::if @example.update_attributes(params[:type])
:::::format.html {redirect_to(@example, '''flash[:notice] => 'Example was successfully updated.'''')}
::::else
:::::format.html { render :action => "edit" }
::::end
:::end
::end
::def
::....
::end
:end


'''In the show(@example) view, we can make use of session and flash as- '''

'''<%=notice%>'''
'''<%=session[:example_name]%>'''

In the above code, the ExampleController class has a index method that sets the session for the user and
update method that sets the flash variable ,we set the session variable with the name of the example obtained from
the user stored in the params hash, we can access it in any view in that session.In the update method, flash is used to set
the notice to a desired value. Then it is used in the view to display the message.

= Advantages/Disadvantages =

== Session <ref name="ref6"> http://ruby.railstutorial.org/chapters/sign-in-sign-out#sec:sessions_controller </ref> ==

'''Session Advantages:'''


1.A session object helps us store useful information about the application like the session_id, currently logged in user details. 
2.It is similar to hash and helps us take advantages of the hash functionalities in Ruby. 
3.Since, it persists forever, the session variables can be used to perform authentication,server side validation and take care of the security aspects
of the application. 


'''Session Disadvantages:'''

1. The session object is a heavy weight object as it is used to store a lot of application related information. 
2. we have to be careful while dealing with session variables as it is subject to malicious attacks and sensitive information can be divulged if not
taken care of while programming. 
3. As the session variables persists forever, it is the programmers responsibility to reset the information of the application when the application goes
out of the current scope logically. 
4. Too many session variable manipulation and storage can make the code inefficient and can cause unexpected behaviour if not programmed carefully.


== Flash ==

'''Flash Advantages:'''

1. A lightweight object that helps us store the information of the state the application is in. 
2. Since flash is similar to hash, it helps us abuse the advantages of hash. 
3. Any key can be passed into the flash object and the user is responsible for extracting the information from the corresponding object 
4. It is less tedious to manage as its lifetime persists only until the next request. 


'''Disadvantages:'''

1. As the information stored in the flash object persists only until the next request, it is not useful for providing security related capabilities to
the application. 
2. It has limited capabilities and used for displaying simple error messages, notices or warnings in the application. 
3. It cannot store dynamic information. 


= Conclusion/Summary =

HTTP is a stateless protocol and the web applications require saving of the application state frequently. Based on the application state, certain actions are taken. This is possible in RUBY using redirection flash object. The redirection flash object persists for a short duration and helps us store simple information about the application. Another flash like object that provides us very rich capabilities in terms of information storge, authentication and security is the session object. We have seen the differences between the two. It is the programmers responsibility to appropriately use the flash or the session object depending on what needs to be achieved.

= References =
<references />

CSC/ECE 517 Fall 2012/ch1b 1w67 ks

2012-10-04T02:49:25Z

Knagar: /* Overview/Introduction */

= Overview/Introduction =
 Redirection refers to redirection of incoming request from one page to another. HTTP is stateless, hence redirection with session/flash makes it stateful.As the http requests are stateless,it leads to losing the state of the previous request. Thus Rails provides hash called Flash which persist until the end of the next request received and Session hash, which unlike flash persists forever. <ref>http://www.youtube.com/watch?v=0m8lmRwS7E0</ref>.

For information on how to format the text of your article, create tables, and use section headings and references, see this [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/WIKI_Features article].

= Flash in Ruby =
Flash in ruby helps to remember the state until the end of the next request. It is basically used to store error messages as warnings and information as notice in the hash. This is used in views to print the error messages or notice. Instead of notice or warnings, we can define user defined hash and print its value in the view as we did for the notice and warnings. Basically it helps in flashing messages on the views. It stores values in the form of hash table. It is particularly useful to show messages after a redirect.Whenever you want to display any kind of status message or error message "Your email id is updated" or "Invalid Password" etc.
Rails loads it when you set it in your controller code and it is displayed in your view (if you have it set to display in the view). Rails discards the value when it is rendered on the client. The Flash values set in either notice/error or any user defined message in the controller can be accessed in the views to display the result of the action taken place in the controller.

= Session in Ruby =
Most applications need to keep track of certain state of a particular user. Examples include shopping cart for online shopping account or the user id of the currently logged in user. Without the idea of sessions, the user would have to identify, and probably authenticate, on every request. Rails will create a new session automatically if a new user accesses the application. It will load an existing session if the user has already used the application.

A session usually consists of a hash of values and a session id, usually a 32-character string, to identify the hash. Every cookie sent to the client’s browser includes the session id. And the other way round, the browser will send it to the server on every request from the client.

In Ruby session persists forever and is stored in the browser cookies by default. The session data can thus be deleted by clearing content of the cookies. Session is useful when we have to remember the state for a long time. Examples include Authentication where the user enters its login id and password that needs to be available for the whole session that the user is logged in. There are some alternative storage modes for session such as Storage table or No SQL data structure.<ref name="ref5"> http://www.tutorialspoint.com/ruby-on-rails/rails-session-cookies.htm/ </ref>

= How it works =

== Session ==
Session stores small amount of data that persists between requests. The session is only available in the controller and the view and can use one of a number of different storage mechanisms such as cookies, tables, cache, memcache etc.
The session stores session id in cookies as it is insecure when embedded in the url.This unique id is used to look up the session data on its storage locations such as cookies, database tables, no sql data structure, cache etc.The data storage in cookies by default makes the session lightweight and easy to access and it does not requires calls to the storage locations for accessing the session data. The cookies can store atmost 4 kb data and hence gives cookie overflow exception if the data in the session exceeds the 4 kb limit.The cookie data is not encrypted but it cannot be edited by being visible in the url. <ref name="ref1"> http://guides.rubyonrails.org/security.html#sessions/ </ref>
Session values are stored in a key,value pair. In Ruby we store it like a hash.

1. To add a session attribute we say
session[:username]=params[:username].
Here we assign the username received from the user to the session variable.
2. To delete a session attribute value, just assign the key to nil.
eg: session[:username]=nil.
Here we are deleting the session attribute username.
3. The session can also be reset
reset_session
This will reset the complete session hash

== Flash ==

The flash is a special part of the session which is cleared with each request. This means that values stored there will only be available in the next request, which is useful for storing error messages etc. It is accessed in much the same way as the session, like a hash. Flash is used by the controller to pass messages to the view. The controller can pass messages about the success or failure of the desired action. In Ruby,w e can also pass the flash message as part of the redirection again informing the view about the state of the action performed when redirecting. The user can also pass user defined messages and also pass messages for debugging purposes. The flash message displayed on the form/view is now taken care by the next request. The layout that receives the flash has to decide the action to be performed on the basis of the message received from the flash.<ref name="ref4">http://guides.rubyonrails.org/action_controller_overview.html#the-flash </ref>

1. To set a flash value as a notice <ref name="ref3">http://pupeno.com/2009/11/19/ensuring-the-displaying-of-flash-messages-in-ruby-on-rails/ </ref>
flash[:notice]= "User logged in successfully"
The flash message sets the notice value. This flashes the notice on the form when the user successfully logs into the system.

2. To set a flash value as a warning <ref name="ref3">http://pupeno.com/2009/11/19/ensuring-the-displaying-of-flash-messages-in-ruby-on-rails/ </ref>
flash[:error]= "Please provide the username and password"
The flash message sets the error value. This automatically flashes the notice saying that the user did not provide the username and password.

3. To set flash message as part of redirection
redirect_to( posts_show, :notice => "Post successfully created" )
The above statement redirects the method call to the appropriate url and displays a notice there automatically saying the post was successfully
created.

4. The value of flash to be saved for the subsequent requests
flash.keep
The above statement keeps all values of flash, that resulted from the redirection, to be used in the subsequent requests.

5. The value of flash to be saved in the current request
flash.now
The above statement keeps the values of flash, that resulted from the redirection, to be used for the current request.

= Example - Session/Flash =

:Class ExamplesController < ApplicationController 
::def index
::'''session[:example_name]=params[:example][:name]'''
::...
::end
::def update
:::@example = Example.find(params[:id])
:::respond_to do |format|
::::if @example.update_attributes(params[:type])
:::::format.html {redirect_to(@example, '''flash[:notice] => 'Example was successfully updated.'''')}
::::else
:::::format.html { render :action => "edit" }
::::end
:::end
::end
::def
::....
::end
:end


'''In the show(@example) view, we can make use of session and flash as- '''

'''<%=notice%>'''
'''<%=session[:example_name]%>'''

In the above code, the ExampleController class has a index method that sets the session for the user and
update method that sets the flash variable ,we set the session variable with the name of the example obtained from
the user stored in the params hash, we can access it in any view in that session.In the update method, flash is used to set
the notice to a desired value. Then it is used in the view to display the message.

= Advantages/Disadvantages =

== Session <ref name="ref6"> http://ruby.railstutorial.org/chapters/sign-in-sign-out#sec:sessions_controller </ref> ==

'''Session Advantages:'''


1.A session object helps us store useful information about the application like the session_id, currently logged in user details. 
2.It is similar to hash and helps us take advantages of the hash functionalities in Ruby. 
3.Since, it persists forever, the session variables can be used to perform authentication,server side validation and take care of the security aspects
of the application. 


'''Session Disadvantages:'''

1. The session object is a heavy weight object as it is used to store a lot of application related information. 
2. we have to be careful while dealing with session variables as it is subject to malicious attacks and sensitive information can be divulged if not
taken care of while programming. 
3. As the session variables persists forever, it is the programmers responsibility to reset the information of the application when the application goes
out of the current scope logically. 
4. Too many session variable manipulation and storage can make the code inefficient and can cause unexpected behaviour if not programmed carefully.


== Flash ==

'''Flash Advantages:'''

1. A lightweight object that helps us store the information of the state the application is in. 
2. Since flash is similar to hash, it helps us abuse the advantages of hash. 
3. Any key can be passed into the flash object and the user is responsible for extracting the information from the corresponding object 
4. It is less tedious to manage as its lifetime persists only until the next request. 


'''Disadvantages:'''

1. As the information stored in the flash object persists only until the next request, it is not useful for providing security related capabilities to
the application. 
2. It has limited capabilities and used for displaying simple error messages, notices or warnings in the application. 
3. It cannot store dynamic information. 


= Conclusion/Summary =

HTTP is a stateless protocol and the web applications require saving of the application state frequently. Based on the application state, certain actions are taken. This is possible in RUBY using redirection flash object. The redirection flash object persists for a short duration and helps us store simple information about the application. Another flash like object that provides us very rich capabilities in terms of information storge, authentication and security is the session object. We have seen the differences between the two. It is the programmers responsibility to appropriately use the flash or the session object depending on what needs to be achieved.

= References =
<references />

CSC/ECE 517 Fall 2012/ch1b 1w67 ks

2012-10-04T02:44:29Z

Knagar: /* References */

= Overview/Introduction =
 Redirection in ruby refers to the where a user is redirected from one page to another. HTTP is stateless, hence session/flash makes it stateful.As the http requests are stateless, hence this leads to losing all the state that we had before. Thus Rails provides a hash called Flash such that it persists until the end of the next request received.
Also there is a session hash, which unlike flash persists forever. <ref>http://www.youtube.com/watch?v=0m8lmRwS7E0</ref>.

For information on how to format the text of your article, create tables, and use section headings and references, see this [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/WIKI_Features article].

= Flash in Ruby =
Flash in ruby helps to remember the state until the end of the next request. It is basically used to store error messages as warnings and information as notice in the hash. This is used in views to print the error messages or notice. Instead of notice or warnings, we can define user defined hash and print its value in the view as we did for the notice and warnings. Basically it helps in flashing messages on the views. It stores values in the form of hash table. It is particularly useful to show messages after a redirect.Whenever you want to display any kind of status message or error message "Your email id is updated" or "Invalid Password" etc.
Rails loads it when you set it in your controller code and it is displayed in your view (if you have it set to display in the view). Rails discards the value when it is rendered on the client. The Flash values set in either notice/error or any user defined message in the controller can be accessed in the views to display the result of the action taken place in the controller.

= Session in Ruby =
Most applications need to keep track of certain state of a particular user. Examples include shopping cart for online shopping account or the user id of the currently logged in user. Without the idea of sessions, the user would have to identify, and probably authenticate, on every request. Rails will create a new session automatically if a new user accesses the application. It will load an existing session if the user has already used the application.

A session usually consists of a hash of values and a session id, usually a 32-character string, to identify the hash. Every cookie sent to the client’s browser includes the session id. And the other way round, the browser will send it to the server on every request from the client.

In Ruby session persists forever and is stored in the browser cookies by default. The session data can thus be deleted by clearing content of the cookies. Session is useful when we have to remember the state for a long time. Examples include Authentication where the user enters its login id and password that needs to be available for the whole session that the user is logged in. There are some alternative storage modes for session such as Storage table or No SQL data structure.<ref name="ref5"> http://www.tutorialspoint.com/ruby-on-rails/rails-session-cookies.htm/ </ref>

= How it works =

== Session ==
Session stores small amount of data that persists between requests. The session is only available in the controller and the view and can use one of a number of different storage mechanisms such as cookies, tables, cache, memcache etc.
The session stores session id in cookies as it is insecure when embedded in the url.This unique id is used to look up the session data on its storage locations such as cookies, database tables, no sql data structure, cache etc.The data storage in cookies by default makes the session lightweight and easy to access and it does not requires calls to the storage locations for accessing the session data. The cookies can store atmost 4 kb data and hence gives cookie overflow exception if the data in the session exceeds the 4 kb limit.The cookie data is not encrypted but it cannot be edited by being visible in the url. <ref name="ref1"> http://guides.rubyonrails.org/security.html#sessions/ </ref>
Session values are stored in a key,value pair. In Ruby we store it like a hash.

1. To add a session attribute we say
session[:username]=params[:username].
Here we assign the username received from the user to the session variable.
2. To delete a session attribute value, just assign the key to nil.
eg: session[:username]=nil.
Here we are deleting the session attribute username.
3. The session can also be reset
reset_session
This will reset the complete session hash

== Flash ==

The flash is a special part of the session which is cleared with each request. This means that values stored there will only be available in the next request, which is useful for storing error messages etc. It is accessed in much the same way as the session, like a hash. Flash is used by the controller to pass messages to the view. The controller can pass messages about the success or failure of the desired action. In Ruby,w e can also pass the flash message as part of the redirection again informing the view about the state of the action performed when redirecting. The user can also pass user defined messages and also pass messages for debugging purposes. The flash message displayed on the form/view is now taken care by the next request. The layout that receives the flash has to decide the action to be performed on the basis of the message received from the flash.<ref name="ref4">http://guides.rubyonrails.org/action_controller_overview.html#the-flash </ref>

1. To set a flash value as a notice <ref name="ref3">http://pupeno.com/2009/11/19/ensuring-the-displaying-of-flash-messages-in-ruby-on-rails/ </ref>
flash[:notice]= "User logged in successfully"
The flash message sets the notice value. This flashes the notice on the form when the user successfully logs into the system.

2. To set a flash value as a warning <ref name="ref3">http://pupeno.com/2009/11/19/ensuring-the-displaying-of-flash-messages-in-ruby-on-rails/ </ref>
flash[:error]= "Please provide the username and password"
The flash message sets the error value. This automatically flashes the notice saying that the user did not provide the username and password.

3. To set flash message as part of redirection
redirect_to( posts_show, :notice => "Post successfully created" )
The above statement redirects the method call to the appropriate url and displays a notice there automatically saying the post was successfully
created.

4. The value of flash to be saved for the subsequent requests
flash.keep
The above statement keeps all values of flash, that resulted from the redirection, to be used in the subsequent requests.

5. The value of flash to be saved in the current request
flash.now
The above statement keeps the values of flash, that resulted from the redirection, to be used for the current request.

= Example - Session/Flash =

:Class ExamplesController < ApplicationController 
::def index
::'''session[:example_name]=params[:example][:name]'''
::...
::end
::def update
:::@example = Example.find(params[:id])
:::respond_to do |format|
::::if @example.update_attributes(params[:type])
:::::format.html {redirect_to(@example, '''flash[:notice] => 'Example was successfully updated.'''')}
::::else
:::::format.html { render :action => "edit" }
::::end
:::end
::end
::def
::....
::end
:end


'''In the show(@example) view, we can make use of session and flash as- '''

'''<%=notice%>'''
'''<%=session[:example_name]%>'''

In the above code, the ExampleController class has a index method that sets the session for the user and
update method that sets the flash variable ,we set the session variable with the name of the example obtained from
the user stored in the params hash, we can access it in any view in that session.In the update method, flash is used to set
the notice to a desired value. Then it is used in the view to display the message.

= Advantages/Disadvantages =

== Session <ref name="ref6"> http://ruby.railstutorial.org/chapters/sign-in-sign-out#sec:sessions_controller </ref> ==

'''Session Advantages:'''


1.A session object helps us store useful information about the application like the session_id, currently logged in user details. 
2.It is similar to hash and helps us take advantages of the hash functionalities in Ruby. 
3.Since, it persists forever, the session variables can be used to perform authentication,server side validation and take care of the security aspects
of the application. 


'''Session Disadvantages:'''

1. The session object is a heavy weight object as it is used to store a lot of application related information. 
2. we have to be careful while dealing with session variables as it is subject to malicious attacks and sensitive information can be divulged if not
taken care of while programming. 
3. As the session variables persists forever, it is the programmers responsibility to reset the information of the application when the application goes
out of the current scope logically. 
4. Too many session variable manipulation and storage can make the code inefficient and can cause unexpected behaviour if not programmed carefully.


== Flash ==

'''Flash Advantages:'''

1. A lightweight object that helps us store the information of the state the application is in. 
2. Since flash is similar to hash, it helps us abuse the advantages of hash. 
3. Any key can be passed into the flash object and the user is responsible for extracting the information from the corresponding object 
4. It is less tedious to manage as its lifetime persists only until the next request. 


'''Disadvantages:'''

1. As the information stored in the flash object persists only until the next request, it is not useful for providing security related capabilities to
the application. 
2. It has limited capabilities and used for displaying simple error messages, notices or warnings in the application. 
3. It cannot store dynamic information. 


= Conclusion/Summary =

HTTP is a stateless protocol and the web applications require saving of the application state frequently. Based on the application state, certain actions are taken. This is possible in RUBY using redirection flash object. The redirection flash object persists for a short duration and helps us store simple information about the application. Another flash like object that provides us very rich capabilities in terms of information storge, authentication and security is the session object. We have seen the differences between the two. It is the programmers responsibility to appropriately use the flash or the session object depending on what needs to be achieved.

= References =
<references />

CSC/ECE 517 Fall 2012/ch1b 1w67 ks

2012-10-04T02:44:12Z

Knagar: /* Session */

CSC/ECE 517 Fall 2012/ch1b 1w67 ks

2012-10-04T02:42:59Z

Knagar: /* References */

= Overview/Introduction =
 Redirection in ruby refers to the where a user is redirected from one page to another. HTTP is stateless, hence session/flash makes it stateful.As the http requests are stateless, hence this leads to losing all the state that we had before. Thus Rails provides a hash called Flash such that it persists until the end of the next request received.
Also there is a session hash, which unlike flash persists forever. <ref>http://www.youtube.com/watch?v=0m8lmRwS7E0</ref>.

For information on how to format the text of your article, create tables, and use section headings and references, see this [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/WIKI_Features article].

= Flash in Ruby =
Flash in ruby helps to remember the state until the end of the next request. It is basically used to store error messages as warnings and information as notice in the hash. This is used in views to print the error messages or notice. Instead of notice or warnings, we can define user defined hash and print its value in the view as we did for the notice and warnings. Basically it helps in flashing messages on the views. It stores values in the form of hash table. It is particularly useful to show messages after a redirect.Whenever you want to display any kind of status message or error message "Your email id is updated" or "Invalid Password" etc.
Rails loads it when you set it in your controller code and it is displayed in your view (if you have it set to display in the view). Rails discards the value when it is rendered on the client. The Flash values set in either notice/error or any user defined message in the controller can be accessed in the views to display the result of the action taken place in the controller.

= Session in Ruby =
Most applications need to keep track of certain state of a particular user. Examples include shopping cart for online shopping account or the user id of the currently logged in user. Without the idea of sessions, the user would have to identify, and probably authenticate, on every request. Rails will create a new session automatically if a new user accesses the application. It will load an existing session if the user has already used the application.

A session usually consists of a hash of values and a session id, usually a 32-character string, to identify the hash. Every cookie sent to the client’s browser includes the session id. And the other way round, the browser will send it to the server on every request from the client.

In Ruby session persists forever and is stored in the browser cookies by default. The session data can thus be deleted by clearing content of the cookies. Session is useful when we have to remember the state for a long time. Examples include Authentication where the user enters its login id and password that needs to be available for the whole session that the user is logged in. There are some alternative storage modes for session such as Storage table or No SQL data structure.<ref name="ref5"> http://www.tutorialspoint.com/ruby-on-rails/rails-session-cookies.htm/ </ref>

= How it works =

== Session ==
Session stores small amount of data that persists between requests. The session is only available in the controller and the view and can use one of a number of different storage mechanisms such as cookies, tables, cache, memcache etc.
The session stores session id in cookies as it is insecure when embedded in the url.This unique id is used to look up the session data on its storage locations such as cookies, database tables, no sql data structure, cache etc.The data storage in cookies by default makes the session lightweight and easy to access and it does not requires calls to the storage locations for accessing the session data. The cookies can store atmost 4 kb data and hence gives cookie overflow exception if the data in the session exceeds the 4 kb limit.The cookie data is not encrypted but it cannot be edited by being visible in the url. <ref name="ref1"> http://guides.rubyonrails.org/security.html#sessions/ </ref>
Session values are stored in a key,value pair. In Ruby we store it like a hash.

1. To add a session attribute we say
session[:username]=params[:username].
Here we assign the username received from the user to the session variable.
2. To delete a session attribute value, just assign the key to nil.
eg: session[:username]=nil.
Here we are deleting the session attribute username.
3. The session can also be reset
reset_session
This will reset the complete session hash

== Flash ==

The flash is a special part of the session which is cleared with each request. This means that values stored there will only be available in the next request, which is useful for storing error messages etc. It is accessed in much the same way as the session, like a hash. Flash is used by the controller to pass messages to the view. The controller can pass messages about the success or failure of the desired action. In Ruby,w e can also pass the flash message as part of the redirection again informing the view about the state of the action performed when redirecting. The user can also pass user defined messages and also pass messages for debugging purposes. The flash message displayed on the form/view is now taken care by the next request. The layout that receives the flash has to decide the action to be performed on the basis of the message received from the flash.<ref name="ref4">http://guides.rubyonrails.org/action_controller_overview.html#the-flash </ref>

1. To set a flash value as a notice <ref name="ref3">http://pupeno.com/2009/11/19/ensuring-the-displaying-of-flash-messages-in-ruby-on-rails/ </ref>
flash[:notice]= "User logged in successfully"
The flash message sets the notice value. This flashes the notice on the form when the user successfully logs into the system.

2. To set a flash value as a warning <ref name="ref3">http://pupeno.com/2009/11/19/ensuring-the-displaying-of-flash-messages-in-ruby-on-rails/ </ref>
flash[:error]= "Please provide the username and password"
The flash message sets the error value. This automatically flashes the notice saying that the user did not provide the username and password.

3. To set flash message as part of redirection
redirect_to( posts_show, :notice => "Post successfully created" )
The above statement redirects the method call to the appropriate url and displays a notice there automatically saying the post was successfully
created.

4. The value of flash to be saved for the subsequent requests
flash.keep
The above statement keeps all values of flash, that resulted from the redirection, to be used in the subsequent requests.

5. The value of flash to be saved in the current request
flash.now
The above statement keeps the values of flash, that resulted from the redirection, to be used for the current request.

= Example - Session/Flash =

:Class ExamplesController < ApplicationController 
::def index
::'''session[:example_name]=params[:example][:name]'''
::...
::end
::def update
:::@example = Example.find(params[:id])
:::respond_to do |format|
::::if @example.update_attributes(params[:type])
:::::format.html {redirect_to(@example, '''flash[:notice] => 'Example was successfully updated.'''')}
::::else
:::::format.html { render :action => "edit" }
::::end
:::end
::end
::def
::....
::end
:end


'''In the show(@example) view, we can make use of session and flash as- '''

'''<%=notice%>'''
'''<%=session[:example_name]%>'''

In the above code, the ExampleController class has a index method that sets the session for the user and
update method that sets the flash variable ,we set the session variable with the name of the example obtained from
the user stored in the params hash, we can access it in any view in that session.In the update method, flash is used to set
the notice to a desired value. Then it is used in the view to display the message.

= Advantages/Disadvantages =

== Session ==

'''Session Advantages:'''


1.A session object helps us store useful information about the application like the session_id, currently logged in user details. 
2.It is similar to hash and helps us take advantages of the hash functionalities in Ruby. 
3.Since, it persists forever, the session variables can be used to perform authentication,server side validation and take care of the security aspects
of the application. 


'''Session Disadvantages:'''

1. The session object is a heavy weight object as it is used to store a lot of application related information. 
2. we have to be careful while dealing with session variables as it is subject to malicious attacks and sensitive information can be divulged if not
taken care of while programming. 
3. As the session variables persists forever, it is the programmers responsibility to reset the information of the application when the application goes
out of the current scope logically. 
4. Too many session variable manipulation and storage can make the code inefficient and can cause unexpected behaviour if not programmed carefully.


== Flash ==

'''Flash Advantages:'''

1. A lightweight object that helps us store the information of the state the application is in. 
2. Since flash is similar to hash, it helps us abuse the advantages of hash. 
3. Any key can be passed into the flash object and the user is responsible for extracting the information from the corresponding object 
4. It is less tedious to manage as its lifetime persists only until the next request. 


'''Disadvantages:'''

1. As the information stored in the flash object persists only until the next request, it is not useful for providing security related capabilities to
the application. 
2. It has limited capabilities and used for displaying simple error messages, notices or warnings in the application. 
3. It cannot store dynamic information. 


= Conclusion/Summary =

HTTP is a stateless protocol and the web applications require saving of the application state frequently. Based on the application state, certain actions are taken. This is possible in RUBY using redirection flash object. The redirection flash object persists for a short duration and helps us store simple information about the application. Another flash like object that provides us very rich capabilities in terms of information storge, authentication and security is the session object. We have seen the differences between the two. It is the programmers responsibility to appropriately use the flash or the session object depending on what needs to be achieved.

= References =
<references />

http://ruby.railstutorial.org/chapters/sign-in-sign-out#sec:sessions_controller

CSC/ECE 517 Fall 2012/ch1b 1w67 ks

2012-10-04T02:42:43Z

Knagar: /* Session in Ruby */

= Overview/Introduction =
 Redirection in ruby refers to the where a user is redirected from one page to another. HTTP is stateless, hence session/flash makes it stateful.As the http requests are stateless, hence this leads to losing all the state that we had before. Thus Rails provides a hash called Flash such that it persists until the end of the next request received.
Also there is a session hash, which unlike flash persists forever. <ref>http://www.youtube.com/watch?v=0m8lmRwS7E0</ref>.

For information on how to format the text of your article, create tables, and use section headings and references, see this [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/WIKI_Features article].

= Flash in Ruby =
Flash in ruby helps to remember the state until the end of the next request. It is basically used to store error messages as warnings and information as notice in the hash. This is used in views to print the error messages or notice. Instead of notice or warnings, we can define user defined hash and print its value in the view as we did for the notice and warnings. Basically it helps in flashing messages on the views. It stores values in the form of hash table. It is particularly useful to show messages after a redirect.Whenever you want to display any kind of status message or error message "Your email id is updated" or "Invalid Password" etc.
Rails loads it when you set it in your controller code and it is displayed in your view (if you have it set to display in the view). Rails discards the value when it is rendered on the client. The Flash values set in either notice/error or any user defined message in the controller can be accessed in the views to display the result of the action taken place in the controller.

= Session in Ruby =
Most applications need to keep track of certain state of a particular user. Examples include shopping cart for online shopping account or the user id of the currently logged in user. Without the idea of sessions, the user would have to identify, and probably authenticate, on every request. Rails will create a new session automatically if a new user accesses the application. It will load an existing session if the user has already used the application.

A session usually consists of a hash of values and a session id, usually a 32-character string, to identify the hash. Every cookie sent to the client’s browser includes the session id. And the other way round, the browser will send it to the server on every request from the client.

In Ruby session persists forever and is stored in the browser cookies by default. The session data can thus be deleted by clearing content of the cookies. Session is useful when we have to remember the state for a long time. Examples include Authentication where the user enters its login id and password that needs to be available for the whole session that the user is logged in. There are some alternative storage modes for session such as Storage table or No SQL data structure.<ref name="ref5"> http://www.tutorialspoint.com/ruby-on-rails/rails-session-cookies.htm/ </ref>

= How it works =

== Session ==
Session stores small amount of data that persists between requests. The session is only available in the controller and the view and can use one of a number of different storage mechanisms such as cookies, tables, cache, memcache etc.
The session stores session id in cookies as it is insecure when embedded in the url.This unique id is used to look up the session data on its storage locations such as cookies, database tables, no sql data structure, cache etc.The data storage in cookies by default makes the session lightweight and easy to access and it does not requires calls to the storage locations for accessing the session data. The cookies can store atmost 4 kb data and hence gives cookie overflow exception if the data in the session exceeds the 4 kb limit.The cookie data is not encrypted but it cannot be edited by being visible in the url. <ref name="ref1"> http://guides.rubyonrails.org/security.html#sessions/ </ref>
Session values are stored in a key,value pair. In Ruby we store it like a hash.

1. To add a session attribute we say
session[:username]=params[:username].
Here we assign the username received from the user to the session variable.
2. To delete a session attribute value, just assign the key to nil.
eg: session[:username]=nil.
Here we are deleting the session attribute username.
3. The session can also be reset
reset_session
This will reset the complete session hash

== Flash ==

The flash is a special part of the session which is cleared with each request. This means that values stored there will only be available in the next request, which is useful for storing error messages etc. It is accessed in much the same way as the session, like a hash. Flash is used by the controller to pass messages to the view. The controller can pass messages about the success or failure of the desired action. In Ruby,w e can also pass the flash message as part of the redirection again informing the view about the state of the action performed when redirecting. The user can also pass user defined messages and also pass messages for debugging purposes. The flash message displayed on the form/view is now taken care by the next request. The layout that receives the flash has to decide the action to be performed on the basis of the message received from the flash.<ref name="ref4">http://guides.rubyonrails.org/action_controller_overview.html#the-flash </ref>

1. To set a flash value as a notice <ref name="ref3">http://pupeno.com/2009/11/19/ensuring-the-displaying-of-flash-messages-in-ruby-on-rails/ </ref>
flash[:notice]= "User logged in successfully"
The flash message sets the notice value. This flashes the notice on the form when the user successfully logs into the system.

2. To set a flash value as a warning <ref name="ref3">http://pupeno.com/2009/11/19/ensuring-the-displaying-of-flash-messages-in-ruby-on-rails/ </ref>
flash[:error]= "Please provide the username and password"
The flash message sets the error value. This automatically flashes the notice saying that the user did not provide the username and password.

3. To set flash message as part of redirection
redirect_to( posts_show, :notice => "Post successfully created" )
The above statement redirects the method call to the appropriate url and displays a notice there automatically saying the post was successfully
created.

4. The value of flash to be saved for the subsequent requests
flash.keep
The above statement keeps all values of flash, that resulted from the redirection, to be used in the subsequent requests.

5. The value of flash to be saved in the current request
flash.now
The above statement keeps the values of flash, that resulted from the redirection, to be used for the current request.

= Example - Session/Flash =

:Class ExamplesController < ApplicationController 
::def index
::'''session[:example_name]=params[:example][:name]'''
::...
::end
::def update
:::@example = Example.find(params[:id])
:::respond_to do |format|
::::if @example.update_attributes(params[:type])
:::::format.html {redirect_to(@example, '''flash[:notice] => 'Example was successfully updated.'''')}
::::else
:::::format.html { render :action => "edit" }
::::end
:::end
::end
::def
::....
::end
:end


'''In the show(@example) view, we can make use of session and flash as- '''

'''<%=notice%>'''
'''<%=session[:example_name]%>'''

In the above code, the ExampleController class has a index method that sets the session for the user and
update method that sets the flash variable ,we set the session variable with the name of the example obtained from
the user stored in the params hash, we can access it in any view in that session.In the update method, flash is used to set
the notice to a desired value. Then it is used in the view to display the message.

= Advantages/Disadvantages =

== Session ==

'''Session Advantages:'''


1.A session object helps us store useful information about the application like the session_id, currently logged in user details. 
2.It is similar to hash and helps us take advantages of the hash functionalities in Ruby. 
3.Since, it persists forever, the session variables can be used to perform authentication,server side validation and take care of the security aspects
of the application. 


'''Session Disadvantages:'''

1. The session object is a heavy weight object as it is used to store a lot of application related information. 
2. we have to be careful while dealing with session variables as it is subject to malicious attacks and sensitive information can be divulged if not
taken care of while programming. 
3. As the session variables persists forever, it is the programmers responsibility to reset the information of the application when the application goes
out of the current scope logically. 
4. Too many session variable manipulation and storage can make the code inefficient and can cause unexpected behaviour if not programmed carefully.


== Flash ==

'''Flash Advantages:'''

1. A lightweight object that helps us store the information of the state the application is in. 
2. Since flash is similar to hash, it helps us abuse the advantages of hash. 
3. Any key can be passed into the flash object and the user is responsible for extracting the information from the corresponding object 
4. It is less tedious to manage as its lifetime persists only until the next request. 


'''Disadvantages:'''

1. As the information stored in the flash object persists only until the next request, it is not useful for providing security related capabilities to
the application. 
2. It has limited capabilities and used for displaying simple error messages, notices or warnings in the application. 
3. It cannot store dynamic information. 


= Conclusion/Summary =

HTTP is a stateless protocol and the web applications require saving of the application state frequently. Based on the application state, certain actions are taken. This is possible in RUBY using redirection flash object. The redirection flash object persists for a short duration and helps us store simple information about the application. Another flash like object that provides us very rich capabilities in terms of information storge, authentication and security is the session object. We have seen the differences between the two. It is the programmers responsibility to appropriately use the flash or the session object depending on what needs to be achieved.

= References =
<references />

http://ruby.railstutorial.org/chapters/sign-in-sign-out#sec:sessions_controller
http://www.tutorialspoint.com/ruby-on-rails/rails-session-cookies.htm

CSC/ECE 517 Fall 2012/ch1b 1w67 ks

2012-10-04T02:41:57Z

Knagar: /* Session in Ruby */

= Overview/Introduction =
 Redirection in ruby refers to the where a user is redirected from one page to another. HTTP is stateless, hence session/flash makes it stateful.As the http requests are stateless, hence this leads to losing all the state that we had before. Thus Rails provides a hash called Flash such that it persists until the end of the next request received.
Also there is a session hash, which unlike flash persists forever. <ref>http://www.youtube.com/watch?v=0m8lmRwS7E0</ref>.

For information on how to format the text of your article, create tables, and use section headings and references, see this [http://expertiza.csc.ncsu.edu/wiki/index.php/CSC/ECE_517_Fall_2011/WIKI_Features article].

= Flash in Ruby =
Flash in ruby helps to remember the state until the end of the next request. It is basically used to store error messages as warnings and information as notice in the hash. This is used in views to print the error messages or notice. Instead of notice or warnings, we can define user defined hash and print its value in the view as we did for the notice and warnings. Basically it helps in flashing messages on the views. It stores values in the form of hash table. It is particularly useful to show messages after a redirect.Whenever you want to display any kind of status message or error message "Your email id is updated" or "Invalid Password" etc.
Rails loads it when you set it in your controller code and it is displayed in your view (if you have it set to display in the view). Rails discards the value when it is rendered on the client. The Flash values set in either notice/error or any user defined message in the controller can be accessed in the views to display the result of the action taken place in the controller.

= Session in Ruby =
Most applications need to keep track of certain state of a particular user. Examples include shopping cart for online shopping account or the user id of the currently logged in user. Without the idea of sessions, the user would have to identify, and probably authenticate, on every request. Rails will create a new session automatically if a new user accesses the application. It will load an existing session if the user has already used the application.

A session usually consists of a hash of values and a session id, usually a 32-character string, to identify the hash. Every cookie sent to the client’s browser includes the session id. And the other way round, the browser will send it to the server on every request from the client.

In Ruby session persists forever and is stored in the browser cookies by default. The session data can thus be deleted by clearing content of the cookies. Session is useful when we have to remember the state for a long time. Examples include Authentication where the user enters its login id and password that needs to be available for the whole session that the user is logged in. There are some alternative storage modes for session such as Storage table or No SQL data structure.<ref name="ref5"> http://refactoring.com/ </ref>

= How it works =

== Session ==
Session stores small amount of data that persists between requests. The session is only available in the controller and the view and can use one of a number of different storage mechanisms such as cookies, tables, cache, memcache etc.
The session stores session id in cookies as it is insecure when embedded in the url.This unique id is used to look up the session data on its storage locations such as cookies, database tables, no sql data structure, cache etc.The data storage in cookies by default makes the session lightweight and easy to access and it does not requires calls to the storage locations for accessing the session data. The cookies can store atmost 4 kb data and hence gives cookie overflow exception if the data in the session exceeds the 4 kb limit.The cookie data is not encrypted but it cannot be edited by being visible in the url. <ref name="ref1"> http://guides.rubyonrails.org/security.html#sessions/ </ref>
Session values are stored in a key,value pair. In Ruby we store it like a hash.

1. To add a session attribute we say
session[:username]=params[:username].
Here we assign the username received from the user to the session variable.
2. To delete a session attribute value, just assign the key to nil.
eg: session[:username]=nil.
Here we are deleting the session attribute username.
3. The session can also be reset
reset_session
This will reset the complete session hash

== Flash ==

The flash is a special part of the session which is cleared with each request. This means that values stored there will only be available in the next request, which is useful for storing error messages etc. It is accessed in much the same way as the session, like a hash. Flash is used by the controller to pass messages to the view. The controller can pass messages about the success or failure of the desired action. In Ruby,w e can also pass the flash message as part of the redirection again informing the view about the state of the action performed when redirecting. The user can also pass user defined messages and also pass messages for debugging purposes. The flash message displayed on the form/view is now taken care by the next request. The layout that receives the flash has to decide the action to be performed on the basis of the message received from the flash.<ref name="ref4">http://guides.rubyonrails.org/action_controller_overview.html#the-flash </ref>

1. To set a flash value as a notice <ref name="ref3">http://pupeno.com/2009/11/19/ensuring-the-displaying-of-flash-messages-in-ruby-on-rails/ </ref>
flash[:notice]= "User logged in successfully"
The flash message sets the notice value. This flashes the notice on the form when the user successfully logs into the system.

2. To set a flash value as a warning <ref name="ref3">http://pupeno.com/2009/11/19/ensuring-the-displaying-of-flash-messages-in-ruby-on-rails/ </ref>
flash[:error]= "Please provide the username and password"
The flash message sets the error value. This automatically flashes the notice saying that the user did not provide the username and password.

3. To set flash message as part of redirection
redirect_to( posts_show, :notice => "Post successfully created" )
The above statement redirects the method call to the appropriate url and displays a notice there automatically saying the post was successfully
created.

4. The value of flash to be saved for the subsequent requests
flash.keep
The above statement keeps all values of flash, that resulted from the redirection, to be used in the subsequent requests.

5. The value of flash to be saved in the current request
flash.now
The above statement keeps the values of flash, that resulted from the redirection, to be used for the current request.

= Example - Session/Flash =

:Class ExamplesController < ApplicationController 
::def index
::'''session[:example_name]=params[:example][:name]'''
::...
::end
::def update
:::@example = Example.find(params[:id])
:::respond_to do |format|
::::if @example.update_attributes(params[:type])
:::::format.html {redirect_to(@example, '''flash[:notice] => 'Example was successfully updated.'''')}
::::else
:::::format.html { render :action => "edit" }
::::end
:::end
::end
::def
::....
::end
:end


'''In the show(@example) view, we can make use of session and flash as- '''

'''<%=notice%>'''
'''<%=session[:example_name]%>'''

In the above code, the ExampleController class has a index method that sets the session for the user and
update method that sets the flash variable ,we set the session variable with the name of the example obtained from
the user stored in the params hash, we can access it in any view in that session.In the update method, flash is used to set
the notice to a desired value. Then it is used in the view to display the message.

= Advantages/Disadvantages =

== Session ==

'''Session Advantages:'''


1.A session object helps us store useful information about the application like the session_id, currently logged in user details. 
2.It is similar to hash and helps us take advantages of the hash functionalities in Ruby. 
3.Since, it persists forever, the session variables can be used to perform authentication,server side validation and take care of the security aspects
of the application. 


'''Session Disadvantages:'''

1. The session object is a heavy weight object as it is used to store a lot of application related information. 
2. we have to be careful while dealing with session variables as it is subject to malicious attacks and sensitive information can be divulged if not
taken care of while programming. 
3. As the session variables persists forever, it is the programmers responsibility to reset the information of the application when the application goes
out of the current scope logically. 
4. Too many session variable manipulation and storage can make the code inefficient and can cause unexpected behaviour if not programmed carefully.


== Flash ==

'''Flash Advantages:'''

1. A lightweight object that helps us store the information of the state the application is in. 
2. Since flash is similar to hash, it helps us abuse the advantages of hash. 
3. Any key can be passed into the flash object and the user is responsible for extracting the information from the corresponding object 
4. It is less tedious to manage as its lifetime persists only until the next request. 


'''Disadvantages:'''

1. As the information stored in the flash object persists only until the next request, it is not useful for providing security related capabilities to
the application. 
2. It has limited capabilities and used for displaying simple error messages, notices or warnings in the application. 
3. It cannot store dynamic information. 


= Conclusion/Summary =

HTTP is a stateless protocol and the web applications require saving of the application state frequently. Based on the application state, certain actions are taken. This is possible in RUBY using redirection flash object. The redirection flash object persists for a short duration and helps us store simple information about the application. Another flash like object that provides us very rich capabilities in terms of information storge, authentication and security is the session object. We have seen the differences between the two. It is the programmers responsibility to appropriately use the flash or the session object depending on what needs to be achieved.

= References =
<references />

http://ruby.railstutorial.org/chapters/sign-in-sign-out#sec:sessions_controller
http://www.tutorialspoint.com/ruby-on-rails/rails-session-cookies.htm