Свойства и их абстракции.

[Munin]

kolas в сообщении #384915 писал(а):

Но есть и непростые случаи, и мне представляется, что методы и язык оод (ооп по русски) помогут установить эти непростые моменты, и возможные направления поиска.

Не помогут.

kolas в сообщении #384915 писал(а):

Повторяюсь, не вмешивайтесь, если не считаете это нужным.

Я считаю нужным. Как вы протрезвеете, если вас не ставить перед суровой реальностью?

kolas в сообщении #384915 писал(а):

Кстати хочу Вас поправить, абстракция не будет иметь два свойства "синее" и "круглое", а будет иметь свойства "цвет" и "форма".

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

kolas в сообщении #384915 писал(а):

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

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

AlexDem в сообщении #384934 писал(а):

У объекта значения всех свойств заданы явно

И это-то в реальном мире идеализация, иногда слишком грубая.

--

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

[Joker_vD]

(Оффтоп)

После того, как я в книге Страуструпа прочитал, что делать класс Круг потомком класса Эллипс не следует, я в ООП разочаровался. И то сказать — зачем мне нужна программа, в которой круги не являются также и эллипсами? Такая программа будет хреново моделировать реальность.

[Munin]

(Оффтоп)

Ага. У Шилдта было перечислено штук 8-10 разных видов отношений IS-A, существующих в реальном мире, и из них примерно половина не ложилась на ООП-шное отношение производного и базового класса. Круг и эллипс как раз один из таких примеров. Точную цитату не приведу, так как книжку давно потерял.

[kolas]

Joker_vD в сообщении #384985 писал(а):

я в книге Страуструпа прочитал

Страуструп, это создатель с++, по мотивам ооп, но он не был создателем ооп. И сейчас есть конкретное правило, что от чего наследуется квадрат от прямоугольника, или наоборот, это уже осмыслили не беспокойтесь.

Munin в сообщении #384945 писал(а):

К тому же в физике и так есть порядок, давно установленный и вполне успешно работающий

Пример в студию.

Munin в сообщении #384945 писал(а):

с ООП вы познакомились (и то неплотно, с его недостатками ещё не знакомы)....

Опять телепатия?

Да я согласен, что проблема аксиоматизации и формализации физики очень непростая, но попытаться стоит.

-- Ср дек 08, 2010 23:10:44 --

Munin в сообщении #384945 писал(а):

Нет, ошибаетесь. В данном случае именно "синее" и "круглое"

А про это обычно говорят - не умеешь, не берись, видно что опыта работы в ооп у вас ноль с минусом.

[AlexDem]

Не знаю, возможно Вам будет интересно глянуть книгу Stephen Wolfram "A New Kind of Science". Я не читал подробно, но то, что посмотрел, что-то не очень впечатлило. Физики его вроде как здорово критикуют.

-- Ср дек 08, 2010 21:40:02 --

Munin в сообщении #384945 писал(а):

AlexDem в сообщении #384934 писал(а):

У объекта значения всех свойств заданы явно

И это-то в реальном мире идеализация, иногда слишком грубая.

Ну, мы тут о моделях пока, а они - идеальные...

[Munin]

kolas в сообщении #385001 писал(а):

Пример в студию.

Закажите себе в студию десятитомник Ландау-Лифшица, и наслаждайтесь.

kolas в сообщении #385001 писал(а):

И сейчас есть конкретное правило, что от чего наследуется квадрат от прямоугольника, или наоборот, это уже осмыслили не беспокойтесь.

Угу, и в каждом языке осмыслили по-своему :-)

kolas в сообщении #385001 писал(а):

Опять телепатия?

Опять всё видно как на ладони по вашим высказываниям. Вы что, думаете, что невежество можно скрыть?

kolas в сообщении #385001 писал(а):

Да я согласен, что проблема аксиоматизации и формализации физики очень непростая, но попытаться стоит.

:-) Ею занимаются лет сто с лишним, и умы побольше вашего. И кстати, насчёт "стоит" тоже есть разные мнения, повесомей вашего.

kolas в сообщении #385001 писал(а):

А про это обычно говорят - не умеешь, не берись, видно что опыта работы в ооп у вас ноль с минусом.

:-) Вы называете опытом работы в ооп неумело построенную абстракцию? Такой "опыт" у меня был, но потом я чему-то научился.

-- 08.12.2010 20:46:01 --

AlexDem в сообщении #385022 писал(а):

Ну, мы тут о моделях пока, а они - идеальные...

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

[Joker_vD]

kolas в сообщении #385001 писал(а):

И сейчас есть конкретное правило, что от чего наследуется квадрат от прямоугольника, или наоборот, это уже осмыслили не беспокойтесь.

Так что же от чего наследуется? квадрат от прямоугольника, прямоугольник от квадрата или они вообще в одну иерархию не вписываются?

[AlexDem]

Munin в сообщении #385026 писал(а):

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

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

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

Пара интересных цитат: "По теореме Мальцева о компактности, теория имеет модель тогда, и только тогда, когда любое конечное число ее аксиом имеет модель". Если я здесь не перевираю, это как раз и будет означать, что если у нас на руках пачка разных теорий, непротиворечивых по отдельности, то существует и объединяющая их непротиворечивая теория. Или: "КМТ берет начало от работ Лёвенгейма (1915) и Скулема (1920), установивших существование моделей любой бесконечной мощности для любой непротиворечивой теории, имеющей бесконечную модель" - например, существуют даже счётные модели теории множеств, в которой мы выражали наши идеальные объекты (это если я там не проврался).

