Я не знаю как это воспринимают другие, но на мой взгляд, тот факт что можно рассматривать многих животных как нечто с четырьмя конечностями - это и есть обобщение (aka абстракция).
Если кто-то вкладывает в слово "абстракция" что-то другое, то это его личная проблема, имхо.

Давай я микролекцию тут прочитаю о сущности абстракции и абстрагирования (чую это давно уже надо было сделать, чтоб ссылаться):
Абстракцию можно мыслить как результат некоторой функции абстрагирования.
Пусть это будет F(x). Тогда абстракция - это y = F(x).
Такая функция осуществляет редукцию объекта на в ходе.
Т.е. одному y соответствует много x

Пример1:
x - это 3D модели животных.
y - это значение перечисления (двуногое, четвероногое, безногое, неведомая хрень)

Пример2:
x - это картинки с изображением набора предметов (одних и тех же)
y - это число, которое соответствует количеству предметов на картинке.

И это не пространные рассуждения. F(x) - это вычислимая функция.
x и y - это материальные объекты (электроны в оперативе, структуры мозга, почеркушки на бумаге, etc)

Доступно объясняю?

Если я хочу определить процедуру, которая будет заставлять четвероногое животное бежать галопом, то мне пофиг, что это за животное. Мне нужно только сигналы подавать в определенной последовательности на его 4 ноги.

Если мне нужно подковать четырехногое животное, то я определю интерфейс чуть уже. Например, добавлю метод, получающий копыто с ноги.

Если я хочу накормить животное, то мне пофиг, что это за животное. Мне от него нужно только понимание команды "Жри()" )))

Ну и как бы вроде наше мышление именно так и устроено. Разве нет?
Разве добавление в программирование чего-то сверх этого не раздувание сложности?

Товарищи, классическое ООП сделано так как сделано, не потому что это хорошая модель, а только лишь потому что это можно очень легко и эффективно сделать технически. Т.е. оно такое из-за ограничений технологии, а не по желанию создателей. Неужели вы это не понимаете?
А вселенная не дура. Она дешево профит не продает.

Какие нафиг иерархии, Kemet?
Иерархия в Oberon-07 нужна только чтобы RECORD удобно разрезать технически на предка и потомка. Все. Точка.
Это конкретная техника диктует иерархию. Иерархия - это досадная необходимость. А вы носитесь с ней как с граалем.

> -- Цитата:
> Это и нужно проанализировать и заняться проектированием
Тут много кто мнит себя архитектором (включая меня конеш). Вот только выхлопа чет не видать.

> -- Цитата:
> Объект сам должен предоставлять возможные интерфейсы
Я же писал выше, что 1 интерфейс == 1 метод. Что еще то нужно?
Ты объявил метод - это и есть заявка на поддержку интерфейса.
Если объявлять заявку на составные интерфейсы, то количество конфликтов интерфейсов будет расти по экспоненте относительно количества методов в интерфейсах.
В то время как с элементарными интерфейсами конфликт только один - это совпадение имени при несовпадении параметров.

Не поленюсь даже на пример:
Есть интерфейс 1: X(), Y(), Z()
Есть интерфейс 2: X(), Z(), Y()
Они не совместимы! Чо буш делать если тебе нужно оба в твоем объекте? Полностью реализацию продублируешь?
Или диспетчер запилишь? (т.е. оверхед как у утиных, но при этом нужны телодвижения при кодинге... и где выигрыш?)