Twenty-four. behavioral design patterns-Strategy Pattern)

Document directory

• Definition
• Instance 1 -- sorting method
• Strengths and weaknesses
• Application scenarios

• Definition

Defines a series of algorithms (algorithms family), encapsulates each algorithm, and allows them to replace each other (interchangeable ). The rule mode allows algorithms to change independently of customers who use it.

The UML class diagram is as follows:

　　

The relationship between classes and objects is:

1. Strategy: defines a public interface for all supported algorithms. Context uses this interface to call the algorithm defined by ContextStrategy.

2. ContextStrategy (specific Strategy class): Call the Strategy interface to implement specific algorithms.

3. Context: Use the ContextStrategy object to configure the execution environment. Maintain a reference instance for Strategy. You can define an interface for Strategy to access its data.

The following figure shows the order of typical applications:

　　

• Instance 1 -- sorting method

The following example demonstrates that the policy mode encapsulates different sorting algorithms for multiple objects, allowing customers to dynamically change different sorting policies, including Quicksort, Shellsort, and Mergesort. The class diagram is as follows:

　　

　　

View Code

Namespace ConsoleApplication
{
// Abstract sorting policy class
Abstract class SortStrategy
{
Abstract public void Sort (ArrayList list );
}
// Quick sorting of specific policies
Class QuickSort: SortStrategy
{
Public override void Sort (ArrayList list)
{
List. Sort (); // the Sort of ArrayList uses the quick rank by default.
Console. WriteLine ("Quick Sort ");
}
}
// Specific policy shell sorting
Class ShellSort: SortStrategy
{
Public override void Sort (ArrayList list)
{
// List. ShellSort (); // method omitted
Console. WriteLine ("shell sorting ");
}
}
// Hybrid sorting of specific policies
Class MergeSort: SortStrategy
{
Public override void Sort (ArrayList list)
{
// List. MergeSort (); // method omitted
Console. WriteLine ("MergeSort ");
}
}

// Scenario
Class SortedList
{
Private ArrayList list = new ArrayList ();
Private SortStrategy sortStrategy;
// Set the sorting method and pass in the sorting policy object
Public void SetSortStrategy (SortStrategy sortStrategy)
{
This. sortStrategy = sortStrategy;
}
// Sort objects using the input sorting Policy
Public void Sort ()
{
SortStrategy. Sort (list );
}
// Add the elements to be arranged
Public void Add (string name)
{
List. Add (name );
}
Public void Display ()
{
Foreach (string name in list)
Console. WriteLine ("" + name );
}
}

Class Program
{
Static void Main (string [] args)
{
SortedList studentRecords = new SortedList ();
StudentRecords. Add ("Samuel ");
StudentRecords. Add ("Jimmy ");
StudentRecords. Add ("Sandra ");
StudentRecords. Add ("Anna ");
StudentRecords. Add ("Vivek ");
// Sort by quick sorting
StudentRecords. SetSortStrategy (new QuickSort ());
StudentRecords. Sort ();
StudentRecords. Display ();
Console. Read ();
}
}
}

• Strengths and weaknesses

The policy mode provides an alternative to the derived subclass, defines each behavior of the class, and removes the judgment statement of the conditions in the Code, making it easier to expand and combine new behaviors, there is no need to change the application at all. Policy mode avoids the use of multiple conditional transfer statements, and the system becomes updated and flexible. The application policy mode generates many sub-classes, which are in line with the high cohesion responsibility allocation mode.

• Application scenarios

The following scenarios are suitable for the application policy mode:

1. The behavior of multiple classes is different.

2. You need to make many changes to the behavior algorithm.

3. the customer does not know the data to be used by the algorithm.