Итак, есть некая активность. В мифологическом сознании первобытного человека за каждым действием стоит сознательное существо. Например, если течет, то делает это живое существо — река, если светит, то делает это живое существо Солнце. Поэтому в мифологическом сознании у каждого действия есть сознающий себя актор, который это действие выполняет. И мы можем сказать, что назначение (функция) этого актора — делать это действие. Я специально говорю о том, что все это происходит только в рамках мифологического сознания. Например, машина едет по дороге только в рамках мифологического сознания, потому что на самом деле машина не обладает волей и не может куда-то ехать. Наш язык настроен на отражение мифологического сознания, поэтому нам так сложно мыслить иначе. Например, можно было бы сказать, что участником активности является машина и дорога, в результате этой активности машина постоянно перемещается по дороге, но мы, одушевляя машину, говорим о том, что это делает именно машина. Таким образом, назначение машины в рамках мифологического сознания — ехать, или в рамках мифологического мышления функция машины — ехать. (хотя мы могли бы с тем же успехом одушевить колесную пару и сказать, что ехать — это функция колесной пары, а не машины). Замечу, что назначение как и функция — не имеет начала и конца в рамках существующего контекста.
В рамках того же мифологического сознания, если мы не знаем актора, но видим, что происходит нечто, то мы говорим о действии, которое происходит само по себе, и называем его процессом. Например, если мы видим пламя, то говорим, что идет процесс горения. При этом, если мы выяснили, что идет сжигание попутного газа, то мы можем, одушевив попутный газ в рамках мифологического сознания, сказать, что функция попутного газа — гореть. Мы можем также выяснить, что сжигание происходит при помощи специального факела, и, одушевив факел, мы говорим, что функция факела — сжигать попутный газ. Все ровно так же, как с машиной и колесной парой — что одушевили, то и делает: попутный газ, или факел. Я хочу подчеркнуть, что процесс — это функция без актора, и, также как функция, — не имеет начала и конца в рамках существующего контекста.
Иногда нам надо сказать об активности, которая имела начало и конец. В мифологическом сознании это действие также делает одушевленный актор, например, вулкан выбросил лаву. При этом описание активности в виде операции не есть описание активности в виде функции. Например, в мифологическом сознании функция Солнца — давать тепло. Но допустим, что в какой-то момент Солнце взрывается. В рамках мифологического сознания это происшествие не есть функция Солнца, — это операция, совершенная Солнцем. Описание активности в виде операции также не есть описание активности в виде процесса.
Иногда мы говорим о последовательности действий — сначала делается одно, потом второе, потом третье и тд. Такое описание активности — есть сценарий. При этом описание активности в виде сценария не есть описание активности в виде функции, или в виде процесса.
Иногда мы говорим о типовой последовательности действий. Например, мы говорим, что при пожаре надо действовать определенным образом. Тогда мы говорим о модели сценариев, или о регламенте. Регламент есть модель моделей активностей. При этом очень часто регламент путают с процессом, пытаясь одним словом назвать модель активности и модель модели активности. Это является грубой логической ошибкой.
В ООП мифологическое сознание проникло в виде методов, которые должны выполняться определенными объектами определенных классов. В статье Мир есть совокупность фактов, а не вещей об этом хорошо написано. Нам трудно мыслить вне рамок мифологического сознания и потому кажется естественным, что объект класса «машины» обладает методом «ехать». Но по сути своей — этот способ мышления — попытка одушевить неодушевленное.
Спасибо за внимание. Я, как и обещал, был краток.
Комментарии (42)
lair
18.12.2016 14:21В мифологическом сознании первобытного человека за каждым действием стоит сознательное существо
Нет. "Для мифологического сознания все, что существует — одушевлено." (википедия)
Например, машина едет по дороге только в рамках мифологического сознания, потому что на самом деле машина не обладает волей и не может куда-то ехать.
Вообще-то, нет. Чтобы ехать, не нужна воля.
Наш язык настроен на отражение мифологического сознания
С чего бы вдруг?
Собственно, из двух показанных выше неверных посылок вы и строите неверный вывод: "В ООП мифологическое сознание проникло в виде методов, которые должны выполняться определенными объектами определенных классов."
Нам трудно мыслить вне рамок мифологического сознания и потому кажется естественным, что объект класса «машины» обладает методом «ехать».
Человеку, который знаком с оригинальной концепцией Кея, и знает, что "метод "ехать" объекта "машина"" — это, на самом деле, сообщение "езжай" объекту "машина", это совершенно не кажется противоестественным и/или мифологичным. Есть актор, способный на конкретное действие, есть команда, его активирующая. Все логично.
SBKarr
18.12.2016 14:36+1Ключевой признак мифологического/магического/первобытного сознание — отсутствие цепочки выведения фактов (или категорий по Гегелю). Представление языковой пары «машина едет» как примера магического сознания и есть пример магического сознания, ибо это поверхностное представление. Что есть «машина»? Если у машины за рулём человек, она перестала быть машиной? Когда «машина едет», она с человеком за рулём один объект или нет?
Магическое сознание отличается тем, что «машина», и «дорога», и характеристика «едет» — монолитные сооружения в мыслях, неделимые, невыводимые, независимые. Язык здесь глубоко не при чём, без общественных установок/стереотипов язык нас ничему не учит, ни к чему не принуждает, он пуст, глух и бессмысленен.
Чтобы от магического состояния уйти, нужно приучить разум делать декомпозицию объектов и понятий автоматически. Даже если человек делает всего два шага разборки на составляющие, он уже не подвержен классическим ошибкам.
Монолитность мыслительных конструкций — признак, определяющий мифологическое сознание, из которого легко следуют и одушевление всего и вся, и святая вера в ритуал. Этот признак — часть мышления, не следующая из языковых навыков. Язык — продукт, а не основа. Например, категория «вещь в себе» очень хорошо ложится на традиционные выражения «ты не в себе!», «приди в себя!». То есть, язык подталкивает нас к кантовской философии, что ли?
P.S. Если интересно, как в действительности определить магическое сознание, рекомендую «Науку Логики» Гегеля,
drafterleo
18.12.2016 23:22+1Мне кажется, имеет смысл разделять мифологическое сознание и магическое мышление (во всяком случае попытки переосмыслить миф более-менее современном контексте осуществлялись и после Гегеля — скажем, Лосев или Барт). Миф (мифологиеское сознание) — это что-то вроде «зонда» восприятия, или такой специфический стиль осмысления. Не уверен, что его можно полностью вытравить из психики без высокого риска печальных последствий для последней. Например, свет лампочки накаливания для меня более уютен, тёпл, чем «казённый» свет классической люминесцентной лампы. Я могу до посинения декомпозировать этот факт, вспоминая электические схемы, закон Джоуля-Ленца, спектры электромагнитного излучения и т.п., раскапывая и рационализируя личный опыт (когда и с чего оно мне «прописалось») — квалитивное восприятие на уровне осчусчений останется таким же (а если и поменятеся, то целиком и сразу). Это мифологическое сознание. А вот если бы я искренне верил, что лампочкам самим по себе присуще эмоционально-температурное свойство (и лампочки таким образом мне что-то важное сообщают :)) — это было бы магическое мышление. Кстати, если при чтении этого текста у Вас (надеюсь) возникает какой-то относительно одушевлённый образ собеседника, это срабатывает мифологическое сознание (натурализатор концептов по Барту).
maxstroy
19.12.2016 06:41Спасибо за интересный комментарий! Моя статья — попытка за волосы поднять самого себя над мифологическим мышлением. Делается это исключительно в рамках задачи — построения расширяемой модели данных. Мне приходится отделять факты от их интерпретации. Причем на каком-то уровне ты начинаешь понимать, что само существование стула уже есть интерпретация. А, посмотрев далее, понимаешь, что и сам я — тоже плод интерпретации. Хорошо, что для целей моделирования мне это знание не нужно, иначе все начнется с того, что было слово и слово было… (непроизносимо)
S_A
19.12.2016 05:01+1Вот очень жаль что я пропустил обсуждение и статью про (любимого очень мною) Витгенштейна, так что тут
оторвусьвыскажусь.
Мир конечно это совокупность фактов, а не вещей. Факты связывают объекты (вещи). Здесь можно соглашаться. А дальше начинается разница, программирование и ООП в частности в свою очередь не настолько примитивны, насколько кажется. Если углубляться в Витгенштейна, то язык (программирования, моделирования и чего угодно) состоит в некотором отношении с миром и предложения на нём отражают факты, да. И Договор.закрыть() — это тоже факт, хотя он может и не совпадать с миропредставлением отдельно взятого бухгалтера. Просто это не тот договор, который у бухгалтера. Испытывать зуд при этом не стоит.
Если я правильно понял, вы считаете что процессное описание ближе к реальному описанию мира потому что нет «управляющего» объекта? В любом случае, в ООП его тоже нет. В нём нет объекта «мир» (хотя можно и завести), и в нем можно завести объект «процесс». Почему кто-то (автор программы в конечном итоге) просит что-то сделать объект, а не объект «делает сам»? Потому что программирование — это НЕ моделирование!!! Попробуйте создать модель, которая изменит состояние моделируемого объекта. Сможете? Нет.
Вся хрень в том, что Витгенштейна никто не дочитывает до конца. Есть у Дмитрия Гайдука такой рассказ (аудио), «про слова». Заканчивается тем, что (эвфемизмы) «слово само по себе фигня, важно как оно сказано, где и в какой момент. И конец». У Витгенштейна же одна из мыслей что перестановки слов ничего не меняют в мире, потому что это модель. Как только слово начинает что-то менять, оно становится объектом, как и всё в ООП. И конец.maxstroy
19.12.2016 06:28+1Потому что программирование — это НЕ моделирование!!!
Мой пост об этом же. И тезис был для тех, кто считает, что при помощи нотаций UML он моделирует реальный мир, а не программный код. Я считаю, что ООП — это про программу, а не про реальный мир. И, если так, то я спокоен, но очень часто (слишком часто) я слышу, что давайте построим диаграмму классов для описания реального мира (с наследованием и прочей требухней, которой в реальном мире нет и быть не может). И вот тогда я с удивлением обнаруживаю, что по-прежнему жив миф об ООП как о способе моделирования мира.S_A
19.12.2016 06:50Ну тогда я вас немного не в том ключе понял. Возможно вы были излишне кратки :) В любом случае читаю ваши публикации с интересом.
maxstroy
19.12.2016 06:55Просто мы знаем, кто такие системные аналитики — те, кто могут построить модели в нотациях UML, но вот кто такие бизнес-аналитики, которые должны строить модели предметных областей, нам неизвестно, потому что для них не придумали языка и методики описания предметных областей.Вот и приходится брать, что дают, чтобы из говна и палок слепить модель. Лично меня это не устраивает и я пытаюсь придумать что-то удобное для бизнес-анализа
S_A
19.12.2016 07:07Чем не устраивает BPMN? Лучше пока ничего нет, и в общем далеко не самое плохое из возможного.
Собственно сложность бизнес-аналитики не в столько в отсутствии инструментария на мой взгляд, а в огромном разнообразии (нет, не видов бизнеса, а) инструментария управления бизнесом. Все их вариации и комбинации приводят к тому, что каждая организация — этакий франкештейн, у которого некоторые конечности созрели больше, чем другие, и это ломает любые нотации.
Елиферов и Репин в своей книге про процессное моделирование писали, что можно (и может быть даже нужно) придумывать свои нотации под случай, главное чтобы они были доступными. Сами понимаете, чем универсальнее способ описания, тем сложнее в нём будет описана каждая деталь. И наоборот — чем детальнее способ описания, тем менее он универсален (и второй проект его окончательно доломает).
Я в своей практике бизнес-анализа «на общественных началах» понял, что лучше таких вещей как runthemodel.com я вряд ли что найду, поэтому и вам рекомендую жить в системной парадигме (которая как никак сейчас основная). Крутить концепции 100-летней давности любопытно, но у них был другой бэкграунд, и они были заточены под решение других противоречий.
S_A
19.12.2016 07:23+1Ага, нашел вашу статью про то, чем не устраивает BPMN (и до кучи диаграммы Гантта). Конкретно в том случае (когда индивидуальные проекты недалеки от типовых), всё решается понятием шаблона. Шаблонизация встречается много где, и по сути является в моделировании… моделью моделируемого.
Поэтому «до некоторой степени универсальный» «описатель» должен в себе содержать возможности по шаблонизации. Это немного отличная от ООП концепция, и по сути называется в экономике и менеджменте параметризацией.maxstroy
19.12.2016 08:17Да, шаблон — есть модель модели. Но в ИТ, а также у консультантов на эту тему полная каша. Они на одну доску ставят модели и модели моделей, смешивая уровни абстракции.
Кроме того, я прошу правильно меня понять — я не занимаюсь вопросами управления или инструментами управления бизнесом. Я строю модели описания активности, которые потом могут быть применены в качестве инструмента управления бизнесом, но сами по себе таковыми не являются. Проблема консультантов в том, что они сразу переходят к интерпретации данных, пропустив шаг сбора данных. Это приводит к избирательному видению и ограниченности мышления
Shortki
19.12.2016 06:32+1При определённом уровне развития и семантика может казаться магией. Машина (как автомобиль) это семантическая конструкция обобщающая определённый тип средств передвижения. Возможно в детском возрасте она может иногда восприниматься в мифологическом аспекте, и её можно “по-человечески” попросить ехать быстрее, но обычно в утилитарном использовании взрослый человек воспринимает слово “машина” как удобный ярлык, не требующий сложного разъяснения при использовании и обходящийся без мифологических коннотаций и одушевлений.
Вы обнаружили корреляцию и сделали из неё далеко идущие выводы, всё потому что мифология “паразитирует” на семантике, а нас с детства учат что мифологический подход самый низкозатратный при объяснении не вполне ясных явлений.
Ну, а ООП это лишь семантическая методика, не мифологический подход, попытка смешать одно с другим приводит к концепции магии, а здесь и до Гарри Поттера недалеко, и это не комплимент.
aso
19.12.2016 08:04«Машина едет» означает (может означать) что машина движется «сама», без наличия внешних побуждающих сил.
Сиречь источник её движения находится внутри неё самой — а не снаружи, как в случае телеги, кареты или лошади.
Точно так же часы с кукушкой отсчитывают время и кукуют необходимое количество раз — в силу «внутренних причин», своего устройства, а не желания кого-то снаружи.
То же самое относится и к компьютеру, который исполняет программу в силу своих «внутренних» причин — а не чего-то внешнего.
Разумеется, можно трактовать эту ситуацию и мифологически — что «машина — вещь одушевлённая», но это другое.maxstroy
19.12.2016 08:29Источником движения машины может быть что угодно, — мы не знаем что именно, но лишь догадываемся. Мы можем сказать, что участвует в движении машины: дорога, водитель, машина, воздух, другие машины, другие водители и проч., но сказать в чем причина ее передвижения — не можем, потому что это лишь наша гипотеза в текущий момент времени при текущем уровне знаний и представлений. Для бизнеса не нужна модель причин, но нужна модель фактов, фактов без интерпретации их. А лишь потом тот, кто хочет, может интерпретировать эти факты так, как захочет
Oxygen99
29.03.2017 10:34+1Да, это, конечно, бюджетно. Но все равно круто! Надо будет жене как-нибудь нечто похожее изготовить)
maxstroy
19.12.2016 09:15Факты собирает следователь, оценку им дает судья. Моя задача — построить модель для следователя. Давать оценку будут разные стейкхолдеры и получать разные результаты, но это уже второй шаг. Я же вижу, что первый шаг в моделировании просто пропускается и сразу переходят ко второму — даче оценок. Но тогда нельзя на основе такой модели построить представления разных точек зрения, и ценность модели резко падает. Как минимум, она становится нерасширяемой.
aso
19.12.2016 09:55Если следователь не будет задумываться о том, как и на основании чего судья даёт оценку собранным следователем фактам (на самом деле работа следователя отнюдь не сводится к сбору улик) — то судья будет постоянно давать негативную оценку собранным следователем «фактам», а последнее — будет поводом для постановки вопроса о профнепригодности данного «следователя».
Играть эту игру в стеке разработки можно дольше — но, в конце-концов — работа продукта, созданного на основании Ваших предсказаний окажется некорректной — и те, кто им пользовался — окажутся у разбитого корыта.
Сиречь заботиться о корректности и единстве модели, на основании которой Вы взаимодействуете с дальнейшими этапами разработки — в том числе и Ваша задача, и Ваш интерес.
P.S. А называть первичные данные — «фактами» — это очень сильно льстить им.maxstroy
19.12.2016 10:27Возможно Вы правы, но это значит, что я плохо донес мысль. Как только мы говорим «машина едет», мы даем такую интерпретацию событиям, которую потом будет сложно переделать в «водитель катится в машине». Поэтому кто катится и почему — вопрос второй, но и в первом и во втором случае участники у нас одни и те же. Фиксация этих участников и есть факты, а приписывание им ролей — это интерпретация.
aso
19.12.2016 10:48Здесь какой-то уже совсем глубокий уход от обычной семантики русского языка.
Сказать «водитель катится в машине» — как-то совсем нельзя.
«Водитель катается на машине» — т.е. передвигается бесцельно, с целью получить удовольствие от самого процесса «катания».
«Водитель катается в машине» — боюсь, что он потерял сознание, и его тело безвольно катается по полу кабины.
В общем, Ваша градация, мягко говоря — нечёткая и неоднозначная.
А описание без выявления причинно-следственных связей — неполное по-определению.maxstroy
19.12.2016 10:52Выявление участников — первый шаг, второй — интерпретация их участия с разных точек зрения, сравнение разных точек зрения, проведение анализа с учетом интересов разных стейкхолдеров. Строить модель только с точки зрения одного стейкхолдера — обречь себя на нерасширяемость модели и на невозможность ее анализа.
aso
19.12.2016 13:11Гхм.
Давайте начнём с базы.
Мир есть совокупность объектов, которые вступают в отношения.
(Ну и ещё объекты имеют свойства; иногда свойства непросто отличить от отношений.)
Факты — это некоторые высказывания относительно объектов внешнего мира, их свойств и отношений — которые являются истинными.
Например, «машина едет [по дороге]» — это высказывание — и, возможно — факт.
Хотя немножЭчко и интерпретация — ибо можно «снизить» уровень высказывания — «положение машины [относительно дороги] изменяется».
При этом первичными данными будет набор отметок о положении объекта «машина» относительно объекта «дороги», к примеру.
Стейкхолдеры — это не столько «объекты:, сколько категории, т.е. множества объектов, обладающих неким общим свойством, интересующим нас в текущей ситуации.
Стейкхолдеры — это часть объектов всего окружающего мира, плюс у нас всегда существует „окружающая среда“ (та же дорога, к примеру) — и возможны „случайные участники“ — например, на дорогу перед машиной выбегает пешеход или корова.
Ну и плюс — у „окружающей среды“ могут быть „состояния“ — т.е. свойства.
Дождь, туман или гололёд на дороге.
Т.е., в общем-то это тоже может быть рассмотрено как объекты — но проще и удобнее рассматривать их в качестве „свойств среды“.
Вопрос, включать ли „случайных участников“ или „окружающую среду“ в число стейкхолдеров — или отнесения тех или иных явлений в какую-либо из категорий есть вопрос философский, т.е. сильно зависит от конкретных условий задачи.
Ну и плюс — весь процесс классифицирования есть процесс итеративный, в котором стадии „выявления участников“ и определения их взаимоотношений — взаимосвязаны, и полноценно существовать друг без друга не могут.
Как-то так, мне кажется.
geher
19.12.2016 14:29С точки зрения формальной логики в конструкции «водитель катится в машине» больше «магии», чем в конструкции «машина едет».
По сути это комбинация установленной связи водитель-машина (водитель в машине) и состояния машины (едет).
В данном процессе осуществляется обмен управляющими воздействиями. Водитель воздействует на управляющие органы машины, сообщая ей свои требования, а машина перемещает водителя в соответствии с измененным после получения управляющего «сообщения» от водителя внутренним состоянием.
Cyrus
19.12.2016 11:48Точно так же часы с кукушкой отсчитывают время и кукуют необходимое количество раз — в силу «внутренних причин», своего устройства, а не желания кого-то снаружи.
Но как же, взводил их вполне конкретный человек, который хотел, чтобы с определенной периодичностью кукушка куковала.
Аналогично и с машиной, которая едет. У нее может быть не только мотор и топливо, но и блок автоматической подачи, этот блок может даже сам принимать решение, очень запутанное, основанное на обучении. В один прекрасный день вы выходите, а она угадывает, что нужно подъехать именно сейчас. Но все же, когда-то ее запустили и это все тот же механизм, который взвели на заводе чьей-то конкретной рукой. Возможно даже механической, но и она в свою очередь тоже была кем-то создана.
Означает ли это, что «одушевленность» определяется простой невозможностью отследить первопричину движения?aso
19.12.2016 13:19Но как же, взводил их вполне конкретный человек
Их может взводить не только человек, и не обязательно конкретный человек — результат их работы от этого ничуть не изменится.
Я называю такие вещи «автономными системами» — т.е. алгоритм их функционирования определяется их внутренним устройством, из внешней среды приходят только некие достаточно простые вещи.
Но все же, когда-то ее запустили и это все тот же механизм, который взвели на заводе чьей-то конкретной рукой. Возможно даже механической, но и она в свою очередь тоже была кем-то создана.
Это не имеет значения.
Означает ли это, что «одушевленность» определяется простой невозможностью отследить первопричину движения?
Понятие «одушевлённости» вообще никак не возможно определить — бо мы не знаем на сегодня, что такое «душа». Для меня и собака и кошка — имеют душу, а для кого-то не всякий человек — одушевлён.
Но если в корректном описании объекта понятия «душа» можно избежать — то его следует избегать.
Любая машина работает в соответствии с физическими законами, и эти законы могут быть познаны и использованы при её изготовлении.
maxstroy
19.12.2016 14:40-1С практической точки зрения оказывается не важно, кто и что делает в активности. Главное — кто и что участвует в активности. И тогда модель становится симметричной — есть участники активности и состояния объектов, более ничего, но ничего более нам и не надо. Интересно, что попытки найти акторов, результаты и проч — лишние. Для анализа активности это несущественно. Но мы все равно продолжаем цепляться за мифологические представления об акторах, совершающих деяния
geher
19.12.2016 09:34Какие-то странные посылки и выводы.
1. Машина едет — это ни магическое, ни мифологическое сознание. Это не более чем утверждение, заостряющее внимание на соединенин предмета и действия.
Если машина едет, то это не обязательно ее воля или даже функция (это вполне может быть просто побочный эффектом).
И также это не означает, что высказывающийся не имеет понятия о причинах и процессе «ехать» и о внутреннем устройстве, позволяющем машине выполнять это действие.
2. Следует разделять ООП и инструменты для его реализации.
Суть ООП — описание взаимодействия между объектами путем передачи ими друг другу уведомлений.
Классы в «ООП языках» являются всего лишь инструментом, позволяющим описать поведение объекта, выделив его в программе синтаксисом языка. А вызов метода всего лишь реализует частный случай обмена уведомлениями, когда вызывающая сторона уведомляет о необходимости выполнить действие, а вызываемый объект рапортует о результате (причем второе не обязательно).
Исключения же не являются частью объектной модели.Они нужны только для того, чтобы обработать ситуацию, когда реальное взаимодействие объектов вошло в противоречие с созданным программистом описанием в виде программы.
Конечно, классы с методами не покрывают всего многообразия возможных сценариев взаимодействия объектов. Но никто не мешает реализовать недостающие инструменты для реализации всего остального самому или воспользоваться готовыми решениями.maxstroy
19.12.2016 10:37-1Мы находимся в мире, который описывается четырехмерным пространством-временем. Для моделирования этого мира нам не надо прибегать к термину «соединение объекта и действия», который был бы уместен в эпоху Аристотеля, но совсем не уместен в 21 веке. Дело в том, что в четырехмерном мире нет объектов без действий и действий без объектов. Объекты и действия — одно и то же. На этом стоит стандарт ИСО 15926 и это позволяет моделировать мир при помощи теории множеств. Иначе — добро пожаловать в Древнюю Грецию!
Суть ООП в описании кода, но не предметного мира. Я дал коммент насчет ООП только для того, чтобы подчеркнуть, насколько ООП далек от моделирования реального мира.geher
19.12.2016 15:10Во-первых, мы соединяем не объект и действие, а предмет и действие.
А это объекты разных категорий.
Во-вторых, тот факт, что объект не существует без действия не делает некоторое конкретное действие объекта необходимым в нашей модели (например, нам может быть совершенно безразлично, что машина не только едет, но и издает звуки).
Далее, соединение предмета и действия является не более чем элементом процесса построения модели, когда ма соединяем нужные действия с нужными предметами, игнорируя те, которыми можно пренебречь.
Ну и утверждение, что объекты и действия суть одно и то же, как мне представляется, некорректно. Пусть объект не существует без действия, но он может быть чем-то бОльшим, чем одно лишь действие.
Что же до соотношения ООП, моделирования и описания кода, то, может быть, я отстал от жизни и не заметил упрощения понятия «программирование», но я как-то привык считать создание модели предметной области неотъемлемой частью процесса пиограммирования, а потому привык распространять понятие ООП и на этот этап.
Vlad_fox
19.12.2016 14:09статья краткая — это плюс.
минус — так и не понял какую проблему поднял автор в статье и как предложил ее решить.maxstroy
19.12.2016 14:45Я хотел поделиться исследованиями в области терминологии, — слишком часто я слышу, как разные вещи называют одним словом — процесс. А определение функции настолько ужасное, что воспроизводить его я не буду. Хотелось разобраться в этом и поделиться.
Vlad_fox
20.12.2016 13:17Спасибо за ответ. Хочу поделиться мыслью об:
Нам трудно мыслить вне рамок мифологического сознания… Но по сути своей — этот способ мышления — попытка одушевить неодушевленное.
Предлагаю понятие «сознание» убрать из рассмотрения вообще, достаточно «мышление». Меньше путаницы будет.
«Одушевленное/неодушевленное» тоже не использовать, это рудиментарные понятия только усугубляющие путаницу.
вместо «мифологическое мышление» использовать понятие «обьектно-субъекнтый подход»:
есть обьект/субьект который получив на вход А (аргументы и имя метода в ООП, заклинание в магии, удар в физике, добавление воды в химии..) выдает Б ( выполнение другого метода в ООП, действие силы в магии, движение в физике, растворение в химии… ).
вся суть подхода в том, что можно прогнозировать ожидаемый исход от действия, зная набор формул (правил, теорию) какие А вызывают какие Б.
Это дает возможность построить модель предметной области и более-менее еффективно в ней моделировать ее и свое поведение.
этот подход самый древний, разработан еще первобытными, которые рисовали оленей на стенах пещер и первые слова языков. но работает и по сегодня как самый массово доступный и применяемый.
Другой подход — системный. появился недавно и еще в разработке. громоздкий в оперировании, теоретически еще не проработанный, возможно в человеческой логике (логике человеческих языков) и вовсе окажется неподъемным. Но уже неплохо показывает себя в компьютерных системах (модели не нейросетях).
Других подходов насколько помню не известно.
Итого, остается по знаменитому принципу «разделяй и властвуй», нарезать из реальности небольшие слабо связанные между собой сектора, для которых строить языковые модели с более-менее однозначными иерархически сгруппированными наборами понятий и в них работать в объектно-субъектном подходе.
и помнить, что многие понятия из разных моделей при похожем написании несут достаточно различающуюся смысловую нагрузку…
Vlad_fox
20.12.2016 19:11-1пример понятий из разных моделей знаний, выраженных одним и тем же термином:
скорость (движения) в физике — целое семейство понятий (средняя с., моментальная с.) связывает расстояние со временем при движении тела.
скорость (реакции) в химии — связывает время реакции с составом хим. реактивов и условиями реакции (температура, давление..) (расстояние выпало)
скорость схождения числового ряда — связывает кол-во елементов ряда с точностью схождения (и время и пространство выпали).
если свести их в «единое» понятие — получится что-то настолько абстрактное (зависимость одной величины какого-то явления от нескольких других величин), что оно захватит и множество других понятий и будет практически неприменимо для прикладного мышления внутри моделей… сольется с понятием зависимость или функция…
Да, все что написал и пишу -это ИМХО, не претендующее на исключительную истину общего употребления,
это только полуфабрикаты моего мышления в поисках теории знания, информации… (вдруг кто иначе воспримет, минусовать начнет из-за несогласия)
sand14
В изначальном объектно-ориентированном подходе у машины нет метода «ехать».
Любой объект может принять любое сообщение, и результат не гарантирован.
Машина, скорее всего, поедет, а лошадь скорее всего, нет — ей нужно сообщение «скакать галопом».
Но когда ОО-языки стали превращаться из динамических в статические, процесс отправки сообщение объекту стал называться вызовом метода, а имя сообщения методом.
Получилась подмена:
изначально имя сообщения (метода) задавалось вызывающей стороной,
а потом внезапно оказалось, возможные для вызова методы стали задаваться на стороне объекта-приемника.
Отсюда и получилось, что «машина имеет метод 'ехать'».
Недавно на хабре была серия статей про Алана Кея и Smalltalk — можно обратиться к ним и почитать дополнительные материалы по Smalltalk.
И, наверное, не случайно динамические языки до сих пор популярны и активно развиваются (Ruby и многие другие).
maxstroy
Спасибо за комментарий! Просто часто можно слышать про методы объектов класса в ООП и это вводит в заблуждение
sand14
Есть еще один момент: изначально в идее Алана Кея было определено, что объекты могут «развиваться» в течение времени жизни.
Это значит, что список сообщений, который может обработать объект, может меняться со временем.
Если говорить в современных терминах («метод объекта»), то что происходит, когда мы пытаемся вызвать метод, который не имеет смысла для текущего состояния объекта (текущего сочетания значений полей)?
В статических языках такой метод должен сгенерировать исключение вида InvalidOperationException:
Очевидно, что если возможно такое состояние объекта, при котором тот или иной метод является недопустимой операцией, то это архитектурная ошибка при разработке иерархии типов в соответствующем приложении.
Но гораздо хуже, если разработчик класса в таком случае, вместо генерации исключения, сразу вернет управление из метода (метод «ничего не делает», но клиентский код будет «думать», что метод отработал), и еще хуже, если в методе будет выполнена основная ветка кода на неконсистентных данных.
А что происходит в динамических языках?
Плюсы динамического подхода:
drafterleo
Помимо инкапсуляции (сведения функций и состояний в отдельный структурно-семантический «объём») в ООП ещё наличествуют абстракция, полиморфизм и наследование. Код, посылающий сообщения, скорее всего будет оперировать не конкретными объектами, а их обобщениями. То есть в его представлении будут не машины или лошади, а, например, транспортные средства. И сообщения, соответственно, будут — «переместиться» вместо «ехать» или «скакать». А как именно перемещаться (или не перемещаться) уже решат сами объекты, исходя из своего классового существа и актуального состояния. В этом главная практическая польза ООПа, иначе и огород было бы незачем городить.
sand14
Есть мнение, что наследование лишь одно из возможных (и не самое удачное) средств реализации полиморфизма и повторного использования кода.
Конечно, машина и лошадь вполне могут обработать сообщение «переместиться», если в заданной предметной области способ перемещения не важен, а вот здание класса «недвижимость» — нет.
drafterleo
Кто ж спорит. Однако, я думаю, что наследование — это в некотором роде золотая середина. С одной стороны, управляющий код может знать все объекты «в лицо» и манипулировать ими очень тонко в зависимости от индивидуальных особенностей (что требует весьма больших информационных затрат). С другой стороны, программа-оператор может вообще ничего не знать об объектах, с которыми работает (кроме того, что они объекты), и надеяться, что они «поймут» и обработают транслируемые команды-сообщения (здесь проблемы с обеспечением нужного результата — вроде как «моё дело прокукарекать, а там хоть не рассветай»). А вот если известен базовый класс управляемых объектов, мы получаем достаточную гарантию реализации абстрактных методов, т.е. заблаговременно знаем, какие сообщения будут обработаны подопечными объектами наверняка (что позволяет поднять уровень общей организации, особо не повышая сложность управляющего кода).
aso
А обработка сообщения осуществляется Господом Богом — или, всё-таки — кодом объекта?
«Изначальный» (первоначальный) язык ООП — это Симула, которая несколько раньше Алана Кея.
Хотя последний и придумал название «ООП».