А то ООП какое-то...

[Munin]

AlexDem в сообщении #385104 писал(а):

Пара интересных цитат: "По теореме Мальцева о компактности, теория имеет модель тогда, и только тогда, когда любое конечное число ее аксиом имеет модель". Если я здесь не перевираю, это как раз и будет означать, что если у нас на руках пачка разных теорий, непротиворечивых по отдельности, то существует и объединяющая их непротиворечивая теория.

Нет, увы. Теория A может быть непротиворечива, теория B непротиворечива, а часть аксиом теории A плюс часть аксиом теории B - противоречива.

[AlexDem]

Мне кажется, там ключевое слово - "любое", поэтому если у нас есть A и B, то видимо на подмножестве тех же аксиом есть и C, которая противоречива.

[kolas]

Joker_vD в сообщении #385039 писал(а):

Так что же от чего наследуется? квадрат от прямоугольника, прямоугольник от квадрата

Принцип подстановки Лискоу говорит, что квадрат от прямоугольника.

Munin в сообщении #385131 писал(а):

Нет, увы. Теория A может быть непротиворечива, теория B непротиворечива, а часть аксиом теории A плюс часть аксиом теории B - противоречива.

Здесь и затравка для эксперимента, вот эффект от формализации. А пока в физике существуют титаны, которые и двигают ее в перед, а метода как такового нет.

AlexDem в сообщении #385104 писал(а):

Вообще, есть такая теория моделей.

Намедни общался с товарищем, он как раз математик, специализируется на теории моделей. Проблема все та же, как ее сформулировал Гильберт, проблема аксиоматизации физики. Вообще он много интересного рассказал, например, что логика это и есть феноменология, т.е. какую логику мы применим, такая и будет у нас математика. Так же и в физике, какие измерения мы проделаем, такая модель у нас и получится. По теории моделей получается, что если формула у нас не противоречива, то она - модель.

[Xaositect]

kolas в сообщении #385197 писал(а):

Принцип подстановки Лискоу говорит, что квадрат от прямоугольника.

Это не принцип подстановки говорит, это говорит здравый смысл. А принцип подстановки говорит, что при этом нельзя написать метод, растягивающий фигуру вдоль оси $x$ без выделения нового объекта, если только язык не поддерживает возможность изменения типа объекта на лету, чего он обычно не поддерживает, если он не Common Lisp и не Python, где тип вообще понятие б-м относительное.
Все решения этой проблемы либо приводят квадраты к прямоугольникам явно (поэтому мы всегда разделяем случаи работы с квадратом как с квадратом и с квадратом как с прямоугольником - лишняя работа), либо создют новый объект - результат операции (концептуально лучший вариант, но о нем уже удобнее думать в терминах смешанной функционально-объектной парадигмы, а не чистого ООП), либо являются чисто техническими уловками и извращают иерархию либо перегружают ее лишними классами. Есть еще хорошее решение - двойное наследование: конструкторы и геттеры наследовать как обычно, а модификаторы и сеттеры - снизу вверх, но его даже Common Lisp не поддерживает.

kolas в сообщении #385197 писал(а):

формула у нас не противоречива, то она - модель.

Формула не может быть моделью. Если формула не противоречива, то для нее существует модель.

[AlexDem]

Xaositect в сообщении #385254 писал(а):

Если формула не противоречива, то для нее существует модель.

А разве модель существует для отдельной формулы, а не для теории в целом? Я опираюсь на такое определение:

Цитата:

Интерпретация формальной системы – это метод трактовки формул системы, посредством которого устанавливается взаимосвязь данной формальной системы и содержательной теории, для описания которой она используется. Интерпретация, в которой истинны все выводимые формулы данной системы, есть модель. Если формальная система имеет модель, то она является содержательно непротиворечивой, а следовательно – и формально непротиворечивой.

[Xaositect]

AlexDem в сообщении #385255 писал(а):

А разве модель существует для отдельной формулы, а не для теории в целом? Я опираюсь на такое определение:

Ну мы всегда можем рассмотреть теорию с одной аксиомой. Это уж буквоедство ИМХО.

[kolas]

Xaositect в сообщении #385254 писал(а):

Это не принцип подстановки говорит, это говорит здравый смысл.

А что такое здравый смысл? Чтобы не вникать в этот вопрос и придумали правило подстановки Лискоу, который говорит, что потомок не должен расширять контракт абстракции, а лишь его реализовывать. Например, квадрат - особая реализация прямоугольника. Если мы наследуем квадрат от прямоугольника, то и приводить типы не надо, квадрат будет прямоугольником по умолчанию, если наоборот, то возникнут большие неприятности.
Функциональное программирование с ооп это, на мой взгляд, квинтэссенция современного проектирования ИС. Хотя, я где-то встречал реализацию функциональной парадигмы на java, которая чисто ооп язык, даже без указателей на функцию (делегатов).

-- Чт дек 09, 2010 16:09:49 --

Xaositect в сообщении #385254 писал(а):

Есть еще хорошее решение - двойное наследование....

Это реализуется с помощью делегатов и событий, довольно специфический прием, но и довольно распространенный. Можно вместо него использовать паттерн - шаблонный метод. Вообще странный Вы выбрали термин - двойное наследование, я сначала его понял как множественное наследование, но ниже был описан именно шаблонный метод.