Здравствуйте, Sshur, Вы писали:

S>Здравствуйте, Gaperton, Вы писали:

G>>

G>>Можешь даже обойтись гомоморфной моделью, позволяющей смоделировать процесс — ладно уж, тождество строения оставим за кадром. Ну так как, приведешь пример ОО модели, описывающей реальный мир? Или с этим обнаружились какие-то сложности?

G>>Короче, вопрос ребром. Надо понимать тебя так, что ты таки отказываешься от своего тезиса (ОО моделирует реальный мир), признавая, что метод вообще говоря для этого не годится? Или модель все-таки будет?

S>Я так понял проблема в разных трактовках понимания словосочетания "реальный мир".
Именно. Проблема исключительно в терминологической неточности. Не скажи вы "реальный мир" — вопросов бы не было.

S>Я под реальным миром понимаю в первую очередь те его области, для которых уже пишутся ОО программы.
Хм, простите мое занудство, но тогда получается, что области, для которых ОО программы не пишутся, в меньшей степени относятся к реальному миру? Взять, например, секс с девушкой, или распитие пива?

Вообще, если вы хотите определить только тот класс процессов, который удачно моделируется при помощи ОО, то "реальный мир" — не очень удачный термин.

S>Для моделирования процессов в луже никто не будет писать ОО программы- там есть специальные математические методы.
Угу. Именно. Пример с лужей — не единственный, он самый яркий. Далеко не все процессы удобно моделировать при помощи ОО с его иерархиями классов. Можно еще массу примеров накидать.

Здравствуйте, Gaperton, Вы писали:

G>Или модель все-таки будет?

Можно я? Спасибо!

public class Puddle
{
    ...
}

public class Drop
{
    ...
}

Здравствуйте, Sshur, Вы писали:

S>Дык со всех сторон и не надо — применительно к наемному работнику наверняка достаточно будет к достаточно какой-нибудь уже хорошо разработанной иерархии (а такие есть, уверен — программы расчета зарплаты как-то работают) добавить пару уровней абстрации, если появятся неподходящие частные случаи.. Не надо брать физиологические модели. (Если только мы не рассматриваем случай работы за еду и работодателю нужно кормить работника ровно настолько чтобы тот мог выполнять обязанности )

S>Кроме того, класс не обязан иметь все возможные атрибуты — для этого есть полиморфизм.


Вот тут-то и получается: зачем писать классы, если их потом менять и переписывать.
А если я модель бубу делать социологическую — "работа за еду". Может у меня диссертация такая?

Здравствуйте, Sshur, Вы писали:


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С, что уже есть первый шаг к ограничению и упрощению.

почитайте про Domain Specific Languages

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Gaperton, Вы писали:

G>>Или модель все-таки будет?

IT>Можно я? Спасибо!

IT>

IT>public class Puddle
IT>{
IT>    ...
IT>}

IT>public class Drop
IT>{
IT>    ...
IT>}
IT>

Эта модель не соответствует тому что требовал Gaperton.
Насколько я понимаю он требовал описать динамическую модель взаимодействия капли и лужи.
И не просто в виде двух — трёх методов типа: "кослулась" "утонула"
Требовалась модель изменения формы лужи и капли при их взаимодействии.

В качестве статической модели можно было бы предложить, чтобы эти объекты содержали коллекции триангуляций для моделирования их поверхностей.
Но вот законы их взаимодействия в ОО модель уложить не получится (даже с помощью диаграмм взаимодействий) поскольку ОО модель соответствует математической декомпозиции конечных автоматов, а она неспособна описать сам алгоритм.

Таким образом формально ОО моделирование хорошо там где необходима автоматная декомпозиция. Например для "уменьшения" сложности написания программ. Так как это позволяет в каждый момент рассматривать небольшую часть всего требуемого конечного автомата.

Сами же функции преобразования состояний автоматов описываются алгоритмами.

Возвращаясь к капле с лужей
конечно невозможно описать законы взаимодействия этих объектов в виде ОО примитивов, однако можно построить модель упрощающую написание программы их взаимодействия.

Здравствуйте, Sshur, Вы писали:

S>Так вот вопрос, а почему до сих пор нет библиотек, в которых существовала бы иерархия классов, описывающих объекты того самого реального мира? Все же создаваемые программные системы не являются самоцелью, они преследуют решение каких-то конкретных задач.. И вот здесь бы пригодилась например, ОО модель склада или цеха по производству пулеметов, или там универсальная модель наемного работника, которая бы учитывала бы все возможные способы начисления зарплаты. И не надо говорить, что все работают по разному — просто пока никто не добрался до нужного уровня абстракции Тем более что все эти модели должны отражать вполне конкретные объекты реального мира и соответственно рано или поздно можно добраться до адекватной модели, отражающей ВСЕ возможные варианты использования этих объектов.

1C ?

Здравствуйте, Stepochkin, Вы писали:

S>Эта модель не соответствует тому что требовал Gaperton.

Какие ещё требования были к объектной модели кроме капли и лужи? Давай уточняй требования, будем строить модель дальше.

S>Насколько я понимаю он требовал описать динамическую модель взаимодействия капли и лужи.

Он требовал построить объектную модель. Хотя подразумевать мог что угодно.

S>И не просто в виде двух — трёх методов типа: "кослулась" "утонула"

В простейшем виде для такой постановки задачи и так сойдёт

S>Требовалась модель изменения формы лужи и капли при их взаимодействии.

Т.е. хочется промежуточных состояний? Ну так уточняй детали состояния и будет тебе модель.

S>В качестве статической модели можно было бы предложить, чтобы эти объекты содержали коллекции триангуляций для моделирования их поверхностей.

... как часть объектной модели?

S>Но вот законы их взаимодействия в ОО модель уложить не получится (даже с помощью диаграмм взаимодействий) поскольку ОО модель соответствует математической декомпозиции конечных автоматов, а она неспособна описать сам алгоритм.

Алгоритмы никто и не собирается описывать объектами, хотя компиляторы даже это делают, так что теоретически возможно. Но вот то что алгоритмы сами по себе нафиг не нужны так это факт. Нужны результаты их работы. Результаты — это данные, которые легко можно представить как состояния объектов.

S>Таким образом формально ОО моделирование хорошо там где необходима автоматная декомпозиция. Например для "уменьшения" сложности написания программ. Так как это позволяет в каждый момент рассматривать небольшую часть всего требуемого конечного автомата.

S>Сами же функции преобразования состояний автоматов описываются алгоритмами.

И как это противоречит моей объектной модели лужи?