"Design pattern Refinement" Learning notes (10)------Strategy (strategy) mode

"Design pattern Refinement" Learning notes (10) ------Strategy (policy) mode

GoF : Define a series of algorithms, encapsulate them one by one, and allow them to replace each other. This mode allows the algorithm to vary independently from the customer who uses it.

For example, in our system, we need to paint a graphic or a WordArt (such a system is in the real world, a bill output system made by my former company has this function). If we need a variety of colors of graphics or WordArt, then we will each color of the graphic or WordArt to achieve one is very stupid, because the demand is changing. When we implement a graphic or WordArt. Some of the column colors should be implemented separately. This allows us to harden our code without having to set the color and graphics state.

Here is the case code: (the case is simpler to illustrate the problem)

First define the color abstract class

Package strategy;

Public abstract class Color

{

public abstract void Printcolor ();

}//end class Color

Implement two colors separately

Package strategy;

public class Redcolor extends Color

{

public void Printcolor ()

{

System.out.println ("Print the Red color!");

}//end Printcolor ()

}//end class Redcolor

Package strategy;

public class Blackcolor extends Color {

public void Printcolor ()

{

System.out.println ("Print the Black color!");

}//end Printcolor ()

}//end class Blackcolor

The following implementation of an algorithm to solve the class for users to select the appropriate algorithm

Package strategy;

public class Colorsolver

{

private color color;

Public Colorsolver (Color Col)

{

This.color = col;

}//end colorsolver (...)

public void Printsinglecolor ()

{

Color.printcolor ();

}//end Printsiglecolor ()

public void Printallcolor (Color col)

{

This.color = col;

}

}//end class Colorsolver

Finally let's implement the call

Package strategy;

public class Strategypattern

{

Private Colorsolver cs = new Colorsolver (new Redcolor ());

public void print ()/color

{

Cs.printsinglecolor ();

CS = new Colorsolver (new Blackcolor ());

Cs.printsinglecolor ();

}//end print ()

public static void Main (string[] args)

{

SYSTEM.OUT.PRINTLN ("Strategy pattern.../n");

Strategypattern sp = new Strategypattern ();

Sp.print ();

}//end Main (...)

}//end Strategypattern

The results of the operation are as follows

Strategy pattern ...

Print the Red color!

Print the Black color!

In this way, we have achieved the purpose of switching the algorithm at random during operation.

Here's a UML diagram:

Strategy The model is based on a few principles:

L objects have responsibility. The user's responsibility is to know what algorithm to use.

• The different specific implementations of these responsibilities are expressed by using polymorphism.

L need to manage several different implementations in the same way-conceptually-the same algorithm.

A good design experience: separating the behaviors that occur in the problem area-that is, decoupling them. This allows us to change the class responsible for a behavior without having a bad effect on other behaviors.

In some ways, the strategy pattern is about algorithmic encapsulation. In practice, however, I have found that it can be used to encapsulate almost any kind of rule. For example, in this article I give a sample of color.

Strategy pattern Key Features:

L Intent: To allow you to use different business rules or algorithms-depending on the scenario in which they appear.

L Problem: The algorithm needs to be selected based on the client or data being processed. If you just have some algorithm that doesn't change, you don't need strategy mode.

Solution: The choice of the algorithm and the implementation of the algorithm to separate. Allow customers to make choices based on scenarios.

L Effect: The strategy pattern defines a series of algorithms; the switch statement or conditional statement is avoided; You must call all algorithms in the same way, they must have the same interface.

It seems to me that the strategy pattern defines an abstract class and then derives several classes that have unique methods for different objects through downward transitions. It is simpler to say that it is the application of polymorphism in OO concepts. (or I understand it wrong, and please advise)

Summary:

Strategy mode is a method of defining an algorithm family. Conceptually, all of these algorithms work the same. They just have different implementations.

By deriving all the different ways of executing an algorithm from an abstract class, the main module does not need to worry about which of the many possibilities is actually being used. This allows new changes to be added. , but it has also created the need to manage these changes.

trackback:http://tb.blog.csdn.net/trackback.aspx?postid=610786