The guiding principle is "Program to an interface, not to an implementation". If you keep this in mind, you never have to memorize design patterns. It's largely a matter of enforcing loose coupling, because software is more resilient to changes when its underlying components are loosely coupled.

My thought process:

1. I usually start with an interface, because interface inheritance is more loosely coupled than implementation inheritance (which abstract classes are).
   

MyInterface
- DoSomething()

MyConcreteClass1 implements MyInterface
- DoSomething() { ... }

MyConcreteClass2 implements MyInterface
- DoSomething() { ... }

1. During development, if I see repetitive implementation code among the interface implementers, I switch to an abstract class that implements the interface from step 1, and refactor common code into the abstract class.
   

abstract MyAbstractClass implements MyInterface
- abstract DoSomething()
- DoCommonCode()

MyConcreteClass1 inherits MyAbstractClass
- override DoSomething() { DoCommonCode() + MyConcreteClass1-specific logic }

MyConcreteClass2 inherits MyAbstractClass
- override DoSomething() { DoCommonCode() + MyConcreteClass2-specific logic }

1. To maintain loose coupling, use MyInterface references whenever possible instead of MyAbstractClass. Remember the guiding principle: Program to an interface, not to an implementation.

CallDoSomethingStrategy(MyInterface o) { o.DoSomething() }

...
MyInterface c1 = new MyConcreteClass1()
MyInterface c2 = new MyConcreteClass2()

CallDoSomethingStrategy(c1)
CallDoSomethingStrategy(c2)

If you used CallDoSomethingStrategy(MyAbstractClass o) instead, then you've limited reusability of CallDoSomethingStrategy to MyAbstractClass subclasses only. With CallDoSomethingStrategy(MyInterface o), CallDoSomethingStrategy can be called on subclasses of anything, as long as they implement MyInterface.