Здравствуйте, <Аноним>, Вы писали:

А>Ладно, проехали. На самом деле, я хотел просто дать ссылку на обсуждение на "Хабрахабре", но саму ссылку забыл. Устраивать обуждение непосредственно самой "Circle-Ellipse Problem" я не собирался — это занятие ну чересчур примитивное. Не ожидал, что кто-то начнет этим заниматься.

Но и писать тогда что кто то "очвидно неправ", не стоит?

Здравствуйте, minorlogic, Вы писали:

M>Но и писать тогда что кто то "очвидно неправ", не стоит?

Конечно, стоит. Логика — мой друг.

Вы, если хотите, можете ради эксперимента сделать классы Circle и Ellipse с какими-нибудь достаточно вменяемыми и полезными интерфейсами и унаследовать одно от другого, по вашему вкусу.

Потом расскажете, что у вас получилось.

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

Здравствуйте, <Аноним>, Вы писали:

А>Здравствуйте, minorlogic, Вы писали:

M>>Но и писать тогда что кто то "очвидно неправ", не стоит?

А>Конечно, стоит. Логика — мой друг.

А>Вы, если хотите, можете ради эксперимента сделать классы Circle и Ellipse с какими-нибудь достаточно вменяемыми и полезными интерфейсами и унаследовать одно от другого, по вашему вкусу.

У меня достаточно экспериментальной практики, спасибо.

А>Потом расскажете, что у вас получилось.

Вы молодой человек совсем не понимаете о чем речь. Пока ответственность (responsibility) Circle и Ellipse не определена ЯВНО, все рассуждения про архитектурные решения бессмысленны.

А попытка строить дизайн от ДАННЫХ, обречена на провал по определению.

P.S.

Движок обработки 2д столкновений может реализовывать интерфейс раннего reject через интерфейс bounding circle. В этом контексте вполне резонно конкретный класс Ellipse реализовать интерфейс BoundingCircle

Здравствуйте, minorlogic, Вы писали:

M>Вы молодой человек совсем не понимаете о чем речь. Пока ответственность (responsibility) Circle и Ellipse не определена ЯВНО, все рассуждения про архитектурные решения бессмысленны.
M>А попытка строить дизайн от ДАННЫХ, обречена на провал по определению.

Да, этого я действительно пока не понимаю. Визуально в ООП дизайн вроде бы строится от данных, но при этом все постоянно говорят, что не от данных. Этого противоречия "от данных — не от данных" я уже очень долго не могу понять.

Ладно, буду изучать дальше и думать.

Здравствуйте, <Аноним>, Вы писали:

А>Да, этого я действительно пока не понимаю. Визуально в ООП дизайн вроде бы строится от данных, но при этом все постоянно говорят, что не от данных. Этого противоречия "от данных — не от данных" я уже очень долго не могу понять.

Обычно говорят что объекты строятся моделируя объекты предметной области. Но объекты это совсем не обязательно только данные. Можно применять классический ОПП от Гради Буча отталкиваясь от функциональности объектов (хотя и данные совсем отбрасывать не стоит).

Самый главный вопрос в этом контексте "За что этот объект будет отвечать?".


Например.

В графическом движке появилась необходимость представлять и передавать ориентацию объекта. Для этого реализовали класс quaternoin , а потом спросили себя "а за что отвечает класс quaternoin?".
В таком случае вполне может появится класс TransformSO3 или RotationTransformation или Orientation который будет скрывать представление вращения изнутри и предоставлять наружу интерфейс например в виде матрицы33.

Ну и т.п.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, minorlogic, Вы писали:

M>>Вы молодой человек совсем не понимаете о чем речь. Пока ответственность (responsibility) Circle и Ellipse не определена ЯВНО, все рассуждения про архитектурные решения бессмысленны.
M>>А попытка строить дизайн от ДАННЫХ, обречена на провал по определению.

А>Да, этого я действительно пока не понимаю. Визуально в ООП дизайн вроде бы строится от данных, но при этом все постоянно говорят, что не от данных. Этого противоречия "от данных — не от данных" я уже очень долго не могу понять.

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

Здравствуйте, Аноним, Вы писали:

