Как мало людей понимает ООП... - Философия программирования

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

J>Ну да, и что? Я про то самое векторное поле — различные модели его вычисления вполне ложатся в ООП с (о, ужас!) наследованием

Вопрос не в том, "ложатся или не ложатся". Если поднапрячься, то можно и круглой пробкой квадратное отверстие заткнуть.
Вопрос в том, даёт ли ООП тут хоть какое-то преимущество перед не-ООП, или нет. Надо понимать, что наличие одного метода, который удалось сделать виртуальным, не даёт нам никакого ощутимого выигрыша. Вот вы сумели декомпозировать задачу так, что устройство сетки можно менять независимо от алгоритма расчёта новых параметров частиц, я вас правильно понял?
Пока что выглядит всё так, что этому алгоритму достаточно иметь функцию Double getFieldValues(Point point).
Ради одной функции городить типы с полиморфизмом и наследованием выглядит, скажем так, избыточным.

J>Ну и про массив я тоже ничего не говорил, я говорил про коллекцию частиц — что, коллекции объектов уже не ООП?
А что у вас там такого особенного с этими коллекциями, что не укладывается в банальный массив? Что именно вы инкапсулируете?

J>Ессно, с массивом в вычматах удобнее всего работать, но в данном случае это совершенно не важно.

Как раз удобство — единственное, что тут важно. Вычислительная мощность у всех моделей совершенно одинакова.
Отличаются две вещи — удобство представления (грубо говоря — объём кода, который нужно написать, чтобы взлетело, и переписать, когда надо что-то поправить) и результирующая эффективность.
Для вычметодов ООП как правило мешает и тому и другому.

J>А "вычислитель" — это вообще время (оператор эволюции), оно вполне в природе есть

Ну в таком случае координата — это оператор перемещения. Давайте координату тоже объектом сделаем, нет?

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

M>Это какой то неправильный ООП

Это — чистый, незамутнённый ООП. В нём нет ничего, кроме объектов. Вас просто избаловали мультипарадигменные языки, в которых, скажем, арифметика (абсолютно, к слову, необъектная) встроена из коробки.
А если вам дать настоящий ООП, где Add — это виртуальный метод у интерфейса INumberArithmetic, то вы застрелитесь писать решение квадратного уравнения.

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

M>>Это какой то неправильный ООП

S>Это — чистый, незамутнённый ООП. В нём нет ничего, кроме объектов. Вас просто избаловали мультипарадигменные языки, в которых, скажем, арифметика (абсолютно, к слову, необъектная) встроена из коробки.
S>А если вам дать настоящий ООП, где Add — это виртуальный метод у интерфейса INumberArithmetic, то вы застрелитесь писать решение квадратного уравнения.

А в чем именно проблема, если не считать эффективности? Если определить "+" как инфиксный синоним для INumberArithmetic.Add, то это как-то сильно будет мешать ООПу?

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

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

M>>Это какой то неправильный ООП

S>Это — чистый, незамутнённый ООП. В нём нет ничего, кроме объектов. Вас просто избаловали мультипарадигменные языки, в которых, скажем, арифметика (абсолютно, к слову, необъектная) встроена из коробки.
S>А если вам дать настоящий ООП, где Add — это виртуальный метод у интерфейса INumberArithmetic, то вы застрелитесь писать решение квадратного уравнения.

Тогда резонно изложить ваше понимание "настоящий ООП".

... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>

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

ВВ>А в чем именно проблема, если не считать эффективности? Если определить "+" как инфиксный синоним для INumberArithmetic.Add, то это как-то сильно будет мешать ООПу?
В том, что не вполне понятно, чей именно это метод. Известные мне языки, где такие штуки разрешены, используют для них ограничения, делающие их несовместимыми с ООП.

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

V>>И ты до сих пор не выяснил?
S>Я как раз выяснил. Был разочарован.
V>>Ну дык, а я выяснил еще давно: ООП уместно там, где речь идет об изменяемом состоянии. (*)
S>Вы не юлите. Покажите пальцем — как устроена объектная модель в моделировании процессов в гидро/газодинамике?
S>Есть ли там отдельные экземпляры объектов для каждой молекулы? Сколько там классов? Какова схема наследования, если она есть?
S>Используются ли виртуальные методы?

