Extension Trade-offs — Decision Matrix

Four Core Mechanisms

1. Plugins — intercept specific method calls
2. Observers — react to dispatched events
3. Preferences — replace entire class implementations
4. Service Contracts — define stable API interfaces

How They Relate

Service Contracts define the API
  -> Preferences replace implementations
  -> Plugins modify behavior on top
  -> Observers react to side effects

Comparison Table

When to Use What

Combining Mechanisms

// Service Contract defines the interface
interface ProductRepositoryInterface {
    public function get($sku, $editMode = false, $storeId = null, $forceReload = false);
}

// Preference provides default implementation
class ProductRepository implements ProductRepositoryInterface {
    public function get($sku, ...) { /* ... */ }
}

// Plugin adds caching
public function aroundGet($subject, $proceed, $sku, ...) {
    return $this->cache->remember('product_' . $sku, fn() => $proceed($sku, ...));
}

// Observer handles side effects after save
$this->eventManager->dispatch('catalog_product_save_after', ['product' => $product]);

Plugin Maintainability

Pros:

• Composable across modules
• Easy to disable
• Upgrade safe
• Granular control

Cons:

• Generated code can be confusing
• Debugging requires understanding interception
• Too many plugins on one method create complex chains

Observer Maintainability

Pros:

• Clean separation of concerns
• Easy to add/remove
• One-to-many patterns
• No method coupling

Cons:

• Hard to trace execution flow
• No return values
• Event data can be modified unexpectedly
• Debugging requires logging

Preference Maintainability

Pros:

• Full control over class behavior
• Can add new methods
• Direct override

Cons:

• Only one per class
• Upgrade fragile
• Hard to compose
• Can break other modules

Service Contract Maintainability

Pros:

• Stable API across versions
• Interface-based testing
• Clear boundaries
• Upgrade safe

Cons:

• More upfront design
• Cannot modify existing contracts
• Requires versioning strategy

Performance Metrics

Performance Best Practices

// Bad: too many plugins on one method
<type name="Product">
    <plugin name="plugin1" type="..." sortOrder="10"/>
    <plugin name="plugin2" type="..." sortOrder="20"/>
    <plugin name="plugin3" type="..." sortOrder="30"/>
    <plugin name="plugin4" type="..." sortOrder="40"/>
    <plugin name="plugin5" type="..." sortOrder="50"/>
</type>

// Good: consolidate into one plugin with internal logic
<type name="Product">
    <plugin name="product_enhancer" type="Vendor\Plugin\ProductEnhancer" sortOrder="10"/>
</type>

Decision Checklist

1. Need to modify args/returns? -> Plugin
2. Need side effects? -> Observer
3. Need full class replacement? -> Preference
4. Need stable API? -> Service Contract
5. Need custom fields? -> Extension Attributes
6. Can multiple modules extend? -> Plugin or Observer (not Preference)
7. Upgrade safety critical? -> Plugin, Observer, or Service Contract