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

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

Имхо, оценивать уровень программистов по хабрахабру — всё равно, что судить о мире в целом — по какому-нить ньюсру

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

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

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

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

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


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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

P.S.

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

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

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

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

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

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

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

А>Это тебя надо в мусорку, хамло.
А давайте таки закроем филиал ЛоРа, плииз?

Если по теме — задача сама по себе бессмысленная. Чего мы хотим добиться? Представить окружность как эллипс? Эллипс как окружность (если, конечно, фокусы совпадают)? Поработать с геометрическими абстракциями или отрисовать графические примитивы? Или просто показать, что баррдак в модели не пропадает магическим образом, если изложить модель в ооп-терминах?

It depends — для каждого случая вполне можно подобрать свои компромиссные решения. Самое правильное —

Liskov substitution principle, вид сбоку. Эллипс никак не связан с кругом ровно по тем же причинам, по которым прямоугольник не связан с квадратом.

en.wikipedia.org/wiki/Circle-ellipse_problem

Другими словами, не надо использовать наследование просто потому, что кажется что им можно решить проблему. Точно так же, как и с регулярными выражениями, у вас теперь две проблемы. Ну, и холивар в духе "микроскоп — отстойный ударный инструмент!" — третья

Здравствуйте, Аноним, Вы писали:
А>Я вижу проблему в том, что две трети программистов решили применить некорректное наследование в этом элементарном классическом примере.

Сходил в Википедию — там есть рекомендация наследовать эллипс от круга, ибо "для эллипса надо хранить больше информации".
И еще мешок с тележкой "возможных решений" предложили.
Ужос.


Аж руки зудят закатать статью вида "ellipse-triangle problem"

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

W>Это надо в мусорку.

Это тебя надо в мусорку, хамло.

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

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

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

M>>А какое корректное ?

А>В этом примере, очевидно, не нужно наследовать одно от другого.

Очевидно что вы ошибаетесь.

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

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

А>мне уже давно кажется, что в ООП есть некоторые принципиальные логические недостатки,

Как я понял из всех здешних (в т.ч. давнишних) и хабровских (из сабжа) споров, у ООП принципиальный недостаток всего один: оно не является серебряной пулей. Есть однако подозрение, что это недостаток не ООП.

А>и в целом это ущербная методология.

Гы.

А>И видимое отсутствие единого понимания ООП является всего лишь проявлением глубоких фундаментальных проблем данной дисциплины.

Отсутствие решений для sqrt(-1) на множестве действительных чисел является всего лишь проявлением глубоких фундаментальных проблем данного множества.

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

А>На "Хабрахабре" устроили голосование и обсуждение классической "Circle-ellipse problem".

А где ссылка?

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

А>Некорректное? Для этого надо спросить: что они понимают под кругом и эллипсом.

Глубокое замечание.

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


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

Одной из проблем, которая порождает подобные дискуссии, является проблема эллипса и окружности. Её можно сформулировать так:

Как с точки зрения объектно-ориентированного подхода правильно объединить в единую иерархию два класса — класс Эллипс и класс Окружность:

(1) Унаследовав Эллипс от Окружности?
(2) Или унаследовав Окружность от Эллипса?

Одни программисты выступают за вариант (1), а другие — за вариант (2).

Какой же из этих подходов является более правильным?

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

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

Таким образом, одна из задач классификации в науке — это сокращение объёма требуемой памяти без сокращения количества информации.

Должны быть задачи и у классификации при проектировании программ.

Далее здесь

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

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

А>Вследствие чего плодят новые данные — сами объекты.
Данные отличаются от объектов тем, что у данных поведение упрощено. В 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 имеет полное право форматировать винт.

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

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

По идее, это надо в "Коллеги улыбнитесь". На "Хабрахабре" устроили голосование и обсуждение классической "Circle-ellipse problem".

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

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

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

А>По идее, это надо в "Коллеги улыбнитесь". На "Хабрахабре" устроили голосование и обсуждение классической "Circle-ellipse problem".

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

Как на основе этого голосования можно делать выводы про знание базовых концепций ООП? Все зависит от того как разработчик определит характеристики этих объектов и какие характеристики можно выделить в общую группу (назвать предком). При удачном стечении обстоятельств множество свойств одного объекта может полностью совпасть с пересечением множеств свойств данных объектов. То есть результаты опроса скорее всего покажут с какими моделями чаще приходилось работать программистам. Для меня например круг и эллипс — это подкласс прямоугольников

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

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

M>А какое корректное ?

В этом примере, очевидно, не нужно наследовать одно от другого.

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

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

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

D>...у ООП принципиальный недостаток всего один: оно не является серебряной пулей. Есть однако подозрение, что это недостаток не ООП.

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

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

Вы, господа, своими ответами иллюстрируете причину, по которой не стоит обсуждать какие-либо более-менее нетривиальные вопросы на форумах: в ответ вы получите либо общее место (изложение стереотипных суждений, ответ dimgel), либо демагогию (приведение к абсурду, ответ minorlogic).

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

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

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

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

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

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

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

А>По идее, это надо в "Коллеги улыбнитесь". На "Хабрахабре" устроили голосование и обсуждение классической "Circle-ellipse problem".

Это надо в мусорку. Ты что хотел-то? Поругать Хабр или сказать, что такие элементарные вещи должны знать в детском саду? Ну тогда приведи свое, "единственно верное" решение проблемы.

P.S. Хабр наводнен самыми разными представителями самых разных профессий.

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

D>А где ссылка?

Да, черт, это ж надо было так стормозить...

http://habrahabr.ru/blogs/programming/123014/

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

