Давным давно, когда ООП для меня было в новинку, я прочитал в одной книжке, что объекты моделируют реальность (вроде бы Гради Буч). Я не могу привести ссылку, но хорошо помню, что это была не случайная мысль, а мощный разработанный тезис, который, в частности, выдвигался в поддержку самого ООП — якобы оно нужно программисту, чтобы моделировать реальность, с помощью него моделировать реальность очень хорошо. И до сих пор я замечаю, что иногда этот тезис проскакивает в общих размышления об ООП у его поклонников, типа "таким образом мы лучше моделируем реальность".
Я, однако, не поклонник, смотрю на ООП критически, и это одна из причин, почему. Я не думаю, что программы моделируют реальный мир. Таковыми являются только те программы, у которых в ТЗ прямо записано, что функция программы — моделирование. Например, предсказание погоды, компьютерные игры (стрелялки). Конечно, ПО для моделирования — важная и нужная часть ПО, но именно часть. А в ООП получается, что каждая программа неявно моделирует. Мне, честно говоря, тяжело это представить.
Мне могут привести конкретные примеры. Например, система учёта ТМЦ моделирует, собственно, ТМЦ, как там они перемещаются географически и пр. С этим я не спорю. А бухучёт что моделирует? Бумажный бухучёт? А если мы вспомним, что сами деньги — это не бумажки или драгоценные металлы, а условность. А компьютерная игра "Шахматы" что моделирует? Деревянные шахматы? Которые тоже условность, и в свою очередь моделируют что?.. К любой программе можно притянуть за уши какой-то физический объект, потому что компьютеры появились относительно недавно, и у многих программ должен быть хотя бы бумажный прототип.
Я не возражаю против того, что любая программа что-то моделирует. Это вопрос схоластики. Доказать можно. Меня интересует, насколько полезен такой взгляд программисту, насколько полезно ложить его как основу парадигмы программирования.
Я предпочитаю смотреть на программу как на машину — что она умеет делать, насколько удобно ей управлять. Возможно даже, тезис о моделировании — это хитрый ход конём, уход от пользователя. У нас есть объективная реальность, мы её в тиши кабинета с ретортами и колбами моделируем, а пользователь со своими предложениями пусть пока постоит за дверью. А ведь даже моделирование интересует не вообще, а в том аспекте, который интересует пользователя. Самолёты учитываются по-разному в бухгалтерии, КБ, аэропорту.
Этот взгляд губителен хотя бы тем, что мы концентрируемся на предметной области, а не на тех преимуществах, которые даёт современная техника. Ведь компьютер может гораздо больше, чем делалось с помощью ручки и бумаги... Зачем же моделировать ручку и бумагу?
Или я уделяю слишком много всему этому внимания?
Это одна из ошибок, благодаря которым некоторые товарищи приходят к выводу что ООП никуда не годится. В реальности все заметно сложнее. Большинство современных моделей программирования рассчитаны не на моделирование, а на конструирование. А для перехода от модели реального мира к модели программы существуют специальные процедуры. Например для реляционных БД это нормализация, для ООП это объектная декомпозиция.
Удобство же ООП не в том что оно удачно моделирует реальный мир, а в том что модель ООП привычнее для восприятия человеку, который даже абстракции представляет ввиде неких сущностей. Ну чтобы можно было как бы пощупать. Вот ООП и предлагает некий набор кубиков и напильник к ним для подгонки. Даже если готового кубика нет — всегда проще сделать новый кубик, нежели с нуля лепить всю конструкцию. Все остальные особенности разных реализаций ООП суть просто разные виды кубиков — одноразовые/многоразовые, твердые или из пластилина и т.п.
Здравствуйте, 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>Т.е. термин может употребляться как в широком, так и в узком смысле.
Конечно.
У воображаемых моделей тоже есть правила. Единственный их недостаток — они находятся в голове и поэтому часто пребывают в неоформившемся состоянии. И прототип, который работает, тоже часто бывает в голове. Обычно человек моделирует что-либо сложное, перед тем, как сделать это.
Вам, видимо, нужна материальная модель. Зафиксированная на каком-либо носителе (человеческий мозг не подходит).
