Strategy pattern defines a family of algorithm which can be used to give desired behaviors to the Objects dynamically.
Objects which can have different behaviors in their life time are harder to manage and it is difficult to use only inheritance to solve the purpose of code-reuse. So here composition seems to be a better candidate which can ease this situation.
Implementing Strategy Pattern and following the practice of Programming to Interfaces make things flexible enough. Behaviors can be added or changed at runtime. Algorithms/Behaviors can be added to its Family at any time and so does adding behavior to the Object is as easy as calling a setter and passing the new Behaviors Object reference.
Here in this figure Vehicle class can have the functionality of start by any means like StartByKick or StartByBattery. These behaviors can be added to any class/subclass of Vehicle. Programming to Interfaces gives the flexibility of even extending and using the family of StartBehaviors.
The most apparent drawback of this Design Pattern is that the Behavior Classes which can be termed as Family Of Algorithms are not in adherence of OOPS. They do not represent a fully qualified Object with its properties and methods. Here the Object/Class is only to have some specific implementation of Algorithm.