M>>Вы молодой человек совсем не понимаете о чем речь. Пока ответственность (responsibility) Circle и Ellipse не определена ЯВНО, все рассуждения про архитектурные решения бессмысленны.
M>>А попытка строить дизайн от ДАННЫХ, обречена на провал по определению.

А>Да, этого я действительно пока не понимаю. Визуально в ООП дизайн вроде бы строится от данных, но при этом все постоянно говорят, что не от данных. Этого противоречия "от данных — не от данных" я уже очень долго не могу понять.

Все правильно. От данных. Только к данным применять наследование требуется очень и очень редко (я бы сказал, что вообще не требуется, но не люблю абсолютно категоричных заявлений). И почти всегда данные лучше отделить от алгоритмов их обработки. Для алгоритмов тоже редко требуется наследование, но все же чаще чем к данным.

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

Здравствуйте, Аноним, Вы писали:
А>"Circle-ellipse problem".
А кто-нибудь может объяснить, зачем нужен круг, если есть эллипс? Рисовать надо? Ну рисуй эллипс, не перетрудишься.

Здравствуйте, Аноним, Вы писали:

А>Да, этого я действительно пока не понимаю. Визуально в ООП дизайн вроде бы строится от данных, но при этом все постоянно говорят, что не от данных. Этого противоречия "от данных — не от данных" я уже очень долго не могу понять.
Всё очень просто. ООП — оно про поведение. Забудьте для начала о данных, ищите сходства и отличия в поведении объектов.
Именно поэтому бессмысленно обсуждать схему наследования для объектов, у которых поведение никак не описано. Я могу представить вполне валидные примеры с поведением, для которого Circle и Ellipse прекрасно будут наследоваться друг от друга. И могу представить примеры с поведением, при котором они наследоваться не смогут.

Данные объектам нужны исключительно для того, чтобы требуемое поведение обеспечить. Если вы начинаете строить дизайн от данных, то это не ООП.
Дизайн от данных — это, к примеру, классический ER или новомодный REST.

Здравствуйте, Mr.Cat, Вы писали:

MC>Здравствуйте, Аноним, Вы писали:
А>>"Circle-ellipse problem".
MC>А кто-нибудь может объяснить, зачем нужен круг, если есть эллипс? Рисовать надо? Ну рисуй эллипс, не перетрудишься.

Кто сказал , что их рисовать надо ?

Здравствуйте, minorlogic, Вы писали:
M>Кто сказал , что их рисовать надо ?
А ты всегда отвечаешь вопросом на вопрос?

Здравствуйте, Аноним, Вы писали:

А>В принципе, я всю жизнь любил делать все как следует, качественно. Теперь я пытаюсь научиться программировать как следует, качественно, стать хорошим программистом.

Возьми с полки пирожок. И сразу положи обратно, потому что ты не объяснил, что значит "как следует" и "качественно". Это не шутка и не стёб, если что. "Следовать" что-либо может только из чего-то ещё, а "качественность" невозможна без предварительной формулировки качеств.

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

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

А>В программировании я никак не могу соединить концы с концами и довести идеи до логического завершения. Каждая новая программа или модуль — это эксперимент. Каждую новую программу приходится "рожать" в муках и переделывать по несколько раз. Утомило это все невыносимо.

Это свидетельствует о неясной постановке задачи. В переводе на русский: ты сам не знаешь, чего хочешь получить на выходе.

Здравствуйте, Аноним, Вы писали:

А>Заставляет задуматься о том, насколько базовые концепции объектно-ориентированного программирования понятны средней массе программистов, да и о полноценности самого объектно-ориентированном программирования.

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

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

Здравствуйте, Sinclair, Вы писали:

S>Всё очень просто. ООП — оно про поведение. Забудьте для начала о данных, ищите сходства и отличия в поведении объектов.
S>...

S>Данные объектам нужны исключительно для того, чтобы требуемое поведение обеспечить. Если вы начинаете строить дизайн от данных, то это не ООП.