Зачем виртуальные методы?

S>Я вот имею основания полагать, что никакого ООП там и в помине нет, несмотря на изменяемое состояние.

Полагай что хочешь.

ООП уместно там, где речь идет об изменяемом состоянии.

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

ООП не запрещает никакую математику.

S>Только в макроскопическом случае в массивах хранились скалярные и векторные поля вроде плотности, давления, температуры, и скорости, а в случае микроскопического моделирования храним массивы координат и скоростей отдельных молекул.

Да ради бога. Но спекулирование такого рода не запрещают ООП для этой задачи. Собсно, она и так уже ООП, т.к. моделирование идет от иммитации объектов прикладного мира. А исопльзовались ли там ключевые слова из ООП или ООП-язык — до фени. ООП — это точка зрения и способ решения задачи. Это не обязательно виртуальные методы, но обязательно обособленное состояние. Не ты ли как-то упоминал такую важную часть ООП как identity объектов?

S>Если у вас есть другая информация — поделитесь. А надувать щёки и переводить разговор на личности не надо — я вам уже говорил, здесь это оффтоп.

Я уже поделился той информацией, которой обладал, далее изобретать не стану, ес-но. По мне приведенной информации хватило с головой как ответ на это:

Совсем хардкор, где бесполезность ООП лично для меня очевидна. Есть лужа (совсем необязательно являющаяся сечением шара), в лужу бросили камень (вектор скорости совсем необязательно перпендикулярным поверхности). Задача: описать поведение волн с течением времени.

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

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

K>Введем в рассмотрение ФП, где на вход функции дается состояние, а на выходе получаем новое. С учетом работы GC каких-то практических отличий от изменяемых объектов будет негусто.

А какие вообще проблемы моделировать ФП на ООП или наоборот?

Заметь, устройство методов в ООП выглядит ровно аналогично: на вход метода дается состояние, а на выходе получаем новое. Единственная разница, что это новое состояние записываем по тому же адресу, а не по новому, т.к. нам приходится обслуживать понятие "экземпляр объекта". Но если ты сможешь точно так же обслуживать понятие "экземпляр" для своей ФП-программы, то получишь ровно тоже самое, вид сбоку, а имено — монаду State, которая и есть модель императивного ПО, на котором, в свою очередь, ООП эмулируется на ура.

K>При этом еще интересно посмотреть на обьекты ocaml.

Как раз неинтересно, бо ocaml — мультипарадигменный язык. То бишь ему ничего не надо моделировать, у него и так всё есть.

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

Ф>Оно там через векторные поля считается, никаких частиц.

Оно по-разному считается. Но чем мощнее со временем компы, тем более популярны методы на основе моделирования частиц.

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

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

J>>Ну да, и что? Я про то самое векторное поле — различные модели его вычисления вполне ложатся в ООП с (о, ужас!) наследованием

S>Вопрос не в том, "ложатся или не ложатся". Если поднапрячься, то можно и круглой пробкой квадратное отверстие заткнуть.
Оно, конечно, да, но тут не в тему немного.

S>Вопрос в том, даёт ли ООП тут хоть какое-то преимущество перед не-ООП, или нет. Надо понимать, что наличие одного метода, который удалось сделать виртуальным, не даёт нам никакого ощутимого выигрыша. Вот вы сумели декомпозировать задачу так, что устройство сетки можно менять независимо от алгоритма расчёта новых параметров частиц, я вас правильно понял?
Да, все так.

S>Пока что выглядит всё так, что этому алгоритму достаточно иметь функцию Double getFieldValues(Point point).
S>Ради одной функции городить типы с полиморфизмом и наследованием выглядит, скажем так, избыточным.

Еще поле надо пересчитывать, т.е. нечто вроде void update(Environment e, Particles ps).
Еще надо хранить всю структуру полевой модели (разные типы сеток).
Имхо, вполне достаточно для класса, не?

J>>Ну и про массив я тоже ничего не говорил, я говорил про коллекцию частиц — что, коллекции объектов уже не ООП?
S>А что у вас там такого особенного с этими коллекциями, что не укладывается в банальный массив? Что именно вы инкапсулируете?
Ну, например, их может быть несколько — горячие электроны, холодные электроны, электроны из разных долин...
Т.е. будет коллекция коллекций — это уже не совсем массив, правда?
А если еще ввести междолинные переходы...

