KapreSoft
From Coding to Cooking to Coins:
Antonio Lagnada's Blog on Software, Music, Food, and Finance
Antonio Lagnada's Blog on Software, Music, Food, and Finance
Navigating through the intricate landscape of software design, one often encounters the pivotal decision of whether to employ the strategy pattern or leverage polymorphism. As cornerstone concepts of object-oriented programming (OOP), each brings its unique advantages and potential pitfalls. This comprehensive guide is thoughtfully curated to elucidate the situations where the strategy pattern holds the upper hand over polymorphism, all the while maintaining a steadfast adherence to esteemed design principles.
The strategy pattern, a prestigious design pattern within the OOP domain, empowers the selection of an algorithm’s behavior dynamically at runtime. Rather than cementing commitment to a single algorithm, a diverse array of algorithms is meticulously carved out, with each residing in its distinct class. These classes are designed to be interchangeable, thereby bestowing upon the context the liberty to oscillate between them as necessitated by the situation at hand. This judicious encapsulation of behavior not only amplifies code re-usability but also _ flexibility and testability.
public interface PaymentStrategy {
void pay(int amount);
}
public class CreditCardPayment implements PaymentStrategy {
private String name;
private String cardNumber;
public CreditCardPayment(String name, String cardNumber) {
this.name = name;
this.cardNumber = cardNumber;
}
@Override
public void pay(int amount) {
// Implementation for credit card payment
}
}
public class PaypalPayment implements PaymentStrategy {
private String emailId;
public PaypalPayment(String emailId) {
this.emailId = emailId;
}
@Override
public void pay(int amount) {
// Implementation for PayPal payment
}
}
At the other end of the spectrum, polymorphism stands tall as another crucial concept in OOP. It extends the privilege to distinct classes to interpret a common method in their unique, bespoke manner. This is seamlessly actualized through inheritance, wherein a superclass lays down a method, subsequently allowing its progeny, the subclasses, to furnish specific implementations as they see fit.
Figure 1. Design Diagram of an Animal Polymorphism
Also available in: SVG | PlantText
This diagram visually represents the inheritance relationship where Dog and Cat classes extend the Animal class, with each of the three classes containing a sound method.
Here is a java code that represents this design:
public class Animal {
public void sound() {
System.out.println("Animal makes a sound");
}
}
public class Dog extends Animal {
public void sound() {
System.out.println("Dog barks");
}
}
public class Cat extends Animal {
public void sound() {
System.out.println("Cat meows");
}
}
Opting for the strategy pattern proves itself invaluable when confronted with a myriad of algorithms or behaviors pertaining to a particular task, each demanding the elasticity to be supplanted interchangeably at runtime. This methodology aligns seamlessly with the design principles advocating for program to interface, not implementation, while also championing the cause of composition over inheritance. The thoughtful encapsulation of behavior not only propels code re-usability but also ensures the maintenance of pristine, unblemished code.
Here’s a redesign of your classes using the strategy pattern:
Figure 2. Design Diagram of an Animal Sound Strategy
Also available in: SVG | PlantText
The diagram shows that DogSound, CatSound, and DefaultSound all implement the SoundStrategy interface and that the Animal class uses the SoundStrategy interface.
In this refactored design, the separate Dog and Cat classes are no longer necessary. Their distinct behaviors are encapsulated within their respective strategy classes, DogSound and CatSound, both of which implement the SoundStrategy interface. This approach aligns with the strategy pattern, allowing for flexible and interchangeable behavior at runtime. By encapsulating the sound-making behavior within these strategy classes, the design adheres to the principle of composition over inheritance, reducing complexity and enhancing maintainability.
Here is a java code that represents this design:
public interface SoundStrategy {
void makeSound();
}
public class Animal {
private SoundStrategy soundStrategy;
public Animal(SoundStrategy soundStrategy) {
this.soundStrategy = soundStrategy;
}
public void setSoundStrategy(SoundStrategy soundStrategy) {
this.soundStrategy = soundStrategy;
}
public void performSound() {
soundStrategy.makeSound();
}
}
public class DogSound implements SoundStrategy {
@Override
public void makeSound() {
System.out.println("Dog barks");
}
}
public class CatSound implements SoundStrategy {
@Override
public void makeSound() {
System.out.println("Cat meows");
}
}
public class DefaultSound implements SoundStrategy {
@Override
public void makeSound() {
System.out.println("Animal makes a sound");
}
}
In this example, we have an interface SoundStrategy with a method makeSound. This method is implemented by DogSound, CatSound, and DefaultSound, each providing a specific implementation for the sound the animal makes. The Animal class has a SoundStrategy field, and its constructor accepts a SoundStrategy object to initialize this field. The setSoundStrategy method allows changing the sound strategy dynamically. The performSound method in Animal delegates the responsibility of making a sound to the current soundStrategy object. This redesign aligns with the strategy pattern, encapsulating the sound-making behavior in separate classes and providing flexibility in changing the behavior at runtime.
Another example for instance, is a logistics operation in the throes of grappling with varying shipping strategies. Instead of entrenching each method within the codebase, it is astutely encapsulated within its dedicated class, thereby rendering them interchangeable based on the shifting sands of requirements.
Figure 2. Design Diagram of a Shipping Strategy
Also available in: SVG | PlantText
In this diagram, the Order class has an association with the ShippingStrategy interface, indicating that it uses the interface. The FedExShipping and UPSShipping classes implement the ShippingStrategy interface.
Here is a java code that represents this design:
public interface ShippingStrategy {
double calculateShippingCost(Order order);
}
public class FedExShipping implements ShippingStrategy {
@Override
public double calculateShippingCost(Order order) {
// Implementation for FedEx shipping cost calculation
return // FedEx specific calculation;
}
}
public class UPSShipping implements ShippingStrategy {
@Override
public double calculateShippingCost(Order order) {
// Implementation for UPS shipping cost calculation
return // UPS specific calculation;
}
}
public class Order {
private ShippingStrategy shippingStrategy;
public Order(ShippingStrategy shippingStrategy) {
this.shippingStrategy = shippingStrategy;
}
public void setShippingStrategy(ShippingStrategy shippingStrategy) {
this.shippingStrategy = shippingStrategy;
}
public double calculateShippingCost() {
return shippingStrategy.calculateShippingCost(this);
}
}
The given code snippet illustrates a strategy pattern implementation for calculating shipping costs in a flexible and interchangeable manner. The ShippingStrategy interface defines a single method, calculateShippingCost, which takes an Order as a parameter and returns a double representing the shipping cost.
Two concrete classes, FedExShipping and UPSShipping, implement this interface, each providing a specific method to calculate shipping costs according to FedEx and UPS respectively. The Order class has a ShippingStrategy field, and its constructor accepts a ShippingStrategy object to initialize this field. The setShippingStrategy method allows changing the shipping strategy dynamically.
The calculateShippingCost method in Order delegates the responsibility of calculating the shipping cost to the current shippingStrategy object, demonstrating the core principle of the strategy pattern where algorithms (shipping cost calculations in this case) are encapsulated in separate classes and can be easily switched at runtime.
When we consider the evolution and expansion of software applications, the difference in growth between polymorphism and the strategy pattern is quite distinct.
In the case of polymorphism, growth predominantly occurs through the mechanism of inheritance. As new functionalities or variants of existing functionalities are introduced, they are typically incorporated into the system by creating new subclasses that inherit from a common superclass. Each of these subclasses then provides its own specific implementation of the behavior dictated by the superclass. This approach tends to grow the class hierarchy vertically, adding more branches to the inheritance tree. However, this can sometimes result in a rigid structure that can be difficult to modify or extend as the system evolves.
Design Advantages:
Testability Advantages:
public class Animal {
public void sound() {
System.out.println("Animal makes a sound");
}
}
public class Dog extends Animal {
public void sound() {
System.out.println("Dog barks");
}
}
public class Cat extends Animal {
public void sound() {
System.out.println("Cat meows");
}
}
On the flip side, the strategy pattern facilitates growth through the addition of new behavioral implementations. As the need for new behaviors arises, new classes encapsulating these behaviors are created and made interchangeable with existing behaviors. This approach grows the system horizontally, adding more options for behavior without modifying the existing class hierarchy. This results in a more flexible and maintainable structure that can easily adapt to changes over time.
Design Advantages:
Testability Advantages:
public interface ShippingStrategy {
double calculateShippingCost(Order order);
}
public class FedExShipping implements ShippingStrategy {
@Override
public double calculateShippingCost(Order order) {
// Implementation for FedEx shipping cost calculation
return // FedEx specific calculation;
}
}
public class UPSShipping implements ShippingStrategy {
@Override
public double calculateShippingCost(Order order) {
// Implementation for UPS shipping cost calculation
return // UPS specific calculation;
}
}
In summary, while polymorphism tends to grow the system through inheritance, resulting in a potentially rigid vertical structure, the strategy pattern promotes horizontal growth by adding new behavioral implementations. This fundamental difference highlights the flexibility and maintainability advantages offered by the strategy pattern in adapting to the ever-evolving landscape of software applications. The strategy pattern also tends to be more test-friendly, offering ease of testing different behaviors in isolation.
When testing polymorphic classes, you often find yourself writing separate tests for each subclass, which can lead to duplicate assertions. For example:
@Test
public void testDogSound() {
Animal dog = new Dog();
assertEquals("Dog barks", dog.sound());
}
@Test
public void testCatSound() {
Animal cat = new Cat();
assertEquals("Cat meows", cat.sound());
}
@Test
public void testDefaultAnimalSound() {
Animal animal = new Animal();
assertEquals("Animal makes a sound", animal.sound());
}
In the above example, each subclass of Animal requires a separate test, even though the assertion logic is quite similar. This can result in redundant code and increase the maintenance burden as the number of subclasses grows.
Conversely, when using the strategy pattern, we can test the behaviors independently and then test their integration with the Animal class separately:
@Test
public void testAnimalWithDogSound() {
SoundStrategy dogSound = new DogSound();
Animal animal = new Animal(dogSound);
assertEquals("Dog barks", animal.performSound());
}
@Test
public void testDogSound() {
SoundStrategy dogSound = new DogSound();
assertEquals("Dog barks", dogSound.makeSound());
}
@Test
public void testCatSound() {
SoundStrategy catSound = new CatSound();
assertEquals("Cat meows", catSound.makeSound());
}
In this example, the DogSound and CatSound behaviors are tested independently of the Animal class. We then have a single test for the Animal class with the DogSound behavior, significantly reducing duplicate assertions. This approach simplifies the testing process and ensures scalability as new behaviors are introduced.
The ease of testing is a good indicator that the strategy pattern provides a clear advantage in scenarios where behavior needs to be changed dynamically. By isolating behaviors and making them interchangeable, the strategy pattern facilitates a more modular and maintainable design. This translates to simpler and more effective testing procedures, as each behavior can be tested in isolation, and their integration with the main class can be verified with minimal tests.
Compared to the redundancy in testing polymorphic classes, this serves as a strong testament that a strategy pattern is best for this case. The modular nature of the strategy pattern allows for independent testing of behaviors and their integration, significantly reducing the complexity and duplication often found in testing polymorphic classes.
The intricate tapestry of software design is masterfully woven from myriad threads of strategic decisions, among which the pivotal choice between the strategy pattern and polymorphism prominently stands.
In cases where your design finds itself entangled in the complexities of polymorphism, it might be judicious to shift towards a more behavioral approach, as encapsulated by the strategy pattern. This method doesn’t just bring clarity and flexibility to your design process, effectively easing the traversal through multifaceted design challenges, but it also significantly bolsters the testability of your system. Such an enhancement in testability proves invaluable, as it facilitates the independent validation of each behavior or strategy, thereby streamlining the testing process.
The strategy pattern emerges as a paragon of flexibility, proffering a resilient framework that deftly accommodates the interchangeability of algorithms or behaviors in real-time. Deeply rooted in time-honored design principles, it stands as a monumental tribute to the indispensability of code re-usability and the unwavering pursuit of impeccable, flawless code. The utility of the strategy pattern is abundantly clear, particularly in scenarios that demand the meticulous encapsulation of behavior, as eloquently illustrated by the previously discussed example of shipping cost calculations. Ultimately, this approach doesn’t merely solve problems; it resolves them with unparalleled elegance and efficiency, epitomizing the very essence of clean, maintainable code.