Michaellux

Когда вы делаете ПО вы делаете код который взаимодействует с другим кодом.
Любая функция, процедура, каждая строка --- это код который взаимодействует с другим кодом выше или ниже по тексту. Взаимодействие одного кода с другим кодом всегда осуществляется через некий интерфейс -- набор правил входа\выхода и ожиданий в поведении кода. Даже когда вы объявляете переменную в локальной области видимости - это тоже интерфейс для кода, который использует эту переменную. Другой код ожидает, что в переменная существует, имеет корректное значение, и может быть использована корректным образом. Каждый раз эти правила сосуществования кода различны, они меняются от языка к языку от разработчика к разработчику.
Лучший язык (моё имхо) - это тот язык который подходит для описания интерфейсов взаимодействия в широком смысле этого слова. Я говорю об интерфейсе как некотором контракте одного кода с другим, одной строки кода со следующей, одного оператора с другими.
Конечно существуют разные подходы для описания таких интерфейсов. Сейчас распространен принцип описательного "делай как я сказал". В этом подходе программа дробиться на простые сущности, которые каким-либо образом взаимодействуют друг с другом.
В ООП это классы-объекты, в функциональном - это функции.
Суть меняется на самом деле слабо, все это нужно чтобы:
1. формализовать описание интерфейсов взаимодействия.
2. Прийти к какому-то единообразному способу такого описания.

В ООП идут дальше, абстрагируясь от конкретной реализации класса, и вводя лишь только способы взаимодействия сущностей (описание этого взаимодействия). Т.о. появляется абстрактные классы и интерфейсы.
В функциональном способе описания также пошли в сторону абстракции. Например а Haskell есть типы и интерфейсы типов -- это что касается контрактов, и есть функции высших порядков -- это что касается реализации интерфейсов.
Такими способами уменьшается сложность ПО и дробиться код улучшается надежность.
Но даже жесткий линейный код на BASIC - это все тот же способ описать интерфейс взаимодействия одного кода с другим.

Помимо ООП и функционального программирования есть куча других методик:
Полный список можно тут взять: https://ru.wikipedia.org/wiki/%D0%9A%D0%B0%D1%82%D... - и тот достаточно абстрактно-сырой.

Короче ООП это не панацея, а лишь еще один способ описания этого дивного и сложного мира и взаимоотношений в нем.

Прочитайте книгу "Чистая архитектура" (Р.Мартин), все встанет на свои места.
Контракт - не может быть реализацией, это абстракция. Применяется тогда когда планируется менять реализацию (конкретику) контракта по мере эксплуатации системы, обычно в долгоиграющий проектах.

Абстрактный класс - это родительский класс который дает своим предкам что то общее + необходимость реализации своего контракта, но он относится к конкретике, а не контракту.

Я использую примерно такой подход:
1. Получаем данные.
1.1. Запрашиваем из внешних систем или вводим руками.
1.2. Результат в консоль или в лог-файл.
2. Сохраняем данные.
2.1. Создаём БД.
2.2. Перенаправляем данные из внешних систем в БД.
3. Обрабатываем данные.
3.1. Реализуем бизнес-логику.
3.2. Результаты сохраняем в БД или показываем пользователю.
4. Отображение результата.
4.1. Достаём данные из БД и отправляем пользователю.
4.2. Взаимодействие с пользователем.
5. Повторяем в необходимом порядке и с необходимыми изменениями по всем слоям.