Дело не только в этом. Когда ты связываешь группу объектов абстрактным классом или интерфейсом, ты же делаешь это не просто так. Благодаря этому ты можешь работать с объектами в полиморфной манере. Т.е. у тебя появляется возможность передать в параметр методов и конструкторов не реализацию, а сделать параметром абстрактный класс или интерфейс, тогда в такой метод ты можешь передать любую реализацию, что удобно. С интерфейсом аналогично. Пример, паттерн стратегия, вот тебе слабая связанность объектов. Далее, IEnumerable<<Базовый класс> может содержать любых наследников, и в такой параметр метода ты так же можешь их передать, благодаря полиморфизму. Что касается интерфейса на каждое действие — нет, в этом и есть суть абстракции, здравого смысла и оптимального баланса, когда ты создаёшь интерфейс или базовый класс, ты в первую очередь создаёшь общую модель взаимодействия. Чтобы в микроволновке что-то приготовить, нужно выставить время и нажать старт, Нужна кнопка и таймер. Нужно ли что-то ещё? Нужно думать. Ты объединяешь классы определённой общей абстракцией, а этот самый преславутый "контракт", о котором пишут в книгах, описывает эту общею модель взаимодействия; т.е. какие методы нужны чтобы повлиять на каждый класс и он выполнил свою функцию. Глупо на каждое действие писать интерфейс, ибо одно действие — это не функция, функция в плане... если мы создадим отдельный интерфейс на таймер микроволновки и на кнопку старт — это сомнительный функционал. Ну и в противовес, плохо делать жирный интерфейс, ибо лишний функционал ты будешь тащить из класса в класс.
