rumasterov

чтобы избежать случайного присвоения

Асинхронность - это выполнение параллельных операций в одном потоке; Мультитрединг, очевидно, в нескольких. Блокировка потока исполнения, вроде функции sleep, а не использование таймера - блокирует поток исполнения (внезапно! Ваш кэп). Надо быть феерически наивным, чтобы ожидать чего-то иного =)

Абстрактный класс позволяет частично реализовать функциональность и указать что должно быть реализовано в потомках, это удобно как для базового класса. Но использовать его в качестве реализации механизма зависимости не стоит, т.к.:
1. Могут возникнуть ситуации когда понадобиться реализовать класс не наследуясь от абстрактного класса.
2. Один класс может использоваться в нескольких зависимостях и для каждой из них может быть свой набор обязательных характеристик. В этом случае Вам придется "раздувать" базовый класс что не хорошо.

Интерфейсы же просто описывают структуру функциональности. Вам по сути дела то и не важно знать как-то или иной класс реализовывает функциональность, главное - понимать что он может делать. С этой точки зрения интерфейс подойдет как нельзя лучше

По-моему зависимости внутри системы от интерфейсов более гибкие.

Разумеется зависимости от интерфейсов гибче, т.к. не заставляют вас использовать какую-либо реализацию (пусть даже частичную). Используя интерфейс, вы декларируете необходимый минимум информации для взаимодействия компонент, и ничего более.

LoggerInterface

В каждом ОО-языке свои конвенции именования интерфейсов, но скорее всего лучше назвать просто Logger. Вы же не пишете Class в конце имени каждого класса.

Подскажите, пожалуйста, как правильно определить когда использовать интерфейс и когда абстрактный класс?

Интерфейс - когда хотите описать контракт взаимодействия, иными словами, сгруппировать несколько методов. Вся фишка интерфейса в том, что его можно реализовать только полностью, а не частично.
Абстрактный класс - когда хотите предложить некоторую частичную реализацию. Это может быть как реализация ранее описанного интерфейса (что более чем нормальная ситуация), так и абстрактный класс с собственными публичными (в том числе абстрактными) методами. Во втором случае вы одновременно описываете некий интерфейс и тут же - его частичную реализацию, которой сможет воспользоваться класс-наследник.