Здравствуйте, vdimas, Вы писали:
V>И ты до сих пор не выяснил?
Я как раз выяснил. Был разочарован. V>Ну дык, а я выяснил еще давно: ООП уместно там, где речь идет об изменяемом состоянии. (*)
Вы не юлите. Покажите пальцем — как устроена объектная модель в моделировании процессов в гидро/газодинамике?
Есть ли там отдельные экземпляры объектов для каждой молекулы? Сколько там классов? Какова схема наследования, если она есть?
Используются ли виртуальные методы?
Я вот имею основания полагать, что никакого ООП там и в помине нет, несмотря на изменяемое состояние. Что математика там устроена ровно так же, как была устроена до введения моделирования молекулярного уровня — т.е. есть массивы чисел с плавающей запятой, и есть методы по вычислению следующих значений по предыдущим.
Только в макроскопическом случае в массивах хранились скалярные и векторные поля вроде плотности, давления, температуры, и скорости, а в случае микроскопического моделирования храним массивы координат и скоростей отдельных молекул.
Если у вас есть другая информация — поделитесь. А надувать щёки и переводить разговор на личности не надо — я вам уже говорил, здесь это оффтоп.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, pkl, Вы писали:
pkl>Почему не подтвердили-то? Дверь — объект, состояния — открыта, закрыта — всё прекрасно ложится. Как конкретно дверь открывается — в обычной жизни вообще никого не колышит. Каждый, кто пользуется дверью делает это на автомате — тут чё-то повернул, тут потянул, открылось — это как на велике кататься. Никто не будет думать о том, как она там двигается, вися на петлях и как у неё там замок работает. Важно только закрыта она или открыта...
Ну и где тогда тут ООП? Напомню, что оно — полностью про поведение объектов. Где "поведение" == "реакция объекта на посылаемые ему сообщения".
Состояние объектам в ООП нужно постольку, поскольку оно помогает им проявлять нужное поведение.
А у вас получается ровно наоборот — вам совершенно неважно поведение двери, зато важно состояние. В ООП так нельзя — объект дверь инкапсулирует своё состояние. Узнать о состоянии вы можете только из наблюдаемого поведения объекта — грубо говоря, попытавшись пройти в дверь. Если ударились лбом (получили InvalidOperationException) — значит, дверь была закрыта.
В ООП, чтобы узнать, открыта ли дверь, вам придётся приделать к ней специальный метод bool isOpen(). В реальной жизни такого метода нет — вы и так видите, открыта ли дверь. Именно поэтому RL очень плохо ложится на ООП.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Steamus, Вы писали:
S>По правде говоря — забавно. Какие-такие иные особенные волшебные подходы предоставляют другие методологии проектирования/программирования, что люди их практикующие могут эдак снисходительно потешаться над ООП? Дескать... ООП клоуны вы все, вот у нас о-о-о как всё круто!
Никто не потешается над ООП. Потешаются над людьми, покусанными ООП, и пытающимися заменить всё на свете при помощи ООП.
ООП прекрасно работает там, где оно уместно. Но это никак не связано с особенностями того, как мыслит человек.
Пытаться программировать так, как мыслит человек, вообще вредно. Скажем, банальное сложение целых внутри компьютера устроено вовсе не так, как его делает человек — потому, что компьютер может лучше.
Так и ООП — оно хорошо там, где есть что моделировать с его помощью. Это встречается гораздо реже, чем думают нубы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
V>Моделирование процессов в гидро/газодинамике именно через аппарат взаимодействия дискретных частиц — это один из самых популярных видов моделирования в этих областях.
V>детсад как он есть.
Оно там через векторные поля считается, никаких частиц.
Здравствуйте, Философ, Вы писали:
V>>Моделирование процессов в гидро/газодинамике именно через аппарат взаимодействия дискретных частиц — это один из самых популярных видов моделирования в этих областях.
Ф>Оно там через векторные поля считается, никаких частиц. Ф>http://ru.wikipedia.org/wiki/Векторное_поле
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
V>>>Но да... сами данные для трансформации тоже являются понятиями некоей предметной области, то бишь сами по себе заведомо являются объектами... Даже если это структура со всеми публичными полями... просто это другой уровень дизайна... В итоге, получается та самая классика: объекты состоят из объектов, а процедуры обрабатывают одни объекты, получая из них другие.
S>>Долго пытался вникнуть и не вник. Ты хочешь сказать что ФП это объекты + процедуры, которые на выходе дают объекты? Так, наверное, можно считать, но это далековато от положения вещей.
V>Ничуть не далеко. Хотя ООП-дизайн состоит сплошь из абстрактных типов, но в рантайм работают вполне конкретные типы, которые орудуют вполне конкретными данными, ничуть не хуже, чем ФП орудует структурами. Там всех отличий в механике ФП vs ООП, что в первом случае мы просто трансформируем данные, а во втором случае мы эти трансформированные данные перезаписываем по одним и те же адресам, в которых хранится состояние объекта.
Согласен, что такое отличие есть. Но оно не исчерпывающее. Это отличие порождает другие отличия вплоть до совершенно разного набора практик и идеологии. Но ты хочешь смотреть на это лишь под тем соусом что и ФП и ООП это структуры и функции. Еще можешь припомнить то что ФП и ООП программы выполняются одинаково на одном и том же императивном вычислителе. Пожалуйста, тут я с тобой спорить не собираюсь, как не стал бы спорить с утверждением что человек и белка имеют по 2 глаза, одному носу и вообще родственники.
V>Кароч, нет в ФП никакой магии, котрую ты уже примерно второй год пытаешься найти. Это естественное развитие процедурного подхода, точно так же как ООП является развитием процедурного подхода.
В ФП нет магии, но развитием процедурного подхода оно не является. Соглашусь лишь что в развитии ФП и ООП многое шло параллельно и они безусловно влияли друг на друга.
V>Поэтому ФП отлично смотрится в методах объекта, вычисляющих следующее состояние этого объекта. Впрочем, еще хрен его знает когда здесь это подробно обсуждали.
смотрится неплохо, но причина вовсе не "поэтому".
S>>Все равно что сказать что паровоз это телега с самоваром, забыв упомянуть что ездит по рельсам и что чай не является побочным продуктом от езды.
V>На подобные кривые аналогии у меня всегда реакция как на кислый лимон.
Лимон? Ну и что... Вот если бы ты сказал как на пенку от кипяченого молока... Лимон-то это круто.
V>Ты всё еще не оставил попыток найти некую магию в ФП? Нет никакой магии. ФП привлекательна своими характерными гарантиями... но механизм этих гарантий нифига не rocket science, и вполне воспроизводим в ООП (в виде аннотаций типов и методов, например). Другое дело, что часть мейнстрима отказалась от этих аннотаций и гарантий (C#, например)... Скорее всего по соображениям интероперабельности с языками, где этих гарантий нет.
Вопросы воспроизводимости механизмов и возможности эмуляции одного на другом вторичны и не особо меня интересуют, как ты уже наверное понял. Мне любопытны наборы практик, а не выводы типа "все **П выполняются в машинных кодах => произошли от него".
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>Надеюсь, это было твое ИМХО
V>Это был здравый смысл. В пылу спора коллеги на этом сайте как-то охотно забывают о субъективном характере практически любой информации, которой обмениваются.
Вот и ты не забывай. Помни, что твой здравый смысл — не более чем чье-то имхо.
S>>Мы вообще-то говорили об ООП. Это на тот случай, если ты решил контекст восстановить по одному лишь моему сообщению. В рамках того контекста, в котором я тут общаюсь, я делаю предположение о том что твое ИМХО считает что все, где встречается упоминание числа либо какой-то величины, можно смело относить к ООП...
V>Я понял твоё усиление и весь нагнетаемый трагизм. Надо было тебе еще н авсякий случай переспросить и поставить такой смайл: . V>Но ответ — да. Да, любое конкретное значение — это не абстракция, это выражение некоего понятия предметной области.
Я принял к сведению твое имхо
S>>Я не рассчитывал что ты влезешь с середины и не поймешь о чем речь (или сделал вид что не понял).
V>Я влез с самого начала. Другое дело, что мммм... не могу согласиться со столь серьезным отношением к столь несерьезным вещам. ООП как и ФП, это в первую очередь набор практик, которые обслуживают некую т.з. на способ решения задачи. А ты пытаешься эти набры практик мало того, что возвести в антагонизм друг к другу, дык еще каждую из них в абсолют. Самое время вот этому:
V>Кароч, неблагодарное это дело... Хотя бы потому, что эти наборы практик постоянно развиваются. То бишь любая твоя т.з., пусть даже самая адекватная, назавтра безбожно устареет.
С чем тебя и поздравляю. Имхо, твоя т.з. не самая адекватная, да еще и устарела.
Надеюсь что возвращая заданный тобой акцент, я сделал продолжение в этом духе малоперспективным. Но боюсь, что продолжение может оказаться для тебя все-таки занимательным.
Здравствуйте, Sinclair, Вы писали:
S>Вы не юлите. Покажите пальцем — как устроена объектная модель в моделировании процессов в гидро/газодинамике? S>Есть ли там отдельные экземпляры объектов для каждой молекулы? Сколько там классов? Какова схема наследования, если она есть? S>Используются ли виртуальные методы?
Например (я конкретно о том, с чем имел дело, буду говорить — моделирование полевого транзистора методом частиц), поле можно представлять очень по-разному — в виде прямоугольной сетки, в виде треугольной сетки, в виде смеси обеих по произвольным границам. Также можно по-разному интерполировать поле внутри каждого конечного элемента. Все это замечательно укладывается в ООП — частица просто спрашивает у объекта соответствующего полевого класса, какой вектор поля в той точке, где она находится, пользуясь только базовым интерфейсом, а реализация может быть какой угодно.
А у базового интерфейса, по сути, всего два метода: один я уже озвучил, а второй — пересчитать себя из внешнего поля и коллекции частиц.
Вполне себе ООП.
Здравствуйте, мыщъх, Вы писали:
K>>Еще одна проблема — в реальном мире состояние "открыта-закрыта" субъективно со стороны наблюдателя. K>>Одному надо, чтобы было герметично закрыто, иначе не считает что закрыто, другому нужно, чтобы была заперта, иначе не закрыта.
М>так я же и пишу: открыта/закрыта/заперта. еще можно добавить "зафиксирована" в открытом, закрытом или промежуточном состоянии.
Только оценка ее состояния зависит и от обозревателя, и от двери. Оценка "состояния" двери — функция от двух переменных, самой двери с ее геометрическим положением и наблюдателя. Если дальше уточнять модель, в параметры функции добавятся разного рода автоматика и системы безопасности.
Мы мыслим очень разнообразно. В случае двери имеют место два набора функций — для оценки состояния двери и для ее открывания и закрывания с разными параметрами. Ни "состояние двери", ни "открытие двери" не принадлежат одной только двери или наблюдателю/актору.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Wolverrum, Вы писали:
W>>Мысль простая... и ложная.
W>>Мозг не работает объектно. Мозг хз как работает. Просто если бы народ знал, что мозг мыслит объектно, ИИ в его первоначальном понимании был бы создан лет 20 назад. Но ИИ до сих пор нет и не редвидится. Ах и увы.
V>Мозг работает образно и это уже многократно доказано. Если бы не образность мышления, передача знаний в том виде, в каком она сейчас существует, была бы невозможна. Ведь любые слова — это лишь описание неких образов. Эдакая сериализация объектов в текст...
Обрзность и мышление обтектами — это не так уж рядом. Образы могут прозвольно трансформироваться из гусеницы в водопроводный кран или грецкий орех, а потом в течение времени или сожаление от опоздания на поезд, по самого разного рода ассоциативным связям.
Здравствуйте, vdimas, Вы писали:
V>И ты до сих пор не выяснил? V>Ну дык, а я выяснил еще давно: ООП уместно там, где речь идет об изменяемом состоянии. (*)
V>Нет, всё сводится исключительно к тому, что без состояния нет поведения. См. пометку (*). Кто этого не понимает, тот не понимает как устроено и работает ООП. Тот не понимает фундаментальное отличие повдеения от безусловнх реакций. ООП — это такой механизм моделирования "поведения сущностей", который реализован через изменяемое состояние.
Введем в рассмотрение ФП, где на вход функции дается состояние, а на выходе получаем новое. С учетом работы GC каких-то практических отличий от изменяемых объектов будет негусто. При этом еще интересно посмотреть на обьекты ocaml.
Здравствуйте, jazzer, Вы писали: J>Например (я конкретно о том, с чем имел дело, буду говорить — моделирование полевого транзистора методом частиц), поле можно представлять очень по-разному — в виде прямоугольной сетки, в виде треугольной сетки, в виде смеси обеих по произвольным границам. Также можно по-разному интерполировать поле внутри каждого конечного элемента. Все это замечательно укладывается в ООП — частица просто спрашивает у объекта соответствующего полевого класса, какой вектор поля в той точке, где она находится, пользуясь только базовым интерфейсом, а реализация может быть какой угодно. J>А у базового интерфейса, по сути, всего два метода: один я уже озвучил, а второй — пересчитать себя из внешнего поля и коллекции частиц. J>Вполне себе ООП.
Прекрасно, прекрасно. В итоге оказалось, что от "объектов", которые мы наблюдаем в "реальности" (скажем, частицы и их взаимодействие) мы тут же отказались, и ввели совершенно другие понятия. И вместо облака миллионов объектов, обменивающихся сообщениями, мы получили три "объекта" — массив частиц, векторное поле, и "вычислитель" (отсутствующий в природе совсем), который выполняет шаги вычисления. Причём сама процедура вычисления построена на ФП-основе — чистые арифметические функции, а вовсе никакие не методы объектов класса Double.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
V>Мозг работает образно
Я бы сказал, что точно неизвестно, наука тем и занимается, что выясняет, но один из видов мышления — образами. V> и это уже многократно доказано.
Где? Ссылки? V> Если бы не образность мышления, передача знаний в том виде, в каком она сейчас существует, была бы невозможна. Ведь любые слова — это лишь описание неких образов. Эдакая сериализация объектов в текст...
Это аналогия. Она не доказывает вышеприведенного утверждения. Тем более, что первоначально речь шла об объектах в контексте ООП. А аналогии, ассоциации
они обладают гораздо большей свободой, если так можно сказать. Можем же мы мыслить, нарушая ООП? Можем. По поводу сериализации объектов в текст, — спорно. Мне представляется, что это относится к способу формализации, а не к сериализации объектов. В конце концов можно на бумаге заниматься формализацией ради формализации, определив правила и выводя одно из другого. Т.о. например можно решить квадратное уравнение, вообще ничего не представляя об объектах, просто на основании формальных правил. Я не говорю, что вы не правы, — просто имхо мышление богаче, чем просто мыслить объектами.
Здравствуйте, Философ, Вы писали: AC>>Тем не менее, ООП должно умереть! Ф>почему должно? Such a plan
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, Sinclair, Вы писали: AC>>>Тем не менее, ООП должно умереть! Ф>>почему должно? S>потому что all the beauty must die
В каком оно месте "beauty"?
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, jazzer, Вы писали: J>>Например (я конкретно о том, с чем имел дело, буду говорить — моделирование полевого транзистора методом частиц), поле можно представлять очень по-разному — в виде прямоугольной сетки, в виде треугольной сетки, в виде смеси обеих по произвольным границам. Также можно по-разному интерполировать поле внутри каждого конечного элемента. Все это замечательно укладывается в ООП — частица просто спрашивает у объекта соответствующего полевого класса, какой вектор поля в той точке, где она находится, пользуясь только базовым интерфейсом, а реализация может быть какой угодно. J>>А у базового интерфейса, по сути, всего два метода: один я уже озвучил, а второй — пересчитать себя из внешнего поля и коллекции частиц. J>>Вполне себе ООП. S>Прекрасно, прекрасно. В итоге оказалось, что от "объектов", которые мы наблюдаем в "реальности" (скажем, частицы и их взаимодействие) мы тут же отказались, и ввели совершенно другие понятия. И вместо облака миллионов объектов, обменивающихся сообщениями, мы получили три "объекта" — массив частиц, векторное поле, и "вычислитель" (отсутствующий в природе совсем), который выполняет шаги вычисления. Причём сама процедура вычисления построена на ФП-основе — чистые арифметические функции, а вовсе никакие не методы объектов класса Double.
Ну да, и что? Я про то самое векторное поле — различные модели его вычисления вполне ложатся в ООП с (о, ужас!) наследованием
Ну и про массив я тоже ничего не говорил, я говорил про коллекцию частиц — что, коллекции объектов уже не ООП?
Ессно, с массивом в вычматах удобнее всего работать, но в данном случае это совершенно не важно.
А "вычислитель" — это вообще время (оператор эволюции), оно вполне в природе есть
M>>Расскажи, как ложится на ООП-парадигму такое банальное описание, как «открыть дверь». С нетерпением жду
AVK>Вопрос, что характерно, демонстрирует непонимание тобой основ ОО проектирования.
AVK>Надо, наверное, уже в граните выбивать — не существует правильного ООП дизайна для абстрактного набора сущностей. Целевая функция качества дизайна всегда зависит от решаемых задач. Нет задач, нет и дизайна.
Каки бы ни были задачи, любая модель (ООП, ФП, процедурная) к реальности будет относиться по стольку по скольку
S>>>Спасибо. Но офуеть. Откуда у Мамута, зацикленного на ФП и слабо связываещего пару слов, такой рейтинг? BS>>за такое надо банить. переход на личности.
S>Спокойно. Всё хорошо. Меня уже банили два раза за последние сутки. Если портал заинтересован в том, что бы шла напряжённая, интересная людям дискуссия, то больше он банить не должен. Если ещё раз забанит, то я уйду. Пусть пишут школьники. Как на хабре.
Осталось понять:
— каким образом обсуждение моей личности является напряженной, интересной дискуссией?
— почему человек, считающий обсуждение моей личности напряженной интересной дискуссией, думает, что он не школьник?
S>А может быть использована для худшей читабельности. Потому что в чистом ООП решение квадратного уравнения вы устанете читать, и уж тем более запаритесь понимать, как оно работает.
.
