TLDR;
This video explains the Strategy Design Pattern, a way to make code more flexible and easier to change. It starts by explaining what design patterns are and why they're useful, then uses an example of simulating robots to show how inheritance can lead to problems. The video then introduces the Strategy Pattern as a solution, where different algorithms (like walking, talking, or flying) are put into separate classes that can be swapped out at runtime. This makes the code more adaptable to new features and avoids repeating code. The video also covers the code implementation, UML diagram, and real-life examples of the Strategy Pattern.
- Design patterns are solutions to common problems in software design.
- The Strategy Pattern involves separating different algorithms into separate classes.
- Composition is favored over inheritance.
Introduction [0:00]
Design patterns are pre-existing solutions to common problems in software development. They allow developers to reuse the wisdom of others who have faced similar challenges. Applications are constantly evolving, so designs should be flexible to accommodate new features with minimal code changes. Design patterns, along with object-oriented principles and SOLID principles, help create better, more flexible, and evolving designs. The key is to identify the static and dynamic parts of an application, separating the changing parts into separate classes to minimize the impact of changes on the rest of the application.
Robot Example Problem [3:01]
Consider an application that simulates robots. A basic robot class might have features like walking, talking, and a projection (appearance). Initially, there are two types of robots: companion robots and worker robots. Both inherit from the robot class and override the projection method to define their unique appearances, while walking and talking remain common.
Why Inheritance is Bad [4:08]
Inheritance allows a child class to extend the features of a parent class. However, problems arise when new types of robots with different behaviors are introduced. For example, a new "Sparrow" robot can fly, requiring a new fly method. If many robots can fly, the same fly code would be repeated in each robot class, violating the DRY (Don't Repeat Yourself) principle. Moving the fly method to the parent class would make all robots fly, which is not desired. Increasing the inheritance hierarchy by creating "Flyable" and "Non-Flyable" robot classes can lead to a complicated inheritance tree as more behaviors are added (e.g., robots that fly with jets, robots that can't walk or talk). The solution to inheritance is not more inheritance.
Defining Strategy Pattern [12:04]
The Strategy Design Pattern defines a family of algorithms, putting them into separate classes so that they can be changed at run time.
Revisiting Robot problem [12:26]
To apply the Strategy Pattern to the robot example, first identify the parts of the robot class that change frequently: talking, walking, and flying. These should be separated from the robot class, leaving only the projection method, which remains constant.
Revisiting Definition [21:05]
The Strategy Pattern defines a family of algorithms (talk, walk, fly) and puts them into separate classes (Talkable, Walkable, Flyable) so they can be changed at run time.
Code for Strategy Pattern [23:05]
Create interfaces (or abstract classes) for each behavior: Talkable, Walkable, and Flyable. Each interface defines a single method (talk, walk, fly). Then, create concrete classes that implement these interfaces, providing different implementations for each behavior (e.g., NormalTalk, NoTalk, NormalWalk, NoWalk, NormalFly, NoFly). The robot class then uses composition to hold references to these interfaces, allowing it to dynamically change its behavior at run time. The robot class becomes a "dumb object" that delegates its behavior to the composed interfaces.
Using more less inheritance [25:40]
To completely remove inheritance, the projection method can also be extracted into a separate interface (Projectable) with concrete implementations for different robot appearances. The robot class would then hold a reference to a Projectable object, further increasing flexibility.
Standard UML for Strategy Pattern [27:40]
The standard UML diagram for the Strategy Pattern includes a client class (e.g., the robot class) that uses a strategy interface. Concrete strategy classes implement the strategy interface, providing different algorithms. The client holds a reference to the strategy interface and delegates the execution of the algorithm to the concrete strategy.
Real life example [29:26]
Real-life examples of the Strategy Pattern include payment systems that support different payment methods (UPI, credit/debit card, net banking) and sorting algorithms that offer different sorting strategies (quick sort, merge sort, insertion sort). In each case, the client class (payment system or sorting class) uses a strategy interface to dynamically select the appropriate algorithm at run time.
Conclusions [32:05]
The Strategy Design Pattern is a useful tool for building flexible and maintainable applications. It promotes composition over inheritance, allowing developers to easily add new behaviors without modifying existing code. This pattern is commonly used in various applications and is a valuable topic for software design interviews.