Начало
Сейчас я заново открываю для себя ООП. Если раньше смотрел через призму конкретного языка программирования, то теперь разбираюсь откуда вообще взялось ООП, понятия абстракции, инкапсуляции, наследования; для чего оно нужно и можно ли без этого обойтись.
Дошёл до понятий абстрактного класса и интерфейса. Если забить в поисковике "для чего нужны абстрактные классы" или "для чего нужны интерфейсы", то он выдаст посты примерно с таким обоснованием для их применения: "для работы иногда вам требуются ", "он может пригодиться, если". Воспринимается как нечто необязательное.
Для чего они нужны в ООП в принципе (в широком смысле), а не в конкретном языке программирования я не понял.
Поэтому обратился к книгам.
Середина
Я читаю несколько книг параллельно, но упоминать я буду следующие:
1. "Объектно-ориентированное мышление" М. Вайсфельда
2. "Объектно-ориентированный анализ и проектирование с примерами приложений" Г. Буча
3. "Программист-прагматик. Путь от подмастерья к мастеру" Э. Ханта, Д. Томаса
Возьмём Вайсфельда. Упоминание о том, для чего нужны абстрактные классы и интерфейсы мы находим в начале 8 главы.
Интерфейсы, протоколы и абстрактные классы — это мощные механизмы по-
вторного использования кода, обеспечивающие фундамент для того, что я называю
концепцией контрактов.
То есть, грубо говоря, интерфейсы и абстрактные классы обеспечивают "reusabiity" ПО.
Я вспомнил, что сочетание "контрактная модель" мне уже встречалась у Буча:
При прочтении создаётся впечатление, что контрактная модель имеет более глобальное значение. Чуть ли не основа основ.
У меня начали появляться мысли, что, возможно, абстрактные классы и интерфейсы и описывают, что должен делать объект, что они и есть часть того самого контракта. Это и есть воплощение идеи ответственности/обязанности объекта в языках программирования.
Чтобы в этом удостовериться, обратился к первоисточнику - к книгам Бертрана Мейера в котором описана технология "проектирования по контракту". На первый взгляд, судя по определению всё сходилось:
Проектирование по контракту (Design by Contract) - установление отношений между классом и его клиентами в виде формального соглашения, недвусмысленно устанавливающее права и обязанности сторон.
Но чем дольше я читал, тем больше убеждался, что Вайсфельд и Буч слишком вольно трактуют понятие контракта, либо имеют ввиду какой-то свой "контракт".
Поскольку у Вайсфельда концепция контрактов обеспечивает повторное использование ПО,
у Ханта и Томаса это средство защиты от ошибок:
А у Мейера это средство построения надёжного ПО:
Кроме того, определение инварианта, постусловия и предусловия у Мейера и у других авторов разительно отличаются.
Конец
Возникает множество вопросов.
Можно ли считать Мейера предтечей идеи что класс - это и есть контракт, состоящий из интерфейса и реализации?
Является ли проектирование по контракту основой основ или это всего-навсего один из подходов к разработке ПО?
Имеет ли место вольная трактовка понятий контракта, предусловия, постусловия, инварианта?
Можно ли, например, считать, что предусловия - это те самые интерфейсы, которые должны быть реализованы, чтобы программа выполнилась?
Сложный