Поведение — изменение свойств/данных во времени. Так что поведение — включает данные по определению. Поведение поведением, но необъяснимое поведение — это не поведение, это НЛО То есть поведение должно быть объяснимым, то есть данные и их изменения должны быть согласованными, подчиняться определенными законам/шаблонам. ООП — это способ объяснения этой согласованности, основанный на инкапсуляции — выделении самодостаточных данных и изменений для единицы моделирования, работает хорошо как способ разделения на модули. Наследование — способ выделения общих данных и изменений для нескольких единиц моделирования. Работает хуже, тк это абстракция над инкапсуляцией и не всем дано правильно обобщать. Полиморфизм — это способ обойти проблемы наследования, способ записи "исключений из правила".

Вот моя модель понимания ООП. Но как известно модели бывают разные, и часто "не соответствуют действительности", то есть не соответствуют модели собеседника.

Здравствуйте, Аноним, Вы писали:


А>Поведение — изменение свойств/данных во времени. Так что поведение — включает данные по определению. Поведение поведением, но необъяснимое поведение — это не поведение, это НЛО То есть поведение должно быть объяснимым, то есть данные и их изменения должны быть согласованными, подчиняться определенными законам/шаблонам. ООП — это способ объяснения этой согласованности, основанный на инкапсуляции — выделении самодостаточных данных и изменений для единицы моделирования, работает хорошо как способ разделения на модули. Наследование — способ выделения общих данных и изменений для нескольких единиц моделирования. Работает хуже, тк это абстракция над инкапсуляцией и не всем дано правильно обобщать. Полиморфизм — это способ обойти проблемы наследования, способ записи "исключений из правила".

А>Вот моя модель понимания ООП. Но как известно модели бывают разные, и часто "не соответствуют действительности", то есть не соответствуют модели собеседника.
Дело не в модели собеседника, дело в общепринятой модели.

Общепринятая модель немножко другая, и чем раньше вы её поймете, тем проще вам будет программировать.
Итак, поведение в ООП — это обмен сообщениями. Данных (у объектов) пока никаких нет; есть только сообщения. В традиционных языках обмен сообщениями реализован через вызов методов.
Далее, чтобы обеспечить мало-мальски интересное поведение, объекту дают состояние. Это возможность для него по-разному реагировать на одинаковые сообщения.
Так, например, результат попытки сделать socket.send() сильно зависит от того, был ли перед этим сделан open(), и с какими аргументами.
Вся "согласованность", про которую вы говорите, ограничивается контрактами. Современные мейнстримовые ЯП не шибко развиты в плане формального описания переходов состояний в контрактах (ну, к примеру, что перед тем, как делать socket.send() нужно сделать socket.open()), но модели это не меняет.
Итак, у объекта есть состояние. Инкапсуляция в ООП всего лишь означает запрет на прямой доступ к состоянию объекта. Единственный способ узнать, в каком состоянии находится объект — это послать ему сообщение и посмотреть на реакцию.
Эта инкапсуляция позволяет нам изолироваться от подробностей внутреннего устройства объекта. Мы не знаем, в каких единицах TimeSpan хранит внутри промежуток времени. Нам это неважно.

Инкапсуляция позволяет нам добиться полиморфизма — обеспечить подмену объектов благодаря тому, что за одним и тем же поведением может стоять разное внутреннее устройство.
В ООП можно привнести классы — способ категоризации объектов с общим "внутренним устройством". Два объекта одного и того же класса ведут себя одинаково — то есть, если последовательность получаемых ими сообщений одинакова, то одинакова будет и их реакция.
Только после этого можно говорить о наследовании как промышленном способе получения классов с похожим поведением.

Вот — чистая модель ООП в стиле Алана Кея.
Если задача, которую вы решаете, связана с какими-то данными, то на основе ООП можно построить эмуляцию данных. Ну вот к примеру — берём класс окна, у которого есть, скажем, ширина. Поведение этой ширины достаточно простое — можно отправить окну сообщение setWidth(), и окно в ответ изменит свою ширину. Одним из последствий изменения внутреннего состояния окна будет то, что с этого момента на сообщение getWidth станут приходить другие ответы. Некоторые современнные промышленные ЯП предоставляют автоматизацию этого паттерна, вводя концепцию свойства.
Это очень важный момент — для того, чтобы обеспечить доступ к данным объекта, в ООП есть целый отдельный паттерн.


