В науке естественным ходом развития является, что если теория имеет слабые места, (т.е существуют объекты, для которых она не работает), то рано или поздно появится более общая теория, в которой предыдущая будет частным случаем и все необъяснимые ранее явления будут объяснены.
Но то же самое происходит и в процессе создания ПО!
Архитектор, создавая иерархию объектов под конкретную задачу, постоянно решает те же проблемы: новые возможности постоянно требуют введение все более и более высоких уровней абстрации (иначе внедрение новых возможностей в систему приведет к прописыванию дополнительных условий как здесь http://www.rsdn.ru/Forum/Message.aspx?mid=1241937&only=1).
Сейчас есть огромное количество ОО библиотек, охватывающих самые различные компьютерные технологии (.NET, например), то есть в них подробно и достаточно удобно реализованы абстакции типа окна, базы данных итд, то есть абстракции инструментов, используемых при решении задач реального мира.
Так вот вопрос, а почему до сих пор нет библиотек, в которых существовала бы иерархия классов, описывающих объекты того самого реального мира? Все же создаваемые программные системы не являются самоцелью, они преследуют решение каких-то конкретных задач.. И вот здесь бы пригодилась например, ОО модель склада или цеха по производству пулеметов, или там универсальная модель наемного работника, которая бы учитывала бы все возможные способы начисления зарплаты. И не надо говорить, что все работают по разному — просто пока никто не добрался до нужного уровня абстракции Тем более что все эти модели должны отражать вполне конкретные объекты реального мира и соответственно рано или поздно можно добраться до адекватной модели, отражающей ВСЕ возможные варианты использования этих объектов.
И если такие модели будут созданы, тогда програмирование превратится в технологию. А пока это все-таки отчасти искусство..
Все
ЗЫ. Шаблоны проектирования отчасти решают такую задачу, но не до конца. Это всего лишь общие закономерности, но не более того.
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, Sshur, Вы писали:
S>Так вот вопрос, а почему до сих пор нет библиотек, в которых существовала бы иерархия классов, описывающих объекты того самого реального мира? Все же создаваемые программные системы не являются самоцелью, они преследуют решение каких-то конкретных задач.. И вот здесь бы пригодилась например, ОО модель склада или цеха по производству пулеметов, или там универсальная модель наемного работника, которая бы учитывала бы все возможные способы начисления зарплаты. И не надо говорить, что все работают по разному — просто пока никто не добрался до нужного уровня абстракции Тем более что все эти модели должны отражать вполне конкретные объекты реального мира и соответственно рано или поздно можно добраться до адекватной модели, отражающей ВСЕ возможные варианты использования этих объектов.
Множества всех множеств не существует. Если покажется, что все уже описали, то тут же найдется что-то, что совершенно не укладывается в созданную иерархию. И будет эта абстракция рефакториться во веки веков....
Sshur wrote:
> Так вот вопрос, а почему до сих пор нет библиотек, в которых > существовала бы иерархия классов, описывающих объекты того самого > реального мира?
Потому что реальный мир не описывается нормально иерарихией объектов.
Здравствуйте, _Obelisk_, Вы писали:
_O_>Здравствуйте, Sshur, Вы писали:
S>>Так вот вопрос, а почему до сих пор нет библиотек, в которых существовала бы иерархия классов, описывающих объекты того самого реального мира? Все же создаваемые программные системы не являются самоцелью, они преследуют решение каких-то конкретных задач.. И вот здесь бы пригодилась например, ОО модель склада или цеха по производству пулеметов, или там универсальная модель наемного работника, которая бы учитывала бы все возможные способы начисления зарплаты. И не надо говорить, что все работают по разному — просто пока никто не добрался до нужного уровня абстракции Тем более что все эти модели должны отражать вполне конкретные объекты реального мира и соответственно рано или поздно можно добраться до адекватной модели, отражающей ВСЕ возможные варианты использования этих объектов.
_O_>Множества всех множеств не существует. Если покажется, что все уже описали, то тут же найдется что-то, что совершенно не укладывается в созданную иерархию. И будет эта абстракция рефакториться во веки веков....
Ньютоновской механикой пользуются и ничего, несмотря на то, что она неверна на околосветовых скоростях.
Вполне возможно, что даже неполная модель будет удовлетворять 90% потребностей.. а в технике больше и не надо.
Хотя может это и невозможная задача. Кто знает...
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, Cyberax, Вы писали:
C>Sshur wrote:
>> Так вот вопрос, а почему до сих пор нет библиотек, в которых >> существовала бы иерархия классов, описывающих объекты того самого >> реального мира?
C>Потому что реальный мир не описывается нормально иерарихией объектов.
А мне кажется, что описывается... Каждый же у себя в программе какую-то иерархию создает, которая отражает требуемые объекты и отношения предметной области?
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Sshur wrote:
>>> Так вот вопрос, а почему до сих пор нет библиотек, в которых >>> существовала бы иерархия классов, описывающих объекты того самого >>> реального мира? > C>Потому что реальный мир не описывается нормально иерарихией объектов. > А мне кажется, что описывается... Каждый же у себя в программе > какую-то иерархию создает, которая отражает требуемые объекты и > отношения предметной области?
1. Не каждый — существует еще функциональное и логическое программирование.
2. Объкты программ к рельным объектам отношения обычно не имеют.
Здравствуйте, Sshur, Вы писали:
C>>Потому что реальный мир не описывается нормально иерарихией объектов.
S>А мне кажется, что описывается... Каждый же у себя в программе какую-то иерархию создает, которая отражает требуемые объекты и отношения предметной области?
Вот именно — отражает. С той или иной степенью достоверности. При моделировании объетков реального мира, IMHO, всегда существует противоречие между разнообразием объектов и их взаимодействия и чисто техническими ограничениями (объемом памяти, например). Потом еще на систему объектов действуют все законы природы (общества) сразу. В том числе еще не открытые. Так что абсолютной достоверности достигнуть невозможно.
Здравствуйте, Cyberax, Вы писали:
C>Sshur wrote:
>>>> Так вот вопрос, а почему до сих пор нет библиотек, в которых >>>> существовала бы иерархия классов, описывающих объекты того самого >>>> реального мира? >> C>Потому что реальный мир не описывается нормально иерарихией объектов. >> А мне кажется, что описывается... Каждый же у себя в программе >> какую-то иерархию создает, которая отражает требуемые объекты и >> отношения предметной области?
C>1. Не каждый — существует еще функциональное и логическое программирование.
Ладно, каждый ОО программист.
C>2. Объкты программ к рельным объектам отношения обычно не имеют.
ИМХО наоборот. На стыковке ПО с предметной областью в любом случае будут появлятся такие объекты.
Смысл ОО программирования чтобы представить сложные отношения предметной области в виде легко понимаемой ОО модели, так?
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
S>Ньютоновской механикой пользуются и ничего, несмотря на то, что она неверна на околосветовых скоростях.
S>Вполне возможно, что даже неполная модель будет удовлетворять 90% потребностей.. а в технике больше и не надо. S>Хотя может это и невозможная задача. Кто знает...
Я не уверен, что человек знает все свои потребности, чтоб понять, что 90% из них уже удовлетворено. Потом ведь аппетит приходит во время еды, так и потребности будут появляться по мере их удовлетворения
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, Sshur, Вы писали:
C>>>Потому что реальный мир не описывается нормально иерарихией объектов.
S>>А мне кажется, что описывается... Каждый же у себя в программе какую-то иерархию создает, которая отражает требуемые объекты и отношения предметной области?
P>Вот именно — отражает. С той или иной степенью достоверности. При моделировании объетков реального мира, IMHO, всегда существует противоречие между разнообразием объектов и их взаимодействия и чисто техническими ограничениями (объемом памяти, например). Потом еще на систему объектов действуют все законы природы (общества) сразу. В том числе еще не открытые. Так что абсолютной достоверности достигнуть невозможно.
Ну, абсолютной достоверности никто еще не достиг.. Никакая наука не может похвастаться, что она построила абсолютно достоверную модель окружающего нас мира (разве что философия — но их модели имеют слабую практиескую применимость
Так вот, если физика строит всевозможные модели мира (механистическую, квантовую итд), почему нельзя построить программную? И пусть она будет не достоверна на все 100% — так нам этого и не надо, для целей хранения и обработки значимой информации хватит и какой-то части.
В принципе это должна быть системная модель, но описанная в терминах ООП.
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, Cyberax, Вы писали:
C>Sshur wrote:
>> C>1. Не каждый — существует еще функциональное и логическое >> программирование. >> Ладно, каждый ОО программист.
C>Внимание вопрос! К какому классу принадлежит объект "дамская сумочка", C>от каких классов она наследуется?
Если допустить множественное наследование, то
Объект физического мира (имеет определенные размеры, вес, компоненты)
Средство для переноски вещей со свойством "предназначено для женщин".
Товар (можно купить/продать, имеет стоимость)
Оружие (если долго бить, можно нанести травму)
Предмет роскоши
можно еще напридумывать. Но большинство классов будут не значимы для какой-то определенной точки зрения на объект. Мы же не рассматриваем свойство сумочки переносить вещи если пишем складскую программу?
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Sshur wrote:
> C>Внимание вопрос! К какому классу принадлежит объект "дамская сумочка", > C>от каких классов она наследуется? > Если допустить множественное наследование, то > Объект физического мира (имеет определенные размеры, вес, компоненты) > Средство для переноски вещей со свойством "предназначено для женщин". > Товар (можно купить/продать, имеет стоимость) > Оружие (если долго бить, можно нанести травму) > Предмет роскоши
А еще: "объект из кожи", "объект, ввезенный в страну нелегально",
"причина уничтожения крокодилов", "набор молекул", "объект с зарядом 0"
и т.д.
> можно еще напридумывать.
Именно. Получится просто бесполезный набор фактов, и учитывая огромное
количество предметов в мире — бааальшой бесполезный набор фактов.
Насколько я знаю, такие попытки предпренимальсь еще в 70-80 годах для
создания искусственного интеллекта. Результат — полный провал.
> Но большинство классов будут не значимы для какой-то определенной > точки зрения на объект. Мы же не рассматриваем свойство сумочки > переносить вещи если пишем складскую программу?
А если я пишу складскую программу, то нафига мне нужна глобальная
иерархия объектов? Что это мне даст?
Здравствуйте, Sshur, Вы писали:
S>Ну, абсолютной достоверности никто еще не достиг.. Никакая наука не может похвастаться, что она построила абсолютно достоверную модель окружающего нас мира (разве что философия — но их модели имеют слабую практиескую применимость
О достоверности — именно это я и сказал. Практическая применимость моделей, построенных философами — в академических институтах, занимающихся более приземленными вещами. Потому простой смертный редко ее ощущает.
S>Так вот, если физика строит всевозможные модели мира (механистическую, квантовую итд), почему нельзя построить программную? И пусть она будет не достоверна на все 100% — так нам этого и не надо, для целей хранения и обработки значимой информации хватит и какой-то части.
Почему нельзя? Математическое моделирование рулит. А степень соответствия модели объекту определяется разрешением противоречия между требованиями к модели и вычислительными возможностями строящего модель.
S>В принципе это должна быть системная модель, но описанная в терминах ООП.
S>Подумалось вот на досуге:
S>Так вот вопрос, а почему до сих пор нет библиотек, в которых существовала бы иерархия классов, описывающих объекты того самого реального мира? Все же создаваемые программные системы не являются самоцелью, они преследуют решение каких-то конкретных задач.. И вот здесь бы пригодилась например, ОО модель склада или цеха по производству пулеметов, или там универсальная модель наемного работника, которая бы учитывала бы все возможные способы начисления зарплаты. И не надо говорить, что все работают по разному — просто пока никто не добрался до нужного уровня абстракции Тем более что все эти модели должны отражать вполне конкретные объекты реального мира и соответственно рано или поздно можно добраться до адекватной модели, отражающей ВСЕ возможные варианты использования этих объектов.
S>И если такие модели будут созданы, тогда програмирование превратится в технологию. А пока это все-таки отчасти искусство..
Тут уже говорилось, про классификацию объекта "дамская сумочка"
Дело в том, что объект-в-жизни и ПО-объект сильно различаются (то же уже говорилось), мало того, каждому программисту нужен какой-то свой объект, каждой компании — свой программный продукт, чем-то оличный от других. Всего не создашь — это один из основных законов существования человечества. Как уже говорилось, описать каждый предмет со всех сторон нереально. Поверь наслово — я уже пробовал создать программу, которая всего-навсего унифицированно хранила бы такие описания — ничего не вышло.
>>
Кстати, в классической механики нет слабых мест. Когда появляется новый стиль мышления и => более общее понимание устройства мира, появляется и новая теория.
А слабые места в теории просто исправляются — это самые настоящие ошибки (поэто му то классическая механика до сих пор и применяется).
FDSC wrote:
> Кстати, в классической механики нет слабых мест. Когда появляется > новый стиль мышления и => более общее понимание устройства мира, > появляется и новая теория.
Слабые места в классической механике есть — она НЕ согласуется с
классической же электродинамикой Для согласования пришлось придумать
специальную теорию относительности.
Еще классическая механика не может объяснить почему электрон не падает
на атом. Объяснить это удалось только в квантовой механике.
> А слабые места в теории просто исправляются — это самые настоящие > ошибки (поэто му то классическая механика до сих пор и применяется).
Потому что ее точности достаточно в _большинстве_ случаев.
Скажем, для обычных наручных часов релятивистские эффекты дадут всего
несколько наносекунд в год — обычная погрешность наручных часов будет на
порядки больше.
А вот для спутников GPS с часами наносекундной точности уже пришлось
явно закладывать релятивистские поправки (на Земле часы у спутников идут
быстрее, чем на орбите).
S>И если такие модели будут созданы, тогда програмирование превратится в технологию. А пока это все-таки отчасти искусство..
S>Все
Ништяк, ну сделали ООП модель служащего на все случаи жизни... Ты действительно уверен, что объект этого класса влезет в оперативку, что оператор туц не загнется при попытке создании хотя бы одного его экземпляра?
new RSDN@Home(1.1.4, 303) << new Message(); std::head::ear << "Gunther & Samanta Fox — Touch Me";
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, Sshur, Вы писали:
S>>Подумалось вот на досуге:
S>>Так вот вопрос, а почему до сих пор нет библиотек, в которых существовала бы иерархия классов, описывающих объекты того самого реального мира? Все же создаваемые программные системы не являются самоцелью, они преследуют решение каких-то конкретных задач.. И вот здесь бы пригодилась например, ОО модель склада или цеха по производству пулеметов, или там универсальная модель наемного работника, которая бы учитывала бы все возможные способы начисления зарплаты. И не надо говорить, что все работают по разному — просто пока никто не добрался до нужного уровня абстракции Тем более что все эти модели должны отражать вполне конкретные объекты реального мира и соответственно рано или поздно можно добраться до адекватной модели, отражающей ВСЕ возможные варианты использования этих объектов.
S>>И если такие модели будут созданы, тогда програмирование превратится в технологию. А пока это все-таки отчасти искусство..
FDS>Тут уже говорилось, про классификацию объекта "дамская сумочка" FDS>Дело в том, что объект-в-жизни и ПО-объект сильно различаются (то же уже говорилось), мало того, каждому программисту нужен какой-то свой объект, каждой компании — свой программный продукт, чем-то оличный от других. Всего не создашь — это один из основных законов существования человечества.
С другой стороны, зачем каждый раз изобретать велосипед. Правда, разработчики не будут спешить после реализации какого-либо проекта выкладывать разработанные иерархии классов куда-либо для повторного испоьзования. Коммерческая тайна и авторские права. Вот и делаешь то, что кто-тоуже делал.
FDS>Как уже говорилось, описать каждый предмет со всех сторон нереально. Поверь наслово — я уже пробовал создать FDS>программу, которая всего-навсего унифицированно хранила бы такие описания — ничего не вышло.
Дык со всех сторон и не надо — применительно к наемному работнику наверняка достаточно будет к достаточно какой-нибудь уже хорошо разработанной иерархии (а такие есть, уверен — программы расчета зарплаты как-то работают) добавить пару уровней абстрации, если появятся неподходящие частные случаи.. Не надо брать физиологические модели. (Если только мы не рассматриваем случай работы за еду и работодателю нужно кормить работника ровно настолько чтобы тот мог выполнять обязанности )
Кроме того, класс не обязан иметь все возможные атрибуты — для этого есть полиморфизм.
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, Cyberax, Вы писали:
C>Sshur wrote:
>> C>Внимание вопрос! К какому классу принадлежит объект "дамская сумочка", >> C>от каких классов она наследуется? >> Если допустить множественное наследование, то >> Объект физического мира (имеет определенные размеры, вес, компоненты) >> Средство для переноски вещей со свойством "предназначено для женщин". >> Товар (можно купить/продать, имеет стоимость) >> Оружие (если долго бить, можно нанести травму) >> Предмет роскоши
C>А еще: "объект из кожи", "объект, ввезенный в страну нелегально", C>"причина уничтожения крокодилов", "набор молекул", "объект с зарядом 0" C>и т.д.
>> можно еще напридумывать.
C>Именно. Получится просто бесполезный набор фактов, и учитывая огромное C>количество предметов в мире — бааальшой бесполезный набор фактов. C>Насколько я знаю, такие попытки предпренимальсь еще в 70-80 годах для C>создания искусственного интеллекта. Результат — полный провал.
Все развивается по спирали, не правда? Кроме того,я не предлагал создать иерархию, учитывающую абсолютно все. Я прекрасно понимаю, что это невозможно. Например, нет абсолютного метода оптимизации — найти элемент с максимальной мерой в любом множестве — и ничего, методы оптимизации на семействе гладких функций прекрасно работают.
>> Но большинство классов будут не значимы для какой-то определенной >> точки зрения на объект. Мы же не рассматриваем свойство сумочки >> переносить вещи если пишем складскую программу?
C>А если я пишу складскую программу, то нафига мне нужна глобальная C>иерархия объектов? Что это мне даст?
То, что эта складская программа с минимальными доработками может стать программой по расчету зарплаты.
Поключаешь нужный namespace, и вперед. (Это я утрирую)
А так — х/з, что из этого может получится. Это всего лишь идея, и я спорю только чтобы точнее очертить её суть, а не призываю "все бросить и начать писать универсаную иерархию объектов".
C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Sshur wrote:
> C>Именно. Получится просто бесполезный набор фактов, и учитывая огромное > C>количество предметов в мире — бааальшой бесполезный набор фактов. > C>Насколько я знаю, такие попытки предпренимальсь еще в 70-80 годах для > C>создания искусственного интеллекта. Результат — полный провал. > Все развивается по спирали, не правда? Кроме того,я не предлагал > создать иерархию, учитывающую абсолютно все. Я прекрасно понимаю, что > это невозможно.
Тем не менее, замахнулись именно на это.
> C>А если я пишу складскую программу, то нафига мне нужна глобальная > C>иерархия объектов? Что это мне даст? > То, что эта складская программа с минимальными доработками может стать > программой по расчету зарплаты.
Не смешно. Я не занимался много 1Сом и прочими бухгалтериями, но вы
лучше не говорите такое — засмеют.
> Поключаешь нужный namespace, и вперед. (Это я утрирую)
Объектная модель — это далеко не главная вещь. Нужен еще и код, однако.
Здравствуйте, Cyberax, Вы писали:
C>FDSC wrote:
>> Кстати, в классической механики нет слабых мест. Когда появляется >> новый стиль мышления и => более общее понимание устройства мира, >> появляется и новая теория.
C>Слабые места в классической механике есть — она НЕ согласуется с C>классической же электродинамикой Для согласования пришлось придумать C>специальную теорию относительности.
C>Еще классическая механика не может объяснить почему электрон не падает C>на атом. Объяснить это удалось только в квантовой механике.
Мы понимаем смысл слов "слабые места" по разному.
Всё это не слабые места. То что ты перечислил — это границы применимости теории. Каждая теория имеет границы применимости, в том числе и СТО. Слабые места — это ошибки теории в её же области применения, её внутренняя противоречивость. Я и сказал: "Когда появляется новый стиль мышления и => более общее понимание устройства мира, появляется и новая теория". То есть более общая теория, которая содержит предыдущую как частность.
Если более общая теория содержит предыдущую теорию со слабыми местами — то зачем она вообще нужна?
C>Еще классическая механика не может объяснить почему электрон не падает C>на атом. Объяснить это удалось только в квантовой механике.
Кстати, ОТО по моему, то же этого не объясняет, однако "слабых мест" в ОТО нет. Всё, что ей надо, она описывает правильно.
Мало того, если смотреть на это с твоей точки зрения, в любой физической теории тогда есть слабое место — она не объясняет почему всё именно так, как есть.
Кстати, КМ тоже не объясняет почему e- не падает на атом. Она просто даёт хорошую модель для дальнейших расчётов и выводов.
>> А слабые места в теории просто исправляются — это самые настоящие >> ошибки (поэтому то классическая механика до сих пор и применяется).
C>Потому что ее точности достаточно в _большинстве_ случаев.
C>(на Земле часы у спутников идут C>быстрее, чем на орбите).
Ты уверен, что именно так? Это по СТО так. СТО то же имеет свои границы применимости. В прочем, спутники, пожалуй, туда попадают, точности СТО наверное хватает.
А вообще, я бы не рискнул применять СТО для неинерциальных систем отсчёта.
В каком-то смысле, конечно, ограниечнние на область применимости теории есть её слабость. Но эта слабость идеологии, на которой она построена, а не самих утверждений теории.
При прочностных расчётах стержней в линейном приближении, между прочим, используется так называемая гипотеза плоских сечений, которая на самом деле не верна. Однако сами расчёты иногда дают правильные результаты. То есть теория сама по себе не слабая, а вот предпосылки для её создания неверные.
Вообще, любая теория может не содержать слабых мест, однако просто не согласовываться с действительностью. По моему мнению.
Здравствуйте, Cyberax, Вы писали:
C>Sshur wrote:
>> C>Именно. Получится просто бесполезный набор фактов, и учитывая огромное >> C>количество предметов в мире — бааальшой бесполезный набор фактов. >> C>Насколько я знаю, такие попытки предпренимальсь еще в 70-80 годах для >> C>создания искусственного интеллекта. Результат — полный провал. >> Все развивается по спирали, не правда? Кроме того,я не предлагал >> создать иерархию, учитывающую абсолютно все. Я прекрасно понимаю, что >> это невозможно.
C>Тем не менее, замахнулись именно на это.
Это либо я не так выразился, либо меня не поняли.
>> C>А если я пишу складскую программу, то нафига мне нужна глобальная >> C>иерархия объектов? Что это мне даст? >> То, что эта складская программа с минимальными доработками может стать >> программой по расчету зарплаты.
C>Не смешно. Я не занимался много 1Сом и прочими бухгалтериями, но вы C>лучше не говорите такое — засмеют.
1С я не рассматриваю. Я рассматриваю нормальный объектно-ориентированный язык.
>> Поключаешь нужный namespace, и вперед. (Это я утрирую)
C>Объектная модель — это далеко не главная вещь. Нужен еще и код, однако.
Хорошая объектная модель — 80% дела. ИМХО.
C>-- C>С уважением, C> Alex Besogonov (alexy@izh.com)
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, ansi, Вы писали:
A>Здравствуйте, Sshur, Вы писали:
S>>И если такие модели будут созданы, тогда програмирование превратится в технологию. А пока это все-таки отчасти искусство..
S>>Все
A>Ништяк, ну сделали ООП модель служащего на все случаи жизни... Ты действительно уверен, что объект этого класса влезет в оперативку, что оператор туц не загнется при попытке создании хотя бы одного его экземпляра?
Не на все. На все РАНЕЕ ВСТРЕЧАВШИЕСЯ.
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
S>Так вот вопрос, а почему до сих пор нет библиотек, в которых существовала бы иерархия классов, описывающих объекты того самого реального мира?
ИМХО, потому, что любая такая иерархия была бы бесконечно неэффективна при любом конкретном применении. Общая модель имела бы чрезвычайно много деталей + была бы ужасно запутанной в плане наследования.
Здравствуйте, Ranger_XL, Вы писали:
S>>Так вот вопрос, а почему до сих пор нет библиотек, в которых существовала бы иерархия классов, описывающих объекты того самого реального мира?
R_X>ИМХО, потому, что любая такая иерархия была бы бесконечно неэффективна при любом конкретном применении. Общая модель имела бы чрезвычайно много деталей + была бы ужасно запутанной в плане наследования.
В такой иерархии можно находиться на любом нужном уровне, то есть учитывать только необходимые для данного контретного случая атрибуты. И я не сказал — ВСЕ объекты реального мира. Может, какую-то их часть. Начинать можно с малого, не замахиваться же на все и сразу.
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, Sshur, Вы писали:
S>Здравствуйте, Cyberax, Вы писали:
C>>Sshur wrote:
>>> Так вот вопрос, а почему до сих пор нет библиотек, в которых >>> существовала бы иерархия классов, описывающих объекты того самого >>> реального мира?
C>>Потому что реальный мир не описывается нормально иерарихией объектов.
S>А мне кажется, что описывается... Каждый же у себя в программе какую-то иерархию создает, которая отражает требуемые объекты и отношения предметной области?
У тебя есть лужа воды. В нее капает капелька жидкости (тоже воды). В луже происходит очень интересный и красивый процесс — вода расплескивается а потом идут волны. Попробуй смоделировать и описать процесс посредством иерархии взаимодействующих объектов. Причем так, чтобы программа из этого могла получится, а не сферический конь в вакууме.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Sshur, Вы писали:
S>>Здравствуйте, Cyberax, Вы писали:
C>>>Sshur wrote:
>>>> Так вот вопрос, а почему до сих пор нет библиотек, в которых >>>> существовала бы иерархия классов, описывающих объекты того самого >>>> реального мира?
C>>>Потому что реальный мир не описывается нормально иерарихией объектов.
S>>А мне кажется, что описывается... Каждый же у себя в программе какую-то иерархию создает, которая отражает требуемые объекты и отношения предметной области?
G>У тебя есть лужа воды. В нее капает капелька жидкости (тоже воды). В луже происходит очень интересный и красивый процесс — вода расплескивается а потом идут волны. Попробуй смоделировать и описать процесс посредством иерархии взаимодействующих объектов. Причем так, чтобы программа из этого могла получится, а не сферический конь в вакууме.
Млин, ну не хочу я описать всё и вся посредством иерархии классов!!
Мне достаточно иерархии классов, описывающих мою предметную область (логистика). Мне не важно, как крутятся колеса у машины, перевозящей груз, а важно лишь когда она поехала, когда приедет и сколько метров при этом она проедет.
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, Sshur, Вы писали:
C>>>>Потому что реальный мир не описывается нормально иерарихией объектов.
S>>>А мне кажется, что описывается... Каждый же у себя в программе какую-то иерархию создает, которая отражает требуемые объекты и отношения предметной области?
G>>У тебя есть лужа воды. В нее капает капелька жидкости (тоже воды). В луже происходит очень интересный и красивый процесс — вода расплескивается а потом идут волны. Попробуй смоделировать и описать процесс посредством иерархии взаимодействующих объектов. Причем так, чтобы программа из этого могла получится, а не сферический конь в вакууме.
S>Млин, ну не хочу я описать всё и вся посредством иерархии классов!!
S>Мне достаточно иерархии классов, описывающих мою предметную область (логистика). Мне не важно, как крутятся колеса у машины, перевозящей груз, а важно лишь когда она поехала, когда приедет и сколько метров при этом она проедет.
Ну мало ли, что там логистика. Ты утверждаешь, ни много ни мало, что реальный мир описывается нормально иерархией классов. Я возражаю.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Sshur, Вы писали:
C>>>>>Потому что реальный мир не описывается нормально иерарихией объектов.
S>>>>А мне кажется, что описывается... Каждый же у себя в программе какую-то иерархию создает, которая отражает требуемые объекты и отношения предметной области?
G>>>У тебя есть лужа воды. В нее капает капелька жидкости (тоже воды). В луже происходит очень интересный и красивый процесс — вода расплескивается а потом идут волны. Попробуй смоделировать и описать процесс посредством иерархии взаимодействующих объектов. Причем так, чтобы программа из этого могла получится, а не сферический конь в вакууме.
S>>Млин, ну не хочу я описать всё и вся посредством иерархии классов!!
S>>Мне достаточно иерархии классов, описывающих мою предметную область (логистика). Мне не важно, как крутятся колеса у машины, перевозящей груз, а важно лишь когда она поехала, когда приедет и сколько метров при этом она проедет.
G>Ну мало ли, что там логистика. Ты утверждаешь, ни много ни мало, что реальный мир описывается нормально иерархией классов. Я возражаю.
Иерархия классов — модель реального мира. Достаточно?
Прежде чем отвечать, подумай, что такое модель и зачем создаются модели.
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, Sshur, Вы писали:
S>Здравствуйте, Gaperton, Вы писали:
G>>Здравствуйте, Sshur, Вы писали:
C>>>>>>Потому что реальный мир не описывается нормально иерарихией объектов.
S>>>>>А мне кажется, что описывается... Каждый же у себя в программе какую-то иерархию создает, которая отражает требуемые объекты и отношения предметной области?
G>>>>У тебя есть лужа воды. В нее капает капелька жидкости (тоже воды). В луже происходит очень интересный и красивый процесс — вода расплескивается а потом идут волны. Попробуй смоделировать и описать процесс посредством иерархии взаимодействующих объектов. Причем так, чтобы программа из этого могла получится, а не сферический конь в вакууме.
S>>>Млин, ну не хочу я описать всё и вся посредством иерархии классов!!
S>>>Мне достаточно иерархии классов, описывающих мою предметную область (логистика). Мне не важно, как крутятся колеса у машины, перевозящей груз, а важно лишь когда она поехала, когда приедет и сколько метров при этом она проедет.
G>>Ну мало ли, что там логистика. Ты утверждаешь, ни много ни мало, что реальный мир описывается нормально иерархией классов. Я возражаю.
S>Иерархия классов — модель реального мира. Достаточно?
Ты кусочек реального мира в виде лужи смоделируй сначала, а потом будешь спрашивать, достаточно или нет. Пока — недостаточно.
S>Прежде чем отвечать, подумай, что такое модель и зачем создаются модели.
А ты расскажи — тут всем это интересно. Что такое модель? Зачем они создаются?
Здравствуйте, Gaperton, Вы писали: S>>Прежде чем отвечать, подумай, что такое модель и зачем создаются модели. G>А ты расскажи — тут всем это интересно. Что такое модель? Зачем они создаются?
Здравствуйте, Sshur, Вы писали:
S>Здравствуйте, Gaperton, Вы писали: S>>>Прежде чем отвечать, подумай, что такое модель и зачем создаются модели. G>>А ты расскажи — тут всем это интересно. Что такое модель? Зачем они создаются?
S>Здесь
Очень кстати ты эту ссылку привел. Вот, смотрим:
Такая многозначность термина становится понятной, если учесть, что М. в конкретных науках так или иначе связываются с применением моделирования, т. е. с выяснением (или воспроизведением) свойств какого-либо объекта, процесса или явления с помощью другого объекта, процесса или явления — его "М." (типичные примеры: "планетарная" М. атома и концепция "электронного газа", апеллирующие к более наглядным — точнее, более привычным — механическим представлениям). Поэтому первое естественно возникающее требование к М. — это полное тождество строения М. и "оригинала".
Так что там у нас насчет ОО модели лужи и падающей в нее капли — как примера? Можешь даже обойтись гомоморфной моделью, позволяющей смоделировать процесс — ладно уж, тождество строения оставим за кадром. Ну так как, приведешь пример ОО модели, описывающей реальный мир? Или с этим обнаружились какие-то сложности?
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Sshur, Вы писали:
S>>Здравствуйте, Gaperton, Вы писали: S>>>>Прежде чем отвечать, подумай, что такое модель и зачем создаются модели. G>>>А ты расскажи — тут всем это интересно. Что такое модель? Зачем они создаются?
S>>Здесь
G> Очень кстати ты эту ссылку привел. Вот, смотрим:
G>
G>Такая многозначность термина становится понятной, если учесть, что М. в конкретных науках так или иначе связываются с применением моделирования, т. е. с выяснением (или воспроизведением) свойств какого-либо объекта, процесса или явления с помощью другого объекта, процесса или явления — его "М." (типичные примеры: "планетарная" М. атома и концепция "электронного газа", апеллирующие к более наглядным — точнее, более привычным — механическим представлениям). Поэтому первое естественно возникающее требование к М. — это полное тождество строения М. и "оригинала".
G>Так что там у нас насчет ОО модели лужи и падающей в нее капли — как примера? Можешь даже обойтись гомоморфной моделью, позволяющей смоделировать процесс — ладно уж, тождество строения оставим за кадром. Ну так как, приведешь пример ОО модели, описывающей реальный мир? Или с этим обнаружились какие-то сложности?
Читаем дальше —
Однако выполнение этого условия может оказаться затруднительным или ненужным, да и вообще настаивать на нём неразумно, поскольку никакого упрощения исследовательской задачи, являющейся важнейшим стимулом для моделирования, использование одних лишь изоморфных М. не даёт
?
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Ты исходишь из популярной, но совершенно не верной предпосылки, которая до сих пор встречается в некоторых книгах, и уже неоднократно здесь обсуждалась, а именно:
Объекты используемые ООП есть модели объектов реального мира.
Уже миллион раз обсуждалось, что это предпосылка не только не верна, она попросту вредна — для того же проектирования.
А если эту предпосылку убрать — то вся идея рассыпается, так как совершенно не ясно — что ты будешь помещать в библиотеки классов.
Здравствуйте, AndreyFedotov, Вы писали:
AF> Ты исходишь из популярной, но совершенно не верной предпосылки, которая до сих пор встречается в некоторых книгах, и уже неоднократно здесь обсуждалась, а именно: AF>
AF> Объекты используемые ООП есть модели объектов реального мира.
AF>Уже миллион раз обсуждалось, что это предпосылка не только не верна, она попросту вредна — для того же проектирования. AF>А если эту предпосылку убрать — то вся идея рассыпается, так как совершенно не ясно — что ты будешь помещать в библиотеки классов.
А ссылки можно? А то если это так, то получается, что я в своем профессиональном развитиии пошел не туда.
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, AndreyFedotov, Вы писали:
AF> Ты исходишь из популярной, но совершенно не верной предпосылки, которая до сих пор встречается в некоторых книгах, и уже неоднократно здесь обсуждалась, а именно: AF>
AF> Объекты используемые ООП есть модели объектов реального мира.
AF>Уже миллион раз обсуждалось, что это предпосылка не только не верна, она попросту вредна — для того же проектирования. AF>А если эту предпосылку убрать — то вся идея рассыпается, так как совершенно не ясно — что ты будешь помещать в библиотеки классов.
И еще, вдогонку — предпосылка верна, надо только добавить слово "описательные модели".
А вот их использование при проектировании возможно и не оправдано.
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, Sshur, Вы писали:
G>>Так что там у нас насчет ОО модели лужи и падающей в нее капли — как примера? Можешь даже обойтись гомоморфной моделью, позволяющей смоделировать процесс — ладно уж, тождество строения оставим за кадром. Ну так как, приведешь пример ОО модели, описывающей реальный мир? Или с этим обнаружились какие-то сложности?
S>Читаем дальше — S>
S>Однако выполнение этого условия может оказаться затруднительным или ненужным, да и вообще настаивать на нём неразумно, поскольку никакого упрощения исследовательской задачи, являющейся важнейшим стимулом для моделирования, использование одних лишь изоморфных М. не даёт
S>?
Хе-хе Читаем непосредственно со следующего предложения.
Т. о., на следующем уровне мы приходим к представлению о М. как об упрощённом образе моделируемого объекта, т. е. к требованию гомоморфизма М. "оригиналу". (Гомоморфизм, как и изоморфизм, "сохраняет" все определённые на исходной системе свойства и отношения, но, в отличие от изоморфизма, это отображение, вообще говоря, однозначно лишь в одну сторону: образы некоторых элементов "оригинала" в М. оказываются "склеенными" — подобно тому, как на сетчатке глаза или на фотографии сливаются в одно пятно изображения близких между собой участков изображаемого предмета.)
А теперь читаем мой пост еще раз, внимательнее:
Можешь даже обойтись гомоморфной моделью, позволяющей смоделировать процесс — ладно уж, тождество строения оставим за кадром. Ну так как, приведешь пример ОО модели, описывающей реальный мир? Или с этим обнаружились какие-то сложности?
Короче, вопрос ребром. Надо понимать тебя так, что ты таки отказываешься от своего тезиса (ОО моделирует реальный мир), признавая, что метод вообще говоря для этого не годится? Или модель все-таки будет?
G>Можешь даже обойтись гомоморфной моделью, позволяющей смоделировать процесс — ладно уж, тождество строения оставим за кадром. Ну так как, приведешь пример ОО модели, описывающей реальный мир? Или с этим обнаружились какие-то сложности?
G>Короче, вопрос ребром. Надо понимать тебя так, что ты таки отказываешься от своего тезиса (ОО моделирует реальный мир), признавая, что метод вообще говоря для этого не годится? Или модель все-таки будет?
Я так понял проблема в разных трактовках понимания словосочетания "реальный мир". Я под реальным миром понимаю в первую очередь те его области, для которых уже пишутся ОО программы. Для моделирования процессов в луже никто не будет писать ОО программы- там есть специальные математические методы.
В одной из книг по разработке ПО(то ли Фаулер, то ли Мартин) я встретил пример создания ОО модели копира для программы управления. Здесь ОО модель составить можно и нужно. Или ты хочешь сказать что это невозможно?
Потом. Модели строятся не только с целью изучения моделируемого явления. Иерархия классов в ООП — это описательная модель и не более того.
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Здравствуйте, Sshur, Вы писали:
S>Здравствуйте, AndreyFedotov, Вы писали:
AF>> Ты исходишь из популярной, но совершенно не верной предпосылки, которая до сих пор встречается в некоторых книгах, и уже неоднократно здесь обсуждалась, а именно: AF>>
AF>> Объекты используемые ООП есть модели объектов реального мира.
AF>>Уже миллион раз обсуждалось, что это предпосылка не только не верна, она попросту вредна — для того же проектирования. AF>>А если эту предпосылку убрать — то вся идея рассыпается, так как совершенно не ясно — что ты будешь помещать в библиотеки классов.
S>И еще, вдогонку — предпосылка верна, надо только добавить слово "описательные модели". S>А вот их использование при проектировании возможно и не оправдано.
В том то и дело, что не верна даже в этом случае.
Простой пример. Объект — стиральная машина. Вполне себе описательная модель. Но вот что бы с ними работать, в программе используется другой объект — вектор, список, карта, массив — в общем какой то контейнер. Так вот — этот контейнер никакого физического смысла не имеет. То есть в общем случае он не моделирует какой-либо объект реального мира.
Здравствуйте, Sshur, Вы писали:
S>Здравствуйте, Gaperton, Вы писали:
G>>
G>>Можешь даже обойтись гомоморфной моделью, позволяющей смоделировать процесс — ладно уж, тождество строения оставим за кадром. Ну так как, приведешь пример ОО модели, описывающей реальный мир? Или с этим обнаружились какие-то сложности?
G>>Короче, вопрос ребром. Надо понимать тебя так, что ты таки отказываешься от своего тезиса (ОО моделирует реальный мир), признавая, что метод вообще говоря для этого не годится? Или модель все-таки будет?
S>Я так понял проблема в разных трактовках понимания словосочетания "реальный мир".
Именно. Проблема исключительно в терминологической неточности. Не скажи вы "реальный мир" — вопросов бы не было.
S>Я под реальным миром понимаю в первую очередь те его области, для которых уже пишутся ОО программы.
Хм, простите мое занудство, но тогда получается, что области, для которых ОО программы не пишутся, в меньшей степени относятся к реальному миру? Взять, например, секс с девушкой, или распитие пива?
Вообще, если вы хотите определить только тот класс процессов, который удачно моделируется при помощи ОО, то "реальный мир" — не очень удачный термин.
S>Для моделирования процессов в луже никто не будет писать ОО программы- там есть специальные математические методы.
Угу. Именно. Пример с лужей — не единственный, он самый яркий. Далеко не все процессы удобно моделировать при помощи ОО с его иерархиями классов. Можно еще массу примеров накидать.
Здравствуйте, Sshur, Вы писали:
S>Дык со всех сторон и не надо — применительно к наемному работнику наверняка достаточно будет к достаточно какой-нибудь уже хорошо разработанной иерархии (а такие есть, уверен — программы расчета зарплаты как-то работают) добавить пару уровней абстрации, если появятся неподходящие частные случаи.. Не надо брать физиологические модели. (Если только мы не рассматриваем случай работы за еду и работодателю нужно кормить работника ровно настолько чтобы тот мог выполнять обязанности )
S>Кроме того, класс не обязан иметь все возможные атрибуты — для этого есть полиморфизм.
Вот тут-то и получается: зачем писать классы, если их потом менять и переписывать.
А если я модель бубу делать социологическую — "работа за еду". Может у меня диссертация такая?
S>Подумалось вот на досуге:
S>В науке естественным ходом развития является, что если теория имеет слабые места, (т.е существуют объекты, для которых она не работает), то рано или поздно появится более общая теория, в которой предыдущая будет частным случаем и все необъяснимые ранее явления будут объяснены.
S>Но то же самое происходит и в процессе создания ПО!
S>Архитектор, создавая иерархию объектов под конкретную задачу, постоянно решает те же проблемы: новые возможности постоянно требуют введение все более и более высоких уровней абстрации (иначе внедрение новых возможностей в систему приведет к прописыванию дополнительных условий как здесь http://www.rsdn.ru/Forum/Message.aspx?mid=1241937&only=1).
S>Сейчас есть огромное количество ОО библиотек, охватывающих самые различные компьютерные технологии (.NET, например), то есть в них подробно и достаточно удобно реализованы абстакции типа окна, базы данных итд, то есть абстракции инструментов, используемых при решении задач реального мира.
S>Так вот вопрос, а почему до сих пор нет библиотек, в которых существовала бы иерархия классов, описывающих объекты того самого реального мира? Все же создаваемые программные системы не являются самоцелью, они преследуют решение каких-то конкретных задач.. И вот здесь бы пригодилась например, ОО модель склада или цеха по производству пулеметов, или там универсальная модель наемного работника, которая бы учитывала бы все возможные способы начисления зарплаты. И не надо говорить, что все работают по разному — просто пока никто не добрался до нужного уровня абстракции Тем более что все эти модели должны отражать вполне конкретные объекты реального мира и соответственно рано или поздно можно добраться до адекватной модели, отражающей ВСЕ возможные варианты использования этих объектов.
S>И если такие модели будут созданы, тогда програмирование превратится в технологию. А пока это все-таки отчасти искусство..
S>Все
S>ЗЫ. Шаблоны проектирования отчасти решают такую задачу, но не до конца. Это всего лишь общие закономерности, но не более того.
То что ты описал — крайность и уже только поэтому недостижима. Но! Тенденции к "ремесленизации" индустрии ПО тем не менее существуют. Основной аргумент противников этого приблизительно звучит так: "все очень разное, обобщение этих разностей невозможно, а если и возможно — то ведет к катастрофическому уменьшению эфеективности". Основная ошибка, в целом, вобщем-то, верного суждения, что кроме тенденции к обобщению со стороны программиста, существует еще и тендеция к унификации и упрощению со стороны потребителей ПО. Далеко ходить не будем — возьмем всем нам хорошо известную бухгалтерию. Лет эдак 10-15 назад каждая мало-мальски уважающая себя контора стала компьютеризироваться и обзаводиться бухгалтерским ПО. ПО как правило заказывалось различным конторкам и отражало собственное представление компании о том, как должен организовываться документооборот внутри компании, вестись учет клиентов, рассчитываться зарплата и т.д. Сейчас ситуация изменилась фактически в корне — компания покупает готовое ПО и уже под него изменяет организацию своей работы. Т.е. модель функционирования оргранизации навязываемая ПО, де факто, становиться некоторым стандартом. Можно возразить, что подобное ПО, например 1С, предоставляет возможность гибко настраивать систему под конкретного заказчика, писать скрипты на собственном макроязыке и т.д. Но все это — лишь возможности в рамках самой 1С, что уже есть первый шаг к ограничению и упрощению.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Gaperton, Вы писали:
G>>Или модель все-таки будет?
IT>Можно я? Спасибо!
IT>
IT>public class Puddle
IT>{
IT> ...
IT>}
IT>public class Drop
IT>{
IT> ...
IT>}
IT>
Эта модель не соответствует тому что требовал Gaperton.
Насколько я понимаю он требовал описать динамическую модель взаимодействия капли и лужи.
И не просто в виде двух — трёх методов типа: "кослулась" "утонула"
Требовалась модель изменения формы лужи и капли при их взаимодействии.
В качестве статической модели можно было бы предложить, чтобы эти объекты содержали коллекции триангуляций для моделирования их поверхностей.
Но вот законы их взаимодействия в ОО модель уложить не получится (даже с помощью диаграмм взаимодействий) поскольку ОО модель соответствует математической декомпозиции конечных автоматов, а она неспособна описать сам алгоритм.
Таким образом формально ОО моделирование хорошо там где необходима автоматная декомпозиция. Например для "уменьшения" сложности написания программ. Так как это позволяет в каждый момент рассматривать небольшую часть всего требуемого конечного автомата.
Сами же функции преобразования состояний автоматов описываются алгоритмами.
Возвращаясь к капле с лужей
конечно невозможно описать законы взаимодействия этих объектов в виде ОО примитивов, однако можно построить модель упрощающую написание программы их взаимодействия.
Здравствуйте, Sshur, Вы писали:
S>Так вот вопрос, а почему до сих пор нет библиотек, в которых существовала бы иерархия классов, описывающих объекты того самого реального мира? Все же создаваемые программные системы не являются самоцелью, они преследуют решение каких-то конкретных задач.. И вот здесь бы пригодилась например, ОО модель склада или цеха по производству пулеметов, или там универсальная модель наемного работника, которая бы учитывала бы все возможные способы начисления зарплаты. И не надо говорить, что все работают по разному — просто пока никто не добрался до нужного уровня абстракции Тем более что все эти модели должны отражать вполне конкретные объекты реального мира и соответственно рано или поздно можно добраться до адекватной модели, отражающей ВСЕ возможные варианты использования этих объектов.
Здравствуйте, Stepochkin, Вы писали:
S>Эта модель не соответствует тому что требовал Gaperton.
Какие ещё требования были к объектной модели кроме капли и лужи? Давай уточняй требования, будем строить модель дальше.
S>Насколько я понимаю он требовал описать динамическую модель взаимодействия капли и лужи.
Он требовал построить объектную модель. Хотя подразумевать мог что угодно.
S>И не просто в виде двух — трёх методов типа: "кослулась" "утонула"
В простейшем виде для такой постановки задачи и так сойдёт
S>Требовалась модель изменения формы лужи и капли при их взаимодействии.
Т.е. хочется промежуточных состояний? Ну так уточняй детали состояния и будет тебе модель.
S>В качестве статической модели можно было бы предложить, чтобы эти объекты содержали коллекции триангуляций для моделирования их поверхностей.
... как часть объектной модели?
S>Но вот законы их взаимодействия в ОО модель уложить не получится (даже с помощью диаграмм взаимодействий) поскольку ОО модель соответствует математической декомпозиции конечных автоматов, а она неспособна описать сам алгоритм.
Алгоритмы никто и не собирается описывать объектами, хотя компиляторы даже это делают, так что теоретически возможно. Но вот то что алгоритмы сами по себе нафиг не нужны так это факт. Нужны результаты их работы. Результаты — это данные, которые легко можно представить как состояния объектов.
S>Таким образом формально ОО моделирование хорошо там где необходима автоматная декомпозиция. Например для "уменьшения" сложности написания программ. Так как это позволяет в каждый момент рассматривать небольшую часть всего требуемого конечного автомата.
S>Сами же функции преобразования состояний автоматов описываются алгоритмами.
И как это противоречит моей объектной модели лужи?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Тем более что все эти модели должны отражать вполне конкретные объекты реального мира и соответственно рано или поздно можно добраться до адекватной модели, отражающей ВСЕ возможные варианты использования этих объектов.
Если нам не помогут, то мы тоже никого не пощадим.
