Difference between the Composite Pattern and Decorator Pattern?

What is the difference between the Composite Pattern and Decorator 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. So the essence is that all elements in your composite structure have the same interface even though some are leaf nodes and others are entire structures. User interfaces often use this approach to allow easy composability.

http://en.wikipedia.org/wiki/Composite_pattern

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 behaviour 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 behaviour of the contained element.

http://en.wikipedia.org/wiki/Decorator_pattern

The structure of composite pattern and decorator look the same but they have different intent.

Composite gives an unified interface to a leaf and composite.

Decorator decorator gives additional feature to leaf, while giving unified interface.

Examples

Composite pattern: classic windows folders and files. Windows folders are composites. files are leaves. A double click on either of them opens the file/folder - double click is unified interface.

Decorator pattern: Buffered io - java.io.FileWriter and java.io.BufferedWriter both extend java.io.Writer. java.io.BufferedWriter is composite and FileWriter is leaf. BufferedWriter adds additional responsibility (or feature) of buffering to FileWriter. write() method is unified interface, whereas buffering is additional feature.

A decorator can be viewed as a degenerate composite with only one component. However, a decorator adds additional responsibilities—it isn't intended for object aggregation.

This is what is said in "Design Patterns-Elements of Reusable Object Oriented Software" by the gang of four.

The difference is probably more one of purpose than implementation. In some instances the composite pattern is preferable to subclassing. For example, you can add the functionality that you want a class to have by adding instances of other classes to it and then exposing the functionality through a forwarding interface.

Decorators allow you to transparently add functionality, usually a single capability, to an class without clients of the instances of the class needing to know the that there's a decorator there - for example, a "login_required" decorator on a view in Django raises an exception if the user isn't logged in, but otherwise the view behaves as it would without the decorator.

In both cases you have one object embedded within another, but what you're trying to accomplish is arguably different.