Для чего все-таки нужны интерфейсы?
Представь у тебя есть какой-нибудь метод, который принимает в агрументах объект, например, типа UserdoSomething(User user)
Ты можешь передавать в этот метод любой объект типа User или объекты классов, наследующих User.
Но можно сделать еще гибче, например описать некий интерфейс  UserInteface и указать в определении метода его: doSomething(UserInterface user)
Теперь ты можешь передавать в метод объект любого класса, который реализует интерфейс UserInterface.
Разумеется, изначальный класс User из этого примера тоже должен реализовывать этот интерфейс.
То есть, указывая в типе данных параметра какой-то конкретный класс, ты привязываешься к этому классу или его наследникам, а указывая интерфейс ты привязываешься к этому интерфейсу, который может реализовать любой другой класс, связность уменьшается, а это хорошо. А если ты в этих, еще не написанных классах будешь просто писать нужные методы, то не сможешь объект этих классов использовать, тип данных то будет другой, хотя методы и будут описаны.
И, как уже написали выше, один класс может реализовывать несколько интерфейсов.
На самом деле, всё довольно просто: интерфейсы нужны для декомпозиции модели и облегчения разработки ПО. По факту, интерфейс описывает набор операций, который можно совершить над объектом. Если вы пишите какую-то функциональность, то она допустим работает только с теми объектами, над которыми можно совершать определённые действия, а что это за объекты вас не волнует. Буква "I" из набора принципов SOLID про этом, почитайте.
Вот допустим я пишу модуль, который должен стучать, по всему тому, что можно постучать. Есть у меня функция "knock(IKnockable o)" ну и соответствующий интерфейс. Клиенты, кому надо воспользоваться этим модулем, реализуют этот интерфейс в своих классах и пользуются. Но мой модуль вообще ничего не знает об клиентах, он просто работает со всем, что реализует определённый протокол взаимодействия (интерфейс). Это ещё и связанность понижает.