S>Имхо, оценивать уровень программистов по хабрахабру — всё равно, что судить о мире в целом — по какому-нить ньюсру

А что, там какие-то особо ущербные программисты собираются, даже ниже среднего уровня? Я этого просто не знал, извините.

А какие сайты "правильные"?

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

А>А что, там какие-то особо ущербные программисты собираются, даже ниже среднего уровня? Я этого просто не знал, извините.
Нет, там собираются люди. Не для того, чтобы решить проблемы, а так — потрындеть и полюбоваться на трындёж со стороны. То же самое в полный рост наблюдается на местных политике/священных войнах/ожизни. Несмотря на то что большинство участников — люди неглупые, общий уровень осведомлённости, аргументации и взаимоуважения прям зашкаливает, да.

Ну как, будем обзывать хабрахабровцев ущербными, вас — в мусорку хамлом, а меня — троллем? Или таки поостережёмся делать выводы по поверхностным ассоциациям?

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

А>Как на основе этого голосования можно делать выводы про знание базовых концепций ООП? Все зависит от того как разработчик определит характеристики этих объектов и какие характеристики можно выделить в общую группу (назвать предком). При удачном стечении обстоятельств множество свойств одного объекта может полностью совпасть с пересечением множеств свойств данных объектов. То есть результаты опроса скорее всего покажут с какими моделями чаще приходилось работать программистам. Для меня например круг и эллипс — это подкласс прямоугольников

Я вижу проблему в том, что две трети программистов решили применить некорректное наследование в этом элементарном классическом примере.

А как насчет более сложных случаев в реальных программах? Как вы думаете, будут ли они принимать неправильные решения и делать бредовые и логически ошибочные объектные модели? Конечно, будут. И делают.

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

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

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

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

А>Я вижу проблему в том, что две трети программистов решили применить некорректное наследование в этом элементарном классическом примере.
Некорректное? Для этого надо спросить: что они понимают под кругом и эллипсом. Без знания на это вопрос не о чем судить. Главное чтоб у разработчиков были _непротиворечивые_абстракции_ для "модели мира" для разрабатываемой программы.

А>А как насчет более сложных случаев в реальных программах? Как вы думаете, будут ли они принимать неправильные решения и делать бредовые и логически ошибочные объектные модели? Конечно, будут. И делают.
Без комментариев. Я сам грешен. Не буду судить, да не судим буду

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

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

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

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

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

А>>Некорректное? Для этого надо спросить: что они понимают под кругом и эллипсом.

А>Глубокое замечание.

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

Надо сперва дать определение этим буквосочетаниям в рамках решаемой задачи, потом спрашивать что у них общего, разного.

Голубой и синий. Понимайте как хотите, но кто из них объектно-ориентированный "папа", а кто объектно-ориентированный "сын"?

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

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

А какое корректное ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Например.

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

Ну и т.п.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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? Не на вики же читать про него, не на хабре
Никто не написал.

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

А>По идее, это надо в "Коллеги улыбнитесь". На "Хабрахабре" устроили голосование и обсуждение классической "Circle-ellipse problem".

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

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

Хабр самое подходящее места для обсуждения подобных проблем я считаю

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

А>Я вижу проблему в том, что две трети программистов решили применить некорректное наследование в этом элементарном классическом примере.


Где ты это там видишь?
58.72% (1495) Круг — это подкласс Эллипса

Всё верно..

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

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

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

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

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

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

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

А>>А деталь реализации — наследование здесь не понадобилась. ООП Алана Кея без наследования.
S>Нет.
А и не спорю. Просто рест и ооп скорее всего ортогональны чем противоположны. А вот рест и рпс...

Здравствуйте, Аноним, Вы писали:
А>Наследование — это один и единственный контракт современных популярных ООЯ и через это игольное ушко приходится пропускать все возможные контракты. Это не балкон с перилами это клетка с единственной дверью. Слишком жесткое ограничение. Поэтому интерфейсы, интерфейсы с единственным методом, или вообще без методов, разные виды реализаций миксинов, патерны и тп.
Слишком сильное утверждение. Шаблоны в С++ позволяют строить контракты в "утином" стиле. Одна возможность подменить в аргументах шаблона функцию на функтор уже в разы перекрывает "наследование". И это — не единственный вариант выхода за пределы наследования. Но это — уже не ООП, это ортогонально ему.
С точки зрения ООП, более мягким вариантом контрактов являяются интерфейсы. Там "плохого" наследования нет.

А>Искажение еще до написания промышленного кода, на этапе проектирования. Более менее ОО только use case'ы, а дальше уже идет проектирование с учетом "правильного" наследования и построение "правильной" иерархии. Потому что по другому невозможно для мейнстрим "объектно наследуемых" языков.
Конечно же все ошибки тут делаются на этапе проектирования. Вопрос только в том, что такое "правильная" иерархия.
Чтобы её построить, нужно мыслить в терминах поведения, а не данных. Вот и всё. А уже потом надо придумывать способ обеспечить требуемое поведение. И для этого, помимо банального наследования, есть масса паттернов.

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

единственный публичный метод в IShape — это double GetArea()

Ну и где вы тут видите ширину и высоту? Опять просится дизайн от данных? Думайте о поведении. Есть ли там внутри ширина и высота — никого не интересует.
Не относящиеся к делу метафоры про животных я поскипал.

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

А>Детали реализации. Здесь все объекты одинаковы и других не может быть.
Ну, то есть мы выкинули из ООП ООП. Точно так же нельзя считать функциональным языком тот, в котором строго одна функция, и эта функция main().