Тут такое дело, имхо: там где ооп про "Figure, Animal и абстрактными методами" - это левое ооп, норвежского типа,
а там где ооп про "объектами реального мира" - это правое, калифорнийского посола.
Начинающий сено от соломы не отличает, как же у него ооп должно заработать?
И вот ещё, когда-то в наивные времена, считалось, что было бы замечательно,
если бы программа смогла не просто заработать, а нашлись бы способы правдоподобного формального суждения о том,
что программа работает правильно, в некотором строго указанном смысле.

Этот заход, отставший от жизни, намекает на то, что используемые в программировании концепты должны быть пригодны к суждению о них в рамках формальных математических построений.

У левого ооп с самого начала с вменяемой математикой такого рода серьёзные проблемы.
И почти все что в рамках левого ооп достигнуто, достигалось не контексте объектов,
а в процессе работы с автоматами или шаблонами/обобщениями.
К автоматам ооп как-то пристёгивается, хоть и не является обязательным,
а во втором случае ооп это просто антиконценпия, и выглядит, имхо, просто как
изуродованная модель работы с обобщениями.

Правое ооп, там где про "объекты реального мира" - не жилец без вменяемых математизированных моделей взаимодействия этих объектов - будь то модели акторов или Хоаровы модели взаимодействующих процессов.

То есть имхо, "само по себе" ооп ни быть понято, ни работать не может.
И нечего здесь на студентов пенять, бла-бла-бла.


Опыт помогает давать правильные имена наблюдаемым феноменам.
Адам, до того, как был проклят, работал в Эдеме программистом, и давал там имена
животным и растениям.
Не методом восприятия буквально, или через призму ( у него не было очков),
а путём подбора целесообразных имен.
Конечно, для этого требуется опыт.


Имхо, не совсем так.
В связи с тем, что "состояния нет" - прозрачно реализуется любая изобретённая и, вероятно,
любая будущая модель сети "взаимодействующих объектов".
По крайней мере до тех пор, пока игнорируется вопрос о том, а существует ли у самой сети состояние.
Но вот с самими "объектами" возникает маленькая проблема: как имитировать состояние средствами, не предполагающими оного.
Будучи ошеломительно эффективным в одном месте, ФП оказываются изумляюще затруднительным в другом.
Хотя Erlang-у с Elixir-ом это никак процветать не мешает.

полудух,


Figure, Animal, Dog, Wolf - это вообще не объекты, а имена,
в терминах которых вы, как Адам, описываете окружающий мир и рассуждаете о нём.
Вообще, программирование, это техника/наука манипулирования именами, а не объектами.

Называя их объектам, вы к первоначальному смыслу и целесообразности этих имен
привязываете некий дополнительный смысл, зачем-то нужный вам в технических целях.
Ну, может быть, этот дополнительный смысл где-то и полезен, в специальных случаях.
Но почему вам всегда и заведомо не хватает исходного смысла используемых имен.
Не может так оказаться, что навязанная вам, или усвоенная вами техника универсального
сведения всего мира к "объектам", ограничивает вас в рамках слишком бедной системы имен?

А левое от правого отличается так:
Норвежское "ооп" концентрируется на классификациях - "объект" описывается как то, что принадлежит некоторой системе классификации.
Для калифорнийского "ооп" классификация не интересна, но оно знает, что объекты это то,
там и тогда, когда требуется организовать взаимодействие между какими-то совокупностями
самостоятельно функционирующих сущностей.


Кто такие "интерфейсы"? Это "объекты" или нет?
Если да - зачем для некоторых объектов потребовалось специальное "системное" имя?
Если нет, то что они вообще делают в "ооп", где весь мир - "объекты"?
О чём весь этот, уже много лет как потерявший актуальность, хайп?

Предположим, что он о "многократном повторном использовании кода".
Тогда, применительно к норвежскому ооп, в изначальной формулировке,
тезис о пользе ооп будет звучать так:
а) постройте "удачную", "соответствующую задаче" систему классификации
б) поместите код, предполагаемый к повторному использование к корни построенных классификаций
в) многократно используйте этот код в наследниках.

Вернемся на время к Адаму.
Занимался ли он классификациями? Несомненно.
А должны ли мы помнить об этом? А вот это вряд ли.
Все имена птиц, животных и рыб остались и используются до сих пор,
а классификации - нет.

Классификации - это сложно - сложная и не сводимая к простой древовидности штука.
Фасетные классификации не кладутся в иерархии.
После Адама много достойнейших людей занимались классификациями, и мало какие из них
переживали своих создателей.
В классификациях Платона курица оказывалась неотличима от человека.
А таблицы Менделеева создаются вообще один раз за время жизни человечества.
Что вообще делать с "подходом к программированию", в котором до написания программы
ты должен создать классификацию задействованных в ней "объектов"...
Её вообщи нельзя использовать практически, потому что в ней нельзя начать писать.
А главный секрет программирования заключается в том, что никакую программу нельзя написать с "первого раза".
Заранее известно, что программу придется менять, пока она не приобретет свой финальный вид.
И, навязывая себе рабскую зависимость от выбранной (обязательно неудачно) системы классификации,
вы оказываетесь в ситуации, когда программу нужно не просто менять, а обязательно выкидывать
и переписывать заново целиком.
Тут уж не до "многократного использования кода" становится...

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

Обычно это выглядит как-то так:
Мне в программе понадобится:
а) умножать целые числа
б) возводить их в целочисленную степень
в) иногда вычислять n-ый член последовательности Фибоначчи
г) возводить матрицы в целочисленные степени
д) размножать строки
е) ...
Все это делается одним алгоритмом, я знаю его, и хотел бы написать функцию один раз,
так чтобы она оказалась пригодна к вызову для всех таких ситуаций "многократно".
В формальные параметры такой функции будут попадать различные фактические параметры, в зависимости
от существа выполняемой в конкретном месте операции -
возведения в степень целого или размножения указанной строки заданное колисчество раз.
И все, что требуется от входных параметров - предоставлять возможность выполнения
над экзеплярами параметров необходимых алгоритму действий.

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

Но сама потребность повторного использования кода
ни терминах "объектов", ни связанных с ними "интерфейсов"
формулируется, а в терминах требований к обеспечиваемым типами фактических входных параметров операциям.

ООП вообще не требуется и не подразумевается задачей повторного использования кода.

iOracleDev,
компилятор машина, доцент тупой, а людям вообще не следует заниматься программированием.
По крайней мере, большинству из них.

Стараниями писателей компиляторов профессия уже давно заметно выродилась,
и даже уже вот-вот люди заменятся на Алис, но инкапсуляция здесь ни при чём.