Comparing Design Patterns

I am learning design patterns using C#. One of the challenges that I am facing is that they look similar. Could you please help me to distinguish them – basically when to use them? - Why not the other?

1. Bridge and Strategy
2. State and Strategy
3. Façade and Strategy
4. Composite and Strategy

I understand that there are lots of resources available in the web. However they does not treat this special scenario.

[Note: I am looking for implementation examples and rationale behind the selection; not mere explanations]

Thanks for your response. I made more attempts to learn Bridge.

I have the following scenario.

In my room there are two TVs. Each one has its own remote control; but both has the same interface for the user to use. However I want to have my own remote control in which I will use the processors of any of the two remotes.

I have the following code. I think, th开发者_JAVA技巧is is Strategy Pattern. I want to convert this to Bridge.

1. How to convert it into Bridge?

2. What is the advantage that I will get by converting into Bridge?

   public class PhilliTV { public void Begin() { Console.WriteLine("PhilliTV Bagan"); } }

   public class SonTV
       {
           public void Initiate()
           {
               Console.WriteLine("SonTV Initiated");
           }
        }
   
   
   
   
     public class SonRemote : IRemote
       {
           SonTV stv = new SonTV();
           public void Play()
           {
               stv.Initiate();
           }
       }
   
   
    public class PhilliRemote : IRemote
       {
           PhilliTV ptv = new PhilliTV();
           public void Play()
           {
               ptv.Begin();
           }
       }
   
   
     public class URemoteConsumer
       {
           IRemote remote = new PhilliRemote();
   
           public void MyPlay()
           {
               remote.Play();
           }
   

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:)

State vs Strategy: In state, it is the object who is in control of deciding which algorithm to use (which depends on its current state), while in strategy, it is the client which is in control of what algorithm to use.

"..it is the object who is in control of deciding which algorithm to use.." is not so clear (to me, at least).

The object has a state pointer, let's say "currentState" pointer. All states support the same interface, know how to handle methods A,B and C (for example).

When the object needs to perform some method (A, B or C - exposed by State interface) it triggers currentState.A(), currentState.B() or currentState.C().

The actual handling is done inside each state; this way we avoid using multiple if-else conditions for determining our own state.