Давным давно, когда ООП для меня было в новинку, я прочитал в одной книжке, что объекты моделируют реальность (вроде бы Гради Буч). Я не могу привести ссылку, но хорошо помню, что это была не случайная мысль, а мощный разработанный тезис, который, в частности, выдвигался в поддержку самого ООП — якобы оно нужно программисту, чтобы моделировать реальность, с помощью него моделировать реальность очень хорошо. И до сих пор я замечаю, что иногда этот тезис проскакивает в общих размышления об ООП у его поклонников, типа "таким образом мы лучше моделируем реальность".
Я, однако, не поклонник, смотрю на ООП критически, и это одна из причин, почему. Я не думаю, что программы моделируют реальный мир. Таковыми являются только те программы, у которых в ТЗ прямо записано, что функция программы — моделирование. Например, предсказание погоды, компьютерные игры (стрелялки). Конечно, ПО для моделирования — важная и нужная часть ПО, но именно часть. А в ООП получается, что каждая программа неявно моделирует. Мне, честно говоря, тяжело это представить.
Мне могут привести конкретные примеры. Например, система учёта ТМЦ моделирует, собственно, ТМЦ, как там они перемещаются географически и пр. С этим я не спорю. А бухучёт что моделирует? Бумажный бухучёт? А если мы вспомним, что сами деньги — это не бумажки или драгоценные металлы, а условность. А компьютерная игра "Шахматы" что моделирует? Деревянные шахматы? Которые тоже условность, и в свою очередь моделируют что?.. К любой программе можно притянуть за уши какой-то физический объект, потому что компьютеры появились относительно недавно, и у многих программ должен быть хотя бы бумажный прототип.
Я не возражаю против того, что любая программа что-то моделирует. Это вопрос схоластики. Доказать можно. Меня интересует, насколько полезен такой взгляд программисту, насколько полезно ложить его как основу парадигмы программирования.
Я предпочитаю смотреть на программу как на машину — что она умеет делать, насколько удобно ей управлять. Возможно даже, тезис о моделировании — это хитрый ход конём, уход от пользователя. У нас есть объективная реальность, мы её в тиши кабинета с ретортами и колбами моделируем, а пользователь со своими предложениями пусть пока постоит за дверью. А ведь даже моделирование интересует не вообще, а в том аспекте, который интересует пользователя. Самолёты учитываются по-разному в бухгалтерии, КБ, аэропорту.
Этот взгляд губителен хотя бы тем, что мы концентрируемся на предметной области, а не на тех преимуществах, которые даёт современная техника. Ведь компьютер может гораздо больше, чем делалось с помощью ручки и бумаги... Зачем же моделировать ручку и бумагу?
Или я уделяю слишком много всему этому внимания?
Это одна из ошибок, благодаря которым некоторые товарищи приходят к выводу что ООП никуда не годится. В реальности все заметно сложнее. Большинство современных моделей программирования рассчитаны не на моделирование, а на конструирование. А для перехода от модели реального мира к модели программы существуют специальные процедуры. Например для реляционных БД это нормализация, для ООП это объектная декомпозиция.
Удобство же ООП не в том что оно удачно моделирует реальный мир, а в том что модель ООП привычнее для восприятия человеку, который даже абстракции представляет ввиде неких сущностей. Ну чтобы можно было как бы пощупать. Вот ООП и предлагает некий набор кубиков и напильник к ним для подгонки. Даже если готового кубика нет — всегда проще сделать новый кубик, нежели с нуля лепить всю конструкцию. Все остальные особенности разных реализаций ООП суть просто разные виды кубиков — одноразовые/многоразовые, твердые или из пластилина и т.п.
Здравствуйте, beroal, Вы писали:
B>Давным давно, когда ООП для меня было в новинку, я прочитал в одной книжке, что объекты моделируют реальность (вроде бы Гради Буч). Я не могу привести ссылку, но хорошо помню, что это была не случайная мысль, а мощный разработанный тезис, который, в частности, выдвигался в поддержку самого ООП — якобы оно нужно программисту, чтобы моделировать реальность, с помощью него моделировать реальность очень хорошо. И до сих пор я замечаю, что иногда этот тезис проскакивает в общих размышления об ООП у его поклонников, типа "таким образом мы лучше моделируем реальность".
[skip] B>Этот взгляд губителен хотя бы тем, что мы концентрируемся на предметной области, а не на тех преимуществах, которые даёт современная техника. Ведь компьютер может гораздо больше, чем делалось с помощью ручки и бумаги... B>Зачем же моделировать ручку и бумагу? B>Или я уделяю слишком много всему этому внимания?
А чему еще уделять внимание? Кодированию что-ли?
Представь, что у людей есть реальная модель (которой они до этого пользовались), и они хотят реализовать ее на компьютере. Тогда они делают вычислительную модель, основываясь на реальной модели. Поскольку ресурсы компьютера ограничены (скорость, память, время), и возможности компьютера по моделированию реальности не безграничны, вычислительная модель ОБЯЗАНА отличаться от реальной модели. Тут и чисто формальные отличия (например, язык программирования), и смысловые (например, поверхность предмета вместо предмета целиком).
В зависимости от предметной области эти различия могут быть большими или маленькими. Гради Буч, например, часто автоматизировал бизнес-процессы, и как раз там возможности современных компьютеров позволяют реализовать модель, мало отличающуюся от модели-прообраза.
А вот в 3d-графике что прикажете делать?
Итак, поскольку вычислительная модель и реальная модель существуют в различных средах, понятно, что они должны различаться. Встает вопрос, насколько, и как бы это все дело по максимуму упростить и алгоритмизировать.
Ну тут разные дядьки предлагали свои идеи.
Посмотрим теперь снова на идею программирования от объектов:
Первое. Все предметы реального мира становятся объектами. Конечно, нас интересуют только объекты, которые мы собрались автоматизировать, поэтому остальные нужно выкинуть — чем меньше модель, тем проще ее сделать.
Теперь привяжем некоторым объектам поведение, некоторым — данные, некоторым — состояние. Некоторым — все вместе
Мы должны сделать это таким образом, чтобы количество связей и количество объектов было как можно меньше — опять же, не забываем, что нам все это программировать, да еще и отлаживать
Что мы получили? Правильно, контракты объектов!
На этом шаге важно не забыть: время, затрачиваемое на "поведение" объектов в каждый момент работы не должно превышать скоростные возможности компьютера. Как и место в памяти, на жестком диске, в кристалле. Если будет так, то говорят, что задача не влезла в компьютер и модель придется изменять.
Ну а дальше — все, как по нотам. Выбираем шамана, который говорит, каким правилам лучше всего следовать при реализации выбранных алгоритмов и при трансформировании модели в код (типа, он так когда-то делал и все быстро/качественно/весело/несмотря ни на что/с грехом пополам/как-то еще получалось), правила записываем на бумажке, на долгую память (вот оттуда апологеты парадигм программирования и берутся), и начинаем заниматься нелегким программистским трудом
Конечно, можно проделывать все шаги, описанные выше, без ручки, бумажки, доски, правил кодирования, шаблонов проектирования, продвинутых средств моделирования, по старинке, в голове. Одно плохо — эффективность все больше падает при возрастании объема той части, которую нужно держать в голове
Ну а после написания первого варианта (иногда и во время) появляется еще одна заманчивая возможность — оптимизация. Типа, переплюнем реальную модель, да еще и компьютер будет делать за минуты и за копейки то, что раньше делал сутками и за солидную часть бюджета страны. И часто ведь получается. Но теперь снова, уже у других мужиков, надо совета спрашивать... Впрочем, если программа позволит такие деньжищи экономить, то почему бы и нет!
Ну и таким образом, я надеюсь, с высоты птичьего полета, понятно, с чем и зачем возюкаются программисты, и как к этому привязано ООП?
Попробую теперь прокомментировать твою фразу:
B>Этот взгляд губителен хотя бы тем, что мы концентрируемся на предметной области, а не на тех преимуществах, которые даёт современная техника. Ведь компьютер может гораздо больше, чем делалось с помощью ручки и бумаги...
ООП — это методика превращения человеческих идей в программы.
Предметная область — первый шаг на пути к этому. Но если она будет тесно связана с программой все время разработки, скорее всего, мы получим от этого преимущества. Программа будет понятной без комментариев, ведь имя объекта или его тип — это уже замечательный комментарий!, и внезапно придуманные изменения модели ака преждевременная оптимизация будут понятным и локальным образом отображаться на программу.
А оптимизирует наши излишества пусть всегда внимательный компилятор
Здравствуйте, AndrewVK, Вы писали:
AVK>Это одна из ошибок, благодаря которым некоторые товарищи приходят к выводу что ООП никуда не годится. ...
AVK>... Вот ООП и предлагает некий набор кубиков и напильник к ним для подгонки. Даже если готового кубика нет — всегда проще сделать новый кубик, нежели с нуля лепить всю конструкцию. Все остальные особенности разных реализаций ООП суть просто разные виды кубиков — одноразовые/многоразовые, твердые или из пластилина и т.п.
Совершенно нет желания возразить, хочу скорее уточнить, что кубики-напильники это по-видимому все же модульное, а не объектно-ориентированное программирование. Да и вот в ASP.NET я почему-то не OnLoad переопределяю, а Page_Load подключаю. А ООП ли это?
P.S. Ну и да, я и есть один из тех самых пришедших к выводу товарищей. Не категорично конечно, но скажем для 60-80% задач.
Здравствуйте, igna, Вы писали: I>Совершенно нет желания возразить, хочу скорее уточнить, что кубики-напильники это по-видимому все же модульное, а не объектно-ориентированное программирование.
Ещё можно назвать декомпозиция и повторное использование кода. Эта метода, кажется, не требует ни ООП, ни моделирования. Даже на форуме уже где-то обсуждалось.
Здравствуйте, igna, Вы писали:
I>Совершенно нет желания возразить, хочу скорее уточнить, что кубики-напильники это по-видимому все же модульное, а не объектно-ориентированное программирование.
Все таки ты меня видимо не понял. Речь шла не о реализации (к которой имеет отношение модульность и компонентность), а о модели программы.
I> Да и вот в ASP.NET я почему-то не OnLoad переопределяю, а Page_Load подключаю. А ООП ли это?
ASP.NET ООП, а то, о чем ты говоришь всего лишь различное использование его идей на практике.
Здравствуйте, buriy, Вы писали: B>Представь, что у людей есть реальная модель (которой они до этого пользовались), и они хотят реализовать ее на компьютере. Тогда они делают вычислительную модель, основываясь на реальной модели. B>[skip]
Вы начинаете с "реальная модель" и дальше поехало... А я именно наличие этой модели поставил под сомнение.
Кстати, я не обсуждаю ООП. Я выделил жирным шрифтом, что обсуждаю. B>Я не возражаю против того, что любая программа что-то моделирует. Это вопрос схоластики. Доказать можно. Меня интересует, насколько полезен такой взгляд программисту, насколько полезно ложить его как основу парадигмы программирования.
Не хотелось бы сбиваться на флейм.
Re[2]: Программирование есть моделирование реального мира
Здравствуйте, AndrewVK, Вы писали: AVK>Это одна из ошибок, благодаря которым некоторые товарищи приходят к выводу что ООП никуда не годится.
Прочитайте моё сообщение внимательнее, и вы увидите, что я не хаю ООП. B>Я не возражаю против того, что любая программа что-то моделирует. ... насколько полезен такой взгляд программисту, насколько полезно ложить его как основу парадигмы программирования.
ООП — это просто источник вопроса. AVK>Это одна из ошибок, благодаря которым некоторые товарищи приходят к выводу что ООП никуда не годится. В реальности все заметно сложнее. Большинство современных моделей программирования рассчитаны не на моделирование, а на конструирование. А для перехода от модели реального мира к модели программы существуют специальные процедуры. Например для реляционных БД это нормализация, для ООП это объектная декомпозиция.
Меня не интересует схоластика. Если моделирование = конструирование, то дальше я пас, обсуждайте без меня. Я говорю именно о моделировании реального мира ("моделировании предметной области методами ООП" здесь
).
Короче, о моделировании в узком смысле слова. Это когда с помощью физических экспериментов устанавливаем свойства исследуемого объекта, а затем составляем программу, которая имитирует деятелььность объекта. Экономический резон — проводить манипуляции с объектом экономически невыгодно или невозможно. AVK>А для перехода от модели реального мира к модели программы существуют специальные процедуры.
У вас я опять вижу "модель реального мира". Я лично пляшу от пользователя. Как главбух решил — так и будет. Предметная область не играет определяющей роли. Для программиста реальный мир — сущность виртуальная.
Re[3]: Программирование есть моделирование реального мира
Здравствуйте, beroal, Вы писали:
AVK>>Это одна из ошибок, благодаря которым некоторые товарищи приходят к выводу что ООП никуда не годится. B>Прочитайте моё сообщение внимательнее, и вы увидите, что я не хаю ООП.
А ты прочти мое и покажи где я говорю о том что ты его хаешь.
AVK>>Это одна из ошибок, благодаря которым некоторые товарищи приходят к выводу что ООП никуда не годится. В реальности все заметно сложнее. Большинство современных моделей программирования рассчитаны не на моделирование, а на конструирование. А для перехода от модели реального мира к модели программы существуют специальные процедуры. Например для реляционных БД это нормализация, для ООП это объектная декомпозиция. B>Меня не интересует схоластика.
С чего ты взял что это схоластика? Вполне реальные наблюдения.
B> Если моделирование = конструирование,
Я этого не говорил. Я говорил о том что разработка дизайна программ = конструирование.
AVK>>А для перехода от модели реального мира к модели программы существуют специальные процедуры. B>У вас я опять вижу "модель реального мира". Я лично пляшу от пользователя.
Пляши. Только толку от этого 0. Пользователь не может знать как писать программы. Максимум что от него можно добиться это набор требований, и то для этого нужно море усилий. А от требований до реального проекта, по которому можно писать код еще очень долгий путь. А когда со слов пользователя сразу начинает проектироваться программа, то это мягко говоря кустарный подход. И даже если не говорить о том плохо это или хорошо, делать выводы о применимости или неприменимости того или иного метода исходя из подобного подхода не стоит.
B> Как главбух решил — так и будет.
Смени место работы. Я серьезно. А то так и будешь считать ОО-декомпозицию схоластикой.
B> Предметная область не играет определяющей роли. Для программиста реальный мир — сущность виртуальная.
Здравствуйте, beroal, Вы писали:
B>Ещё можно назвать декомпозиция
В этом то и вся "фишка". Декомпозиции бывают разные. Есть две совершенно ортогональные: алгоритмическия декомпозиция и объектная. Апологеты ООП утверждают, что объектная декомпозиция лучше, чем алгоритмическая, ну а поклонники структурного программирования, соответственно, агетируют за алгоритмическую. В стиле декомпозиции и заключается разница между ООП и структурным подходом, а, отнюдь, не в "моделировании реального мира".
Здравствуйте, beroal, Вы писали:
B>Вы начинаете с "реальная модель" и дальше поехало... А я именно наличие этой модели поставил под сомнение.
Смысл не поменяется, еслм заменить фразу "реальная модель" на "идеальная модель". То есть на идеализированную модель, существующую исключительно в сознании человека. Действительно, фраза "реальная модель" не имеет никакого смысла, так как человек мыслит своими собственными абстракциями, то есть используя ТОЛЬКО "идеальную модель". Причем моя идеальная модель автомобиля будет сильно отличаться от идеальной модели человека, конструирующего автомобили. Другими словами, модели существуют только в нашем сознании. В этом смысле для меня модель "автомобиль" абсолютно ничем не отличается от модели "файл". Поэтому, я буду преобразовывать свою идеальную модель в программную, используя одни и теже принципы, в не зависимости от того, есть ли прообраз идеальной модели в реальном мире, или нет. А для такого преобразования, имхо, наиболее подходит объектная декомпозиция.
... << RSDN@Home 1.1.4 @@subversion >>
лэт ми спик фром май харт
Re[4]: Программирование есть моделирование реального мира
B>Короче, о моделировании в узком смысле слова. Это когда с помощью физических экспериментов устанавливаем свойства исследуемого объекта, а затем составляем программу, которая имитирует деятелььность объекта. Экономический резон — проводить манипуляции с объектом экономически невыгодно или невозможно.
Жду ответа, являются ли модели, о которых вы говорите, моделями в инженерном смысле слова.
Ещё раз напомню, что я не обсуждаю ООП. Чёрт меня дёрнул написать это слово в теме. Неужели, когда говорим о моделях, без ООП не обойтись?
Здравствуйте, prVovik, Вы писали: B>>Вы начинаете с "реальная модель" и дальше поехало... А я именно наличие этой модели поставил под сомнение. V>Смысл не поменяется, еслм заменить фразу "реальная модель" на "идеальная модель" ... В этом смысле для меня модель "автомобиль" абсолютно ничем не отличается от модели "файл". Поэтому, я буду преобразовывать свою идеальную модель в программную, ... для такого преобразования, имхо, наиболее подходит объектная декомпозиция.
Вот и вы исходите из того, что у нас есть модель, и мы её преобразовываем в программу. Модель чего? Модель "автомобиль" нужна только для игрушки-симулятора. Я думаю, что не для всякой программы можно указать, моделью чего она является. По кайней мере, я таких программ-моделей не пишу.
Похоже, что термин "модель", стоящий в начале пути, стал уже аксиомой.
Re[4]: Программирование есть моделирование реального мира
Здравствуйте, AndrewVK, Вы писали: AVK>Пляши. Только толку от этого 0. Пользователь не может знать как писать программы. Максимум что от него можно добиться это набор требований, и то для этого нужно море усилий. А от требований до реального проекта, по которому можно писать код еще очень долгий путь. А когда со слов пользователя сразу начинает проектироваться программа, то это мягко говоря кустарный подход. И даже если не говорить о том плохо это или хорошо, делать выводы о применимости или неприменимости того или иного метода исходя из подобного подхода не стоит.
С этим я полностью согласен. Такие кустарные программы поддерживаю, и сам рекомендую отправлять их на свалку.
Но вы не так меня поняли. Я сравниваю подход "от пользователя" и "от реального мира". Разве сможем мы правильно учитывать самолёт в бухучёте, если будем руководствоваться общеизвестными представлениями о самолёте? Для аэродинамического учёта этих знаний также недостаточно. Всё равно возвращаемся к пользователю. Тогда можно ли вообще утверждать, что программа моделирует самолёт? А может, пользователя?
А про то, как писать программы, когда общее представление о предмете разговора уже есть, т.е. о его бухгалтерских или аэродинамических качествах, я не говорю. Они определяются инструментом. Тут я совершенно согласен, взяли ООЯ — хошь не хошь, придется использовать ООП, взяли реляционную СУБД — реляционный подход, нормализация, и т.д.
Здравствуйте, beroal, Вы писали:
B>Вот и вы исходите из того, что у нас есть модель, и мы её преобразовываем в программу. Модель чего? Модель "автомобиль" нужна только для игрушки-симулятора. Я думаю, что не для всякой программы можно указать, моделью чего она является. По кайней мере, я таких программ-моделей не пишу.
Модели "автомобиля" бывают совершенно разные. Вы, наверное, говорили о той, которая нужна для игрушки-симулятора — ну да, такую вполне можно представить. B>Похоже, что термин "модель", стоящий в начале пути, стал уже аксиомой.
То, что находится у вас в голове при написании программы — это часть модели программы, точнее, так называется. Модель — идеальное понятие, и может не иметь реализации в виде каких-либо моделей средств моделирования.
Всегда ли есть модель-прообраз для этой модели? Этот вопрос уже философский.
Мне нравится такой подход: "Все, что сделано руками человека, было однажды им придумано".
И еще один философский вопрос: стОит ли вообще привлекать понятие модели для написания программ? На мой взгляд, стОит. Хотя бы потому, что стОит в голове иметь абстрактное понятие "процесс программирования", которое уже использует понятие модели. Рефлексия в малых дозах полезна в любых количествах.
p.s. Скажите пожалуйста, вы предпочитаете императивный алгоритмический подход в программировании или все же декларативный объектный?, и почему.
/bur
Re[5]: Программирование есть моделирование реального мира
Здравствуйте, beroal, Вы писали: B>Но вы не так меня поняли. Я сравниваю подход "от пользователя" и "от реального мира". Разве сможем мы правильно учитывать самолёт в бухучёте, если будем руководствоваться общеизвестными представлениями о самолёте?
Мы должны руководствоваться общеизвестными представлениями о самолёте и бухгалтерскими представлениями о бухучете самолетов и бухгалтерскими представлениями о бухучете вообще. >Для аэродинамического учёта этих знаний также недостаточно. Всё равно возвращаемся к пользователю. Тогда можно ли вообще утверждать, что программа моделирует самолёт? А может, пользователя?
Мы можем представлять самолет КАК УГОДНО. Это наша задача — представить его так, чтобы он был представлен достаточно качественно (функц. требования) и достаточно вычислительно эффективно (нефункц. требования).
prVovik пишет:
> B>Ещё можно назвать декомпозиция > В этом то и вся "фишка". Декомпозиции бывают разные. Есть две > совершенно ортогональные: алгоритмическия декомпозиция и объектная. > Апологеты ООП утверждают, что объектная декомпозиция лучше, чем > алгоритмическая, ну а поклонники структурного программирования, > соответственно, агетируют за алгоритмическую.
Алгоритмическая и объектная декомпозиции — почти ортогональны, то есть
почти не влияют друг на друга. Соответственно при проектировании ПО в
ООП-стиле требуется сделать обе декомпозиции и совместить их.
Здравствуйте, buriy, Вы писали: B>Мне нравится такой подход: "Все, что сделано руками человека, было однажды им придумано". B>И еще один философский вопрос: стОит ли вообще привлекать понятие модели для написания программ? На мой взгляд, стОит. Хотя бы потому, что стОит в голове иметь абстрактное понятие "процесс программирования", которое уже использует понятие модели. Рефлексия в малых дозах полезна в любых количествах.
Кажется, я начинаю понимать. После того, как мы оставили слово "модель", но отбросили "реального мира", и стали называть моделью всё, что может быть придумано, всё становится на свои места. Пишу ли я программу или поэму — я пишу модель.
Дело в том, что в инженерном смысле это не модель. Инженерная модель — это не только описание, она ещё и работает. Это правила, по которым она работает. И модель имеет прототип. Действительно, программа имеет и исходный код, и правила, по которым выполняется. Программа может быть инженерной моделью только в том случае, если она имеет прототип, если это программа конкретно для моделирования.
Т.е. термин может употребляться как в широком, так и в узком смысле.
Re[5]: Программирование есть моделирование реального мира
Здравствуйте, beroal, Вы писали: B>Дело в том, что в инженерном смысле это не модель. Инженерная модель — это не только описание, она ещё и работает. Это правила, по которым она работает. И модель имеет прототип. Действительно, программа имеет и исходный код, и правила, по которым выполняется. Программа может быть инженерной моделью только в том случае, если она имеет прототип, если это программа конкретно для моделирования. B>Т.е. термин может употребляться как в широком, так и в узком смысле.
Конечно.
У воображаемых моделей тоже есть правила. Единственный их недостаток — они находятся в голове и поэтому часто пребывают в неоформившемся состоянии. И прототип, который работает, тоже часто бывает в голове. Обычно человек моделирует что-либо сложное, перед тем, как сделать это.
Вам, видимо, нужна материальная модель. Зафиксированная на каком-либо носителе (человеческий мозг не подходит).
Здравствуйте, beroal, Вы писали:
B>Давным давно, когда ООП для меня было в новинку, я прочитал в одной книжке, что объекты моделируют реальность (вроде бы Гради Буч). Я не могу привести ссылку, но хорошо помню, что это была не случайная мысль, а мощный разработанный тезис, который, в частности, выдвигался в поддержку самого ООП — якобы оно нужно программисту, чтобы моделировать реальность, с помощью него моделировать реальность очень хорошо. И до сих пор я замечаю, что иногда этот тезис проскакивает в общих размышления об ООП у его поклонников, типа "таким образом мы лучше моделируем реальность".
В науке часто используется следующий приём: что бы обяснить человеку то, чего он не знает, вместо того, что бы сразу обяснять ему модель, основанную на последних достижениях (часто черезвычайно сложную и противоречивую) — ему обясняют всё очень упрощённо и не правильно. Вспомните физику или химию в школе — мы как бы заново проходим путь, пройденный в своё время наукой — каждый раз узнавая, что то, что нам рассказывали раньше — это не совсем правда и, что на самом деле всё обстоит несколько сложнее — иначе.
То же самое сделал и Гради Буч. Думаю, что он прекрасно знал, что его пояснения мягко говоря не правильны. Но у них есть существенное достоинство — если не воспринимать их черезчур буквально, а воспринять из них лишь идею построении системы взаимодействующих объектов, некоторые аспекты поведения которой напоминают некоторые аспекты "предметной области" — то это позволяет воспринимать и развивать конепции ООП/ООА гораздо быстрее, чем если идти, например, снизу — от ассемблерного кода, пытаясь обяснить как из отдельных регистров и команд получить объект.
Эта метафора (о том, что объектная программа моделирует реальный мир) — это всего лишь взгляд на програмную систему "сверху" — полезный инструмент для того, что бы позволить соеденить программу и реальный мир — сделав возможным осмысленное проектирование и понимание программы.
Думаю, что вы знаете, что электроны в атоме не летают вокуг ядра по круговым орбитам — более того — у них вообще нет орбит пока они в составе атома, но не сетуете по этому поводу на школьную физику.
B>Я, однако, не поклонник, смотрю на ООП критически, и это одна из причин, почему. Я не думаю, что программы моделируют реальный мир. Таковыми являются только те программы, у которых в ТЗ прямо записано, что функция программы — моделирование. Например, предсказание погоды, компьютерные игры (стрелялки). Конечно, ПО для моделирования — важная и нужная часть ПО, но именно часть. А в ООП получается, что каждая программа неявно моделирует. Мне, честно говоря, тяжело это представить.
Программы НЕ моделируют реальный мир. Это делают разработчики программ для того, что бы облегчить себе проектирование. Сложную прогаммную систему гораздо легче представить и понять, если рассматривать её как набор объектов, уровней, модулей, служб и т.д. чем как алгоритм.
B>Мне могут привести конкретные примеры. Например, система учёта ТМЦ моделирует, собственно, ТМЦ, как там они перемещаются географически и пр. С этим я не спорю. А бухучёт что моделирует? Бумажный бухучёт? А если мы вспомним, что сами деньги — это не бумажки или драгоценные металлы, а условность. А компьютерная игра "Шахматы" что моделирует? Деревянные шахматы? Которые тоже условность, и в свою очередь моделируют что?.. К любой программе можно притянуть за уши какой-то физический объект, потому что компьютеры появились относительно недавно, и у многих программ должен быть хотя бы бумажный прототип.
Самое забавное как раз в том, что приведённые примеры как раз относятся к тем областям, где программа реализует как раз таки именно модели. Бухучёт — модель движения денежных потоков между счетами, а шахматы — так это построенная по чётким правилам модель сражения. Лучше сказали бы про компиляторы или линкеры — для них соответствие в реальном мире найти гораздо сложнее... Однако мысль ясна.
Но как мне кажется, всё станет на свои места, если мы примем за основу, что моделированием занимается не сама программа, а человек, который её создаёт.
B>Я не возражаю против того, что любая программа что-то моделирует. Это вопрос схоластики. Доказать можно. Меня интересует, насколько полезен такой взгляд программисту, насколько полезно ложить его как основу парадигмы программирования.
В этом и суть. Программы не моделируют. Моделируют их разработчики. Примеры Буча со стиральными машинами и сельхоз системами изначально критики не выдерживали, если пытаться воспринимать их как модели реальности, так как они даже близко не учитавали большинство важных свойств моделируемых объектов.
B>Я предпочитаю смотреть на программу как на машину — что она умеет делать, насколько удобно ей управлять. Возможно даже, тезис о моделировании — это хитрый ход конём, уход от пользователя. У нас есть объективная реальность, мы её в тиши кабинета с ретортами и колбами моделируем, а пользователь со своими предложениями пусть пока постоит за дверью. А ведь даже моделирование интересует не вообще, а в том аспекте, который интересует пользователя. Самолёты учитываются по-разному в бухгалтерии, КБ, аэропорту. B>Этот взгляд губителен хотя бы тем, что мы концентрируемся на предметной области, а не на тех преимуществах, которые даёт современная техника. Ведь компьютер может гораздо больше, чем делалось с помощью ручки и бумаги... Зачем же моделировать ручку и бумагу? B>Или я уделяю слишком много всему этому внимания?
Именно. Я не видел ни одного разработчика кто занимаясь бухгалтерскими системами додумался бы до моделирования бумажных папок и перьевых ручек.
Искусство и предназначение аналитика, который изучает предметную область как раз и заключается в том, что бы суметь выделить из предметной области то, что в ней следует моделировать. Врядли заказчика обрадует, если бухгалтерская система будет моделировать перьевые ручки, но не будет учитывать перемещение денег по счетам.
Кроме того, если рассмотреть такую программу, как компилятор — то получается, что реального объекта нет, а вот программа и объектная модель — есть.
Здравствуйте, Cyberax, Вы писали:
C>prVovik пишет:
>> B>Ещё можно назвать декомпозиция >> В этом то и вся "фишка". Декомпозиции бывают разные. Есть две >> совершенно ортогональные: алгоритмическия декомпозиция и объектная. >> Апологеты ООП утверждают, что объектная декомпозиция лучше, чем >> алгоритмическая, ну а поклонники структурного программирования, >> соответственно, агетируют за алгоритмическую.
C>Алгоритмическая и объектная декомпозиции — почти ортогональны, то есть C>почти не влияют друг на друга. Соответственно при проектировании ПО в C>ООП-стиле требуется сделать обе декомпозиции и совместить их.
Не совмещение, а последовательноть.
Вопрос только в последовательности. Что сначала — объектная или алгоритмическая? Гамлетовский вопрос.
А вообще, если помнить правила правильного дизайна который должен получиться в конце, то эта два пути к одной и той же цели. И в конце пути — результат может быть совершенно один и тот-же.
Здравствуйте, OpenMinded, Вы писали: OM> Кроме того, если рассмотреть такую программу, как компилятор — то получается, что реального объекта нет, а вот программа и объектная модель — есть.
Да, компиляторы и интерпретаторы — хороший пример. OM> Программы НЕ моделируют реальный мир. Это делают разработчики программ для того, что бы облегчить себе проектирование. Сложную прогаммную систему гораздо легче представить и понять, если рассматривать её как набор объектов, уровней, модулей, служб и т.д. чем как алгоритм.
Так всё-таки. Должен ли программист уметь моделировать? Входит ли это в его должностные обязанности?
Re[6]: Программирование есть моделирование реального мира
Здравствуйте, beroal, Вы писали:
OM>> Программы НЕ моделируют реальный мир. Это делают разработчики программ для того, что бы облегчить себе проектирование. Сложную прогаммную систему гораздо легче представить и понять, если рассматривать её как набор объектов, уровней, модулей, служб и т.д. чем как алгоритм. B>Так всё-таки. Должен ли программист уметь моделировать? Входит ли это в его должностные обязанности?
Да, как мне кажется, обязательно должен. С моей точки зрения, моделирование — суть есть умение адекватно выделять существенное и отбрасывать не существенное. Это должен уметь делать любой человек — и это основа успеха в любой деятельности.
И заметьте — это не имеет отношения к тому, моделирует ли реальный мир сама программа. Важно умение её разработчиков это делать. В действительности что мы называем "моделировать"? Ведь реально за этим стоит — понять, что у товара есть название и цена и что и то и другое придётся где то хранить, что бы отобразить на чеке. Многово ли стоит ожидать от разработчика неспособного додуматься до столь гениальных построений?
Здравствуйте, OpenMinded, Вы писали:
OM> Кроме того, если рассмотреть такую программу, как компилятор — то получается, что реального объекта нет, а вот программа и объектная модель — есть.
Это пять! Это дзен!
Объект не проcто нереален, даже невозможно представить себе степень его нереальности. Это нагромождение одного несуществования на другое, опирающееся на ничто... Зачастую в программировании именно так оно и есть.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, OpenMinded, Вы писали:
OM>> Кроме того, если рассмотреть такую программу, как компилятор — то получается, что реального объекта нет, а вот программа и объектная модель — есть.
MS>Это пять! Это дзен! MS>Объект не проcто нереален, даже невозможно представить себе степень его нереальности. Это нагромождение одного несуществования на другое, опирающееся на ничто... Зачастую в программировании именно так оно и есть.
Конечно дзен. В програмировании вообще очень много прямо-таки религиозных убеждений. Постоянные евангилистские споры в этом форуме по моему это только подтверждают...
Re[5]: Программирование есть моделирование реального мира
Здравствуйте, beroal, Вы писали: B>Но вы не так меня поняли. Я сравниваю подход "от пользователя" и "от реального мира". Разве сможем мы правильно учитывать самолёт в бухучёте, если будем руководствоваться общеизвестными представлениями о самолёте?
Вообще-то модель обычно представляет собой некоторое упрощенное описание моделируемого объекта. Все. Точка. Кирпич может быть смоделирован материальной точкой (и для расчета его траектории в вакууме этого более чем достаточно), а может — как параллелепипед из материала, обладающего некоторыми деформационными свойствами (которые нужны для расчета его напряженного состояния). Также он может моделироваться как объект материального учета, и тогда можно пренебречь всем, кроме стоимости и периода амортизации.
В чем проблема-то? Ты что, решил, что ООП требует от тебя моделировать кирпич как материальное тело?
Более того, в реальном программировании как правило применяются модели моделей. Сама концепция бухгалтерского счета представляет некоторую модель, описывающую экономическую деятельность. В бухгалтерской программе ты будешь моделировать эту модель, а не саму экономическую деятельность. Если от программы требуется не бухгалтерия, а что-то еще — флаг в руки и идем использовать другую модель.
Тем не менее, надо понимать, что с точки зрения самого процесса моделирования "банковский счет" ничуть не менее реален, чем самолет весом в 140 тонн.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, beroal, Вы писали: B>Кажется, я начинаю понимать. После того, как мы оставили слово "модель", но отбросили "реального мира", и стали называть моделью всё, что может быть придумано, всё становится на свои места. Пишу ли я программу или поэму — я пишу модель.
Я совершенно не понимаю твоего стремления использовать нестандартную трактовку термина "модель".
Ты зачем-то приписываешь к термину "модель" слово "инженерная". А потом удивляешься, почему твои программы не имеют никакого отношения к моделированию машинок из картона.
Ты бы еще удивлялся тому, что ООП никак не применимо к Синди Кроуфорд, которая тоже вроде как модель, да еще какая
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, beroal, Вы писали:
B>Давным давно, когда ООП для меня было в новинку, я прочитал в одной книжке, что объекты моделируют реальность (вроде бы Гради Буч).
Это все, естественно, не так.
На самом деле, все было так:
1) Сначала программы писались в машинных командах. В этом смысле реальность моделировалась сонмищем машинных инструкций.
2) Изобрели императивные языки программирования "высокого" уровня. Реальность стали моделировать на этих языках. Кстати, языки программирования ограничили свободу программиста по сравнению со свободой машинных языков — то есть дисциплинировали его.
3) Изобрели структурное программирование (правильные управляющие конструкции IF THEN ELSE END, CASE, WITH и т.д., избавились от неструктурных: goto, break, continue). Реальность стали моделировать = описывать с помощью структурных языков. Заметьте, что свобода программиста ограничилась еще сильнее, а дисциплина, стало быть, выше.
4) Изобрели модульность и сборку мусора. Тут опять степень свободы программиста уменьшилась, а его дисциплина еще сильнее увеличилась. Реальность стали моделировать не просто на структурных языках высокого уровня, а на модульных структурных языках.
5) Изобрели то самое ООП. Оно вообще самым жесточайшим образом урезало свободу программиста — теперь программист был вынужден думать, то есть моделировать = описывать реальность в терминах объектов. Но зато дисциплина программирования опять повысилась.
6) Изобрели КОП (компонентно ориентированное программирование). КОП — являясь по своей сути тем же самым ООП налагает на него некоторые ограничения, тем самым еще сильнее ограничивая свободу программиста, но зато еще сильнее поднимает дисциплину программирования.
И так далее. Мы платим свободой в обмен получаем дисциплину и новые уровни абстракции.
Объекты, на самом деле, не моделируют реальность, точно так же как модули или процедуры ее тоже не моделируют, также как ее не моделируют сонмища машинных инструкций. Но ничего более лучшего у нас пока нет. Поэтому используем что есть.
Здравствуйте, McSeem2, Вы писали:
OM>> Кроме того, если рассмотреть такую программу, как компилятор — то получается, что реального объекта нет, а вот программа и объектная модель — есть.
MS>Это пять! Это дзен! MS>Объект не проcто нереален, даже невозможно представить себе степень его нереальности. Это нагромождение одного несуществования на другое, опирающееся на ничто... Зачастую в программировании именно так оно и есть.
Не могу с Вами согласиться.
Есть и реальный объект — язык.
Есть и соответствующая модель, предложенная Хомским.
Возможно, Вы имеете в виду, что ЯП — искусственные языки (то же можно сказать, к слову, и об эсперанто).
Но основываются они именно на моделировании естественного языка.
Так что дзеном здесь и не пахнет.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
... СГ>6) Изобрели КОП (компонентно ориентированное программирование). КОП — являясь по своей сути тем же самым ООП налагает на него некоторые ограничения, тем самым еще сильнее ограничивая свободу программиста, но зато еще сильнее поднимает дисциплину программирования.
Добавка
7) Затем изобрели Активные Объекты — более нет никаких процессов/потоков с мьютексами/мониторами и т.п., а просто есть "первородные" активности синхронизация которых описывается всего лишь двумя ключевыми словами EXCLUSIVE и AWAIT. С одной стороны это опять есть ограничение свободы программиста, но с другой стороны это еще более дисциплинированное программирование, еще более высокий уровень абстракции.
В будущем изобретут еще что-нибудь еще сильнее поднимающее дисциплину программирования (уровень абстракции) и так далее. Но, в качестве расплаты, на каждом последующем шаге мы будем терять свободу... — свободу в совершении глупых ошибок!
Здравствуйте, beroal, Вы писали:
B>Я не возражаю против того, что любая программа что-то моделирует. Это вопрос схоластики. Доказать можно. Меня интересует, насколько полезен такой взгляд программисту, насколько полезно ложить его как основу парадигмы программирования. B>Я предпочитаю смотреть на программу как на машину — что она умеет делать, насколько удобно ей управлять. Возможно даже, тезис о моделировании — это хитрый ход конём, уход от пользователя. У нас есть объективная реальность, мы её в тиши кабинета с ретортами и колбами моделируем, а пользователь со своими предложениями пусть пока постоит за дверью. А ведь даже моделирование интересует не вообще, а в том аспекте, который интересует пользователя. Самолёты учитываются по-разному в бухгалтерии, КБ, аэропорту. B>Этот взгляд губителен хотя бы тем, что мы концентрируемся на предметной области, а не на тех преимуществах, которые даёт современная техника. Ведь компьютер может гораздо больше, чем делалось с помощью ручки и бумаги... Зачем же моделировать ручку и бумагу? B>Или я уделяю слишком много всему этому внимания?
ИМХО, это очень интересная тема.
Собственно, для "Философии программирования" — основная.
Что такое программирование?
Моделирование? Или что-то другое, какое-нибудь "свободное творчество"?
К слову, вопрос не новый. Прежде он часто обсуждался математиками (что такое математика ).
Отчасти, вопрос действительно философский.
По существу же дела, я с Вами не во всем согласен.
Модели бывают разные. В программировании мы (ИМХО) имеем дело с математическими моделями (иногда говорят "структурами").
Это давно устоявшееся в математике понятие. Оно означает некоторое множество объектов и набор применимых к ним отношений и операций.
Я думаю, что такие модели и имеются в виду.
Математические модели, переходя из области математики в область программирования, естественным образом становятся абстрактными типами данных (АТД, ADT). Такой подход к программированию "проповедуется" в книге Ахо, Ульмана и Хопкрофта "Структуры данных и алгоритмы".
ООП есть следующий этап развития идей, связанных с абстрактными типами данных.
Главное назначение ООП — делать системы "расширяемыми" (extensible).
Там, где расширение системы не предполагается, ООП не нужно.
Что же касается книг Буча, то согласен с Вами полностью.
Возможно, я захожу слишком далеко, но, ИМХО, это — макулатура.
Достаточно сравнить "метод" Буча и, хотя бы, метод объектно-ориентированного анализа Шлаер и Меллора.
Со стороны первого — одни словеса (видимо, обращающиеся к нашей интуиции), со стороны вторых — математически строгий метод.
Идеи книги Шлаер и Меллора "Object lifecycles: modeling the world in states" я применял на практике при разработке сложных систем реального времени (в области безопасности). Этот метод хорошо работает.
Так что программирование — все-таки моделирование, но именно математическое.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, GlebZ, Вы писали:
C>>Алгоритмическая и объектная декомпозиции — почти ортогональны, то есть C>>почти не влияют друг на друга. Соответственно при проектировании ПО в C>>ООП-стиле требуется сделать обе декомпозиции и совместить их.
GZ>Не совмещение, а последовательноть. GZ>Вопрос только в последовательности. Что сначала — объектная или алгоритмическая? Гамлетовский вопрос.
Почему же "гамлетовский"?
ИМХО, этот вопрос имеет однозначный ответ.
Сначала "объекты" (а главное — их типы). Потом алгоритмы.
Алгоритм (даже предварительный, самый общий) всегда опирается на свойства модели.
Например, пишем (на псевдокоде): Выбрать первый элемент из множества.
Это значит, что в нашей модели (даже если она существует только в нашем воображении) множество позволяет выбрать первый элемент.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
AVC,
> ИМХО, этот вопрос имеет однозначный ответ. > Сначала "объекты" (а главное — их типы). Потом алгоритмы. > Алгоритм (даже предварительный, самый общий) всегда опирается на свойства модели.
А модель опирается на use cases, каковые вполне можно считать "алгоритмами". А use cases — на роли, выделение которых, в свою очередь, снова является как бы объектной декомпозицией. Яйцо и курица в чистом виде
> Например, пишем (на псевдокоде): > Выбрать первый элемент из множества. > Это значит, что в нашей модели (даже если она существует только в нашем воображении) множество позволяет выбрать первый элемент.
Вопрос смещается в сторону того, как мы попали в место, где написано "Выбрать первый элемент из множества". Если путем определения того, что мы хотим делать на этом уровне, и "уровни" ассоциированы с действиями (алгоритмами), то, наверное, можно сказать, что алгоритмическая декомпозиция предшествовала объектной. Правда, потом мы сможем найти еще какой-нибудь предшествовавший шаг, на котором мы в первую очередь оперировали данными, а не поведением, и снова заявим о первичности объектной декомпозиции. И так, наверное, до бесконечности, потому что, по-моему, эти процессы происходят одновременно, а не последовательно.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[3]: Программирование есть моделирование реального мира
Здравствуйте, beroal, Вы писали:
B>У вас я опять вижу "модель реального мира". Я лично пляшу от пользователя. Как главбух решил — так и будет. Предметная область не играет определяющей роли. Для программиста реальный мир — сущность виртуальная.
Поверь моему огромному опыту общения с бухгалтерами их лучше вообще не слушать (вернее выслушать, что они хотят, и учитывая, что в большинстве случаев это женьщины). Но предметную область ты должен знать в определенных аспектах лучше главбуха. Никуда не деться, да и не особо и сложно.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>AVC, >> ИМХО, этот вопрос имеет однозначный ответ. >> Сначала "объекты" (а главное — их типы). Потом алгоритмы. >> Алгоритм (даже предварительный, самый общий) всегда опирается на свойства модели. ПК>А модель опирается на use cases, каковые вполне можно считать "алгоритмами". А use cases — на роли, выделение которых, в свою очередь, снова является как бы объектной декомпозицией. Яйцо и курица в чистом виде
Можно и так посмотреть.
Последовательность может быть разной.
Но логически (и в программистской практике) что-то должно быть первым.
Для программиста — это компьютер, в составе команд которого может быть, например, целочисленная арифметика или арифметика с плавающей точкой и т.д.
Грубо говоря, то, что программист пишет на ассемблере — это алгоритм.
Но для этого должен существовать компьютер.
>> Например, пишем (на псевдокоде): >> Выбрать первый элемент из множества. >> Это значит, что в нашей модели (даже если она существует только в нашем воображении) множество позволяет выбрать первый элемент.
ПК>Вопрос смещается в сторону того, как мы попали в место, где написано "Выбрать первый элемент из множества". Если путем определения того, что мы хотим делать на этом уровне, и "уровни" ассоциированы с действиями (алгоритмами), то, наверное, можно сказать, что алгоритмическая декомпозиция предшествовала объектной. Правда, потом мы сможем найти еще какой-нибудь предшествовавший шаг, на котором мы в первую очередь оперировали данными, а не поведением, и снова заявим о первичности объектной декомпозиции. И так, наверное, до бесконечности, потому что, по-моему, эти процессы происходят одновременно, а не последовательно.
Согласен.
Но, все же, я имею в виду логическую последовательность, а не психологическую.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
GZ>>Не совмещение, а последовательноть. GZ>>Вопрос только в последовательности. Что сначала — объектная или алгоритмическая? Гамлетовский вопрос.
AVC>Почему же "гамлетовский"? AVC>ИМХО, этот вопрос имеет однозначный ответ. AVC>Сначала "объекты" (а главное — их типы). Потом алгоритмы.
В большинстве случаев, структура выводится из алгоритма. AVC>Алгоритм (даже предварительный, самый общий) всегда опирается на свойства модели. AVC>Например, пишем (на псевдокоде): AVC>Выбрать первый элемент из множества. AVC>Это значит, что в нашей модели (даже если она существует только в нашем воображении) множество позволяет выбрать первый элемент.
И в зависимости от алгоритма список это массив, деревья, хэш таблицы итд.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
AVC>>Почему же "гамлетовский"? AVC>>ИМХО, этот вопрос имеет однозначный ответ. AVC>>Сначала "объекты" (а главное — их типы). Потом алгоритмы.
S> В большинстве случаев, структура выводится из алгоритма.
Возможно. Но Вы говорите о реализации (=структуре данных).
А я говорю о типе (АТД).
Это разные понятия. И те же Ахо, Ульман и Хопкрофт их отчетливо различают.
AVC>>Алгоритм (даже предварительный, самый общий) всегда опирается на свойства модели. AVC>>Например, пишем (на псевдокоде): AVC>>Выбрать первый элемент из множества. AVC>>Это значит, что в нашей модели (даже если она существует только в нашем воображении) множество позволяет выбрать первый элемент. S> И в зависимости от алгоритма список это массив, деревья, хэш таблицы итд.
Вы опять же говорите о разных реализациях.
А тип (=интерфейс) — один и тот же.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Serginio1, Вы писали:
S> А так как являюсь сторонником Вирта. То в его книге "Алгоритмы + Структуры данных = Программы"
S> На первом месте стоят именно Алгоритмы.
Цитирую упомянутую книгу Вирта:
Итак, у нас были две причины начать книгу главой о строении данных. Во-первых, мы интуитивно понимаем, что данные предшествуют алгоритму, ведь прежде, чем выполнять какие-либо операции, нужно иметь объекты, к которым они применяются.
Так что Вирт, кажется, больше согласен со мной.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Sinclair, Вы писали: S>Я совершенно не понимаю твоего стремления использовать нестандартную трактовку термина "модель". S>Ты зачем-то приписываешь к термину "модель" слово "инженерная". А
Потому что по образованию я инженер. Инженер-системотехник, если быть точным. Хотя зарабатываю программированием, паяльник в руках держать не разучился. Ну и на изучение моделей всяких там транзисторов убил в вузе достаточно много времени.
Здравствуйте, beroal, Вы писали: B>Потому что по образованию я инженер. Инженер-системотехник, если быть точным. Хотя зарабатываю программированием, паяльник в руках держать не разучился. Ну и на изучение моделей всяких там транзисторов убил в вузе достаточно много времени.
Ну что ж, чем раньше ты избавишься от неверной трактовки терминов — тем лучше. А то помнишь, как капитан Врунгель Фуксу грот набивать скомандовал?
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AVC, Вы писали: AVC>Модели бывают разные. В программировании мы (ИМХО) имеем дело с математическими моделями (иногда говорят "структурами"). AVC>Это давно устоявшееся в математике понятие. Оно означает некоторое множество объектов и набор применимых к ним отношений и операций. AVC>Я думаю, что такие модели и имеются в виду.
Вы имеете в виду алгебраические модели, которые отличаются от алгебраических систем тем, что не имеют операций (только отношения)?
Здравствуйте, beroal, Вы писали:
AVC>>Модели бывают разные. В программировании мы (ИМХО) имеем дело с математическими моделями (иногда говорят "структурами"). AVC>>Это давно устоявшееся в математике понятие. Оно означает некоторое множество объектов и набор применимых к ним отношений и операций. AVC>>Я думаю, что такие модели и имеются в виду. B>Вы имеете в виду алгебраические модели, которые отличаются от алгебраических систем тем, что не имеют операций (только отношения)?
Примерно.
Единственное, что меня здесь немного смущает, — то, что термины иногда понимаются по-разному.
С понятием "математической структуры" я познакомился давно (еще студентом).
Прочитал популярную книгу И.Яглома — кажется, "Математические структуры и математическое моделирование".
Математическая структура понималась как множество(а) и набор отношений, связывающих элементы множества.
Примерно так: S = <M; R>
Особенностью алгебраических структур были операции, когда элементу(ам) ставился в соответствие другой элемент, принадлежащий этому множеству, а не отношение (т.е. "булевский тип"). (Конечно, алгебраические структуры являются также математическими . Например, бинарная операция c = a * b можно представить как тернарное отношение R(a, b, c).)
В книге Яглома понятие математической структуры приписывалось (наверное, справедливо) Бурбаки (группе французских математиков) и было связано с "философским" вопросом о единстве математики ("одна математика или много математик").
Когда я познакомился с этим понятием, оно стало попадаться мне на каждом шагу.
Например, в старой (но неплохой) обзорной книге Глушкова "Безбумажная информатика" то же самое называлось математической моделью.
Когда мне на глаза попалась книга Ахо, Ульмана и Хопкрофта, то я увидел, что они пользуюся тем же понятием. Только оно у них приняло форму "математическая модель плюс операторы в рамках этой модели". (Короче, терминология немного "плавает", но смысл остается.) Привожу цитату из первой главы их книги:
Абстрактный тип данных — это математическая модель плюс различные опера-
операторы, определенные в рамках этой модели. Как уже указывалось, мы можем раз-
разрабатывать алгоритм в терминах АТД, но для реализации алгоритма в конкретном
языке программирования необходимо найти способ представления АТД в терминах
типов данных и операторов, поддерживаемых данным языком программирования.
Для представления АТД используются структуры данных, которые представляют
собой набор переменных, возможно, различных типов данных, объединенных оп-
определенным образом.
Тогда мне и подумалось, что именно здесь "математика становится программированием".
Т.е. переход происходит в точке: математическая модель (структура) = абстрактный тип данных.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, AVC, Вы писали: AVC>Когда мне на глаза попалась книга Ахо, Ульмана и Хопкрофта, то я увидел, что они пользуюся тем же понятием. Только оно у них приняло форму "математическая модель плюс операторы в рамках этой модели". (Короче, терминология немного "плавает", но смысл остается.) Привожу цитату из первой главы их книги:[q][b]Абстрактный тип данных — это
У нас она вроде не плавает. Эту терминологию можно встретить в обычном конспекте по дискретной математике, который можно достать в интернете.
Интересно, сколько программистов знают о математическом значении слова "модель" и сколько вкладывают в него математический смысл?
Здравствуйте, beroal, Вы писали:
AVC>>Когда мне на глаза попалась книга Ахо, Ульмана и Хопкрофта, то я увидел, что они пользуюся тем же понятием. Только оно у них приняло форму "математическая модель плюс операторы в рамках этой модели". (Короче, терминология немного "плавает", но смысл остается.) Привожу цитату из первой главы их книги:[q][b]Абстрактный тип данных — это B>У нас она вроде не плавает. Эту терминологию можно встретить в обычном конспекте по дискретной математике, который можно достать в интернете.
Точно!
А я все силился вспомнить, где еще я встречал это понятие.
Помнил, что в каком-то учебнике, но забыл в каком!
B>Интересно, сколько программистов знают о математическом значении слова "модель" и сколько вкладывают в него математический смысл?
Наверное, знают многие.
А вот многие ли связывают между собой математические модели и АТД — действительно вопрос.
По крайней мере, не все методологии программирования и проектирования этому способствуют...
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, beroal, Вы писали:
B>У нас она вроде не плавает. Эту терминологию можно встретить в обычном конспекте по дискретной математике, который можно достать в интернете.
Определения немного разные, вот в чем дело. Поэтому я предпочитаю пользоваться "наивным", интуитивным пониманием этого слова. Ведь все равно определение имеет смысл только в рамках теории.
B>Интересно, сколько программистов знают о математическом значении слова "модель" и сколько вкладывают в него математический смысл?
А какие еще значения? Инженерное и программистское?
Значение слова — это объем его предиката. Но опыт у людей разный, поэтому и объем понятия разный.
Это дзен!
