One of the principles of reusable object oriented design mentioned on the GOF book is "Program to an interface not an implementation".
This is one of the object oriented design rule of thumb which an experience software designer needs to consider when designing software systems; this is used across all across design patterns in one way or another i.e. Strategy Pattern. When programming to interface you commit to to the definition of an interface defined by an interface or an abstract class; you declare variables for the interface or abstract class then assign instance of the concrete classes to this declaration.
Class Diagram Drawing Tool Utilizing Strategy Pattern
Sample Code (for a drawing tool application)
DrawingTool myCurrentTool;
//Set Line Tool as the current tool
myCurrentTool = new LineTool();
//Set Ellipse Tool as the current tool
myCurrentTool = new EllipseTool();
//set Rectangle Tool as current tool
myCurrentTool = new RectangleTool();
Another good example could be a interest computation for different type of bank accounts you'll have a based account of Account the your concrete classes can be SavingsAccount, CheckingAccount, SuperSaverAccount and TimeDepositAccount for example. They can vary in the ComputeInterest method.
One important quote from Erich Gamma
"This principle is really about dependency relationships which have to be carefully managed in a large app. It's easy to add a dependency on a class. It's almost too easy; just add an import statement and modern Java development tools like Eclipse even write this statement for you. Interestingly the inverse isn't that easy and getting rid of an unwanted dependency can be real refactoring work or even worse, block you from reusing the code in another context. For this reason you have to develop with open eyes when it comes to introducing dependencies. This principle tells us that depending on an interface is often beneficial."
Just trying to get the inches here.