Собрал свои мысли об ООП за последние 15 лет. Критикуем!
1. Сегодня для записи программ создано где-то около 2500 языков программирования. История их развития в чем-то схожа с историей развития человеческой речи. Существует мнение, что содержание первых высказываний человека состояли исключительно из требований помощи, которую бы мог оказать ему другой индивид. «Если бы первые высказывания становящегося человека выразить с помощью нашего, развитого языка, они обязательно содержали бы глаголы в повелительном наклонении (“дай!”, “неси!”, “ломай!”, “режь!”, “бей!”, “поднимай!”, “тяни!” и т. п.)». Причем эти команды сопровождались жестами, которые точно указывали к чему конкретно это действие должно быть применено. Ну, очень похоже на команды императивных языков программирования! Например, команды ассемблеров с точным указанием адресов памяти или регистров.
2. Человек вначале научается отличать одну практическую ситуацию, взятую в целом, от другой ситуации. Выделение отдельных элементов этих ситуаций (предметов, над которыми совершаются действия, действий, которые совершаются над предметами) осуществляется позже – по мере того, как в практической деятельности человек все больше знакомился с окружающими его вещами, познавал их свойства и их отношения друг к другу и к самому человеку. Постепенно человек начинает выделять из конкретной ситуации объект действия (в программировании – данные) и само действие (в программировании — функции). Овладение способностью выделять объекты действия было настоящей революцией в умственном развитии первобытного чело века. А это уже очень похоже на объектно-ориентированный подход (ООП), применяемый в программировании. По крайней мере, в его современной реализации в языках Java, C#, C++.
3. При помощи естественного языка человек материализует свои ментальные модели мира, чтобы передать их другому человеку. При помощи ООП программист материализует свои ментальные модели программного продукта, чтобы передать их на исполнение вычислителю. Но действительно ли ООП это главное русло нашей реки? Или это лишь тихая заводь перед крутым поворотом, которая отличается медленным и порой обратным течением воды и которая уже начала заболачиваться?
4. Применение ООП к построению ментальных моделей физического мира имеет более двух тысяч лет истории успешного использования, которое берет начало в трудах Аристотеля. В мире Аристотеля существуют только единичные и конкретно определенные вещи с заданным набором свойств и отнесенные к одной и только одной категории.
5. Да, теперь мы уже научились говорить не просто «неси», а «неси дрова» или «неси камень». В своем развитии языки программирования остановились на том, что научились различать объекты (дрова и камень), но не научились выделять действия над ними. И с точки зрения языка программирования men.carry (firewood) и men.carry (stone) будут разными языковыми единицами, если только объекты firewood и stone не имеют общего предка! Просто реализация этими объектами интерфейса «то, что может носить человек» нас не выручит, поскольку это будет две реализации, а, следовательно, и единиц исходного кода тоже будет две.
6. Здесь скрыто одно из основных ограничений ООП, которое делает наши программы сложнее, чем они могли бы быть, заставляет нас использовать костыли в виде паттернов проектирования, чтобы компенсировать врожденную хромоту ООП. Когда мы пытаемся определить, подходит ли нам конкретный дизайн программной системы или нет, мы не можем рассматривать данное решение изолированно. Мы должны рассматривать его с точки зрения разумных предположений о том, как будет использоваться данный дизайн в последствие. Если перевести этот тезис на язык «дров» и «камней», то это будет звучать, примерно, так. Проектируя программные объекты «дрова» и «камень», мы должны быть в курсе планов Господа, по совершенствованию программной системы. А именно, мы должны предполагать, что Он не ограничится созданием дров и камней, а на шестой день сотворения мира создаст человека, который их будет перетаскивать.
7. О наследовании. Другое ограничение ООП заключается в том, что каждый объект принадлежит одной и только одной иерархии ("is а") классов, пусть даже с возможностью множественного наследования и имеет раз и навсегда заданный набор свойств. Например, красная роза — это цветок, а цветок — это растение. Это противоречит реальности, в которой объекты могут эволюционировать, приобретать новые свойства, и утрачивать ранее существовавшие. Например, роза может стать товаром, а потом подарком. Другой пример. Человек рождается с очень ограниченным набором свойств: иметь возраст, вес, рост, уметь пищать, питаться и портить памперсы. Время идет, и он приобретает новые наборы свойств: ученик школы, покупатель, пассажир, солдат, студент, наемный работник, предприниматель, супруг, родитель и т.д. А возможно и не приобретает. Например, не каждый человек служит в армии, учится в вузе, женится и становится отцом или предпринимателем. Или утрачивает. Например, закончил учиться, отслужил в армии или развелся. Следовательно, один и тот же объект должен иметь возможность принадлежать разным классам и этот набор классов должен быть динамическим, т.е. изменяться в ходе эволюции объекта и самой программной системы. На набор классов, которым относится объект, как правило, накладываются ограничения. Например. Чтобы стать солдатом, человек должен достичь 18 лет. А если человек студент то для того, чтобы стать мужем, необходимо сдать сопромат.
8. О сообщениях. Еще одна странность ООП. «Поведение — это то, как объект действует и реагирует; поведение выражается в терминах состояния объекта и передачи сообщений» (здесь и далее цитаты по Гради Буч, Объектно — ориентированный анализ и проектирование с примерами приложений на С++, Бином, 1998). Но, постойте, если я моделирую столкновение двух автомобилей то, кто из них и какие получает и передает сообщения?
9. О свойствах. «Состояние объекта характеризуется перечнем (обычно статическим) всех свойств данного объекта и текущими (обычно динамическими) значениями каждого из этих свойств». Но принадлежит ли свойство объекта самому объекту? Буду утверждать, что нет. Например, мы говорим данное яблоко – зеленое. Но что это означает не самом деле? Это значит, что если мы направим источник света, близкого по спектру к солнечному свету, то данное яблоко поглотит все длины волн, кроме тех, которые соответствуют диапазону зеленого цвета, и наблюдатель, который способен воспринимать весь спектр солнечного света увидит только отраженный зеленый свет. Если источник или наблюдатель имеют другой диапазон, например, инфракрасный, то цвет яблока будет черным. Таким образом, свойство не есть неотъемлемая характеристика объекта, а является возможным проявлением объекта при его взаимодействии с другими объектами. Например, свойство предмета «плавать по поверхности» может проявляться во взаимодействии с водой и не проявляться во взаимодействии со спиртом.
10. Об агрегации. Мы говорим: швабра «состоит из» (агрегирует) щетки и палки. Но что это означает? Если мы рассматриваем швабру, как предмет способный перемещаться в пространстве, то в этом случае агрегация никак не проявляется, мы рассматриваем швабру как атомарный объект и нам интересны лишь ее общая масса и размеры. Но если мы станем нагружать швабру и испытывать ее на прочность, то агрегация проявится, как взаимодействие составляющих ее объектов щетки и палки и результат испытания будет зависеть от того, происходит ли это взаимодействие посредством вбитых гвоздей или посредством пазов, шипов и клея. Следовательно агрегация есть также взаимодействие объектов.
11. Об ассоциации. Если мы говорим, что объект a является мужем объекта b, то мы декларируем что объекты a и b связаны ассоциацией. Как же может проявляться эта связь? Во-первых, сама эта связь есть результат взаимодействия трех объектов a, b и объекта и с (ЗАГС, некий регистратор, где эта связь рождается, и там же она, кстати, может и исчезнуть). Во-вторых, она будет проявляться в случаях взаимодействий объектов a и b, например, совместное расходование семейного бюджета или рождение и воспитание общего ребенка. Нет смысла спрашивать a.isMarrid (b), он может и соврать. Но вполне осмысленна функция isMarrid (a, b, c). Следовательно, связи, как и свойства, есть возможные взаимодействия между объектами.
12. Об идентичности. «Идентичность — это такое свойство объекта, которое отличает его от всех других объектов». Что должно соответствовать в действительности этому утверждению? Допустим, я перекрасил свой автомобиль. Для меня он, безусловно, остался тем же самым. Но для ГИБДД это будет совсем другой объект, который получит новый номер регистрации. Или другой пример. С автомобиля сняли колеса. Автомобиль остался тем же самым? А если еще и двигатель? Когда автомобиль перестанет быть тем же самым? Идентичность возникает лишь при связывании конкретных объектов. Каждая швабра будет состоять из вполне конкретной щетки и палки. У каждого мужа будет вполне конкретная жена, а у каждого клиента – свой экземпляр счета в банке.
13.Итак, в нашем ментальном мире нет объектов и их свойств. А есть структуры и их взаимодействия. Если мы моделируем дорожное движение, то автомобили следует рассматривать как элементарные узлы структуры, которые вступая во взаимодействие (обгоняя, подрезая, тормозя), консистентно изменяют свое положение в фазовом пространстве (скорость, ряд). С другой стороны, автомобили перестают быть элементарными узлам структуры, как только мы начинаем рассматривать их взаимодействие при столкновении. Мы должны перейти на более низкий структурный уровень. На этом уровне элементарными узлами должны быть: бампер, кузов, рама, двигатель и проч. составные части, а также способы их соединения (болты, сварка и т.д.). Сам факт выделения узла структуры есть акт познавательной деятельности (гештальттеория, Вертгеймер М. Продуктивное мышление. М.: Прогресс, 1987), который зависит от решаемой задачи.
Здравствуйте, craft-brother, Вы писали:
CB>1. Сегодня для записи программ создано где-то около 2500 языков программирования. История их развития в чем-то схожа с историей развития человеческой речи. Существует мнение, что содержание первых высказываний человека состояли исключительно из требований помощи, которую бы мог оказать ему другой индивид. «Если бы первые высказывания становящегося человека выразить с помощью нашего, развитого языка, они обязательно содержали бы глаголы в повелительном наклонении (“дай!”, “неси!”, “ломай!”, “режь!”, “бей!”, “поднимай!”, “тяни!” и т. п.)». Причем эти команды сопровождались жестами, которые точно указывали к чему конкретно это действие должно быть применено.
И самое главное — эти команды подразумевали субъект/объект, который, предполагаемо, должен выполнить эти команды. Таким образом имеем стандартную связку: объект.метод( параметр )
Здравствуйте, craft-brother, Вы писали:
CB>Собрал свои мысли об ООП за последние 15 лет. Критикуем!
CB>2. Человек вначале научается отличать одну практическую ситуацию, взятую в целом, от другой ситуации. Выделение отдельных элементов этих ситуаций (предметов, над которыми совершаются действия, действий, которые совершаются над предметами) осуществляется позже – по мере того, как в практической деятельности человек все больше знакомился с окружающими его вещами, познавал их свойства и их отношения друг к другу и к самому человеку. Постепенно человек начинает выделять из конкретной ситуации объект действия (в программировании – данные) и само действие (в программировании — функции).
И снова упустили того кто должен совершить действие, то есть объект. Берём грамматику естественного языка. В ней базовое предложение это: подлежащее (объект/субъект) + сказуемое (действие) + дополнение (параметр).
CB>5. Да, теперь мы уже научились говорить не просто «неси», а «неси дрова» или «неси камень». В своем развитии языки программирования остановились на том, что научились различать объекты (дрова и камень), но не научились выделять действия над ними. И с точки зрения языка программирования men.carry (firewood) и men.carry (stone) будут разными языковыми единицами, если только объекты firewood и stone не имеют общего предка!
Верно. Посему, анализируя желаемое действия над предметами мы должны абстрагироваться и выделить ту абстракцию, в контексте которой применяется данное действие. Она и будет общим предком. К примеру в нашем случае (в зависимости от задачи) это может быть: переносной предмет, или обрабатываемый предмет, или метательный предмет, или огнедобывающий предмет. Мозг интуитивно выделяет эту абстракцию, в зависимости от того, для чего ему нужны палка/камень/...
Здравствуйте, craft-brother, Вы писали: CB>3. ...Но действительно ли ООП это главное русло нашей реки? Или это лишь тихая заводь перед крутым поворотом, которая отличается медленным и порой обратным течением воды и которая уже начала заболачиваться?
Каким вы видете будующее программирования?
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, AlexCab, Вы писали:
AC>Здравствуйте, craft-brother, Вы писали: CB>>3. ...Но действительно ли ООП это главное русло нашей реки? Или это лишь тихая заводь перед крутым поворотом, которая отличается медленным и порой обратным течением воды и которая уже начала заболачиваться?
AC>Каким вы видете будующее программирования?
Здравствуйте, craft-brother, Вы писали:
CB>Собрал свои мысли об ООП за последние 15 лет. Критикуем!
Имхо, как-то натянуто. Ты критикуешь постулат о естественности ООП.
Согласен, это глупый постулат, но и что? Это ещё надо обосновать, что "естественность" — это преимущество.
По мне с ООП "не так" ровно одно: попытка некоторых личностей "продать" его как универсальное решение, серебряную пулю.
Если отбросить весь этот ажиотаж вокруг ООП, то все становится на свои места, а ООП отправляется в ящик с инструментами наряду
с другими парадигмами, и извлекается строго по необходимости.
Здравствуйте, craft-brother, Вы писали:
CB>Собрал свои мысли об ООП за последние 15 лет. Критикуем!
CB>1. Сегодня для записи программ создано где-то около 2500 языков программирования. История их развития в чем-то схожа с историей развития человеческой речи. Существует мнение, что содержание первых высказываний человека состояли исключительно из требований помощи, которую бы мог оказать ему другой индивид. «Если бы первые высказывания становящегося человека выразить с помощью нашего, развитого языка, они обязательно содержали бы глаголы в повелительном наклонении (“дай!”, “неси!”, “ломай!”, “режь!”, “бей!”, “поднимай!”, “тяни!” и т. п.)». Причем эти команды сопровождались жестами, которые точно указывали к чему конкретно это действие должно быть применено. Ну, очень похоже на команды императивных языков программирования! Например, команды ассемблеров с точным указанием адресов памяти или регистров.
Думаю команды появились несколько позже. Сначала появилась идентификация. Я, он, это. Да это адресация или указание. Только после указания стала возможна инструкция или метод. Ведь требование действия невозможно без указания объекта.
CB>2. Человек вначале научается отличать одну практическую ситуацию, взятую в целом, от другой ситуации. Выделение отдельных элементов этих ситуаций (предметов, над которыми совершаются действия, действий, которые совершаются над предметами) осуществляется позже – по мере того, как в практической деятельности человек все больше знакомился с окружающими его вещами, познавал их свойства и их отношения друг к другу и к самому человеку. Постепенно человек начинает выделять из конкретной ситуации объект действия (в программировании – данные) и само действие (в программировании — функции). Овладение способностью выделять объекты действия было настоящей революцией в умственном развитии первобытного чело века. А это уже очень похоже на объектно-ориентированный подход (ООП), применяемый в программировании. По крайней мере, в его современной реализации в языках Java, C#, C++.
Сори, но тут не совсем так. Познавание свойств в первую очередь вызвало появление классов. Ведь подлежащие это не что иное как классы. Дверь, топор, стул-это классы. Артикль или указание формирует из класса объект. Сравним "Каждый мужчина должен построить дом..." в этой фразе дом это класс. А когда мы говорим "В моем доме 4 этажа" дом это объект. А уже далее формировалось действие..причем к классу и к объекту они отличались.. Совсем как в ООП.
CB>3. При помощи естественного языка человек материализует свои ментальные модели мира, чтобы передать их другому человеку. При помощи ООП программист материализует свои ментальные модели программного продукта, чтобы передать их на исполнение вычислителю. Но действительно ли ООП это главное русло нашей реки? Или это лишь тихая заводь перед крутым поворотом, которая отличается медленным и порой обратным течением воды и которая уже начала заболачиваться?
Тут вообще одна вода.. в русле воды. вместе с поворотом.
CB>4. Применение ООП к построению ментальных моделей физического мира имеет более двух тысяч лет истории успешного использования, которое берет начало в трудах Аристотеля. В мире Аристотеля существуют только единичные и конкретно определенные вещи с заданным набором свойств и отнесенные к одной и только одной категории.
Это откуда? Личное сочинение? С чего вы взяли что мир Аристотеля это единичные вещи?
CB>5. Да, теперь мы уже научились говорить не просто «неси», а «неси дрова» или «неси камень». В своем развитии языки программирования остановились на том, что научились различать объекты (дрова и камень), но не научились выделять действия над ними. И с точки зрения языка программирования men.carry (firewood) и men.carry (stone) будут разными языковыми единицами, если только объекты firewood и stone не имеют общего предка! Просто реализация этими объектами интерфейса «то, что может носить человек» нас не выручит, поскольку это будет две реализации, а, следовательно, и единиц исходного кода тоже будет две.
Почему не научились? Очень даже научились.. Даже абстрактные свойства..Фраза "Он стоит здесь для мебели" очень хорошо демонстрирует свойство класса мебель по отношению к человеку.
CB>6. Здесь скрыто одно из основных ограничений ООП, которое делает наши программы сложнее, чем они могли бы быть, заставляет нас использовать костыли в виде паттернов проектирования, чтобы компенсировать врожденную хромоту ООП. Когда мы пытаемся определить, подходит ли нам конкретный дизайн программной системы или нет, мы не можем рассматривать данное решение изолированно. Мы должны рассматривать его с точки зрения разумных предположений о том, как будет использоваться данный дизайн в последствие. Если перевести этот тезис на язык «дров» и «камней», то это будет звучать, примерно, так. Проектируя программные объекты «дрова» и «камень», мы должны быть в курсе планов Господа, по совершенствованию программной системы. А именно, мы должны предполагать, что Он не ограничится созданием дров и камней, а на шестой день сотворения мира создаст человека, который их будет перетаскивать.
Здесь что-то есть. Но проблема в другом.. Человек начал строить категории (классы) с другой стороны иерархии. Сначала появился пень, потом стул, потом стол и только потом мебель. Мы же программируя сначала построим класс Мебель, а потом будет уточнять стул это или стол..
CB>7. О наследовании. Другое ограничение ООП заключается в том, что каждый объект принадлежит одной и только одной иерархии ("is а") классов, пусть даже с возможностью множественного наследования и имеет раз и навсегда заданный набор свойств. Например, красная роза — это цветок, а цветок — это растение. Это противоречит реальности, в которой объекты могут эволюционировать, приобретать новые свойства, и утрачивать ранее существовавшие. Например, роза может стать товаром, а потом подарком. Другой пример. Человек рождается с очень ограниченным набором свойств: иметь возраст, вес, рост, уметь пищать, питаться и портить памперсы. Время идет, и он приобретает новые наборы свойств: ученик школы, покупатель, пассажир, солдат, студент, наемный работник, предприниматель, супруг, родитель и т.д. А возможно и не приобретает. Например, не каждый человек служит в армии, учится в вузе, женится и становится отцом или предпринимателем. Или утрачивает. Например, закончил учиться, отслужил в армии или развелся. Следовательно, один и тот же объект должен иметь возможность принадлежать разным классам и этот набор классов должен быть динамическим, т.е. изменяться в ходе эволюции объекта и самой программной системы. На набор классов, которым относится объект, как правило, накладываются ограничения. Например. Чтобы стать солдатом, человек должен достичь 18 лет. А если человек студент то для того, чтобы стать мужем, необходимо сдать сопромат.
Это элементарно. Есть такое понятие как роли. Один и тот же объект может выполнять разные роли.. И даже несколько одновременно.. Студент, преподаватель или и то и другое одновременно. Не вижу противоречия с ООП.
CB>8. О сообщениях. Еще одна странность ООП. «Поведение — это то, как объект действует и реагирует; поведение выражается в терминах состояния объекта и передачи сообщений» (здесь и далее цитаты по Гради Буч, Объектно — ориентированный анализ и проектирование с примерами приложений на С++, Бином, 1998). Но, постойте, если я моделирую столкновение двух автомобилей то, кто из них и какие получает и передает сообщения?
Трактуй понятие Сообщение несколько шире и будет тебе счастье. Как по мне так лучше подходит понятие Событие. Хоть это и логическое понятие, но оно имеет имя и потому имеет семантический смысл. А в языке скорее наоборот имеет семантический смысл потому имеет имя. В твоем примере имя события "Столкнулись два автомобиля"
CB>9. О свойствах. «Состояние объекта характеризуется перечнем (обычно статическим) всех свойств данного объекта и текущими (обычно динамическими) значениями каждого из этих свойств». Но принадлежит ли свойство объекта самому объекту? Буду утверждать, что нет. Например, мы говорим данное яблоко – зеленое. Но что это означает не самом деле? Это значит, что если мы направим источник света, близкого по спектру к солнечному свету, то данное яблоко поглотит все длины волн, кроме тех, которые соответствуют диапазону зеленого цвета, и наблюдатель, который способен воспринимать весь спектр солнечного света увидит только отраженный зеленый свет. Если источник или наблюдатель имеют другой диапазон, например, инфракрасный, то цвет яблока будет черным. Таким образом, свойство не есть неотъемлемая характеристика объекта, а является возможным проявлением объекта при его взаимодействии с другими объектами. Например, свойство предмета «плавать по поверхности» может проявляться во взаимодействии с водой и не проявляться во взаимодействии со спиртом.
Динамическими значениями свойств можно пренебречь потому что в каждый момент времени они статические. В твоих примерах свойства таки принадлежат объекту. Не имеет значения внешняя среда. Но таки есть значения свойств, которые не принадлежат объекту. Например, "любимая книга". Если б книга была одна не было б такого свойства "быть любимой". Оно появляется только тогда когда появляется множество объектов. Т.е. это значение свойства множества объектов.
CB>10. Об агрегации. Мы говорим: швабра «состоит из» (агрегирует) щетки и палки. Но что это означает? Если мы рассматриваем швабру, как предмет способный перемещаться в пространстве, то в этом случае агрегация никак не проявляется, мы рассматриваем швабру как атомарный объект и нам интересны лишь ее общая масса и размеры. Но если мы станем нагружать швабру и испытывать ее на прочность, то агрегация проявится, как взаимодействие составляющих ее объектов щетки и палки и результат испытания будет зависеть от того, происходит ли это взаимодействие посредством вбитых гвоздей или посредством пазов, шипов и клея. Следовательно агрегация есть также взаимодействие объектов.
Ну, тут ваще.. Так строй модель соответсвующую задаче и работай с ней. Не вижу проблем.
CB>11. Об ассоциации. Если мы говорим, что объект a является мужем объекта b, то мы декларируем что объекты a и b связаны ассоциацией. Как же может проявляться эта связь? Во-первых, сама эта связь есть результат взаимодействия трех объектов a, b и объекта и с (ЗАГС, некий регистратор, где эта связь рождается, и там же она, кстати, может и исчезнуть). Во-вторых, она будет проявляться в случаях взаимодействий объектов a и b, например, совместное расходование семейного бюджета или рождение и воспитание общего ребенка. Нет смысла спрашивать a.isMarrid (b), он может и соврать. Но вполне осмысленна функция isMarrid (a, b, c). Следовательно, связи, как и свойства, есть возможные взаимодействия между объектами.
Здесь идет речь об отношениях объектов. Хотя отношения можно тоже считать связями. Не суть важно. Важно то, что от того что кто-то солгал отношения не перестали существовать. Даже если загс престанет существовать. Т.е. разбомбят ее со всей документацией. Связь может исчезнуть только с объектом. Либо поменяться. Но вывод правильный "Следовательно, связи, как и свойства, есть возможные взаимодействия между объектами". И что не так с ООП?
CB>12. Об идентичности. «Идентичность — это такое свойство объекта, которое отличает его от всех других объектов». Что должно соответствовать в действительности этому утверждению? Допустим, я перекрасил свой автомобиль. Для меня он, безусловно, остался тем же самым. Но для ГИБДД это будет совсем другой объект, который получит новый номер регистрации. Или другой пример. С автомобиля сняли колеса. Автомобиль остался тем же самым? А если еще и двигатель? Когда автомобиль перестанет быть тем же самым? Идентичность возникает лишь при связывании конкретных объектов. Каждая швабра будет состоять из вполне конкретной щетки и палки. У каждого мужа будет вполне конкретная жена, а у каждого клиента – свой экземпляр счета в банке.
Не вижу тут противоречия. Объект остается тем же самым пока не исчезнет. Удаляй хоть колеса, хоть двигатель. Тут есть любопытная тонкость. Кроме объектов существуют и значения. Т.е. типы. Если считать что целая часть и дробная часть это свойства, то изменив даже одно из свойств мы действительно изменим значение, а старое исчезнет. Более того! Одновременно может существовать множество одинаковых значений!!!
CB>13.Итак, в нашем ментальном мире нет объектов и их свойств. А есть структуры и их взаимодействия. Если мы моделируем дорожное движение, то автомобили следует рассматривать как элементарные узлы структуры, которые вступая во взаимодействие (обгоняя, подрезая, тормозя), консистентно изменяют свое положение в фазовом пространстве (скорость, ряд). С другой стороны, автомобили перестают быть элементарными узлам структуры, как только мы начинаем рассматривать их взаимодействие при столкновении. Мы должны перейти на более низкий структурный уровень. На этом уровне элементарными узлами должны быть: бампер, кузов, рама, двигатель и проч. составные части, а также способы их соединения (болты, сварка и т.д.). Сам факт выделения узла структуры есть акт познавательной деятельности (гештальттеория, Вертгеймер М. Продуктивное мышление. М.: Прогресс, 1987), который зависит от решаемой задачи.
Здесь тоже нет противоречия с ООП. Просто подход другой. Не инструкции следуют одна за другой взаимодействуя с объектами, а происходят события заставляющие взаимодействовать с объектами. Так называемая архитектура машин управляемых потоком данных. Такой подход действительно более естественный. Но как ни крути взаимодействие происходит все равно последовательно. Т.е. с чего начинали в то и уперлись. Не говоря уже о принципах работы мозга. Он, увы, тоже не может распараллелиться и работает последовательно. Осталось мелочи. Смоделировать его работу
Здравствуйте, Steamus, Вы писали:
CB>>Существует мнение, что содержание первых высказываний человека состояли исключительно из требований помощи, которую бы мог оказать ему другой индивид. «Если бы первые высказывания становящегося человека выразить с помощью нашего, развитого языка, они обязательно содержали бы глаголы в повелительном наклонении (“дай!”, “неси!”, “ломай!”, “режь!”, “бей!”, “поднимай!”, “тяни!” и т. п.)». Причем эти команды сопровождались жестами, которые точно указывали к чему конкретно это действие должно быть применено.
S>И самое главное — эти команды подразумевали субъект/объект, который, предполагаемо, должен выполнить эти команды. Таким образом имеем стандартную связку: объект.метод( параметр )
А как быть с этим:
Мочите того мамонта!
У-у-у тигр! Спасайся кто может
Здравствуйте, Steamus, Вы писали:
S>И снова упустили того кто должен совершить действие, то есть объект. Берём грамматику естественного языка. В ней базовое предложение это: подлежащее (объект/субъект) + сказуемое (действие) + дополнение (параметр).
В огромном проценте фраз сказуемое — глагол "являться" (to be). The sky is blue. John is my friend. (в английском это нагляднее, т.к. у нас он часто опускается) Если все натягивать на ООП, у вас "to be" будет методом. И как вы себе представляете такой метод?
Здравствуйте, craft-brother, Вы писали:
CB>7. О наследовании. Другое ограничение ООП заключается в том, что каждый объект принадлежит одной и только одной иерархии ("is а") классов, пусть даже с возможностью множественного наследования и имеет раз и навсегда заданный набор свойств. Например, красная роза — это цветок, а цветок — это растение. Это противоречит реальности, в которой объекты могут эволюционировать, приобретать новые свойства, и утрачивать ранее существовавшие. Например, роза может стать товаром, а потом подарком.
Вы забыли про динамические языки. Есть вполне себе ОО-языки, где объект таки может в процессе жизни менять свой тип, набор ролей и даже набор свойств. Противоречия с ООП тут нет, это вопрос статической системы типов vs. динамической.
Здравствуйте, craft-brother, Вы писали:
CB>9. О свойствах. «Состояние объекта характеризуется перечнем (обычно статическим) всех свойств данного объекта и текущими (обычно динамическими) значениями каждого из этих свойств». Но принадлежит ли свойство объекта самому объекту? Буду утверждать, что нет. Например, мы говорим данное яблоко – зеленое. Но что это означает не самом деле? Это значит, что если мы направим источник света, близкого по спектру к солнечному свету, то данное яблоко поглотит все длины волн, кроме тех, которые соответствуют диапазону зеленого цвета, и наблюдатель, который способен воспринимать весь спектр солнечного света увидит только отраженный зеленый свет. Если источник или наблюдатель имеют другой диапазон, например, инфракрасный, то цвет яблока будет черным. Таким образом, свойство не есть неотъемлемая характеристика объекта, а является возможным проявлением объекта при его взаимодействии с другими объектами.
Эту мысль можно и дальше развить. Само существование объекта не является собственной его характеристикой, а является проявлением нашей мыслительной деятельности по выделению его из реальности. Яблоко как объект существует благодаря тому, что мы решили это скопление частиц/полей назвать отдельным объектом. Объекты лишены не только от имманентных свойств, но и самостоятельного существования. Такой вот прикладной буддизм.
Здравствуйте, D. Mon, Вы писали:
CB>>9. О свойствах. «Состояние объекта характеризуется перечнем (обычно статическим) всех свойств данного объекта и текущими (обычно динамическими) значениями каждого из этих свойств». Но принадлежит ли свойство объекта самому объекту?
DM>Эту мысль можно и дальше развить. Само существование объекта не является собственной его характеристикой, а является проявлением нашей мыслительной деятельности по выделению его из реальности. Яблоко как объект существует благодаря тому, что мы решили это скопление частиц/полей назвать отдельным объектом. Объекты лишены не только от имманентных свойств, но и самостоятельного существования. Такой вот прикладной буддизм.
Ну, это далеко не однозначно с точки зрения философии. Мне вот по душе идеализм. Т.е. парадигма, в которой идеи существуют также, как и вещи.
И как круглый фрукт, и как квантовая система с волновой функцией, яблоко существует — но это просто две идеи, воплотившиеся в одной форме
Свойство объекта (в ООП) в этом случае оказывается резко 'разжалованным' — c концептуального на утилитарный уровень. Т.е. нет "правильного" или неправильного набора полей. Есть как-бы произведение невыразимой в коде сущности и техники моделирования. Тогда выходит, что техник моделирования может применяться одновременно несколько, и они "все правильные" — лишь бы было работоспособно с практической точки зрения.
Так я снимаю с повестки 9-й пункт, да и многие другие
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, Steamus, Вы писали:
S>>И снова упустили того кто должен совершить действие, то есть объект. Берём грамматику естественного языка. В ней базовое предложение это: подлежащее (объект/субъект) + сказуемое (действие) + дополнение (параметр).
DM>В огромном проценте фраз сказуемое — глагол "являться" (to be). The sky is blue. John is my friend. (в английском это нагляднее, т.к. у нас он часто опускается) Если все натягивать на ООП, у вас "to be" будет методом. И как вы себе представляете такой метод?
Это свойства класса. Методы представляю как set и get. Натягивать ВСЁ на ООП не нужно. Нужно "натягивать" лишь то, что имеет отношление к вашей задаче. Если в вашей задаче утверждение "The sky is blue" is важно, то введите свойство color для класса 'Небо'.
S>>И снова упустили того кто должен совершить действие, то есть объект. Берём грамматику естественного языка. В ней базовое предложение это: подлежащее (объект/субъект) + сказуемое (действие) + дополнение (параметр).
DM>В огромном проценте фраз сказуемое — глагол "являться" (to be). The sky is blue. John is my friend. (в английском это нагляднее, т.к. у нас он часто опускается) Если все натягивать на ООП, у вас "to be" будет методом. И как вы себе представляете такой метод?
Фраз уровня "Я Вася. Мне 20 лет. Я живу в Москве. Москва столица родины.", а не нормальных предложений
Здравствуйте, craft-brother, Вы писали:
CB>8. О сообщениях. Еще одна странность ООП. «Поведение — это то, как объект действует и реагирует; поведение выражается в терминах состояния объекта и передачи сообщений» (здесь и далее цитаты по Гради Буч, Объектно — ориентированный анализ и проектирование с примерами приложений на С++, Бином, 1998). Но, постойте, если я моделирую столкновение двух автомобилей то, кто из них и какие получает и передает сообщения?
Моделирование — это процесс упрощённого отображения окружающей действительности С НЕКОТОРОЙ ЦЕЛЬЮ, в условиях недостаточности ресурсов для неупрощённого отображения. Другими словами — моделирование это не цель, это средство. Инструмент решения задачи. Посему, постановка задачи в виде — моделирую столкновение двух автомобилей, не имеет смысла. Ибо зачем?
Задача должна быть сформулирована так: смоделируйте столкновение двух автомобилей С ЦЕЛЬЮ: оценить повреждения тел находящихся внутри при разных скоростях, оценить стоимость покраски поверхности после столкновения, оценить выключится ли сабвуфер после столкновения... ну и так далее.
Как только цель будет сформулирована, сразу становится понятно, что есть объект и какие его свойства критичны.
PS: Вряд ли имеет смысл вводить термин "сообщение" на том уровне, который вы выставили в данной теме. Он тут ни чем не отличается от 'вызов метода'.
> Существует мнение, что содержание первых высказываний человека состояли исключительно из требований помощи, которую бы мог оказать ему другой индивид.
Высосанное из пальца мнение. Впрочем как и все остальное
Науке достоверное известно, что первое высказывание человека было — "Ой, $ля!", что в зависимости от интонации означало удар камнем по пальцу или сигнал опасности.