Strategy Pattern in WordPress Plugins: Complete PHP Development Guide
Introduction
WordPress plugins often need to perform the same type of operation in different ways.
A pricing engine may support multiple pricing rules.
A shipping system may calculate charges using different methods.
A payment plugin may support several gateways.
An AI application may communicate with different providers.
A notification system may deliver messages through email, SMS, or webhooks.
A simple implementation often uses increasingly large conditional statements:
if ( $method === 'flat' ) { // Flat-rate logic. } elseif ( $method === 'weight' ) { // Weight-based logic. } elseif ( $method === 'free' ) { // Free-shipping logic. }
This can work for a small feature.
As more implementations are added, the conditional becomes harder to maintain and test.
The Strategy Pattern solves this problem by moving interchangeable behavior into separate classes with a common interface.
The architecture becomes:
Application Service ↓ Strategy Interface ┌────┼────┐ ↓ ↓ ↓ Strategy A Strategy B Strategy C
The application can select the appropriate strategy without changing its core workflow.
This guide explains what the Strategy Pattern is, how it works in WordPress plugins, when to use it, how it differs from Factory and State patterns, and how to apply it to payments, shipping, pricing, AI providers, notifications, exports, and other real-world plugin systems.
What Is the Strategy Pattern?
The Strategy Pattern is a behavioral design pattern that encapsulates interchangeable algorithms or behaviors behind a common interface.
For example:
interface ShippingStrategyInterface { public function calculate( float $subtotal ): float; }
Different strategies implement the same contract:
ShippingStrategyInterface │ ┌────┼────┐ ↓ ↓ ↓ Flat Rate Weight Free
The application can choose one strategy at runtime.
Why Use Strategy in WordPress Plugins?
Strategy is useful when one feature has multiple valid implementations.
Common examples include:
Payment methods
Shipping calculations
Pricing rules
Discount algorithms
AI providers
Notification channels
Export formats
Search methods
Authentication mechanisms
Recommendation algorithms
Instead of changing one large class each time a new behavior is added, create another strategy implementation.
Conditional Logic vs Strategy
Without Strategy:
OrderService ├── If Provider A ├── Else Provider B ├── Else Provider C └── More Conditions
With Strategy:
OrderService ↓ Strategy Interface ↓ Selected Strategy
This helps isolate behavior.
The service focuses on the workflow.
The strategy focuses on the algorithm.
A Simple Strategy Example
Suppose a plugin needs different discount calculations.
Interface:
interface DiscountStrategyInterface { public function calculate( float $price ): float; }
Implementation:
final class TenPercentDiscount implements DiscountStrategyInterface { public function calculate( float $price ): float { return $price * 0.10; } }
Another:
final class TwentyPercentDiscount implements DiscountStrategyInterface { public function calculate( float $price ): float { return $price * 0.20; } }
The main service doesn't need separate branches for each algorithm.
Strategy Context
The class using a strategy is often called the context.
For example:
final class DiscountService { public function __construct( private DiscountStrategyInterface $strategy ) { } public function calculate( float $price ): float { return $this->strategy->calculate($price); } }
The context knows the contract, not the algorithm's implementation details.
The architecture becomes:
DiscountService ↓ DiscountStrategyInterface ↓ Selected Discount Strategy
Strategy With Dependency Injection
Strategy works naturally with dependency injection.
For example:
final class ShippingService { public function __construct( private ShippingStrategyInterface $strategy ) { } }
The application can inject:
FlatRateStrategy WeightBasedStrategy FreeShippingStrategy
The service doesn't need to instantiate them directly.
Strategy and Factory
Strategy and Factory are commonly used together.
The Factory chooses which strategy to create.
The Strategy performs the behavior.
Configuration ↓ Strategy Factory ↓ Strategy Interface ↓ Selected Strategy
For example:
$strategy = $factory->create( 'weight' );
Then:
$shippingService->calculate( $order );
The responsibilities remain separate.
Strategy and Service Containers
A dependency injection container can also select strategies.
For example:
Container ↓ ShippingStrategyInterface ↓ WeightBasedStrategy
A factory is useful when selection happens dynamically.
A container binding is useful when the implementation is configured globally.
Strategy vs State Pattern
These patterns are easy to confuse.
Strategy
Changes how an operation is performed.
Example:
Shipping ├── Flat Rate ├── Weight Based └── Free
State
Changes behavior according to an object's current state.
Example:
Order ├── Pending ├── Processing ├── Completed └── Cancelled
Strategy is about interchangeable algorithms.
State is about lifecycle-dependent behavior.
Strategy for Payment Gateways
Payment systems are a strong Strategy use case.
Define:
interface PaymentStrategyInterface { public function charge( int $amount, string $currency ): bool; }
Implementations:
PaymentStrategyInterface ├── StripePayment ├── PayPalPayment └── SandboxPayment
Then:
PaymentService ↓ PaymentStrategyInterface ↓ Selected Payment Strategy
This allows the payment workflow to remain provider-neutral.
Strategy for Shipping Calculations
A WooCommerce-oriented plugin might support:
Flat Rate Weight Based Distance Based Free Shipping
Use:
interface ShippingStrategyInterface { public function calculate( array $order ): float; }
Each strategy implements a different calculation.
The main service remains unchanged when new shipping methods are added.
Strategy for Pricing Rules
Pricing systems often contain many variations:
Regular Price Wholesale Price Member Price Seasonal Price Volume Discount
Instead of placing every rule inside one method:
PricingService ↓ PricingStrategyInterface ↓ Selected Pricing Strategy
This makes each pricing algorithm easier to test separately.
Strategy for AI Providers
AI plugins are another strong use case.
Suppose the application supports several providers:
AIProviderInterface ├── Provider A ├── Provider B └── Provider C
The application service can depend on:
interface AIProviderInterface { public function generate( string $prompt ): string; }
Then:
AIService ↓ AIProviderInterface ↓ Selected Provider
The strategy can be selected through a factory or configuration.
Strategy for Notification Channels
A notification system can support:
Email SMS Webhook Push
Interface:
interface NotificationStrategyInterface { public function send( string $message ): bool; }
Each channel becomes a strategy.
This allows the notification service to use one stable contract.
Strategy for Export Formats
Reporting systems often need:
CSV JSON XML
Use:
interface ExportStrategyInterface { public function export( array $data ): string; }
Then:
ExportService ↓ ExportStrategyInterface ┌────┼────┐ ↓ ↓ ↓ CSV JSON XML
Adding a new format means adding a strategy rather than rewriting the export service.
Strategy for Authentication
A plugin may support:
JWT OAuth API Key Basic Authentication
A common contract can hide implementation details:
interface AuthenticationStrategyInterface { public function authenticate( array $credentials ): bool; }
Use security review carefully here. Strategy controls implementation choice; it does not replace authorization or secure credential management.
Strategy for Search
A large WordPress plugin may support several search approaches:
WordPress Search Custom SQL Search External Search Index Semantic Search
For example:
SearchService ↓ SearchStrategyInterface ↓ Selected Search Strategy
This makes search implementations replaceable.
Strategy for Recommendations
Recommendation engines can use:
Recently Viewed Popular Products Collaborative Filtering Rule-Based Recommendations AI Recommendations
A strategy interface allows these algorithms to share the same application entry point.
This is especially useful for WooCommerce and AI-powered product systems.
Strategy for Image Optimization
A media plugin might support:
Local Optimization Provider A Provider B
The service can use:
ImageOptimizationStrategyInterface
Each implementation manages a different optimization approach.
Strategy With Configuration
WordPress options can determine the selected strategy:
$method = \get_option( 'myplugin_shipping_method', 'flat' );
Then a factory can select:
$strategy = $factory->create( $method );
The value should be validated against supported strategy identifiers.
Never turn arbitrary configuration into unrestricted class instantiation.
Strategy and WordPress Filters
WordPress filters can sometimes allow third-party customization:
$strategy = \apply_filters( 'myplugin_shipping_strategy', $strategy );
However, filters should be treated as extension points, not security mechanisms.
Validate the resulting object or type expectations before using it.
Strategy and WordPress Hooks
Strategies can be invoked from hook listeners:
WordPress Hook ↓ Hook Listener ↓ Service ↓ Strategy
The hook handles lifecycle integration.
The strategy handles variable behavior.
This keeps WordPress-specific concerns separate from the algorithm itself.
Strategy and REST API
A REST controller should not contain every implementation branch.
Prefer:
REST Request ↓ Validation ↓ Service ↓ Strategy
For example:
public function calculate( \WP_REST_Request $request ): \WP_REST_Response { $result = $this->service->calculate( $request->get_json_params() ); return new \WP_REST_Response( $result ); }
The service and strategy contain the actual calculation logic.
Strategy and WP-Cron
Background jobs can also use strategies.
For example:
WP-Cron ↓ Sync Service ↓ SyncStrategyInterface ↓ Selected Integration
This makes scheduled workflows reusable.
Strategy and WP-CLI
A CLI command can reuse the same strategy-based service:
WP-CLI ↓ Service ↓ Strategy
This prevents separate implementations for CLI and web requests.
Strategy and WooCommerce
WooCommerce plugins commonly contain behavior that varies by:
Product type
Customer type
Shipping method
Payment provider
Pricing rule
Recommendation model
Discount rule
Strategy is useful when these behaviors share a common interface but differ in implementation.
For example:
WooCommerce Event ↓ OrderService ↓ PricingStrategy ↓ Customer-Specific Pricing
Strategy and AI WooCommerce Recommendations
An AI-commerce plugin might support:
RuleBasedRecommendation PopularProductRecommendation AIRecommendation
The application can use:
RecommendationStrategyInterface
This allows AI recommendations to coexist with traditional algorithms.
Strategy and Dependency Injection Container
A container can bind one strategy:
$container->set( ShippingStrategyInterface::class, fn() => new WeightBasedStrategy() );
For runtime selection, a factory can be preferable:
Container ↓ Strategy Factory ↓ Selected Strategy
Use each mechanism for its intended responsibility.
Strategy and Factory Example
final class ShippingStrategyFactory { public function create( string $method ): ShippingStrategyInterface { return match ( $method ) { 'flat' => new FlatRateStrategy(), 'weight' => new WeightBasedStrategy(), 'free' => new FreeShippingStrategy(), default => throw new \InvalidArgumentException( 'Unsupported shipping strategy.' ), }; } }
Then:
final class ShippingService { public function __construct( private ShippingStrategyFactory $factory ) { } public function calculate( string $method, array $order ): float { return $this->factory ->create($method) ->calculate($order); } }
Strategy and Adapter
Strategy and Adapter can work together for third-party providers.
For example:
AI Strategy ↓ Provider Adapter ↓ External AI API
The Strategy determines the application's behavior.
The Adapter translates provider-specific APIs.
Strategy and Repository
A strategy might need data:
RecommendationStrategy ↓ ProductRepository ↓ Database
The strategy shouldn't necessarily perform raw database operations itself.
Inject a repository or service where appropriate.
Strategy and Caching
Strategies can also be decorated with caching.
For example:
RecommendationService ↓ Cached Strategy ↓ Base Strategy ↓ Database / API
This avoids adding caching logic to every implementation.
Strategy and Testing
One advantage of Strategy is isolated testing.
For example:
$strategy = new WeightBasedStrategy(); self::assertSame( 12.50, $strategy->calculate($order) );
Each algorithm gets its own tests.
The context can then be tested separately with a fake strategy.
Testing the Context
For example:
$strategy = $this->createMock( ShippingStrategyInterface::class ); $strategy ->method('calculate') ->willReturn(15.00); $service = new ShippingService( $strategy );
The service test doesn't need to know how shipping is calculated.
Testing Strategy Selection
The factory should have separate tests:
flat → FlatRateStrategy weight → WeightBasedStrategy free → FreeShippingStrategy
Unsupported methods should fail predictably.
This keeps selection tests separate from algorithm tests.
Strategy and Static Analysis
Strong contracts improve static analysis:
public function create( string $method ): ShippingStrategyInterface
PHPStan can verify that every returned implementation satisfies the interface.
Use explicit parameter and return types.
Strategy and Composer
Namespaced Strategy classes work naturally with Composer:
{ "autoload": { "psr-4": { "Kaddora\\MyPlugin\\": "src/" } } }
For example:
Kaddora\MyPlugin\Strategies\FlatRateStrategy
can map to:
src/Strategies/FlatRateStrategy.php
Strategy Directory Structure
A plugin may use:
src/ ├── Strategies/ │ ├── Shipping/ │ ├── Pricing/ │ ├── Recommendations/ │ └── Notifications/ ├── Factories/ ├── Services/ ├── Contracts/ └── Repositories/
For a larger application, organizing strategies inside business modules can be clearer:
Shipping/ ├── ShippingStrategyInterface.php ├── ShippingStrategyFactory.php └── Strategies/
Choose the structure that best reflects the domain.
Avoid a Generic Strategy Interface
Don't create:
interface StrategyInterface { public function execute(); }
for everything.
This loses domain meaning.
Prefer:
ShippingStrategyInterface PaymentStrategyInterface ExportStrategyInterface RecommendationStrategyInterface
A focused contract communicates purpose.
Avoid Giant Strategy Classes
A strategy should implement one coherent algorithm.
Avoid a strategy containing:
Shipping Pricing Payment Email CRM Analytics
A strategy should remain focused on the behavior it represents.
Avoid Too Many Strategies
Not every variation requires a class.
For example, if an operation only changes one small constant:
$discount = $isMember ? 0.10 : 0.05;
a full strategy hierarchy may be excessive.
Use Strategy when behavior is sufficiently different or likely to evolve independently.
Strategy and Performance
The Strategy Pattern does not automatically improve performance.
It can improve maintainability while introducing additional object calls.
For performance-sensitive code:
Profile actual workloads.
Avoid unnecessary object creation.
Cache expensive results.
Batch database operations.
Avoid repeated API requests.
Architecture should be optimized based on evidence.
Strategy Security Considerations
The strategy itself isn't a security boundary.
A payment strategy still needs secure implementation.
An authentication strategy still needs secure credentials.
A REST strategy still needs validation and authorization.
Use:
Authentication ↓ Authorization ↓ Validation ↓ Strategy
rather than expecting the strategy layer to provide all security controls.
Common Strategy Pattern Mistakes
Avoid:
Creating a strategy for trivial conditionals
Using generic interfaces
Putting unrelated logic into one strategy
Allowing arbitrary class names
Coupling the context to implementations
Duplicating validation in every strategy
Ignoring tests
Introducing unnecessary abstraction
The goal is interchangeable behavior, not maximum class count.
How to Choose a Strategy Boundary
Ask:
What behavior varies?
For example:
How shipping is calculated
Then define:
ShippingStrategyInterface
Ask next:
What remains constant?
The workflow can stay in:
ShippingService
The varying algorithm belongs in the strategy.
This produces:
Stable Workflow + Variable Algorithm ↓ Strategy Boundary
Step-by-Step: Build a Strategy in WordPress
Step 1: Identify Variable Behavior
Example:
Shipping Calculation
Step 2: Define the Contract
interface ShippingStrategyInterface { public function calculate( array $order ): float; }
Step 3: Create Implementations
FlatRateStrategy WeightBasedStrategy FreeShippingStrategy
Step 4: Create the Context
ShippingService
Step 5: Inject the Strategy
Use constructor injection.
Step 6: Add Selection Logic
Use a factory when the strategy is selected dynamically.
Step 7: Validate Configuration
Allow only supported identifiers.
Step 8: Add Unit Tests
Test each strategy independently.
Step 9: Test Selection
Test the factory separately.
Step 10: Test Integration
Verify the strategy works correctly with WordPress or WooCommerce.
Complete Strategy Architecture Example
WordPress │ REST / Admin / Hook │ ▼ ShippingService │ ▼ ShippingStrategyInterface ┌────────┼────────┐ ↓ ↓ ↓ Flat Rate Weight Free Strategy Strategy Strategy
A factory can select the strategy:
Settings ↓ ShippingStrategyFactory ↓ Selected Strategy
A DI container can construct the service and factory.
Why choose Themekaddora?
ThemeKaddora develops WordPress themes, plugins, WooCommerce solutions, AI products, HTML templates, UI kits, SaaS-oriented solutions, and business-focused digital products.
Strategy can be valuable when ThemeKaddora products need interchangeable behavior such as:
AI Providers Payment Methods Pricing Rules Recommendation Algorithms Export Formats Notification Channels Storage Backends
A practical architecture is:
ThemeKaddora Product ↓ Application Service ↓ Strategy Interface ↓ Selected Strategy ↓ Provider / Algorithm / Integration
Factories can select strategies dynamically, while dependency injection provides their dependencies.
The key principle is to keep the context focused on the stable workflow and move truly variable behavior into strategies.
Final Thoughts
The Strategy Pattern is one of the most useful behavioral patterns for WordPress plugins that need interchangeable algorithms or implementations.
The central idea is:
Keep the workflow stable and move variable behavior into separate strategies.
Instead of:
Large Class ├── if A ├── if B ├── if C └── More Conditions
use:
Service ↓ Strategy Interface ↓ Selected Strategy
Strategy is particularly useful for:
Payment methods
Shipping calculations
Pricing rules
AI providers
Notifications
Export formats
Search algorithms
Recommendation engines
Authentication methods
Storage implementations
It works especially well with:
Dependency Injection
Factory Pattern
Adapter Pattern
Repository Pattern
Service Containers
Composer
PSR-4
PHPUnit
PHPStan
PHPCS
But Strategy should not be used for every conditional.
A simple conditional is often better when the behavior is small, stable, and unlikely to grow.
The decision should be based on variation.
Ask:
Does this behavior have multiple meaningful implementations?
Will those implementations evolve independently?
Would separating them make testing and maintenance easier?
When the answer is yes, Strategy can provide a clean architectural boundary.
The most practical architecture is:
Entry Point ↓ Application Service ↓ Strategy Interface ↓ Selected Implementation
A Factory can handle selection.
A Dependency Injection Container can handle construction.
An Adapter can handle external API differences.
A Repository can handle persistence.
Each pattern has a specific job.
The goal is not to create more classes.
The goal is to make changing one algorithm less likely to require changing the entire application.
For growing WordPress, WooCommerce, AI, analytics, automation, and SaaS products, that separation can make new functionality easier to introduce without turning the core service into a collection of conditional branches.
A strong Strategy implementation follows this process:
Identify variation → define a contract → isolate implementations → inject the strategy → test each implementation → select dynamically when necessary.
Use Strategy where behavior genuinely varies.
Keep simple logic simple.
That balance produces WordPress plugins that are easier to extend, test, and maintain.
Frequently Asked Questions
What is the Strategy Pattern in WordPress?
The Strategy Pattern separates interchangeable algorithms or behaviors into individual classes that share a common interface.
Why use Strategy in WordPress plugins?
Use it when a feature can perform the same operation in several substantially different ways and those behaviors may evolve independently.
What are common Strategy Pattern examples in WordPress?
Common examples include shipping calculations, pricing rules, payment methods, AI providers, notifications, exports, search algorithms, and recommendation systems.
What is a strategy interface?
A strategy interface defines the common contract that all interchangeable implementations must follow.
What is the context in the Strategy Pattern?
The context is the class that uses a strategy without depending directly on its concrete implementation.
Can WordPress services use Strategy?
Yes. An application service can receive a strategy through constructor dependency injection.
Can Strategy work with Factory?
Yes. A factory can select and create the strategy required by the application.
Can Strategy be used with WooCommerce?
Yes. Shipping, pricing, payment, recommendations, discounts, and export behavior are common WooCommerce use cases.
Can Strategy be used for AI providers?
Yes. Multiple AI providers can implement a common provider strategy interface.
Can Strategy be used for payment gateways?
Yes. Payment implementations can share a common strategy interface when the application's payment workflow is designed around interchangeable providers.
Should every conditional be converted into a Strategy?
No. Strategy adds abstraction. Use it when behavior is meaningfully different or likely to evolve independently.
Can too many strategies hurt a plugin?
Yes. Excessive classes and abstractions can make simple logic harder to understand.
Should a strategy contain database queries?
Preferably not when database access can be isolated in repositories or infrastructure components. The strategy should focus on its algorithm.
Should a strategy call external APIs directly?
It can when the strategy itself represents a provider implementation, but larger architectures often separate provider-specific API communication into adapters or clients.
Can Strategy and Adapter be used together?
Yes. Strategy can represent application-level interchangeable behavior while Adapter translates provider-specific APIs.
Can Strategy and Repository be used together?
Yes. A strategy can receive a repository to retrieve data required for its algorithm.
Can Strategy and Decorator be used together?
Yes. A strategy can be wrapped with caching, logging, metrics, or retry behavior.
Can Strategy work with a service container?
Yes. A service container can construct and inject a selected strategy.
Should every strategy have its own interface?
Each group of interchangeable behaviors should generally have a focused contract. Avoid a generic StrategyInterface for unrelated features.
What is a good strategy interface?
A good strategy interface describes one domain-specific behavior clearly.
For example:
interface ShippingStrategyInterface { public function calculate( array $order ): float; }
How should I select a strategy?
Use controlled configuration, a factory, or explicit dependency injection depending on whether the strategy is selected dynamically or fixed for the application.
Is arbitrary class instantiation safe for Strategy?
No. Never allow untrusted input to become an unrestricted PHP class name. Use explicit identifiers and allowlisted implementations.
What namespace should Strategy classes use?
A structure such as:
Kaddora\MyPlugin\Strategies
can work well, or strategies can live within domain-specific modules.
Can AI help design Strategy architectures?
Yes. AI can identify repeated conditionals, group interchangeable behaviors, suggest contracts, and generate test cases.
Should AI convert every if statement into Strategy?
No. Many conditionals are simpler and clearer without a Strategy hierarchy.
Can Strategy help refactor a large WordPress plugin?
Yes. Repeated behavior branches can sometimes be extracted into focused strategies, reducing the responsibilities of large service classes.
Why choose ThemeKaddora?
ThemeKaddora develops WordPress themes, plugins, WooCommerce solutions, AI products, HTML templates, UI kits, SaaS-oriented solutions, and business-focused digital products using maintainable architecture, modern PHP practices, dependency injection, API integrations, testing, performance considerations, and scalable engineering workflows.
Comments (0)