Зависимости внутри системы лучше строить от интерфейсов или абстрактных классов? Когда лучше использовать абстрактный класс и когда интерфейс?

Question

[rumasterov]

Например, у нас есть компонент логирования. Мы можем создать AbstractLogger с реализацией по-умолчанию и унаследовать все свои логгеры от него, в конструкторах или сеттерах других классов указывать что они принимают в параметре логгер типа AbstractLogger.

На сколько это правильно? Может лучше использовать интерфейс? Например мы можем создать LoggerInterface, в конструкторах или сеттерах других классов указывать что они принимают в параметре логгер типа LoggerInterface, а например реализацию по-умолчанию реализовать в AbstractLogger который реализует несколько методов из LoggerInterface, таким образом я могу сам решать - унаследоваться от AbstractLogger который для меня уже реализовал несколько методов из интерфейса или если меня эта реализация не устраивает я могу написать свою реализовав LoggerInterface.

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

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

Answer 1

[Станислав Макаров]

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

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

LoggerInterface

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

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

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

Answer 2

[Максим Федоров]

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

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

Answer 3

[Daniil Danilov]

Рекомендую к прочтению:
sergeyteplyakov.blogspot.de/2014/12/what-are-inter...