Здравствуйте, samius, Вы писали:
G>>В этом и заключается свойство identity. При этом если a == b, то a.Equals(b) == true. S>Тут мы получили равенство ссылок, а не отличие в поведении объектов.
Это и есть идентичность в отличие от эквивалентности.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, samius, Вы писали:
G>>>В этом и заключается свойство identity. При этом если a == b, то a.Equals(b) == true. S>>Тут мы получили равенство ссылок, а не отличие в поведении объектов. G>Это и есть идентичность в отличие от эквивалентности.
Не согласен.
Сравнение ссылок (при отсутствии оператора сравнения) дает нам ссылочную эквивалентность; вызов Equals дает нам эквивалентность по умолчанию; Comparison<T> дает нам любую другую эквивалентность. В то время как идентичность обусловлена идентичным поведением.
Объекты a и b не идентичны, т.к. по разному реагируют на x.Equals(b). Но их можно сделать таковыми, переопределив Equals соответствующим образом.
L>>Разве 2 объекта с одинаковым контрактом и без состояния можно как-то отличить?
два объекта с одинаковым поведением и без состояния отличить невозможно. Но можно отличить ссылки на них. Это не одно и то же, т.к. адрес объекта или ссылка на объект — это не внутренний атрибут объекта и он не имеет отношения к поведению объекта в общем случае.
Верно то, что получив положительный результат сравнения ссылок на равенство, можно делать вывод об идентичности объектов. Обратное не верно (из идентичности поведения равенство ссылок не вытекает).
Наоборот, получив отрицательный результат сравнения ссылок на равенство, можно делать вывод лишь о том что мы имеем разные экземпляры. Но идентичность этим самым не опровергнута.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, samius, Вы писали:
G>>>>В этом и заключается свойство identity. При этом если a == b, то a.Equals(b) == true. S>>>Тут мы получили равенство ссылок, а не отличие в поведении объектов. G>>Это и есть идентичность в отличие от эквивалентности. S>Не согласен. S>Сравнение ссылок (при отсутствии оператора сравнения) дает нам ссылочную эквивалентность; вызов Equals дает нам эквивалентность по умолчанию; Comparison<T> дает нам любую другую эквивалентность. В то время как идентичность обусловлена идентичным поведением. S>Объекты a и b не идентичны, т.к. по разному реагируют на x.Equals(b). Но их можно сделать таковыми, переопределив Equals соответствующим образом.
Ссылочная эквивалентность — реализация идентифицируемости (не идентичности, в данном случае слово наталкивает тебя на неверные размышления) в большинстве языков. Вот идентифицируемость в БД осуществляется по ключу, из за этого и возникают проблемы объектно-реляционного отображения.
S>два объекта с одинаковым поведением и без состояния отличить невозможно. Но можно отличить ссылки на них.
Что значит отличить?
S>Это не одно и то же, т.к. адрес объекта или ссылка на объект — это не внутренний атрибут объекта и он не имеет отношения к поведению объекта в общем случае.
Да ну? Покажи как в C# получить ссылку отдельно от самого объекта?
S>Верно то, что получив положительный результат сравнения ссылок на равенство, можно делать вывод об идентичности объектов. Обратное не верно (из идентичности поведения равенство ссылок не вытекает). S>Наоборот, получив отрицательный результат сравнения ссылок на равенство, можно делать вывод лишь о том что мы имеем разные экземпляры. Но идентичность этим самым не опровергнута.
Еще раз, не идентичность, а идентифицируемость. В C# для объектов reference-типов идентифицируемость по ссылке.
Метафора identity — паспорт. Если два человека выглядят и ведут себя одинаково, но у них разные паспорта, то это разные люди. Если один паспорт — то это один человек.
В "мире" SOA вместо "паспорта", используется "адрес проживания". Что скрывается за этим адресом и кто получает сообщения снаружи не видно.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, samius, Вы писали:
S>>Сравнение ссылок (при отсутствии оператора сравнения) дает нам ссылочную эквивалентность; вызов Equals дает нам эквивалентность по умолчанию; Comparison<T> дает нам любую другую эквивалентность. В то время как идентичность обусловлена идентичным поведением. S>>Объекты a и b не идентичны, т.к. по разному реагируют на x.Equals(b). Но их можно сделать таковыми, переопределив Equals соответствующим образом. G>Ссылочная эквивалентность — реализация идентифицируемости (не идентичности, в данном случае слово наталкивает тебя наневерные размышления) в большинстве языков.
Я не делаю различий между этими словами. Говоря об идентичности я подразумеваю identity. Пусть это будет идентифицируемость.
G>Вот идентифицируемость в БД осуществляется по ключу, из за этого и возникают проблемы объектно-реляционного отображения.
Верно, а в ООП объекты идентифицируются по поведению.
S>>два объекта с одинаковым поведением и без состояния отличить невозможно. Но можно отличить ссылки на них. G>Что значит отличить?
В случае объектов — обнаружить отличное поведение. В случае ссылок — обнаружить равенство или неравенство их.
S>>Это не одно и то же, т.к. адрес объекта или ссылка на объект — это не внутренний атрибут объекта и он не имеет отношения к поведению объекта в общем случае. G>Да ну? Покажи как в C# получить ссылку отдельно от самого объекта?
Не получить, но это не делает ссылку атрибутом объекта. Тем более, что объект без ссылки в дотнете существовать может (недетерминированное время).
S>>Наоборот, получив отрицательный результат сравнения ссылок на равенство, можно делать вывод лишь о том что мы имеем разные экземпляры. Но идентичность этим самым не опровергнута. G>Еще раз, не идентичность, а идентифицируемость. В C# для объектов reference-типов идентифицируемость по ссылке.
Identity allows comparison of references. Two references can be compared whether they are equal or not. Due to the identity property, this comparison has special properties. If the comparison of references indicates that the references are equal, then it's clear that the two objects pointed by the references are the same object. If the references do not compare equal, then it's not necessarily guaranteed that the identity of the objects behind those references is different.The object identity of two objects of the same type is the same, if every change to either object is also a change to the other object.
(http://en.wikipedia.org/wiki/Identity_%28object-oriented_programming%29)
т.е. согласно выделенному — из отсутствия равенства ссылок не следует различная идентифицируемость. В том числе в C#.
G>Метафора identity — паспорт. Если два человека выглядят и ведут себя одинаково, но у них разные паспорта, то это разные люди. Если один паспорт — то это один человек.
Если identity принимается за паспорт, то при разных паспортах мы получим разное identity. Из этого следует что экземпляры разные. Верно. Но из того что паспорта одинаковы не будет следовать что экземпляр один.
Это как если в дотнете взять две строки с одинаковым содержимым (пусть будут получены разным способом, что бы избежать скидки на интернирование). Поведение одинаково. о них говорят same identity, даже если ссылки будут отличаться.
G>В "мире" SOA вместо "паспорта", используется "адрес проживания". Что скрывается за этим адресом и кто получает сообщения снаружи не видно.
Это не имеет значения, пока сервис не начнет вести себя в зависимости от накопленной в своем внутреннем состоянии истории. А пока поведение конкретных получателей за этим адресом неотличимо, какая разница, кто из них получит сообщение?
Даже если история копится в БД, но различные экземпляры сервиса реагируют на нее одинаковым образом (шарят это состояние), это позволяет говорить об их same identity (см выделенное курсивом в цитате с википедии).
Здравствуйте, samius, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Вот идентифицируемость в БД осуществляется по ключу, из за этого и возникают проблемы объектно-реляционного отображения. S>Верно, а в ООП объекты идентифицируются по поведению.
Нет, идентифицируемость объекта ортогонально поведению. Фактически возможность узнать являются ли два объекта идентичными (не путать с эквивалентностью). Свойство идентичности нельзя нарушить, в отличие от эквивалентности, которое может зависеть от состояния.
S>>>Это не одно и то же, т.к. адрес объекта или ссылка на объект — это не внутренний атрибут объекта и он не имеет отношения к поведению объекта в общем случае. G>>Да ну? Покажи как в C# получить ссылку отдельно от самого объекта? S>Не получить, но это не делает ссылку атрибутом объекта. Тем более, что объект без ссылки в дотнете существовать может (недетерминированное время).
Нет, может существовать память объекта, но не сам объект, потому что объект — identity+поведение. Если на объект нет ссылок, то фактически у него нет ни identity и нету способов получить поведение.
Не стоит путать концептуальные вещи с деталями реализации. Ведь в .NET value-типы наследуются от Object, но это не значит что для каждого value-типа есть указатель на VMT.
S>>>Наоборот, получив отрицательный результат сравнения ссылок на равенство, можно делать вывод лишь о том что мы имеем разные экземпляры. Но идентичность этим самым не опровергнута. G>>Еще раз, не идентичность, а идентифицируемость. В C# для объектов reference-типов идентифицируемость по ссылке. S>
S>Identity allows comparison of references. Two references can be compared whether they are equal or not. Due to the identity property, this comparison has special properties. If the comparison of references indicates that the references are equal, then it's clear that the two objects pointed by the references are the same object. If the references do not compare equal, then it's not necessarily guaranteed that the identity of the objects behind those references is different.The object identity of two objects of the same type is the same, if every change to either object is also a change to the other object.
S>(http://en.wikipedia.org/wiki/Identity_%28object-oriented_programming%29)
S>т.е. согласно выделенному — из отсутствия равенства ссылок не следует различная идентифицируемость.
Да, потому что это деталь реализации.
S>В том числе в C#.
Нет, ты не можешь в C# получить пару объектов reference типа для которых object.ReferenceEquals(a,b) == true, но a.Equals(b) == false, если нормально реализован Equals. Более того гайдлайн требует чтобы реализация equals была такова что идентичные объекты будут эквивалентны. На это и опирается ООП.
G>>Метафора identity — паспорт. Если два человека выглядят и ведут себя одинаково, но у них разные паспорта, то это разные люди. Если один паспорт — то это один человек. S>Если identity принимается за паспорт, то при разных паспортах мы получим разное identity. Из этого следует что экземпляры разные. Верно. Но из того что паспорта одинаковы не будет следовать что экземпляр один.
Ну возьми SSN\СНИЛС, он не меняется.
S>Это как если в дотнете взять две строки с одинаковым содержимым (пусть будут получены разным способом, что бы избежать скидки на интернирование). Поведение одинаково. о них говорят same identity, даже если ссылки будут отличаться.
Где говорят? Ссылку дай что ли. То что на equal string говорят same identity не делает чести тому кто говорит. И уж точно никак не влияет на соотношение identity и equal в ООП.
G>>В "мире" SOA вместо "паспорта", используется "адрес проживания". Что скрывается за этим адресом и кто получает сообщения снаружи не видно. S>Это не имеет значения, пока сервис не начнет вести себя в зависимости от накопленной в своем внутреннем состоянии истории. А пока поведение конкретных получателей за этим адресом неотличимо, какая разница, кто из них получит сообщение? S>Даже если история копится в БД, но различные экземпляры сервиса реагируют на нее одинаковым образом (шарят это состояние), это позволяет говорить об их same identity (см выделенное курсивом в цитате с википедии).
Нет, ты опять подменяешь понятия. Ты говоришь об эквивалентности (взаимозаменяемости) сервисов, а не об идентичности. Хотя тут ты даже доказать ничего не сможешь, потому что нарываешь на проблему тотальности.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, samius, Вы писали:
S>>Верно, а в ООП объекты идентифицируются по поведению. G>Нет, идентифицируемость объекта ортогонально поведению. Фактически возможность узнать являются ли два объекта идентичными (не путать с эквивалентностью). Свойство идентичности нельзя нарушить, в отличие от эквивалентности, которое может зависеть от состояния.
Если ты под идентичностью подразумеваешь возможность сказать что a1 и a2 это в точности тот же самый объект, занимающий ту же самую память, то identity с википедии точно не про это.
S>>Не получить, но это не делает ссылку атрибутом объекта. Тем более, что объект без ссылки в дотнете существовать может (недетерминированное время). G>Нет, может существовать память объекта, но не сам объект, потому что объект — identity+поведение. Если на объект нет ссылок, то фактически у него нет ни identity и нету способов получить поведение. G>Не стоит путать концептуальные вещи с деталями реализации. Ведь в .NET value-типы наследуются от Object, но это не значит что для каждого value-типа есть указатель на VMT.
Надо сперва разобраться с тем, что подразумевать под identity, способ идентифицировать объект с точностью до экземпляра, либо с точностью до поведения. Вики говорит об поведении, допуская множество объектов с same identity. Есть более компетентные источники с противоположным мнением?
S>>
S>>т.е. согласно выделенному — из отсутствия равенства ссылок не следует различная идентифицируемость. G>Да, потому что это деталь реализации.
Это общая концепция.
S>>В том числе в C#. G>Нет, ты не можешь в C# получить пару объектов reference типа для которых object.ReferenceEquals(a,b) == true, но a.Equals(b) == false, если нормально реализован Equals. Более того гайдлайн требует чтобы реализация equals была такова что идентичные объекты будут эквивалентны. На это и опирается ООП.
ООП опирается на понятие identity. А Equals — это особенности реализации эквивалентности в дотнете.
Качество реализации Equals влияет на работу с этим объектом средствами фреймворка, но не влияет на концептуальные качества объекта, не относящиеся к платформе.
S>>Если identity принимается за паспорт, то при разных паспортах мы получим разное identity. Из этого следует что экземпляры разные. Верно. Но из того что паспорта одинаковы не будет следовать что экземпляр один. G>Ну возьми SSN\СНИЛС, он не меняется.
Не имеет смысла обсуждать без согласования термина identity.
S>>Это как если в дотнете взять две строки с одинаковым содержимым (пусть будут получены разным способом, что бы избежать скидки на интернирование). Поведение одинаково. о них говорят same identity, даже если ссылки будут отличаться. G>Где говорят? Ссылку дай что ли. То что на equal string говорят same identity не делает чести тому кто говорит.
Не знаю, где говорят, но я сделал такой вывод на основании статьи в вики. G>И уж точно никак не влияет на соотношение identity и equal в ООП.
не влияет, т.к. между ними мало общего, учитывая то, что эквивалентность — понятие навесное. Никто не может мне запретить считать эквивалентными людей с одной фамилией при различном их поведении.
S>>Это не имеет значения, пока сервис не начнет вести себя в зависимости от накопленной в своем внутреннем состоянии истории. А пока поведение конкретных получателей за этим адресом неотличимо, какая разница, кто из них получит сообщение? S>>Даже если история копится в БД, но различные экземпляры сервиса реагируют на нее одинаковым образом (шарят это состояние), это позволяет говорить об их same identity (см выделенное курсивом в цитате с википедии). G>Нет, ты опять подменяешь понятия. Ты говоришь об эквивалентности (взаимозаменяемости) сервисов, а не об идентичности. Хотя тут ты даже доказать ничего не сможешь, потому что нарываешь на проблему тотальности.
Я говорю об identity из OOP. Или как минимум о том, что написано в википедии.
Здравствуйте, samius, Вы писали:
S>Но вместо того, что бы отделять тру-ООП от не тру-ООП, предлагаю сфокусировать внимание на том, что на самом деле мы тут обсуждаем лишь один аспект ООП, который даже напрямую нельзя отнести к ООП, т.к. непонятно откуда он взялся вообще. Это способ определения местонахождения метода по данным, которыми он пользуется.
Это один из GRASP-паттернов — Information Expert. Упоминается в книжке Лармана.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, samius, Вы писали:
S>>Но вместо того, что бы отделять тру-ООП от не тру-ООП, предлагаю сфокусировать внимание на том, что на самом деле мы тут обсуждаем лишь один аспект ООП, который даже напрямую нельзя отнести к ООП, т.к. непонятно откуда он взялся вообще. Это способ определения местонахождения метода по данным, которыми он пользуется.
L>Это один из GRASP-паттернов — Information Expert. Упоминается в книжке Лармана.
Order как набор OrderLine-ов в качестве Information Expert ничем не лучше чем набор действующих скидок.
Здравствуйте, samius, Вы писали:
S>>>Но вместо того, что бы отделять тру-ООП от не тру-ООП, предлагаю сфокусировать внимание на том, что на самом деле мы тут обсуждаем лишь один аспект ООП, который даже напрямую нельзя отнести к ООП, т.к. непонятно откуда он взялся вообще. Это способ определения местонахождения метода по данным, которыми он пользуется.
L>>Это один из GRASP-паттернов — Information Expert. Упоминается в книжке Лармана. S>Order как набор OrderLine-ов в качестве Information Expert ничем не лучше чем набор действующих скидок.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, samius, Вы писали:
S>>>>Но вместо того, что бы отделять тру-ООП от не тру-ООП, предлагаю сфокусировать внимание на том, что на самом деле мы тут обсуждаем лишь один аспект ООП, который даже напрямую нельзя отнести к ООП, т.к. непонятно откуда он взялся вообще. Это способ определения местонахождения метода по данным, которыми он пользуется.
L>>>Это один из GRASP-паттернов — Information Expert. Упоминается в книжке Лармана. S>>Order как набор OrderLine-ов в качестве Information Expert ничем не лучше чем набор действующих скидок.
L>Сорри, не распарсил.
Я о том что в качестве Information Expert можно было выбрать набор действующих скидок, а не набор продуктов. Т.е. паттерн Information Expert нам опять таки не дает однозначности. Согласно этому паттерну у нас ответственность можно однозначно назначить Order-у только в случае полного отсутствия системы скидок. И то, имхо, такое действие будет неправильным. Пусть ордер предоставит набор позиций, а сложить их можно левой пяткой по месту использования суммы.
Здравствуйте, samius, Вы писали:
L>>Сорри, не распарсил.
S>Я о том что в качестве Information Expert можно было выбрать набор действующих скидок, а не набор продуктов.
Да я как бы и не спорю. Я отвечал исключительно на вопрос "непонятно откуда он взялся вообще".
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, samius, Вы писали:
S>>Я о том что в качестве Information Expert можно было выбрать набор действующих скидок, а не набор продуктов.
L>Да я как бы и не спорю. Я отвечал исключительно на вопрос "непонятно откуда он взялся вообще".
Да, я понял.
Здравствуйте, -VaS-, Вы писали:
VS>Вопрос с подвохом Нормальный OOD — как минимум, соблюдение SOLID.
SOLID, он тоже не без вопросов. В частности, S, по большому счету, уже содержит I, О надо применять очень аккуратно, а D штука довольно специфическая и имеющая нехилые побочные эффекты. Так что я бы от SOLID только S и L оставил в качестве обязательных.
... << RSDN@Home 1.2.0 alpha 5 rev. 1530 on Windows 7 6.1.7601.65536>>
Здравствуйте, Lloyd, Вы писали:
L>Вот я чем дольше работаю, тем меньше вижу ентое ООП. L>Более того, очень многими неглупыми людьми ставится под сомнение его полезность. Все народ от того же насквозь оопшного DDD плюется, а вот вполне из себя процедурный anemic model вызывает массу положительных эмоций.
Чем больше работаю, тем больше вижу ООП. Если раньше в основном использовал процедурный подход, в котором одни функции вызывают другие, что образует между ними жесткую связь, и количество этих связей плодится в геометрической прогрессии, что неминуемо сказывается на поддерживаемости и скорости развития проекта, то теперь все разложено по объектам, каждый из которых:
1. Имеет свой определенный контракт.
2. Делает свою конкретную работу и ни байта больше, все посторонние действия делегируются соотв. объектам.
На выходе имеем комбинацию этих объектов, как комбинация рабочих на конвеере, каждый из которых делает какое-то небольшое дело, а на выходе — готовый продукт. Захотели — уволили кого-то, поставили людей лучшей квалификации, захотели — поменяли схему сборки узлов на более оптимальную, захотели — выпустили рестайлинговую версию, заменив определенные узлы на более совершенные. Процесс гибок и легко поддается изменению, не влияя на другие компоненты. При этом работу любой части можно проверить автономно, т.к. у нее нет никакой зависимости ни от кого.
Тогда как как процедурный подход сродни ручному управлению, что неэффективно и должно быть забыто как страшный сон.
Здравствуйте, michael_isu, Вы писали:
_>Тогда как как процедурный подход сродни ручному управлению, что неэффективно и должно быть забыто как страшный сон.
Для начала прочитайте, о чем идет речь. Что такое анемик и рич, и увидете, что минус поставили совершенно зря.
Здравствуйте, licedey, Вы писали:
L>Вы все правильно написало. Однако хотелось бы несколько пометок сделать. Язык не должен быть таким сложным как плюсы. Не при каком раскладе. Это что называется попал в нужное время в нужное место. ГУИ нужен, Сишного кода море, а вот тебе и абстрактность во всей ее красе. struct window {}; make_window_visible хуже ведь Class Window { void Show(); void Hide(); }; Для человека.
Аналогия: кирпич — это сложный строительный материал? в руках хорошего строителя из него будет создано добротное здание, которое простоит не одну сотню лет, и может быть будет считаться шедевром инженерной мысли. А можно сделать джамшутами тяп-ляп, будет отсыревать, пропускать холод, портить ремонт внутри, который чаще придется делать, портить твое здоровье, чаще ходить к врачу Но виноват ли в этом кирпич?
L>Тут как говорится, смешались люди кони. От меня требуют (ну впрочем я и сам привык), писать движок антивируса в ООП-стиле. Т.е. сканирование файла — класс. Загрузка сигнатур — класс. Настройки класс. Разновидности сканирование (память, реестр, мбр) — наследование абстрактного класса ScanTask. Вопрос Зачем? И почему наряду со знание базовых знаний (структуры данных, алгоритмы), знай шаблоны проектирования.
Затем, чтобы сделать отдельные части приложения независимыми друг от друга. Т.к. при развитии проекта, изменении требований и т.п. велик риск, что затронув одну часть кода, поломаете другую. Поломаете
L>Есть же задачи (большинство их), где ООП замедляет процесс разработки. Иногда ломаешь голову, чтобы подогнать компоненты системы под иерархию наследования. Или вся эта виртуальность. Ну библиотечное это все течение. Я уже отписывал на хабре, что С++ для реализации задач и С++ для библиотек — это разные языки. Можно сказать, что первое — это повседневный язык студента, а второй преподавателя.
Иерархия наследования к ООП никакого отношения не имеет. Она имеет отношение к людям, любящим иерархии наследования, квалификация которых априори низка, иначе бы они не делали иерархии
L>Я негодую....А еще этот ворох старья тянущейся с 70-ых годов...
Нет там старья, там есть все для счастливой жизни. Нужно просто овладеть предметом.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Ikemefula, Вы писали:
L>>>Более того, очень многими неглупыми людьми ставится под сомнение его полезность. Все народ от того же насквозь оопшного DDD плюется, а вот вполне из себя процедурный anemic model вызывает массу положительных эмоций.
I>>Почему это анемик процедурный ?
L>Потому что имеем разнесение данных и способов работы с ними. Может "процедурный" и не самое удачное слово, но вот "ООП" уж тут точно ни в какие ворота.
ООП — это только поведение. Данные там вообще ортогональны.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Ikemefula, Вы писали:
L>>>ты сейчас с кем разговаривал? причем тут все это?
I>>"модель данных меняется намного реже модели обработки этих данных" @
I>>Вроде как очевидная фраза а тебя понесло непойми куда
L>Это тебя понесло непойми куда. Прочитай определение уже и пойми, что твое разделение модели данных и кода обработки ее и есть уход от ООП в его классичесом определении ("data structures consisting of data fields and methods together with their interactions").
S>The fundamental horror of this anti-pattern is that it's so contrary to the basic idea of object-oriented design; which is to combine data and process together. The anemic domain model is really just a procedural style design, exactly the kind of thing that object bigots like me (and Eric) have been fighting since our early days in Smalltalk.
У Фаулера каша в голове. Тоже начитался определений из википедии.
Здравствуйте, Lloyd, Вы писали:
L>Это не объекты без состояния, у них адрес есть.
"Адрес" объекта не является частью его состояния.
Предлагаю также отказаться от злоупотребления термином "адрес" в этой ветке, т.к. он неявно подразумевает наличие информации о размещении объекта в памяти, и некоторую специальную алгебру над указателями. Это не является фундаментальной частью ООП.
Лучше рассуждать в терминах ссылок, алгебра которых значительно проще.
С точки зрения ООП, identity включает в себя
— возможность иметь ссылку на объект
— возможность сравнить две ссылки между собой на равенство и установить, таким образом, идентичность объекта.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Нормальный OOD — как минимум, соблюдение SOLID.