J>>Ессно, с массивом в вычматах удобнее всего работать, но в данном случае это совершенно не важно.
S>

Как раз удобство — единственное, что тут важно. Вычислительная мощность у всех моделей совершенно одинакова.
Именно, удобство — важно, а массив — нет.

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

J>>А "вычислитель" — это вообще время (оператор эволюции), оно вполне в природе есть

S>Ну в таком случае координата — это оператор перемещения. Давайте координату тоже объектом сделаем, нет?
Не, координатный оператор не перемещает, он ищет координату.
Любая временная эволюция осуществляется оператором эволюции, который экспонента от гамильтониана и времени.

Но вообще да, любой квантовомеханический оператор имеет один и тот же интерфейс:
1) подействовать на данную волновую функцию.
2) посчитать свое среднее на данной волновой функции.
3) посчитать свои собственные значения.

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

S>Вопрос в том, даёт ли ООП тут хоть какое-то преимущество перед не-ООП, или нет.

А зачем тебе ответ на этот вопрос, если рассматриваемое решение итак уже де-факто в ООП-стиле? Даже будь оно выполнено хоть на "плоском" Си. Поздно убегать, уже описали каждую частицу набором св-в и уже вычислили поведение частицы в зависимости от ее мгновенных св-в и внешних усилий.

Или тебя интересует, можно ли тоже самое оформить не в виде ООП? )))
Ес-но можно. Как и любую другую задачуЮ, решенную в ООП-стиле.

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

S>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>А в чем именно проблема, если не считать эффективности? Если определить "+" как инфиксный синоним для INumberArithmetic.Add, то это как-то сильно будет мешать ООПу?
S>В том, что не вполне понятно, чей именно это метод. Известные мне языки, где такие штуки разрешены, используют для них ограничения, делающие их несовместимыми с ООП.

Да в общем нет такой проблемы, "чей именно это метод". По крайней мере, она не обязательно должна быть. Питон вот справляется с такими вещами во вполне ОО-ключе. Строго говоря, код вида "x + y" рассахаривается в "x.__add__ y".

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

S>>В том, что не вполне понятно, чей именно это метод. Известные мне языки, где такие штуки разрешены, используют для них ограничения, делающие их несовместимыми с ООП.

ВВ>Да в общем нет такой проблемы, "чей именно это метод". По крайней мере, она не обязательно должна быть. Питон вот справляется с такими вещами во вполне ОО-ключе. Строго говоря, код вида "x + y" рассахаривается в "x.__add__ y".

+1
В Руби то же самое, ЕМНИП.

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

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

S>>в чистом ООП решение квадратного уравнения

Ф>Так и не смог придумать, куда же в решении квадратного уравнения притулить ООП.
Ф>Разве что само уравнение представить в виде объекта

Ф>class QuadraticEqu
Ф>{
Ф> public QuadraticEqu(CComplex a, CComplex b, CComplex c);
Ф> public CComplex GetD();
Ф> public CComplex GetX();
Ф> public CComplex GetY();
Ф>}

S>>вы устанете читать, и ... понимать

Ф>да, пожалуй тут нужно понимать: поведение и состояние обнаружить не удалось...
Ну как же. Это вы только начали. Теперь давайте попробуем расписать хотя бы GetD() — вы же понимаете, что в православном ООП никаких инфиксных операторов быть не может. У нас только посылка сообщения. И нам ещё надо решить, делать ли Add методом CComplex, или всё-таки CArithmetic, чтобы была возможность реализовывать разные стратегии округления. Непонятно, почему мы взяли CComplex за основу — очень жёсткие зависимости получаются между классами решения.

Непонятно, какое место будет иметь это решение в рамках нашей библиотеки для решения различных типов уравнений. Вот решатель уравнений первого и третьего порядков как будут соотноситься с решателем уравнений второй степени?

Ф>хотя, если коэффициенты, которыми оно задаётся будут сообщениями обмениваться, всё станет интереснее (без веществ такое реализовать сложно)
Ничего сложного. Вполне себе нормальное умственное упражнение. А как вы хотели? Мысленные эксперименты требуют самого дорогого в мире оборудования.

