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

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

ООП не требует что бы некоторая модель решения состояла из одного конкретного объекта.

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

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

Токарный станок работает по шаблону, т.е. по некоторой модели будущего изделия.

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

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

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

S>>Очень хорошо. Я надеюсь, вы понимаете, что (int *) — это не ООП?
S>(int *) — это не ООП
S>>Итератор, определённый таким образом, ведёт себя не как объект, а как value-type.
S>однако я не понимаю почему нельзя считать ООП $iterator = $iterator.MoveNext(). Куда делась идентичность объекта после вызова MoveNext()?
Как куда? Исчезла. $iterator стал совсем другим.

S>Что бы убедить меня в том что я от чего-то хочу отказаться, нужно показать как нарушается идентичность иммутабельного объекта после операций над ним. Например на строке. Что она такого теряет после += "foo"?
Она теряет идентичность.

S>Или может строка это не объект? Тогда что отличает объект от необъекта? Ниужели наличие изменяемого состояния?
Конечно же не объект. Строка имеет семантику value-типа.


S>>В случае ООП итератор это объект. Объект в ООП всегда обладает идентичностью. Это означает, что есть способ установить эквивалентность iterator1 до MoveNext и его же после MoveNext.
S>То же самое и с иммутабельными итераторами. После MoveNext ничего с итератором не случается. Он остается самим собой и эквивалентен себе до MoveNext ссылочно и даже структурно (в контрасте с традиционным итератором).

S>И я не вижу в этом проблему. Если объект от необъекта отличает необходимость изменять члены после каждой операции, то это плохой критерий.
Зачем выворачивать наизнанку мои высказывания. Я говорю про возможность выполнять операции, сохраняя identity, даже если они изменяют состояние. А вовсе не про необходимость изменять состояние после каждой операции.

S>Предлагаю оставаться в рамках традиционной реализации ООП, там где объект можно идентифицировать по его "положению".
Ок.

S>Можно все-таки в коде увидеть признак отсутствия identity у immutable "объектов"? Примеры выше как-то это не показывают. В частности сравнение традиционных и иммутабельных итераторов (с вариациями строки с MoveNext) ведут себя одинаково если не копировать и не сравнивать их почленно.
Я же привёл вам примеры. Никаких почленных сравнений не надо.
Вот вам пример со строками, который показывает разницу между объектами и value-типами:

var sb = new StringBuilder("Hello");
var s = "Hello";
var d = new Dictionary<object, string>;
d[sb] = "Ok";
d[s] = "Ok";
sb += "!";
s+= "!";
System.Console.WriteLine(d[sb]);
System.Console.WriteLine(d[s]); // имеем нарушение идентичности

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


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

Если вас не устраивает токарный станок — возьмите сверлильный. Модели отверстия он не содержит.

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

I>ООП не требует что бы некоторая модель решения состояла из одного конкретного объекта.
Зато ООП однозначно требует, чтобы объекты обладали идентичностью, которая ведёт себя вполне определённым образом.

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

I>>ООП не требует что бы некоторая модель решения состояла из одного конкретного объекта.
S>Зато ООП однозначно требует, чтобы объекты обладали идентичностью, которая ведёт себя вполне определённым образом.

Т.е. ты хочешь сказать, что семантика value-type не вписывается в OOP ? Почему ?

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

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

S>>однако я не понимаю почему нельзя считать ООП $iterator = $iterator.MoveNext(). Куда делась идентичность объекта после вызова MoveNext()?
S>Как куда? Исчезла. $iterator стал совсем другим.
извиняюсь, если покажется передергиванием, но по такой логике все что x = x.Clone() — не является ООП?

S>>Что бы убедить меня в том что я от чего-то хочу отказаться, нужно показать как нарушается идентичность иммутабельного объекта после операций над ним. Например на строке. Что она такого теряет после += "foo"?
S>Она теряет идентичность.
Идентичность по вашему это свойство объекта или переменной?

S>>Или может строка это не объект? Тогда что отличает объект от необъекта? Ниужели наличие изменяемого состояния?
S>Конечно же не объект. Строка имеет семантику value-типа.
Это мешает ей быть объектом?

S>>И я не вижу в этом проблему. Если объект от необъекта отличает необходимость изменять члены после каждой операции, то это плохой критерий.
S>Зачем выворачивать наизнанку мои высказывания.
Приношу извинения
S>Я говорю про возможность выполнять операции, сохраняя identity, даже если они изменяют состояние. А вовсе не про необходимость изменять состояние после каждой операции.
Я пытаюсь понять, что же по вашему отличает иммутабельные объекты от мутабельных в плане idintity. И возможно перегибаю. Здесь опять — в чем проявляется сохранение identity, особенно в тех случаях когда они не изменяют состояние?

S>Я же привёл вам примеры. Никаких почленных сравнений не надо.
S>Вот вам пример со строками, который показывает разницу между объектами и value-типами:

отлично. Добавлю пару штрихов.