Если вы хотите строить дизайн от данных, то у вас получится не ООП. Вот, к примеру, REST — Representational State Transfer. Там все "объекты" прозрачны — известна их структура. У них нет никакого поведения в смысле ООП, т.к. список глаголов заранее определён. Тут наоборот — для того, чтобы эмулировать глаголы, вводятся дополнительные "данные". К примеру, создаём объект payment, связанный с объектом order. За кадром автоматически запускается целый процесс, связанный с поступлением оплаты. А с точки зрения клиента это выглядит так, что order теперь поменял свойство status. У REST есть свои преимущества, особенно в распределённой среде. Но это не ООП, это другая модель. Её математика проработана совсем в другую сторону. Есть понятия идемпотентных операций, есть понятия безопасных операций. Зато нет никакой работы в сторону наследования или полиморфизма. По крайней мере на данном этапе его развития.

Здравствуйте, Sinclair, Вы писали:

Можно выдернуть цитаты из контекста?
S>Общепринятая модель немножко другая, и чем раньше вы её поймете, тем проще вам будет программировать.
S>Итак, поведение в ООП — это обмен сообщениями. Данных (у объектов) пока никаких нет; есть только сообщения.
S>...
S>Вот — чистая модель ООП в стиле Алана Кея.
Спасибо за объяснения. Теперь понятно к чему стремятся при ооп подходе — избавиться от (видимых) данных. Вследствие чего плодят новые данные — сами объекты. При таком описании наследование — это детали реализации, а вот полиморфизм — это очевидное следствие, что-то вроде утиной типизации. Это не "полиморфизм через наследование" принятый у современных ооп языков. Очень похоже на технику в многопоточном программировании — события.
Я не прав, я не Алан Кей.

S>Если вы хотите строить дизайн от данных, то у вас получится не ООП. Вот, к примеру, REST — Representational State Transfer. Там все "объекты" прозрачны — известна их структура. У них нет никакого поведения в смысле ООП, т.к. список глаголов заранее определён.
S>...
Если речь идет о HTTP с ограниченным набором методов-глаголов get, post (и что еще там), а вся хитрая логика спрятана внутри сервера (облака), тогда это те же яйца (ооп алана кея), только в профиль

Похоже на холивар.

Здравствуйте, Аноним, Вы писали:

А>Спасибо за объяснения. Теперь понятно к чему стремятся при ооп подходе — избавиться от (видимых) данных.
В общем-то, да. В ООП нет прямого доступа к состоянию.

А>Вследствие чего плодят новые данные — сами объекты.
Данные отличаются от объектов тем, что у данных поведение упрощено. В Smalltalk, к примеру, не-объектов вовсе нет — даже целые числа, в отличие от современных промышленных ООЯ, являются такими же объектами, как и всё остальное.
Но целые числа ведут себя весьма примитивным образом. Мы посылаем целой переменной, проинициализированной в 0 по умолчанию, сообщение "инкремент" — и она увеличивается на 1. Больше ничего не происходит — не вызываются события on_smth_changed, не перерисовывается UI. Переменная не станет отказываться от этого увеличения потому, что это нарушает какие-то ограничения.
Объект, скажем, список, может получить сообщение "уменьшить Capacity на 10". Но если его capacity равна, скажем, 5, то она не станет равной -5. Это — более сложное поведение, которое инкапсулировано в этом объекте.
Вот, собственно, в этом и отличие объектов от данных.

А>При таком описании наследование — это детали реализации, а вот полиморфизм — это очевидное следствие, что-то вроде утиной типизации. Это не "полиморфизм через наследование" принятый у современных ооп языков.
Ну, современных ООП языков много, и видов полиморфизма в них тоже поддерживается целый ассортимент.
Но почти все они являются реализацией одной и той же модели.
А>Очень похоже на технику в многопоточном программировании — события.
Не вполне. События в многопоточном программировании восходят к гармонично взаимодействующим процессам, придуманным Дийкстрой. ООП ничего не говорит о политике совместного доступа к состоянию. В ГВП эта политика декларируется; эта идея ортогональна ООП — её можно применять как в процедурном программировании, так и в ООП.