Зато потом можно позадаваться практическими вопросами — вроде "как получить приемлемый синтаксис, сохранив такую же выразительную мощность" и "как получить приемлемую производительность, сохранив такую же гибкость".
И теоретическими, вроде "точно ли ООП является серебряной пулей, или для решения квадратных уравнений есть более удобные техники".

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

J>Еще поле надо пересчитывать, т.е. нечто вроде void update(Environment e, Particles ps).
Вот как раз такие штуки и выдают, скажем так, малопригодность ООП для вычметодов. Потому что непонятно, updateField — это метод у Field, у Environment, или у Particles.

J>Еще надо хранить всю структуру полевой модели (разные типы сеток).
J>Имхо, вполне достаточно для класса, не?

J>>>Ну и про массив я тоже ничего не говорил, я говорил про коллекцию частиц — что, коллекции объектов уже не ООП?
S>>А что у вас там такого особенного с этими коллекциями, что не укладывается в банальный массив? Что именно вы инкапсулируете?
J>Ну, например, их может быть несколько — горячие электроны, холодные электроны, электроны из разных долин...
J>Т.е. будет коллекция коллекций — это уже не совсем массив, правда?
J>А если еще ввести междолинные переходы...

Мне сложно вести осмысленную дискуссию на эту тему, т.к. я плохо себе представляю архитектуру решения. То, что вы рассказываете, может запросто быть структурой массивов, безо всякого ООП. Вопрос опять — есть ли этой "коллекции коллекций" какое-то поведение, которое бы имело смысл делать полиморфным? Есть ли состояние, которое имеет смысл инкапсулировать?
Потому что если "горячие/холодные" электроны отличаются только модулем импульса, то совершенно незачем держать их в отдельных коллекциях. Гораздо надёжнее делить их при помощи предикатов, типа

var hotElectrons = from e in allElectrons where e.getEnergy() >= hotBoundary select e;

J>Именно, удобство — важно, а массив — нет.
Массив — это такая коллекция, которая предоставляет произвольный доступ за O(1). Если у вас нет особенных потребностей по заменяемости таких коллекций, то абстрагировать их никакого смысла нет.

J>Да ничего не мешает, когда используется к месту.
Вот как раз "к месту" оно используется редко. Если мы имеем 1 мегаобъект с жизненным циклом "создать-выполнить-убить", то это нифига не ООП. Это эмуляция процедурного программирования, с бессмысленным реверансом в сторону ООП.
А если мы начинаем лепить ООП ради ООП (а только этим может кончится фанатизм типа присутствующего в этом топике, с попыткой доказать превосходство ООП для вообще нафиг всего), то получается полная ерунда. Лишняя виртуальность, не дающая компилятору оптимизировать, лишний код, мешающий восприятию решения, и т.п.

J>Я ж не призываю к ООП-ному виртуальному джихаду, как некоторые тут, я использую то, что наилучшим образом ложится на задачу (вернее даже не подзадачу) — это может быть и ФП, и ООП, и тупое процедурное, и вообще низкоуровневое когда нужно с симдами врукопашную схватиться.
Вот это правильно. Только "врукопашную" мне не нравится. По идее, надо сосредоточиться на том, где вы "добавляете ценность". Т.е. если вы придумали, что можно получить более точное (или более быстрое) решение путём раскидывания электронов по долинам, или там путём изменения формы сетки, или ещё чего, то именно эта особенность вашего решения должна быть записана в понятной форме.
А то, что вы использовали буст или локи — это несущественные подробности.
Посмотрите на математику — люди столетиями работали над синтаксисом, чтобы сделать решения понятными. Если отобрать у математиков возможность, скажем, сокращённо записывать матричные операции, то банальная линейная алгебра сразу станет непостижимой.

Вот и в вычметодах — лучше всего подойдёт тот язык, где надо писать минимум лишних вещей.

J>Но вообще да, любой квантовомеханический оператор имеет один и тот же интерфейс:
J>1) подействовать на данную волновую функцию.
J>2) посчитать свое среднее на данной волновой функции.
J>3) посчитать свои собственные значения.
Очень странно. А почему вы сделали волновую функцию такой пассивной? С чего это вы взяли что оператор должен считать своё среднее на ней, а не она его среднее на себе?
Вы, кстати, собираетесь пользоваться шредингеровским или гейзенберговским представлением?

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

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

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