S>var sb = new StringBuilder("Hello");
S>var s = "Hello";
var s1 = s;
S>var d = new Dictionary<object, string>;
S>d[sb] = "Ok";
S>d[s] = "Ok";
S>sb += "!";
sb = sb.Clone(); // у него нет такого метода, но мог бы быть.
S>s+= "!";
S>System.Console.WriteLine(d[sb]);
System.Console.WriteLine(d[sb]); // а в модифицированном мной примере тут проблема
S>System.Console.WriteLine(d[s]); // имеем нарушение идентичности
System.Console.WriteLine(d[s1]); // по-моему все впорядке с идентичностью объекта по ссылке s1

Вот еще подкину ссылку на Immutable Object

In object-oriented and functional programming, an immutable object is an object whose state cannot be modified after it is created. This is in contrast to a mutable object, which can be modified after it is created.

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

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


I>Т.е. ты хочешь сказать, что семантика value-type не вписывается в OOP ? Почему ?
Потому, что value-type не ведут себя как объекты. У них нет идентичности: все объекты с равным "значением" эквивалентны. Объект — это чёрный ящик, о его внутреннем состоянии мы можем судить только по его поведению. Value-тип — это практически чистое состояние.

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

S>>Как куда? Исчезла. $iterator стал совсем другим.
S>извиняюсь, если покажется передергиванием, но по такой логике все что x = x.Clone() — не является ООП?
Нет. Только то, где мы хотим сохранить идентичность, но не можем.
Вы всё время зачем-то выворачиваете мои утверждения.

S>Идентичность по вашему это свойство объекта или переменной?
Объекта.

S>>Конечно же не объект. Строка имеет семантику value-типа.
S>Это мешает ей быть объектом?
Имхо, да. Вы поймите — не всё, что можно запрограммировать на ОО-языке является реализацией корректной объектной модели. На C# можно, к примеру, сделать чисто статический класс. С точки зрения ООП его не может быть.

S>Я пытаюсь понять, что же по вашему отличает иммутабельные объекты от мутабельных в плане idintity. И возможно перегибаю. Здесь опять — в чем проявляется сохранение identity, особенно в тех случаях когда они не изменяют состояние?
Я привёл примеры. Что именно вам в них непонятно?

S>отлично. Добавлю пару штрихов.
S>

S>>var sb = new StringBuilder("Hello");
S>>var s = "Hello";
S>var s1 = s;
S>>var d = new Dictionary<object, string>;
S>>d[sb] = "Ok";
S>>d[s] = "Ok";
S>>sb += "!";
S>sb = sb.Clone(); // у него нет такого метода, но мог бы быть.
S>>s+= "!";
S>>System.Console.WriteLine(d[sb]);
S>System.Console.WriteLine(d[sb]); // а в модифицированном мной примере тут проблема
S>>System.Console.WriteLine(d[s]); // имеем нарушение идентичности
S>System.Console.WriteLine(d[s1]); // по-моему все впорядке с идентичностью объекта по ссылке s1
Ну и что? Что именно вы хотите продемонстрировать? То, что клонированный объект имеет другую идентити? Ну так это как раз пример на демонстрацию того, что такое идентичность. Показываю ещё раз, в другом разрезе:


