В науке естественным ходом развития является, что если теория имеет слабые места, (т.е существуют объекты, для которых она не работает), то рано или поздно появится более общая теория, в которой предыдущая будет частным случаем и все необъяснимые ранее явления будут объяснены.
Но то же самое происходит и в процессе создания ПО!
Архитектор, создавая иерархию объектов под конкретную задачу, постоянно решает те же проблемы: новые возможности постоянно требуют введение все более и более высоких уровней абстрации (иначе внедрение новых возможностей в систему приведет к прописыванию дополнительных условий как здесь 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, и вперед. (Это я утрирую)
Объектная модель — это далеко не главная вещь. Нужен еще и код, однако.
Тем более что все эти модели должны отражать вполне конкретные объекты реального мира и соответственно рано или поздно можно добраться до адекватной модели, отражающей ВСЕ возможные варианты использования этих объектов.