S>>>в чистом ООП решение квадратного уравнения

Ф>>Так и не смог придумать, куда же в решении квадратного уравнения притулить ООП.
Ф>>Разве что само уравнение представить в виде объекта

Ф>>class QuadraticEqu
Ф>>{
Ф>> public QuadraticEqu(CComplex a, CComplex b, CComplex c);
Ф>> public CComplex GetD();
Ф>> public CComplex GetX();
Ф>> public CComplex GetY();
Ф>>}

S>>>вы устанете читать, и ... понимать

Ф>>да, пожалуй тут нужно понимать: поведение и состояние обнаружить не удалось...
S>надо решить, делать ли Add методом CComplex, или всё-таки CArithmetic
да, этот метод — та ещё задачка %)

S>Непонятно, почему мы взяли CComplex за основу — очень жёсткие зависимости получаются между классами решения.
Потому что множество вещественных чисел является подмножеством для множества комплексных,
логично было взять самое широкое множество.
И какие-такие зависимости?

S>Вот решатель уравнений первого и третьего порядков...
это дополнительные требования, в ТЗ не было — оплачиваются отдельно

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

S>И теоретическими, вроде "точно ли ООП является серебряной пулей, или для решения квадратных уравнений есть более удобные техники".

Мелковата эта задачка для ООП, ибо моделировать здесь нечего.
Нет никакого смысла моделировать ни числа, ни уравнение — не обладает оно ни состоянием, ни поведением.
С "Вычислителем" было бы интереснее, ведь это вполне его метод:
вычислитель.РешитьУравнение()
или что-нибудь, типа вычислитель.ПосчитатьСреднее()

фикус здесь в том, что вычислителей может быть несколько, и вычислители могут быть разными.

Здравствуйте, Философ, Вы писали:
Ф>И какие-такие зависимости?
Очень простые — допустим, вас перестала устраивать точность даблов. Вы хотите работать в арифметике тройной разрядности.
Как нам воспользоваться готовым решением уравнения, без копипасты?
Или вы просто хотите перетащить ваше решение туда, где повсюду используются кватернионы.
Или хотя бы другая реализация комплексных чисел. Вам недостаточно просто скопировать код решателя — надо тянуть все эти CComplex, или заменять их, и т.п.

S>>Вот решатель уравнений первого и третьего порядков...
Ф>это дополнительные требования, в ТЗ не было — оплачиваются отдельно

Ну так в жизни-то всегда есть дополнительные требования. Что ж это за технология такая, где каждое решение — непохоже на соседнее, и его невозможно повторно использовать?

Ф>Не, мой мозг — слишком большая цена.

Вот и я об этом же.

Ф>Мелковата эта задачка для ООП, ибо моделировать здесь нечего.
А задача обработки particle system слишком велика для ООП.

Ф>Нет никакого смысла моделировать ни числа, ни уравнение — не обладает оно ни состоянием, ни поведением.
Абсолютно согласен. Хотя Кей всё-таки собрал из ~~ледяных кристаллов~~ объектов слово Арифметика.

Ф>С "Вычислителем" было бы интереснее, ведь это вполне его метод:
Ф>вычислитель.РешитьУравнение()
Ага. Смотрели на то, как Bart de Smet прикручивал linq к Z-theorem prover? Вот это — ГОСТ 13345-85.

Ф>фикус здесь в том, что вычислителей может быть несколько, и вычислители могут быть разными.
Особенно этот фикус эффектен там, где вычислители сосуществуют в задаче одновременно.
А если нет — не стоит расчехлять ООП. Пусть пока в сейфе полежит

От:	Mamut	http://dmitriid.com
Дата:	30.07.12 08:20
Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	30.07.12 08:22
Оценка:

От:	Mamut	http://dmitriid.com
Дата:	30.07.12 08:31
Оценка:	+2

От:	Философ	http://vk.com/id10256428
Дата:	30.07.12 08:43
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	30.07.12 08:55
Оценка:

	От:	Воронков Василий
	Дата:	30.07.12 09:03
	Оценка:

От:	jazzer	Skype: enerjazzer
Дата:	30.07.12 09:40
Оценка: