I can recommend Head First Design Patterns for this one. From that book:
The difference between State and Strategy is in intent. Using the State pattern you dynamically alter behavior during the life of your object. It's an alternative for if statements all over the class. Using the Strategy pattern you normally do it once, when the object is constructed. It's an alternative for subclassing. The behaviour is flexible, but for agiven object you configure it once.
A facade and Strategy have nothing to do with each other. The Strategy is meant to configure behavior (implementation) at run-time. The Facade just simplifies an existing interface. If you have a complex ATM system, you might want 2 interfaces. One with all of the power, including all kinds of methods on how to deal with errors and such, and one to be called by the front-end, which can be simpler. The front-end code wouldn't need to know how to handle errors, an error handler somewhere else would take care of that. It would only need to know that there is an error. A simplified interface (which hopefully is also more constant over time) would make the life of the front-end developer simpler, and hide away possibly changing elements. That's when you make a Facade. You have the full-featured interface, but most people only use a subset. That subset would the be the Facade.
The composite pattern allows you to compose objects into tree structures. I can't see how you can not see the difference with the Strategy pattern. They hardly have anything in common.
Perhaps some thoughts of actual use of these patterns:
- Bridge when your model of the data is not yet clear. You implement most of your implementation as calls to itself. That way you can make a decent part of the implementation even if the abstraction is still uncertain
- State is usually used when there only a limited amount of states, and the behavior is distinctly different. I'm thinking of coffee machines and printers here. Though you could implement a Banking system such that if the balance is below zero the subtract(amount) would always generate an error:)
- A facade is not uncommon. You may have a data layer (e.g. Hibernate) with an API which has methods used by both business processes and maintenance processes. You can then define 2 simpler APIs, one for business developers and one for maintenance developers. These API's would call of course the complete API, but you wouldn't see that as a business developer.
- Strategy is fairly common, most certainly if you use Spring or any other form of IoC, and for Junit testing you usually also inject an alternative "database" layer.
- The Composite pattern is probably most used in GUI applications. Can't think of a use case other that that right now.
I really recommend Head First Design Patterns, as they even interviewed the various patterns! The patterns then tell a bit about themselves, and why they are the best pattern of all:)