Understanding and Applying the Strategy Design Pattern in Java

Many apps need to share content to different platforms (Weibo, WeChat, QQ, etc.), and a simple if‑else chain quickly becomes hard to maintain as requirements grow.

For a quick illustration, the article first shows a basic conditional implementation:

public void Share{ public void shareOptions(String option){ if(option.equals("微博")){ //function1(); } else if(option.equals("微信")){ //function2(); } else if(option.equals("朋友圈")){ //function3(); } else if(option.equals("QQ")){ //function4(); } //... } }

To improve readability, extensibility, and adherence to the Open‑Closed Principle, the article introduces the Strategy design pattern, one of the 23 GoF patterns, which separates algorithms from their usage.

Strategy pattern roles :

Strategy – the interface defining the algorithm (e.g., DealStrategy).

ConcreteStrategy – classes implementing the algorithm (e.g., DealSina, DealWeChat).

Context – the class that uses a Strategy (e.g., DealContext).

The refactored code looks like this:

public interface DealStrategy { void dealMythod(String option); }

public class DealSina implements DealStrategy { @Override public void dealMythod(String option){ //... } }

public class DealWeChat implements DealStrategy { @Override public void dealMythod(String option){ //... } }

public class DealContext { private String type; private DealStrategy deal; public DealContext(String type, DealStrategy deal){ this.type = type; this.deal = deal; } public DealStrategy getDeal(){ return deal; } public boolean options(String type){ return this.type.equals(type); } }

public class Share { private static List<DealContext> algs = new ArrayList<>(); static { algs.add(new DealContext("Sina", new DealSina())); algs.add(new DealContext("WeChat", new DealWeChat())); } public void shareOptions(String type){ DealStrategy dealStrategy = null; for(DealContext deal : algs){ if(deal.options(type)){ dealStrategy = deal.getDeal(); break; } } dealStrategy.dealMythod(type); } }

This structure eliminates the long if‑else chain, making the code easier to extend: adding a new platform only requires a new ConcreteStrategy and a line in the static block.

The article also shows a Comparator example to illustrate that many standard Java APIs already use the Strategy pattern:

public interface Comparator<T> { int compare(T o1, T o2); }

public class sorter implements Comparator<String> { @Override public int compare(String s1, String s2){ return Integer.compare(s1.length(), s2.length()); } }

For projects that already use reflection, the pattern can be further decoupled by loading strategy classes from configuration files or annotations.

Finally, the article compares Strategy with State pattern, highlighting that Strategy focuses on interchangeable algorithms, while State changes the object's class on each state transition.

In summary, the Strategy pattern helps developers replace complex conditional logic with interchangeable, maintainable algorithm objects, supporting better scalability and adherence to solid design principles.