[c#]
var sb = new StringBuilder("Hello");
var s = "Hello";
var d = new Dictionary<object, string>;
d[sb] = "Ok";
d[s] = "Ok";
var s2 = "Hello"; // у строки нет .Clone, но если бы был, то результат был бы таким же
var sb2 = new StringBuilder("Hello"); // у StringBuiler нет .Clone, но если бы был, то результат был бы таким же
System.Console.WriteLine(d[sb2]); // несмотря на совпадение содержимого, различить настоящие объекты всегда можно
System.Console.WriteLine(d[s2]); // а вот value-типы с равным значением неразличимы

S>Вот еще подкину ссылку на Immutable Object
S>

S>In object-oriented and functional programming, an immutable object is an object whose state cannot be modified after it is created. This is in contrast to a mutable object, which can be modified after it is created.

S>Там считают что иммутабельный объект это прежде всего объект, правда с некой спецификой, которая не мешает ему быть объектом. Я придерживаюсь этой точки зрения.
Интересная точка зрения. В статье приведен скорее некоторый паттерн, чем строгая математика. Это тоже имеет право на жизнь; но скорее мы говорим о некотором "расширенном" ООП, в котором есть черты ещё чего-то.

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

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

S>>>Как куда? Исчезла. $iterator стал совсем другим.
S>>извиняюсь, если покажется передергиванием, но по такой логике все что x = x.Clone() — не является ООП?
S>Нет. Только то, где мы хотим сохранить идентичность, но не можем.
S>Вы всё время зачем-то выворачиваете мои утверждения.
Я их усугубляю, пытаясь понять момент потери идентичности. Если это нервирует — могу прекратить.

S>>Идентичность по вашему это свойство объекта или переменной?
S>Объекта.
Но разве присвоение ссылки что-то делает с объектом? Буч ссылки называет синонимами. И пишет о путанице, которая возникает при работе с синонимами.

S>>>Конечно же не объект. Строка имеет семантику value-типа.
S>>Это мешает ей быть объектом?
S>Имхо, да.
Буч, например, не отделяет объекты которые копируются по значению. Возможно из-за того что в C++ семантику копирования можно контроллировать.

S>Вы поймите — не всё, что можно запрограммировать на ОО-языке является реализацией корректной объектной модели. На C# можно, к примеру, сделать чисто статический класс. С точки зрения ООП его не может быть.
Я понимаю. Но в корне не согласен с тем что иммутабельный объект противоречит ООП своим существованием.

S>>Я пытаюсь понять, что же по вашему отличает иммутабельные объекты от мутабельных в плане idintity. И возможно перегибаю. Здесь опять — в чем проявляется сохранение identity, особенно в тех случаях когда они не изменяют состояние?
S>Я привёл примеры. Что именно вам в них непонятно?
Мне непонятно в каком месте происходит "потеря" идентичности объекта. Все эти примеры манипулируют ссылками на объекты, хотя должны демонстрировать "потерю" идентичности объекта. По определению идентичность — это такое свойство объекта, которое отличает его от остальных. После присваиваний ссылок объект остается вместе с тем свойством, которое его от остальных отличает.
Вот что пишет Буч про идентичность:

Уникальная идентичность (но не обязательно имя) каждого объекта сохраняется на все время его существования, даже если его внутреннее состояние изменилось.

S>>отлично. Добавлю пару штрихов.
S>>

S>>sb = sb.Clone(); // у него нет такого метода, но мог бы быть.
S>>

S>Ну и что? Что именно вы хотите продемонстрировать? То, что клонированный объект имеет другую идентити? Ну так это как раз пример на демонстрацию того, что такое идентичность.
Нет, я пытался продемонстрировать что нормальный объект (мутабельный) точно так же "теряет" идентичность, как и иммутабельный (с ваших слов). На самом деле верно то что у другого объекта другая идентичность. А у старого — своя, и с ней ничего не случилось. Как и со строками. Единственное что отличает sb от строки в этом примере — то что у строки структурная эквивалентность (ничего общего с идентичностью не имеющая).
Так и иммутабельные объекты — они могут иметь структурную эквивалентность, а могут и нет. Способ по которому производится поиск в словаре завязан именно на эквивалентность объектов.

S>Показываю ещё раз, в другом разрезе:
S>

S>var sb = new StringBuilder("Hello");
S>var s = "Hello";
S>var d = new Dictionary<object, string>;
S>d[sb] = "Ok";
S>d[s] = "Ok";
S>var s2 = "Hello"; // у строки нет .Clone, но если бы был, то результат был бы таким же
S>var sb2 = new StringBuilder("Hello"); // у StringBuiler нет .Clone, но если бы был, то результат был бы таким же
S>System.Console.WriteLine(d[sb2]); // несмотря на совпадение содержимого, различить настоящие объекты всегда можно
S>System.Console.WriteLine(d[s2]); // а вот value-типы с равным значением неразличимы
S>

И этот пример на эквивалентность. Его запросто заставить работать по-другому, если создать словарь с компарером, работающем на ReferenceEquals.

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

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

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

S>Мне непонятно в каком месте происходит "потеря" идентичности объекта. Все эти примеры манипулируют ссылками на объекты, хотя должны демонстрировать "потерю" идентичности объекта.
Идентичность тесно связана со ссылками.
S>По определению идентичность — это такое свойство объекта, которое отличает его от остальных. После присваиваний ссылок объект остается вместе с тем свойством, которое его от остальных отличает.
Это понятно. Но у нас нет средства взаимодействовать с объектом без использования ссылок.
Поэтому все особенности поведения идентичности выявляются через манипуляции со ссылками.
Идентичность означает возможность однозначно и корректно ответить на вопрос "ссылаются ли эти две ссылки на один и тот же объект".

S>Нет, я пытался продемонстрировать что нормальный объект (мутабельный) точно так же "теряет" идентичность, как и иммутабельный (с ваших слов). На самом деле верно то что у другого объекта другая идентичность.
У вас не получилось. Объект идентичность не потерял.
S>Так и иммутабельные объекты — они могут иметь структурную эквивалентность, а могут и нет. Способ по которому производится поиск в словаре завязан именно на эквивалентность объектов.
Конечно. Просто для value-типов ссылочная эквивалентность не имеет смысла. А для настоящих объектов — имеет, поскольку для них ссылка и есть их identity.
S>И этот пример на эквивалентность. Его запросто заставить работать по-другому, если создать словарь с компарером, работающем на ReferenceEquals.
Можно. Но это не имеет физического смысла.


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

S>Вообще говоря — любой объект можно считать иммутабельным в некоторой фазе работы программы. иммутабельные от мутабельных отличаются лишь тем, что для них эта фаза длится всё время жизни. А это не исключено и для мутабельных объектов, т.е. мутабельный объект может все время существования сохранять свое наблюдаемое состояние. Было бы странно если бы такое отличие как длина фазы иммутабельности влияло бы на идентичность объекта и как следствие на "истинную объектность".
Это какая-то гуманитарщина. Поймите, иммутабельность — это не случайно обнаруженное поведение программы. Это набор некоторых гарантий. Нельзя быть "немножко беременной", или "частично мужчиной". Гарантированная иммутабельность позволяет нам делать некоторые полезные преобразования программы, т.к. обеспечивает сохранение полезных инвариантов.
Казуальная иммутабельность — всего лишь досадная помеха: она ограничивает возможности наших действий, но не даёт выигрыша.

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

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

S>Ну пока что я не могу получить изоморфизм между поведением модели, построенной из "настоящих" объектов, и из иммутабельных объектов.
А я наоборот не могу обнаружить значительных отличий.

S>>По определению идентичность — это такое свойство объекта, которое отличает его от остальных. После присваиваний ссылок объект остается вместе с тем свойством, которое его от остальных отличает.
S>Это понятно. Но у нас нет средства взаимодействовать с объектом без использования ссылок.
Хорошо, зафиксируем дискуссию вокруг ссылочных объектов и забудем об объектах-значениях
S>Поэтому все особенности поведения идентичности выявляются через манипуляции со ссылками.
S>Идентичность означает возможность однозначно и корректно ответить на вопрос "ссылаются ли эти две ссылки на один и тот же объект".
Верно. Однозначный способ ответить на этот вопрос в дотнете — ReferenceEquals. Все что делают методы Equals, компареры и прочее, все что используют словари — все это отвечает на вопрос об эквивалентности в том или ином смысле и имеет отношение к идентичности только в том случае, если речь идет о ссылочной эквивалентности.

S>>Нет, я пытался продемонстрировать что нормальный объект (мутабельный) точно так же "теряет" идентичность, как и иммутабельный (с ваших слов). На самом деле верно то что у другого объекта другая идентичность.
S>У вас не получилось. Объект идентичность не потерял.
Естественно не потерял.
S>>Так и иммутабельные объекты — они могут иметь структурную эквивалентность, а могут и нет. Способ по которому производится поиск в словаре завязан именно на эквивалентность объектов.
S>Конечно. Просто для value-типов ссылочная эквивалентность не имеет смысла. А для настоящих объектов — имеет, поскольку для них ссылка и есть их identity.
О value-типах тут в смысле о типах, чьи экземпляры передаются по значению? Или о таких как System.String?
S>>И этот пример на эквивалентность. Его запросто заставить работать по-другому, если создать словарь с компарером, работающем на ReferenceEquals.
S>Можно. Но это не имеет физического смысла.
Это имеет лишь тот смысл, что бы показать что пример работает с эквивалентностью а не идентичностью.

S>>По-моему проще согласиться с тем что идентичность — неотъемлемая характеристика объекта, невзирая на возможность изменять его состояние (фактическое или наблюдаемое).
S>С этим никто не спорит. Вопрос только в том, имеет ли идентичность смысл для иммутабельных объектов.
А почему нет? Иммутабельные объекты — это такие объекты, которые не проявляют изменение состояний внешне. Но это не значит что у них нет изменяемого состояния внутри. Возьмем например System.Lazy<T>. Если забыть о его свойстве IsValueCreated, то этот объект можно считать иммутабельным. Такие объекты отличимы один от другого и смысл их отличать есть. Разница от использования того или другого объекта с внешне одинаковым состоянием налицо, ибо может проявляться во времени вычисления значения, либо даже в сайд-эффектах. Но тему о сайдэффектах при работе иммутабельных объектах я не хотел бы развивать, т.к. к чистым концепциям она не имеет отношения.

S>>Вообще говоря — любой объект можно считать иммутабельным в некоторой фазе работы программы...
S>Это какая-то гуманитарщина. Поймите, иммутабельность — это не случайно обнаруженное поведение программы. Это набор некоторых гарантий. Нельзя быть "немножко беременной", или "частично мужчиной".
Как раз в случае иммутабельности можно быть "немножко беременной". Здесь в главе 3 "Круги ада" приведена классификация вариантов изменяемого состояния. Часть из них можно отнести к иммутабельности безоговорочно. Другие случаи (не все конечно) — условно.
Возьмем например случай "Двухфазный цикл жизни": объект во второй фазе несет тот же самый набор гарантий, что и иммутабельный. Но вот странно, получается что в первой фазе он "нормальный", а потом "не объект"....
"Монотонное изменяемое состояние" — типичный иммутабельный объект. Что отличает его от "нормального" объекта? То что он меняет свое состояние лишь однажды?

S>Гарантированная иммутабельность позволяет нам делать некоторые полезные преобразования программы, т.к. обеспечивает сохранение полезных инвариантов.
S>Казуальная иммутабельность — всего лишь досадная помеха: она ограничивает возможности наших действий, но не даёт выигрыша.
Перечень полезных инвариантов выбирается программистом. Например, хочу я реализовать классический функциональный иммутабельный список на COM с распространенными операциями. Казалось бы, IUnknown противоречит иммутабельности. Но я могу считать такие списки "немножко" иммутабельными не обращая внимания на AddRef/Release. Это мне не помешает применять такие объекты для полезных преобразований. Будет ли у них identity?

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

V>>Токарный станок работает по шаблону, т.е. по некоторой модели будущего изделия.
S>Я ждал этого комментария Конечно же, вы считаете шаблон основной частью станка.

Точнее говоря, шаблон — это не модель целиком, а параметр модели (ее проекция). Сама модель результата — это фигура вращения, и устройство станка полностью соответствует этой модели.

Является ли шаблон основной частью станка? Вопрос странный, и это еще мягко сказано.


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

Создания или применения?


S>Вопросы устройства самого станка, безусловно, вторичны.

Золотые слова. Важна лишь степень подходящести инструмента под задачу.


S>Если вас не устраивает токарный станок — возьмите сверлильный. Модели отверстия он не содержит.

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

Здравствуйте, samius, Вы писали:
S>А я наоборот не могу обнаружить значительных отличий.
Мы смотрим с разных точек зрения.

S>Верно. Однозначный способ ответить на этот вопрос в дотнете — ReferenceEquals. Все что делают методы Equals, компареры и прочее, все что используют словари — все это отвечает на вопрос об эквивалентности в том или ином смысле и имеет отношение к идентичности только в том случае, если речь идет о ссылочной эквивалентности.
Ещё раз: ReferenceEquals — это некая низкоуровневая операция. Уместность её применения в качестве основы для identity зависит от "прикладного" смысла окружающего её контекста.
К примеру, я могу забоксить экземпляр структурного типа, и начать манипулировать ссылками на него в ReferenceEquals. Технически ничто не мешает мне это делать; однако физического смысла в этом нет — оттого, что я получил два экземпляра int 5 в хипе, целые числа не стали обладать идентичностью. И с идентичностью этих двух забоксенных экземпляров я не могу сделать ничего полезного.

S>О value-типах тут в смысле о типах, чьи экземпляры передаются по значению? Или о таких как System.String?
С точки зрения теории, разницы между ними нет. Есть value-семантика, она гарантирует некоторое определённое поведение объектов.

S>Это имеет лишь тот смысл, что бы показать что пример работает с эквивалентностью а не идентичностью.
Пример показывает, что вводить идентичность для типов с value-семантикой не имеет физического смысла.

S>А почему нет? Иммутабельные объекты — это такие объекты, которые не проявляют изменение состояний внешне. Но это не значит что у них нет изменяемого состояния внутри. Возьмем например System.Lazy<T>. Если забыть о его свойстве IsValueCreated, то этот объект можно считать иммутабельным. Такие объекты отличимы один от другого и смысл их отличать есть. Разница от использования того или другого объекта с внешне одинаковым состоянием налицо, ибо может проявляться во времени вычисления значения, либо даже в сайд-эффектах. Но тему о сайдэффектах при работе иммутабельных объектах я не хотел бы развивать, т.к. к чистым концепциям она не имеет отношения.
Да, давайте без сайд-эффектов. Весь смысл оптимизации в программировании — в том, чтобы разделить "полезный" эффект и "побочные" эффекты, а затем заниматься преобразованиями программы, которые сохраняют "полезный" эффект, варьируя "побочные".

S>Как раз в случае иммутабельности можно быть "немножко беременной". Здесь в главе 3 "Круги ада" приведена классификация вариантов изменяемого состояния. Часть из них можно отнести к иммутабельности безоговорочно. Другие случаи (не все конечно) — условно.
S>Возьмем например случай "Двухфазный цикл жизни": объект во второй фазе несет тот же самый набор гарантий, что и иммутабельный. Но вот странно, получается что в первой фазе он "нормальный", а потом "не объект"....
А какие преимущества мы можем из этого извлечь? Ну, кроме облегчения отладки?
Для настоящих immutable объектов мы можем проводить трансформации алгоритма автоматически.
S>"Монотонное изменяемое состояние" — типичный иммутабельный объект. Что отличает его от "нормального" объекта? То что он меняет свое состояние лишь однажды?
Это не совсем изменяемое состояние. Объект своё состояние никак не меняет, это, фактически, SSA-форма (single static assignment).

S>Перечень полезных инвариантов выбирается программистом. Например, хочу я реализовать классический функциональный иммутабельный список на COM с распространенными операциями. Казалось бы, IUnknown противоречит иммутабельности. Но я могу считать такие списки "немножко" иммутабельными не обращая внимания на AddRef/Release. Это мне не помешает применять такие объекты для полезных преобразований. Будет ли у них identity?
В узком смысле — будет. Ведь сама идея AddRef/Release подсказывает, что у нас есть ссылки. В широком — .

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

V>Точнее говоря, шаблон — это не модель целиком, а параметр модели (ее проекция). Сама модель результата — это фигура вращения, и устройство станка полностью соответствует этой модели.
Вы вообще видели токарный станок? В нём самом нет никакой модели изделия. Различные компоненты токарного станка (коих, надо сказать, довольно много) взаимодействуют сложным образом для того, чтобы решить задачу. Можно, конечно, заниматься умственным самоудовлетворениям, придумывая "параметрические модели изделия".

V>Создания или применения?
Создания, создания. Ведь ООП вы предлагаете позиционировать как способ упрощения создания моделей задачи, а вовсе не применения.

V>Золотые слова. Важна лишь степень подходящести инструмента под задачу.
Под решение. То же изделие можно получить, к примеру, методом литья. Токарный станок вряд ли будет подходящим инструментом для такого решения, хотя задача и не изменилась.

V>Конечно же содержит параметрическую модель результата, так же как и токарный.
V>Определяется диаметром сверла.
Ага. А отвёртка, надо полагать, содержит достаточно полную модель шурупа, молоток — гвоздя, ложка — блинного теста. Вам самому не смешно?

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

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

V>>Точнее говоря, шаблон — это не модель целиком, а параметр модели (ее проекция). Сама модель результата — это фигура вращения, и устройство станка полностью соответствует этой модели.
S>Вы вообще видели токарный станок?

Вопрос, надо полагать, риторический?

S>В нём самом нет никакой модели изделия.

Да есть. На токарном станке не выточишь кубик. Про фигуру вращения уже напомнил.
Можно предположить, что модели нету, если шаблон не установлен, и токарь работает "ручками". В этом случае у него модель есть в спеке изделия, подробности которой он ручками переносит на соотв. положение резака.

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

Шаблон изделия — это и есть параметр конечного результата.


V>>Создания или применения?
S>Создания, создания. Ведь ООП вы предлагаете позиционировать как способ упрощения создания моделей задачи, а вовсе не применения.

Ты изначально выразился насчет шаблона. Или же перефразируй исходную фразу, а то разговор переходит в русло слепого с глухим.

Да, ООП есть способ упрощения создания таких моделей, где подразумевается поведение, зависимое от состояния. Например, складская программа моделирует поведение кладовщика, где текущие остатки склада — его инкапсулированное состояние.

V>>Золотые слова. Важна лишь степень подходящести инструмента под задачу.
S>Под решение.

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

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

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

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

Отвертка на самом деле один из участников (акторов/объектов) в общей модели закручивания шурупа по его резьбе. Считай, что отвертка — некий адаптер к интерфейсу шурупа для передачи момента вращения. Ведь есть же и автоматические шуруповерты под тот же интерфейс. Почему ты решил, что один участник модели должен быть моделью другого участника? Участники модели взаимодействуют по некоторым интерфейсам.

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

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


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

Да что за бардак у тебя в голове? Выключатель — это часть цепи. Осуществляет замыкание/размыкание в этой модели и имеет вполне определенные состояния. Заметь, лампочка и источник напряжения не имеют состояния, они являются чистыми ф-иями (если не учитывать нагрев спирали), но выключатель — имеет. Соотв, для модели такой цепи нужен один регистр памяти и пара ф-ий.

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

Я вообще предмета спора не понимаю. Если нам удобно обслуживаемую компьютером целевую автоматизацию чего-либо представить в виде модели, участники которой имеют состояние, то самое удобное на сегодня — это ООП. Если удается построить модель, не требующую состояния — можно брать другие парадигмы. Более того, уже раз 1000 замечал, что даже в моделях, имеющих элементы с состояниями, полно бывает "чистых" ф-ий. И даже в самих алгоритмах вычисления следующего состояния объектов крайне удобно использовать именно чистые ф-ии для обеспечения транзакционности. Вот здесь прошелся подробнее: http://rsdn.ru/forum/philosophy/4171151.1.aspx

Автор: vdimas
Дата: 24.02.11

, начиная от фразы "Ты поменьше функциональщиков слушай".

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

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

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

S>Ещё раз: ReferenceEquals — это некая низкоуровневая операция. Уместность её применения в качестве основы для identity зависит от "прикладного" смысла окружающего её контекста.
S>К примеру, я могу забоксить экземпляр структурного типа, и начать манипулировать ссылками на него в ReferenceEquals. Технически ничто не мешает мне это делать; однако физического смысла в этом нет — оттого, что я получил два экземпляра int 5 в хипе, целые числа не стали обладать идентичностью. И с идентичностью этих двух забоксенных экземпляров я не могу сделать ничего полезного.
Это ничего не доказывает.

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

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

S>>Как раз в случае иммутабельности можно быть "немножко беременной". Здесь в главе 3 "Круги ада" приведена классификация вариантов изменяемого состояния. Часть из них можно отнести к иммутабельности безоговорочно. Другие случаи (не все конечно) — условно.
S>>Возьмем например случай "Двухфазный цикл жизни": объект во второй фазе несет тот же самый набор гарантий, что и иммутабельный. Но вот странно, получается что в первой фазе он "нормальный", а потом "не объект"....
S>А какие преимущества мы можем из этого извлечь? Ну, кроме облегчения отладки?
S>Для настоящих immutable объектов мы можем проводить трансформации алгоритма автоматически.
В неизменяемой фазе — все те же, что и для неизменяемых объектов. В изменяемой фазе — может иметь место императивное построение/конфигурация обеъкта.
S>>"Монотонное изменяемое состояние" — типичный иммутабельный объект. Что отличает его от "нормального" объекта? То что он меняет свое состояние лишь однажды?
S>Это не совсем изменяемое состояние. Объект своё состояние никак не меняет, это, фактически, SSA-форма (single static assignment).
Никакого отношения к SSA, имхо. Типичный Lazy<T>.

S>>Перечень полезных инвариантов выбирается программистом. Например, хочу я реализовать классический функциональный иммутабельный список на COM с распространенными операциями. Казалось бы, IUnknown противоречит иммутабельности. Но я могу считать такие списки "немножко" иммутабельными не обращая внимания на AddRef/Release. Это мне не помешает применять такие объекты для полезных преобразований. Будет ли у них identity?
S>В узком смысле — будет. Ведь сама идея AddRef/Release подсказывает, что у нас есть ссылки. В широком — .

Предлагаю закругляться. Сам я не вижу смысл судить об "объектности" объекта по наличию физического смысла идентичности этого объекта. Жаль, если мне не удалось склонить к своему мнению, или хотя бы посеять сомнения в ценности деления на объекты и необъекты по смыслу идентичности. В любом случае спасибо за дискуссию.

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

S>Имхо, да. Вы поймите — не всё, что можно запрограммировать на ОО-языке является реализацией корректной объектной модели. На C# можно, к примеру, сделать чисто статический класс. С точки зрения ООП его не может быть.

Может. Это аналог объекта-синглтона. Разве что чуть упростили интерфейс к нему.

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

V>Вопрос, надо полагать, риторический?
Ага.
V>Да есть. На токарном станке не выточишь кубик. Про фигуру вращения уже напомнил.
Не стоит все ограничения принимать за модель.
V>Можно предположить, что модели нету, если шаблон не установлен, и токарь работает "ручками". В этом случае у него модель есть в спеке изделия, подробности которой он ручками переносит на соотв. положение резака.
Совершенно верно. В спеке (т.е. в чертеже) модель есть. В инструменте — нету.

V>Ты изначально выразился насчет шаблона. Или же перефразируй исходную фразу, а то разговор переходит в русло слепого с глухим.
Я изначально выразился насчёт токарного станка.

V>Да, ООП есть способ упрощения создания таких моделей, где подразумевается поведение, зависимое от состояния. Например, складская программа моделирует поведение кладовщика, где текущие остатки склада — его инкапсулированное состояние.

Что характерно, для складских программ чистое ООП почему-то плохо применимо. Туда идеально подходит реляционная алгебра — поскольку инкапсулированное состояние мало кого интересует. Интересует как раз наоборот — возможность получать различные проекции одного и того же состояния.
Предлагаю поверить мне на слово — я занимался моделированием склада при помощи ООП на профессиональной основе. Ну там, объект Склад, объект Партия, объект ЕдиницаИзмерения.
Результат вкратце: ООП сосёт. Преимуществ никаких, недостатков и ограничений — масса.
Поэтому в реальной складской программе, написанной на ОО-языке, объекты моделируют исключительно компоненты решения — всякие SqlStatement, DBConnection, и прочее.
V>Логично, именно поэтому есть несколько парадигм программирования.
Ну, в общем смысле да. Но я подчеркну — то, что от складской программы требуется давать остатки по партиям/видам товара/складам/поставщикам не означает неприменимости для неё ООП. В конце концов, 99% современных складских программ написаны таки на ОО-языках, и кода за пределами классов там совсем мало. Просто ООП в них применяется не для моделирования задачи или какого-то там "реального мира", а для моделирования решения этой задачи.

V>Тонкость твоего примера в том, что для отлития фигур вращения таки используют токарный станок... для создания прототипа. А последующее литье — это суть копирование прототипа.
Прототип может быть получен чем угодно. В том числе и трёхмерным принтером. Тонкость моего примера в том, что сначала выбирают некоторый путь решения. А потом вот это вот абстрактное решение воплощают в некоторой конкретной парадигме. К примеру, я могу реализовать умножение матриц в виде семейства stateless функций, которые оперируют над immutable данными. А могу — в виде набора stateful объектов, которые обмениваются сообщениями. Уместность того или иного подхода зависит исключительно от того, каким должно получиться полное решение. А вовсе не от задачи. Возможно, в данной задаче вообще можно обойтись без умножения матриц.


V>Отвертка на самом деле один из участников (акторов/объектов) в общей модели закручивания шурупа по его резьбе. Считай, что отвертка — некий адаптер к интерфейсу шурупа для передачи момента вращения. Ведь есть же и автоматические шуруповерты под тот же интерфейс. Почему ты решил, что один участник модели должен быть моделью другого участника?

Это не я решил — это решили те, кто убеждает в том, что основная роль ООП — в моделировании задачи.
Программа точно так же — всего лишь один из участников в общей модели чего-то там. Например, отслеживания отгрузок по складу. Физический склад — другой участник этой модели. И совершенно непонятно, почему один участник должен содержать в себе модель другого.

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

V>Ну дык, почему нет? В чистом ФП при численном интегрировании мы бы получали иммутабельные "сшапшоты" динамического процесса, в ООП мы эти же наборы чисел храним явным образом в тех же самых ячейках памяти, что и на предыдущем шаге, вот и все отличие.
Ну как же — вы очень упрощаете ООП. Какие ещё ячейки памяти? ООП расположено на значительно более высоком уровне абстракции. Вполне возможно, что ФП-компилятор решит повторно использовать те же ячейки памяти, поскольку иммутабельность — это свойство исходной программы, а не ячейки памяти.
В принципе, я могу поверить, хотя и с оговорками, в то, что для моделирования моста удобно будет применять ООП-шные объекты, которые соответствуют его деталям.
А вот для моделирования работы датчика скорости потока на эффекте Холла вы какие объекты собираетесь описывать? Вода, МагнитноеПоле, Датчик?

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

V>Да что за бардак у тебя в голове?
У меня нет никакого бардака.
V>Выключатель — это часть цепи. Осуществляет замыкание/размыкание в этой модели и имеет вполне определенные состояния. Заметь, лампочка и источник напряжения не имеют состояния, они являются чистыми ф-иями (если не учитывать нагрев спирали), но выключатель — имеет. Соотв, для модели такой цепи нужен один регистр памяти и пара ф-ий.
Нам не нужна модель цепи. Выключатель прекрасно работает безо всякой модели. Это была аналогия.
Вот у нас стоит задача управления освещением в комнате. С этим справляется выключатель. В нём, очевидно, модели лампочки нет. Можете на досуге разобрать выключатель и поискать там модель лампочки.
Далее, переходим к более сложной задаче — управление яркостью света. Появляется диммер. Он устроен сложнее, чем выключатель, но модели лампочки в нём по-прежнему нет.
Теперь сделаем управление яркостью света с обратной связью — чтобы ночью свет автоматически включался, а днём выключался. В цепи появятся фотоэлементы, и прочая электроника. Способов решить эту задачу существенно больше, но и в них никакой модели лампочки и окружающей среды по прежнему нет. Есть модель некоего устройства "управляющий элемент".
Если мы захотим усложнять задачу, мы рано или поздно заколебаемся и перейдём в цифровой мир, в котором есть абстрактная железка "микроконтроллер", которая управляет чем угодно. И есть программная часть решения задачи. Так вот — совершенно непонятно, зачем в этот момент внезапно в программной части решения возникнет какая-то модель задачи, которая до сих пор была не нужна. Я не говорю, что там неприменимо ООП. Нет, ООП там очень даже может быть применимо. Но только объекта "лампочка" там, скорее всего, не будет. Вот программный аналог объекта "выключатель" там запросто может оказаться — тот самый регистр.
А тем временем укушенные ООП люди на полном серъёзе предлагают писать программу, в которой будут объекты Лампочка и Фотодатчик.

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

V>Я вообще предмета спора не понимаю. Если нам удобно обслуживаемую компьютером целевую автоматизацию чего-либо представить в виде модели, участники которой имеют состояние, то самое удобное на сегодня — это ООП.
Совершенно верно. Только эта модель будет, грубо говоря, моделью идеального устройства, решающего целевую задачу. А не моделью объектов, из которых состоит предметная область.
Именно поэтому в реальных программах полно объектов типа Window, Control, Connection, и прочих, которые никакого отношения к предметной области не имеют.
Что очень сильно отличается от того, что преподают на курсах "ООП за 21 день".

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

S>value-семантика гарантирует копирование при присваивании и передаче в качестве аргумента. То что она имеет одинаковое поведение со ссылками на иммутабельные объекты, не делает их неразличаемыми.
Нет. Объекты класса String в .Net имеют value-семантику. Очевидно, никаких гарантий копирования эта семантика не даёт. Value-семантика гарантирует взаимозаменяемость объектов с одинаковым состоянием, ни больше и ни меньше. Вы путаете математическую семантику "значение" с реализацией value-типов в конкретной платформе.

S>Что значит вводить? Она есть. Пользоваться ей мало смысла — возможно.
Её нету.
S>А вообще, в ООП паттернах у объектов есть куча ролей, где идентичность не имеет физического смысла. Это делает их не объектами?
Вопрос на миллион долларов.

S>В неизменяемой фазе — все те же, что и для неизменяемых объектов. В изменяемой фазе — может иметь место императивное построение/конфигурация обеъкта.
S>>>"Монотонное изменяемое состояние" — типичный иммутабельный объект. Что отличает его от "нормального" объекта? То что он меняет свое состояние лишь однажды?
S>>Это не совсем изменяемое состояние. Объект своё состояние никак не меняет, это, фактически, SSA-форма (single static assignment).
S>Никакого отношения к SSA, имхо. Типичный Lazy<T>.
Lazy<T>, по приведённой классификации, меняет своё состояние дважды. Сначала — при инициализации, второй раз — при первом обращении.

S>Предлагаю закругляться. Сам я не вижу смысл судить об "объектности" объекта по наличию физического смысла идентичности этого объекта. Жаль, если мне не удалось склонить к своему мнению, или хотя бы посеять сомнения в ценности деления на объекты и необъекты по смыслу идентичности. В любом случае спасибо за дискуссию.
Да, я получил много поводов подумать. на jot.fm была серия статей про математические модели, стоящие за ООП. Надо бы перечитать. А то среди народа упорно бытует мнение о том, что ООП, в отличие от ФП, не формализовано

Вообще, в программировании сейчас наблюдается значительный разрыв между теорией и практикой. Я не знаю, почему он происходит, но выглядит всё просто ужасно. Детям сначала рассказывают про высокое, а потом они приходят работать, а там ужосчто. И про этот ужосчто никаких вменяемых книг уже нету, приходится дотумкивать своим умом. Не всегда успешно. Тем более, что существуют упорно тиражируемые заблуждения, которые только отвлекают от сути вещей. Я уже упоминал про эпический спор об уровнях изоляции в РСУБД? Мне даже ссылки на Бернстайна приводили. Вот только оппа в том, что Бернстайн ни в одном месте про уровни изоляции явно не пишет. Как будто их нет. А они — есть. И вот люди начинают изобретать такие объяснения этим уровням изоляции, что шуба заворачивается. Включая искреннюю веру в то, что не все шедулеры транзакций обязаны обеспечивать сериализуемость.
И вот с ООП — то же самое.