А>Если речь идет о HTTP с ограниченным набором методов-глаголов get, post (и что еще там), а вся хитрая логика спрятана внутри сервера (облака), тогда это те же яйца (ооп алана кея), только в профиль
Нет. Математика — разная. Речь не об HTTP, а о REST. Эта идеология хорошо ложится на HTTP, но никак от него не зависит. Можно и на HTTP наваять совершенно не-RESTful протокол, можно обойтись и без HTTP.
Главная идея REST — все данные наружу; благодаря этому удаётся добиться хороших результатов в распределённой среде. Все методы чётко классифицируются по тому, какие изменения они производят с данными. В ООП, к примеру, нет никакого встроенного способа сказать "вызов getCount безопасен, он гарантированно не сломает состояние объекта". Нет встроенного способа сказать "вызов getOrder выполнять до конца необязательно, если его результат будет таким же, как и в прошлый раз". Нет способа сказать "если во время выполнения setCount произошло исключение, и мы не знаем, изменилось ли состояние объекта, то можно выполнить этот метод ещё раз с тем же параметром, и объект не сломается".
В ООП нет "встроенных" глаголов; их семантика — чёрный ящик. getCount имеет полное право форматировать винт.

Здравствуйте, Sinclair, Вы писали:

А>>При таком описании наследование — это детали реализации, а вот полиморфизм — это очевидное следствие, что-то вроде утиной типизации. Это не "полиморфизм через наследование" принятый у современных ооп языков.
S>Ну, современных ООП языков много, и видов полиморфизма в них тоже поддерживается целый ассортимент.
S>Но почти все они являются реализацией одной и той же модели.
Столкновение теории и практики.
Почти все полиморфизм используют через наследование, малая часть через шаблоны, и лишь в некоторых языках (динамических и языках с поддержкой утиной типизации) есть более-менее полноценная поддержка полиморфизма, без накладываемых языком ограничений. Вследствие чего наследование (деталь реализации) главным в принципах ООП. И появляются приверженцы "объектно наследуемого программирования" (я про себя пишу). Потом разгребай эти проблемы наследования, проблемы круга и эллипса. Сделали бы нормальный полиморфизм — не было бы проблем с "деталью реализации" ООП. Были бы другие проблемы

А>>Очень похоже на технику в многопоточном программировании — события.
S>Не вполне. События в многопоточном программировании восходят к гармонично взаимодействующим процессам, придуманным Дийкстрой. ООП ничего не говорит о политике совместного доступа к состоянию. В ГВП эта политика декларируется; эта идея ортогональна ООП — её можно применять как в процедурном программировании, так и в ООП.
Я это так, к слову сказал. Но есть много схожих практических моментов.

А>>Если речь идет о HTTP с ограниченным набором методов-глаголов get, post (и что еще там), а вся хитрая логика спрятана внутри сервера (облака), тогда это те же яйца (ооп алана кея), только в профиль
S>Нет. Математика — разная. Речь не об HTTP, а о REST. Эта идеология хорошо ложится на HTTP, но никак от него не зависит. Можно и на HTTP наваять совершенно не-RESTful протокол, можно обойтись и без HTTP.
S>Главная идея REST — все данные наружу; благодаря этому удаётся добиться хороших результатов в распределённой среде. Все методы чётко классифицируются по тому, какие изменения они производят с данными. В ООП, к примеру, нет никакого встроенного способа сказать "вызов getCount безопасен, он гарантированно не сломает состояние объекта". Нет встроенного способа сказать "вызов getOrder выполнять до конца необязательно, если его результат будет таким же, как и в прошлый раз". Нет способа сказать "если во время выполнения setCount произошло исключение, и мы не знаем, изменилось ли состояние объекта, то можно выполнить этот метод ещё раз с тем же параметром, и объект не сломается".
S>В ООП нет "встроенных" глаголов; их семантика — чёрный ящик. getCount имеет полное право форматировать винт.
Главная идея РЕСТ(http/www) в том что все данные/объекты уникальны у них есть уникальный ID(url). И вокруг этого танцуют. А вот что и кого танцуют не понятно. Вроде заводят определенный набор методов работы с этими данными: get/post/put/update, crud поверх http и тп. Но это же объект ооп. К разным объектам можно обращаться однообразно — полиморфизм. А деталь реализации — наследование здесь не понадобилась. ООП Алана Кея без наследования.
Пошел читать про РЕСТ. Почему на рсдн нет статьи про REST? Не на вики же читать про него, не на хабре

