Введение: Объект != Класс
Тут народ путается с понятиями: интерфейс - переходник, класс - тип, объект - модуль («физическая» часть системы, класс это описание, объект это функционирующая сущность: Состояние+Методы). Многие вообще классы с объектами путают.
Под «физическим» понимается участвующий в работе, а не являющийся описанием. Разница как описанием типа Int, и реальными 32битами в RAM в которых хранится число. Объект это то, что «работает», а «класс» это описание того как данный «тип» должен работать.
Интерфейс: Прослойка между Объектами
Интерфейс - по русски переходник. В программировании используется для отделения и заменяемости модуля от системы. Интерфейс в программировании - набор правил которым должны соответствовать модули разных типов для замены.
- «Модуль» как правило объект.
- «Тип» как правило класс.
Пример: интерфейс Писатель используются для сохранения данных, а по этому интерфейсу данные могут передавать на сохранения в разные места: по сети, на диск, на принтер.
Пример из жизни: электрическая розетка/штепсель - передают энергию на разные устройтсва от разных источников: ГЭС, Генератор, ТЭЦ, Аккумулятор.
В Системной Дизайне Интерфейсы это «прокладки» через которые модули системы становятся отделяемыми и заменяемыми. Это уже не просто «тип-класса», а именно набор правил которым может соответствовать любой тип. Интерфейсы еще называют контрактами - т.е. наборами договоренностей которые должен соблюдать объект.
Заключение: Достаточно Объекта с Интерфейсом
В ЯП есть еще модули, миксины, лябды и прочее словеса которые затрудняют общее понимание системы как набора заменяемых модулей. Класс - это шаблон/тип по которому создаются объекты. Объект это «физический модуль», интерфейс - переходник по которому модули соединятся друг с другом. Вот и всё ООП.
ЭПИЛОГ
В своей статье я расскзаываю, что сделали инженеры Google, а по совместительству создатели UNIX, в языке Go: максимально упростили ООП модель для практического применения.
Убрали классы, убрали наследование, оставили Композицию/Агрегацию и Интерфейсы. Звучит сложно, на деле примитивно: представили программу как набор заменяемых «модулей» подключенных через интерфейсы.
Модульная система, модуль, переходник - термины широко распространненные за границы программирования, и так гораздо понятней на бытовом плане. Интерфейсы окружают нас везде: в быту розетки, в автомобилестроении шины, колесные диски, в компьютерных играх, в лыжном спорте, в сноуборде, в велосипедах. Везде представлена модульная конструкция которая соединяется через «интерфейс» переходников.
Специально я не иду в детальное объяснение принципов проектирования и не пользуюсь словами вроде Dependency Injection. Цель статьи объяснить базовую идею OOD - Объектно Ориентированного Дизайна, того с чем мы сталкиваемся в быту на ежедневной основе: USB порт, крепление смесителя в ванной, приемник карточки в банкомате, диаметр горлышка пластиковой бутылки, габаритные размеры пакета с соком, высота полки в холодильнике, крышка на банке с соленьями, размер куска мыла - всё реализации концепции интерфейса. Каждый из этих объектов соответствует каким-то правилам, сохраняет контакт и делает элементы системы заменяемыми.
UPD #1:
Дорогой 
Obezyan, благодаря вашему комментарию, я полностью составил ментальную
модель объяснения OOD системы как функционирующего физического агрегата.
- Объект - это деталь.
- Класс - чертеж детали.
- Интерфейс - чертеж соединительного крепления или штекера (интерфейса) по которому идет подключение. Модель крепления, Прокладка, Тип разъема/кабеля для подключения.
Одна идея интерфейсов может быть объяснена с разных сторон. Может быть более прикладным образом через Переходники/Штекеры/Прокладки, а может быть более абстрактно через зависимость реализации от абстракции.
Более абстрактное представление описывает Robert Martin в своей статье DIP (Dependency Inversion Principle) где интерфейс представляет как абстракцию (абстрактный класс). Что накладывается на преставление штекера для розетки - который питает прибор от абстрактной сети, которая может быть ТЭЦ, ГЭС, Дизель, Аккумулятор, Солнечные Батареи.
UPD #2:
Наследование - это синтаксический сахар над Агрегацией. При Агрегации подключается Компонент явно. При Наследовании Компонент подключается не явно: есть разные механизмы наследования. Базовая идея в перенаправленный СООБЩЕНИЯ на обработку в другой КОМПОНЕНТ. Другим КОМПОНЕТНОМ может быть: базовый класс, объект по прототипу, миксин - базовой идеи делегирования полномочий синтаксическая обертка не меняет.
Факт который не понимает 80% кодеров - наследование это дополнение к ООП, а не его суть. А 99% кодеров не понимает, что ООП это про Сообщения, а не про Компоненты-Объекты. Кодер != Инженер.
Изображение от Sendi Metz: Объект как космическая капсула принимающая и передающая радио сигналы.
Суть от Alan Kay:
I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages (so messaging came at the very beginning – it took a while to see how to do messaging in a programming language efficiently enough to be useful).
- https://softwareengineering.stackexchange.com/questions/46592/so-what-did-alan-kay-really-mean-by-the-term-object-oriented
- https://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented
- https://www.quora.com/When-Alan-Kay-conceived-of-object-oriented-programming-as-being-about-objects-that-hide-their-state-and-send-messages-to-other-objects-how-large-were-these-objects-imagined-to-be-and-how-closely-does-current
