LearningTree
Design Tactics to
Reduce Coupling
Patterns and strategies to reduce structural, instantiation, and call dependencies β and a comparison of static vs. dynamic coupling trade-offs.
01
Chapter One Β· Reduce Coupling
Design Tactics to Reduce Coupling in Structural Dependencies
A Structural Dependency exists when a component is directly reliant on the structure or design of another component β changes to one can ripple and break the other.
Polymorphism
- Program to interfaces β depend on abstractions, not concrete types
Decorator Pattern
- Wrap & extend behaviour without modifying original classes
Favour Composition
- Compose objects at runtime instead of rigid inheritance hierarchies
Two Types of Structural Dependencies
Type 1 β Inheritance
- Subclass is directly coupled to the structure of the superclass
- Change to a constructor name or method in the parent directly affects all subclasses
- Highest form of structural coupling β tight coupling
Type 2 β Type Usage
- A component uses a concrete type of another component directly
- Any change to the concrete class (constructor, method name) affects all consumers
- Can be mitigated using abstractions (interfaces)
Tactics to Handle Coupling in Structural Dependencies
1
Polymorphism β Program to an Interface
Instead of depending on a concrete type, depend on an abstraction (interface). Multiple implementations can be swapped without the caller knowing.
❌ Tight β concrete type dependency
Problem:
NotificationService directly references the concrete EmailNotification class β switching to SMS or push requires modifying the service.✓ Loose β interface dependency
Solution: Depend on a
Notification interface. EmailNotification, SmsNotification, etc. implement it β the service never changes.2
FaΓ§ade Pattern β Hide Complexity Behind a Simple Interface
Introduce a Facade between your application and a complex third-party library. The application depends only on the Facade's clean interface β the underlying complexity is hidden and swappable.
❌ Without Facade
Problem:
WebAppdirectly depends onCredentials,ConfigManager, andDataStorage- Changing the library forces changes everywhere in the app
- Every consumer must understand internal library details
✓ With StorageFacade
Solution:
WebAppdepends only onStorageFacade- Facade hides third-party complexity behind a clean interface
- Swap the underlying library without touching the app
3
Decorator Pattern β Add Behaviour Without Inheritance
Instead of adding features directly to a class via inheritance, wrap the class with a Decorator that implements the same interface. Features are composed, not inherited.
❌ Problem β Inheritance subclass explosion
Problem:
CoreRequestHandler needs optional features. Adding each via inheritance creates tight coupling and an unmanageable subclass explosion.✓ Solution β Decorator Chain
Solution:
IHttpRequestHandler (interface) β CoreRequestHandler + RequestHandlerDecorator (abstract) β concrete decorators composed at runtime.Decorator Implementations
Authentication Decorator
public class AuthenticationDecorator extends RequestHandlerDecorator {
public HttpResponse handle(
HttpRequest req) {
if (!authenticate(req)) {
return new HttpResponse(401,
"Unauthorized");
}
return wrappedHandler.handle(req);
}
}
Caching Decorator
public class CachingDecorator extends RequestHandlerDecorator {
public HttpResponse handle(
HttpRequest req) {
HttpResponse cached =
getCachedResponse(req);
if (cached != null) return cached;
HttpResponse res =
wrappedHandler.handle(req);
cacheResponse(req, res);
return res;
}
}
Compression Decorator
public class CompressionDecorator extends RequestHandlerDecorator {
public HttpResponse handle(
HttpRequest req) {
HttpResponse res =
wrappedHandler.handle(req);
return compressResponse(res);
}
}
Composing Decorators at Runtime
Component A β Basic (no extras)
handler = new CoreHttpHandler();
// No decorators β minimal
Component B β Auth + Compression
handler = new AuthenticationDecorator(
new CompressionDecorator(
new CoreHttpHandler()
)
);
Component C β Cache + Compression
handler = new CompressionDecorator(
new CachingDecorator(
new CoreHttpHandler()
)
);
Benefit: Each component composes only the features it needs β no inheritance coupling, no feature explosion. Adding a new decorator (e.g.
RateLimitingDecorator) requires zero changes to existing classes.📋 Chapter 1 — Summary
- Structural dependencies (inheritance and type usage) create tight coupling
- Two types: Inheritance (tightest) & Type Usage (concrete type dependency)
- Polymorphism β program to interfaces, not concrete types
- FaΓ§ade Pattern β hide third-party complexity behind a simple interface
- Decorator Pattern β compose behaviour without inheritance (no subclass explosion)
- Chain decorators for flexible, runtime feature composition
02
Chapter Two Β· Reduce Coupling
Design Tactics to Reduce Coupling in Instantiation Dependencies
An Instantiation Dependency (Creation Coupling) occurs when a component directly creates an instance of another component using new β making it tightly bound to the concrete implementation.
Factory Pattern
- Centralise object creation β consumers don't know the concrete type
Proxy Pattern
- Lazy initialisation β create objects only when actually needed
Dependency Injection
- Dependencies injected from outside by a DI container / assembler
Three Tactics for Instantiation Dependencies
1. Factory Pattern
- Centralise object creation in a factory class
- Consumer asks factory for an object β doesn't know the concrete type
- Adding new types = change factory only
2. Proxy Pattern
- Lazy initialisation β create object only when needed
- Proxy sits between client and real object
- Enables permission/auth checks without touching real class
3. Dependency Injection
- Dependencies are injected from outside, not created internally
- Component doesn't decide which implementation to use
- Wiring done by a DI container / assembler
Tactic 1 β Factory Pattern
❌ Without Factory β grows with every new type
Problem:
PolicySalesAgent directly instantiates policy classes. Adding HealthInsurancePolicy requires modifying PolicySalesAgent β tight coupling.✓ With Factory β consumer decoupled from creation
Solution:
PolicySalesAgent delegates creation to InsurancePolicyFactory. Adding new policy types only changes the factory β agent never changes.Tactic 2 β Proxy Pattern (Lazy Initialisation)
❌ Without Proxy β eager creation everywhere
Problem: All clients create
StudentAccountManager eagerly β even when not needed. Can't modify a third-party class to add lazy init or auth checks.✓ With Proxy β lazy init & cross-cutting concerns
Solution: A
StudentAccountManagerProxy wraps the real class, controls lazy init, and can add auth checks without touching the real class or any client.Tactic 3 β Dependency Injection (DI)
❌ Without DI β OrderService creates its own dependencies
Problem:
OrderService uses new to create concrete implementations β tightly coupled, untestable, and impossible to swap without changing the class.✓ With DI β dependencies injected from outside
Solution: Dependencies are injected via constructor. A DI container wires the concrete implementations at startup β
OrderService depends only on interfaces.📋 Chapter 2 — Summary
- Instantiation coupling occurs when components create their own dependencies using
new - Factory Pattern β centralise object creation; adding new types only changes the factory
- Proxy Pattern β lazy initialisation & cross-cutting concerns without touching the real class
- Dependency Injection β inject dependencies from outside; component doesn't decide implementation
- DI container wires concrete implementations at startup
03
Chapter Three Β· Reduce Coupling
Design Tactics to Reduce Coupling in Call Dependencies
A Call Dependency exists when one component directly calls methods or network endpoints of another. This includes both in-process method calls and cross-process network calls (same machine or different machines).
Abstractions
- Depend on interfaces, not concrete implementations
Adapter Pattern
- Bridge incompatible interfaces without structural coupling
No Cycles
- Eliminate circular AβBβA dependencies with layering
Async Messaging
- Replace direct calls with broker-based messages
Restrict Communication
- Enforce rules β only allowed connections via APIs & gateways
Five Tactics for Call Dependencies
π
1. Abstractions
Depend on interfaces, not concrete implementations. Callers are decoupled from who implements the contract.
π
2. Adapter Pattern
Bridge incompatible interfaces. Allows a component to call another without direct structural coupling.
π
3. Avoid Cyclical Relationships
Circular call dependencies (A→B→A) create unresolvable coupling. Use architecture layers to prevent them.
π¬
4. Asynchronous Messaging
Replace direct calls with messages via a broker. Sender decoupled from receiver β doesn't even need to know the receiver exists.
π§
5. Restrict Communication
Enforce communication rules (layers, APIs, gateways). Only necessary connections allowed β prevents spaghetti coupling.
Tactic 1 β Using Abstractions (Interfaces)
❌ Without Abstraction β direct concrete dependency
Challenge:
OrderService depends directly on CreditCardProcessor. Swapping payment providers requires changing the caller β tight call coupling.✓ With Abstraction β depend on interface
Principle: Define a common
PaymentProcessor interface. OrderService depends only on the interface β any implementation can be swapped without touching the caller.Tactic 2 β Adapter Pattern
❌ Without Adapter β incompatible interfaces
Problem:
OrderService calls processPayment(amount) but the bank provides BankAccountProcessor with debitAccount(amount, accountId) β incompatible signatures, can't plug in directly.✓ With Adapter β bridged to the expected interface
Solution:
BankPaymentAdapter implements PaymentProcessor and wraps BankAccountProcessor, translating processPayment(amt) β debitAccount(amt, id). Neither side changes.Tactic 3 β Avoid Cyclical (Circular) Relationships
❌ Cyclical Dependencies β Problematic
- A calls B, B calls C, C calls A β circular loop
- Cannot build or deploy components independently
- Changes ripple in all directions β unpredictable
- Testing becomes impossible without the full cycle
✓ Layered Architecture β No Cycles
- Enforce one-directional call flow (top → bottom layers)
- Presentation → Business Logic → Data Access → Database
- No lower layer ever calls an upper layer
- Use dependency inversion if a lower layer needs to notify an upper one
Tactic 4 β Asynchronous Messaging
Pattern: Microservice A sends a message to a Message Broker / Queue. Microservice B subscribes and processes the message asynchronously. A and B never directly call each other.
- Sender doesn't expect data back → less dependency → less coupling
- Sender uses the broker interface, not the receiver's interface
- Receiver can be replaced, scaled, or taken offline independently
- Caveat: Cannot convert every call dependency to messaging β use where the result is not immediately needed
Tactic 5 β Restrict Communication
❌ Unrestricted β Every component calls every other
- Any service can call any other service directly
- Creates a spaghetti architecture β tangled, unmaintainable
- A change anywhere can break anything else
- No clear ownership or contract boundaries
✓ Restricted β Only necessary connections allowed
- Enforce API Gateway / layer boundaries
- Services only call components they are architecturally permitted to
- Reduces accidental coupling from ad-hoc shortcuts
- Cleaner, auditable, controllable communication graph
📋 Chapter 3 — Summary
- Call dependencies are the most common form of coupling β method calls & network calls
- Abstractions (interfaces) β decouple callers from concrete callees
- Adapter Pattern β bridge incompatible interfaces without changing either side
- No cyclical relationships β enforce one-directional call flow (layered architecture)
- Async Messaging β broker decouples sender & receiver; sender doesn't need to know the receiver
- Restrict Communication β enforce architecture rules via API gateways and layer boundaries
04
Chapter Four Β· Coupling Types
Static vs Dynamic Coupling
Important caveat: Moving from static coupling to dynamic coupling does NOT necessarily reduce coupling β it only changes when dependencies are resolved.
Static Coupling
- Dependencies resolved at compile time β visible in source code & type system
Dynamic Coupling
- Dependencies resolved at runtime β via DI, reflection, or configuration
Definitions
π
Static Coupling
- Explicit, fixed, or hard-coded dependencies
- Determined at compile time β without running the application
- Describes how components are "wired" to each other
- Example:
new CreditCardService()insideOrderServiceconstructor
β‘
Dynamic Coupling
- Dependencies are resolved at runtime
- Describes how components "call each other" during execution
- Example: DI injection β only at runtime do we know which implementation is used
- Example: Service Discovery β DNS resolves address at runtime
E-Commerce Application β Code Examples
Static Coupling β concrete class hardcoded at compile time
public class OrderService {
private PaymentService paymentService;
public OrderService() {
// Hardcoded β static coupling this.paymentService =
new CreditCardService();
}
public void placeOrder(double amount) {
paymentService.processPayment(amount);
}
}
Dynamic Coupling β resolved at runtime via DI
public class OrderService {
private PaymentService paymentService;
// Which impl? Only known at runtime public OrderService(
PaymentService paymentService) {
this.paymentService = paymentService;
}
public void placeOrder(double amount) {
paymentService.processPayment(amount);
}
}
Data Dependency Examples β Static vs Dynamic
Static β hardcoded IP address
# App 1 β App 2 via hardcoded URL API_URL = "http://192.168.1.100:8081/api/data"
response = requests.get(API_URL)
# Change the IP β must change code & redeploy
Dynamic β service discovery resolves at runtime
# App 1 β Service Discovery β App 2 API_URL = "http://app2.domain/api/data"
response = requests.get(API_URL)
# DNS resolves "app2.domain" at runtime # Move App 2 β update discovery only
Advantages & Disadvantages
| Dimension | Static Coupling | Dynamic Coupling |
|---|---|---|
| Resolution Time | Compile time | Runtime |
| Performance | ✓ Less overhead β no reflection, DNS, or config parsing | ✗ Higher overhead β reflection, DNS resolution, config parsing |
| Tooling Support | ✓ Excellent β IDE autocompletion, refactoring, static analysis, compile-time errors | ✗ Limited β IDE can't trace dynamic lookups; no compiler errors |
| Readability | ✓ Easier to read, reason about, and maintain | ✗ Harder to trace β debugging and troubleshooting are complex |
| Flexibility | ✗ Rigid β modifying dependencies requires rebuild & redeploy | ✓ Flexible β modify dependencies without rebuild; move faster with new features |
| Extensibility | ✗ Harder to extend β changing a dep means redeploying all consumers | ✓ Greater potential β swap implementations via config, DI, or discovery |
| Runtime Risk | ✓ Lower β issues caught at compile time | ✗ Higher risk of runtime failures β missing dependencies, misconfiguration |
| Debugging | ✓ Easy β IDE, compiler & static analysis tools fully supported | ✗ Difficult β hard to analyse dependencies; restricted production access |
Important Caveat
⚠ Moving from static to dynamic coupling does NOT necessarily reduce coupling.
Example: Injecting
Similarly, splitting a monolith into microservices without careful design produces: Low Cohesion → Tight Coupling β now with no static analysis and no compile-time error detection.
Example: Injecting
PayPalService into OrderService via a DI assembler makes the dependency dynamic β but OrderService is still coupled to PayPalService. The coupling exists; it's just resolved at a different time.Similarly, splitting a monolith into microservices without careful design produces: Low Cohesion → Tight Coupling β now with no static analysis and no compile-time error detection.
Dynamic β Decoupled β DI still couples to PayPalService
Monolith β Microservices β automatic decoupling
Rule of thumb: Use static coupling as the default β it's more predictable and maintainable. Use dynamic coupling selectively where runtime flexibility genuinely adds value (config-driven deployments, plugin architectures, service discovery).
📋 Chapter 4 — Summary
- Static and dynamic coupling are different trade-off profiles, not good vs. bad
- Static coupling = dependencies wired at compile time β better tooling, performance, readability
- Dynamic coupling = dependencies resolved at runtime β flexibility, extensibility
- Dynamic coupling risks: higher runtime risk, harder debugging, limited static analysis
- Dynamic β less coupling β it's just resolved at a different time
- Monolith β microservices β automatic decoupling β poor splits produce tight coupling without compile-time safety
- Rule of thumb: use static by default; dynamic only where runtime flexibility genuinely adds value
Summary β All Four Coupling Topics at a Glance
01 Β· Structural
Structural Dependencies
- Inheritance β tightest coupling
- Type usage β concrete type dependency
- Polymorphism β program to interfaces
- FaΓ§ade β hide third-party complexity
- Decorator β compose over inherit
02 Β· Instantiation
Instantiation Dependencies
- Creation coupling β using new directly
- Factory Pattern β centralised creation
- Proxy Pattern β lazy init & cross-cutting
- Dependency Injection β inject from outside
- DI container wires at startup
03 Β· Call
Call Dependencies
- Method calls & network calls
- Abstractions (interfaces)
- Adapter Pattern
- Avoid cyclical relationships
- Async Messaging via broker
- Restrict Communication
04 Β· Static vs Dynamic
Static vs Dynamic Coupling
- Static = compile-time wiring
- Dynamic = runtime resolution
- Static: tooling, performance, clarity
- Dynamic: flexibility, extensibility
- Dynamic ≠ less coupling
Type 1 β Inheritance Coupling
Java β Structural coupling via inheritance
class Animal {
Animal(String name) { ... } // rename this β
} // breaks ALL subclasses class Dog extends Animal {
Dog() { super("Dog"); } // β coupled to Animal constructor
}
Type 2 β Type Usage Coupling
Java β Structural coupling via concrete type usage
class OrderService {
// Tightly coupled to concrete type private CreditCardService service
= new CreditCardService();
}
Polymorphism β Tight Concrete Dependency
Java β Concrete dependency
class NotificationService {
private EmailNotification notifier
= new EmailNotification();
}
Polymorphism β Program to an Interface
Java β Interface-based dependency
interface Notification {
void send(String message);
}
class EmailNotification implements Notification {
public void send(String message) { ... }
}
class SmsNotification implements Notification {
public void send(String message) { ... }
}
class NotificationService {
private Notification notifier;
// Email, SMS, App β all work!
}
Without FaΓ§ade β Direct Coupling
Java β WebApp tightly coupled to library internals
// Third-party cloud storage library classes class Credentials {
public String getToken() { ... }
}
class ConfigurationManager {
public void load(String path) { ... }
}
class DataStorage {
public void save(String key, Object data) { ... }
public Object get(String key) { ... }
}
// β WebApp directly uses ALL library classes class WebApp {
private Credentials creds = new Credentials();
private ConfigurationManager config =
new ConfigurationManager();
private DataStorage storage = new DataStorage();
public void run() {
creds.getToken();
config.load("/config");
storage.save("key", data);
}
}
With FaΓ§ade β Clean Interface
Java β Facade hides third-party complexity
// Facade wraps and hides library complexity class StorageFacade {
private Credentials creds;
private ConfigurationManager config;
private DataStorage storage;
public StorageFacade() {
this.creds = new Credentials();
this.config = new ConfigurationManager();
this.storage = new DataStorage();
config.load("/config");
}
public void save(String key, Object data) {
storage.save(key, data);
}
public Object get(String key) {
return storage.get(key);
}
}
// β WebApp only knows the Facade class WebApp {
private StorageFacade storage =
new StorageFacade();
public void run() {
storage.save("key", data);
Object result = storage.get("key");
}
}
// Swap library β change Facade only!
Problem β Inheritance Subclass Explosion
Java β Tight coupling via inheritance
class CoreRequestHandler {
public HttpResponse handle(HttpRequest req) { ... }
}
// Need auth? Extend. class AuthCoreHandler extends CoreRequestHandler { ... }
// Need cache? Extend again. class CacheCoreHandler extends CoreRequestHandler { ... }
// Need auth + cache? Yet another class! class AuthCacheCoreHandler extends CoreRequestHandler { ... }
// 3 features β up to 7 subclasses. N features β 2α΄Ί subclasses!
Solution β Decorator Chain
Java β Compose decorators at runtime
interface IHttpRequestHandler {
HttpResponse handle(HttpRequest req);
}
abstract class RequestHandlerDecorator implements IHttpRequestHandler {
protected final IHttpRequestHandler wrapped;
protected RequestHandlerDecorator(
IHttpRequestHandler h) { this.wrapped = h; }
}
class AuthenticationDecorator extends RequestHandlerDecorator {
public HttpResponse handle(HttpRequest req) {
if (!authenticate(req))
return new HttpResponse(401, "Unauthorized");
return wrapped.handle(req);
}
}
// Component B β Auth + Compression, no subclass needed: IHttpRequestHandler handler =
new AuthenticationDecorator(
new CompressionDecorator(
new CoreRequestHandler()
)
);
Without Factory β Tight Creation Coupling
Java β PolicySalesAgent tightly coupled to concrete types
public void sellInsurancePolicy(
Customer c, PolicyDetails d) {
InsurancePolicy policy;
if ("home".equals(d.getType()))
policy = new HomeInsurancePolicy(c, d);
else if ("car".equals(d.getType()))
policy = new CarInsurancePolicy(c, d);
else if ("health".equals(d.getType()))
policy = new HealthInsurancePolicy(c, d);
// β Add new type β must edit this method again
}
With Factory β Decoupled Creation
Java β Factory centralises creation; agent never changes
interface InsurancePolicy { void activate(); }
class InsurancePolicyFactory {
public InsurancePolicy createInsurancePolicy(
String type) {
return switch (type) {
case "home" -> new HomeInsurancePolicy();
case "car" -> new CarInsurancePolicy();
case "health" -> new HealthInsurancePolicy();
default -> throw new IllegalArgumentException(type);
};
}
}
class PolicySalesAgent {
private final InsurancePolicyFactory factory;
public void sellInsurancePolicy(
Customer c, PolicyDetails d) {
InsurancePolicy policy =
factory.createInsurancePolicy(d.getType());
// No if/else β agent never changes for new types
policy.activate();
}
}
Without Proxy β Eager Coupling
Java β Clients directly instantiate concrete class
class EnrollmentService {
// Eagerly created β even if never used private StudentAccountManager mgr =
new StudentAccountManager();
public void enrollStudent(Student s) {
mgr.createAccount(s);
}
}
// Every client duplicates the same instantiation class GradeService {
private StudentAccountManager mgr =
new StudentAccountManager(); // β duplicate
}
With Proxy β Lazy Init & Cross-Cutting Concerns
Java β Proxy wraps real class; clients depend on interface
interface AccountManager {
void createAccount(Student s);
}
class StudentAccountManagerProxy implements AccountManager {
private StudentAccountManager real;
public void createAccount(Student s) {
if (real == null)
real = new StudentAccountManager(); // lazy if (!hasPermission(s)) throw new SecurityException();
real.createAccount(s);
}
}
// Clients depend on the interface β never on the real class class EnrollmentService {
private final AccountManager mgr; // β interface only public EnrollmentService(AccountManager mgr) {
this.mgr = mgr;
}
}
Without Abstraction β Concrete Call Dependency
Java β OrderService tightly coupled to CreditCardProcessor
class OrderService {
// Hardcoded concrete type β tight call coupling private CreditCardProcessor processor =
new CreditCardProcessor();
public void placeOrder(double amount) {
processor.processCard(amount, card);
// Swap to PayPal β must change this class
}
}
With Abstraction β Interface-Based Call Dependency
Java β OrderService depends only on PaymentProcessor interface
interface PaymentProcessor {
void processPayment(double amount);
}
class CreditCardProcessor implements PaymentProcessor {
public void processPayment(double amount) { ... }
}
class PayPalProcessor implements PaymentProcessor {
public void processPayment(double amount) { ... }
}
class OrderService {
private final PaymentProcessor processor; // β interface public OrderService(PaymentProcessor p) {
this.processor = p;
}
public void placeOrder(double amount) {
processor.processPayment(amount);
// Swap to PayPal β inject PayPalProcessor β no change here
}
}
Without Adapter β Incompatible Interface
Java β BankAccountProcessor can't implement PaymentProcessor directly
interface PaymentProcessor {
void processPayment(double amount);
}
// Third-party β cannot modify class BankAccountProcessor {
void debitAccount(double amount, String accountId) { ... }
}
// β Cannot do this β method signatures don't match: // class BankAccountProcessor implements PaymentProcessor β FAILS // processPayment(double) β debitAccount(double, String)
With Adapter β Bridged Interface
Java β BankPaymentAdapter translates the call
interface PaymentProcessor {
void processPayment(double amount);
}
// Third-party β unchanged class BankAccountProcessor {
void debitAccount(double amount, String accountId) { ... }
}
// β Adapter bridges the incompatible interface class BankPaymentAdapter implements PaymentProcessor {
private final BankAccountProcessor bank;
public void processPayment(double amount) {
// Translates the call β neither side changes
bank.debitAccount(amount, "default-account");
}
}
// OrderService never knows about BankAccountProcessor PaymentProcessor p = new BankPaymentAdapter(
new BankAccountProcessor());
OrderService svc = new OrderService(p);
Without DI β Hardcoded Dependencies
Java β OrderService creates its own concrete dependencies
public class OrderService {
private PaymentService paymentService;
private ShippingService shippingService;
private NotificationService notificationService;
public OrderService() {
this.paymentService =
new PaymentServiceImpl(); // β tight coupling this.shippingService =
new ShippingServiceImpl();
this.notificationService =
new NotificationServiceImpl();
}
}
// Swap PaymentServiceImpl β must edit constructor
With DI β Injected Dependencies
Java β Dependencies injected via constructor; wired by DI container
public class OrderService {
private final PaymentService ps;
private final ShippingService ss;
private final NotificationService ns;
// DI container injects the right impl at runtime public OrderService(
PaymentService ps,
ShippingService ss,
NotificationService ns) {
this.ps = ps; this.ss = ss; this.ns = ns;
}
}
// Wired at startup β swap via config, not code: OrderService svc = new OrderService(
new PayPalService(), // swapped β new FedExShipping(),
new EmailNotification()
);