Здравствуйте, Аноним, Вы писали:
А>Столкновение теории и практики.
А>Почти все полиморфизм используют через наследование, малая часть через шаблоны, и лишь в некоторых языках (динамических и языках с поддержкой утиной типизации) есть более-менее полноценная поддержка полиморфизма, без накладываемых языком ограничений.
В принципе да, но надо понимать, что ограничения эти сродни перилам на балконе.
Ну и само по себе ООП как теория более-менее ортогонально статической типизации. Просто в 80е-90е было повальное увлечение идеей ранних проверок контрактов, а контракты — это ограничения, вот и получаем дешёвый и надёжный полиморфизм на наследовании.
Ослабление ограничений — это либо отказ от контрактов и перенос граблей в рантайм, либо усовершенствование контрактов ценой разработки более совершенных компиляторов.

А>Вследствие чего наследование (деталь реализации) главным в принципах ООП. И появляются приверженцы "объектно наследуемого программирования" (я про себя пишу).
Вот тут налицо разрыв между теорией и практикой. Не всегда удаётся восстановить исходные идеи ООП путём ревёрс инжиниринга промышленного кода. Тем более, что довольно много книжек про ООП написано откровенно некомпетентнми людьми. Вот именно вследствие этого и получаем наследование главным принципом ООП, при этом главной чертой наследования видится наличие унаследованных полей данных. Искажение картинки.

А>Потом разгребай эти проблемы наследования, проблемы круга и эллипса. Сделали бы нормальный полиморфизм — не было бы проблем с "деталью реализации" ООП. Были бы другие проблемы
Вот это мне не до конца понятно. Мне-то казалось, что трудности моделирования круга и эллипса не связаны с отсутствием "нормального полиморфизма", чем бы он ни был.
Трудности связаны с тем, что люди моделируют не то, что надо.
Если у нас вся задача — в том, чтобы считать площадь фигуры, т.е. единственный публичный метод в IShape — это double GetArea(), то никакой проблемы отнаследовать Circle от Ellipse нету. Более того, это вполне нормальный способ повторно использовать готовый код.
Никакие принципы подстановки не нарушаются, всё в порядке.

А>Я это так, к слову сказал. Но есть много схожих практических моментов.
Я бы не сказал. Практический момент в посылке сообщения в ООП, как правило, это выполнение команды косвенного вызова. Практический момент в посылке сообщения в ГВП — постановка элемента в специальную очередь. Сходства тут чисто поверхностные.

А>Главная идея РЕСТ(http/www) в том что все данные/объекты уникальны у них есть уникальный ID(url). И вокруг этого танцуют.
Да, эта идея полностью совпадает с идентифицируемостью в ООП. Но начиная с этого принципы расходятся в разные стороны.

А>А вот что и кого танцуют не понятно. Вроде заводят определенный набор методов работы с этими данными: get/post/put/update, crud поверх http и тп. Но это же объект ооп.
Нет. Это какое-то очень странное ООП, где у всех объектов ровно один набор методов. Ну, то есть можно его отобразить на ООП, конечно же, но ничего интересного это не даст.

А>К разным объектам можно обращаться однообразно — полиморфизм.
Никакого полиморфизма здесь нет. Для полиморфизма в REST нужно немножко больше, чем одинаковость четырёх глаголов. Нужно ещё договориться о языке разметки запросов и ответов; решить, до какой степени и что считать совместимым.

А>А деталь реализации — наследование здесь не понадобилась. ООП Алана Кея без наследования.
Нет.
А>Пошел читать про РЕСТ. Почему на рсдн нет статьи про REST? Не на вики же читать про него, не на хабре
Никто не написал.