What is the diffrence between strategy design pattern and abstract factory pattern?

Can someone once and for all explain to me the difference between these two and try to give a sort of guideline for when to use each one of 开发者_Go百科them? Examples would be really nice.

---

The INTENT is different other than structural and implementation details. As soon as you grasp this fundamental idea that INTENT is of significance, then you will be on the right path.

Understand the role of intent in design patterns

Intent for Strategy. This is a Behavioral Pattern

1. Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from the clients that use it.
2. Capture the abstraction in an interface, bury implementation details in derived classes.

Intent for Abstract Factory. This is a Creational Pattern

1. Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
2. A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”.

---

Strategy is a workaround for languages that don't have first-class functions. You pass in a strategy object that decides some policy that you want separated from the rest of the code. Think of sorting in Java and how they use Comparators, a Comparator is a strategy object that allows you to specify the policy for sorting separately from the sorting algorithm. That allows you to reuse the code by dropping in different strategies.

Abstract Factory is an object used to create other objects, with the abstract part being that you have a factory that returns an implementation of the factory, where users of the factory access it through an interface. So one factory implementation can be swapped out for another with no changes to users of the factories, because those users are depending on the objects' interfaces only.

---

Factory Design pattern act as a factory and generates different kinds of objects at run time as per your request. So control is at run time and you get to decide the object you require at run time. So coupling among objects will be reduced.

On the other hand, Strategy design pattern allows you to take better control of hierarchical structures by using "has a" relationship over "is a" relationship. Because if we tempt to use inheritance (is a) in a more complex scenario then we may have to override the methods inherited over generations and it avoids code reuse.

Let's say you create an Animal class(or interface) and you are having a move method in it.

And you are hoping to create a bird class by extending it. So you will add flying features under move() method. But what is the case with penguins? They will have walking features.

So every time you create an animal by extending the Animal class, you will have to override the move() method again and again. You can clearly understand move() method is more vulnerable to changes, so best practice is to separate the changing part from core codes.

Simply we can create a separate hierarchy to move() methods. You can assign related move() method to the object via setter methods. So control is passed to run time. Following diagram illustrates that fact;

Following are 2 of my blog posts if you like you can refer them for further details.

1. Factory Design pattern

2. Strategy Design pattern