Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Ну, я как бы, думал, что ты что-то своё под этим понимаешь. Я тут у многих заметил склонность к изобретению своих трактовок терминов и их ниспровержению. То примитивный мапер лёгким ОРМ обзовут, то еще что. Даже ссылку дал, дабы прояснить горизонты. И любому здравомыслящему человеку сразу видно, что описанное по ссылке не ОО-подход
Ага. При этом старина Мартин пользуется известным маркетинговым приёмом — сначала приводит вполне себе внятное описание Service Objects, а затем пишет "а, ну так это — практически то же самое, что и Transaction Script". А раз Transaction Script — чисто процедурное овно, значит такова же и Anemic Model.
Внятного доказательства эквивалентности Service Objects и Transaction Sctript не приведено, оно подразумевается очевидным.
Примерно так же Свидетели Иеговы обосновывают креационизм: "наш мир такой классный и красивый, ну разве же не очевидно, что это оттого, что кто-то его придумал?"
А реально изо всех фатальных недостатков Anemic Model приведён только один: затраты на модель предметной области и на ORM без бенефитов.
Тут я склонен частично согласиться, а частично нет:
— в современных системах, затраты на поддержание маппинга вполне себе приемлемые. Особено если не пытаться вдуть в domain model сложные иерархии наследования.
— бенефит по сравнению с прямой манипуляцией RDBMS в том, что у нас есть богатые метаданные. В частности, можно привязывать внятные правила по валидации данных и иметь сквозные гарантии по всему стеку — от UI до базы данных. При этом выносить эти правила в уровень сервисов как раз неудобно.
В остальном, в принципе, объекты для "предметной области" действительно не нужны. Объекты нужны для того, чтобы манипулировать элементами предметной области, а про это Фаулер напрямую врёт.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
S>>>>Чтобы понять, почему анемик не является менее ООП, достаточно отойти чуть назад и задуматься.
ANS>>>Это зависит от трактовки дефиниций. Если посмотреть на изначальную трактовку, то это явно не ООП.
G>>Ага, фаулер говорит что anemic — не ООП, и все сразу верят.
ANS>Ну, я как бы, думал, что ты что-то своё под этим понимаешь. Я тут у многих заметил склонность к изобретению своих трактовок терминов и их ниспровержению. То примитивный мапер лёгким ОРМ обзовут, то еще что. Даже ссылку дал, дабы прояснить горизонты. И любому здравомыслящему человеку сразу видно, что описанное по ссылке не ОО-подход
Там написано что это не ОО-подход, но доказательств этому нету. Более того по формальным признакам anemic не менее ОО, чем rich.
Здравствуйте, Sinclair, Вы писали:
ANS>>Ну, я как бы, думал, что ты что-то своё под этим понимаешь. Я тут у многих заметил склонность к изобретению своих трактовок терминов и их ниспровержению. То примитивный мапер лёгким ОРМ обзовут, то еще что. Даже ссылку дал, дабы прояснить горизонты. И любому здравомыслящему человеку сразу видно, что описанное по ссылке не ОО-подход S>Ага. При этом старина Мартин пользуется известным маркетинговым приёмом — сначала приводит вполне себе внятное описание Service Objects, а затем пишет "а, ну так это — практически то же самое, что и Transaction Script". А раз Transaction Script — чисто процедурное овно, значит такова же и Anemic Model.
Извини, я до этого места статью был не дочитал Я остановился на втором абзаце. И сходу вопрос, почему "Transaction Script" это "чисто процедурное овно"?
S>А реально изо всех фатальных недостатков Anemic Model приведён только один: затраты на модель предметной области и на ORM без бенефитов. S>Тут я склонен частично согласиться, а частично нет: S>- в современных системах, затраты на поддержание маппинга вполне себе приемлемые. Особено если не пытаться вдуть в domain model сложные иерархии наследования. S>- бенефит по сравнению с прямой манипуляцией RDBMS в том, что у нас есть богатые метаданные. В частности, можно привязывать внятные правила по валидации данных и иметь сквозные гарантии по всему стеку — от UI до базы данных. При этом выносить эти правила в уровень сервисов как раз неудобно.
Вот-вот. Я специально сверху оставил строчку. Похоже я прав, ибо не понимаю при чем тут метаданные. Метаданные это хорошо.
А плохо когда гигантские структуры с гетерами/сетерами передаются туда-сюда. Наличие LazyLoad всё усугубляет, но и без него картина выглядит не очень.
S>В остальном, в принципе, объекты для "предметной области" действительно не нужны. Объекты нужны для того, чтобы манипулировать элементами предметной области,
Так против этого как раз я не возражаю, а только "за".
S>а про это Фаулер напрямую врёт.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, artelk, Вы писали:
A>>Все же, наличие операции сравнения ссылок для определения идентичности не является необходимым для того, чтобы на конкретном языке программирования можно было писать в ООП стиле. Если из .NET/C# выкинуть object.ReferenceEquals, то разрабатывать в ООП стиле все еще будет возможно. G>А как тогда узнать что пара объектов — один и тот же? Ведь на эту операцию завязано много чего.
А требуется ли это многое, чтобы разработка в ООП стиле была возможна?
A>>Вот если выкинуть, например, из C++ указатели и ссылки, а любые "объекты" передавать по значению — ООП будет невозможен: A>>
A>>Хитрость еще в том, что даже тут идентификаторы a1 и a2, по сути, все еще являются ссылками. В строках //1 и //2 мы работаем все с тем же объектом. Только в языках с полным отсутствием изменяемого состояния возможно, чтобы идентификатор не был ссылкой. G>Это неправда. Несмотря на синтаксическую конструкцию A a2 = a1, которая выглядит как присваивание, выполняется конструктор копирования. Что недвусмысленно говорит о копии объекта. но никак не том же самом объекте.
Да, a1 и a2 — ссылки на разные объекты. Посмотри где поставлены комментарии //1 и //2.
A>>Что касается object.ReferenceEquals, то, если он возвращает true, то ссылки гарантированно ссылаются на "один и тот же объект". Однако он может и вернуть false для ссылок на идентичные объекты. Т.е. он накладывает более сильные требования к ссылкам, чем этого требуется для обеспечения идентичности, необходимой для возможности писать в ООП стиле (aka "логической идентичности" в терминологии samius-а). G>Покажи пример такого.
Объект и его прокси.
S>>>>Незачем приводить язык без ссылок. Но если хочется — можно пофантазировать. Пусть будет C#--, который будет в точности C#, но без возможности сравнения ссылок. Обращаться по ссылке можно, сравнивать — нет. S>>>Вполне возможный язык. Ну, для начала в таком C#-- не скомпилируется FCL. S>>>Чтобы она скомпилировалась, придётся придумать способ обойти это ограничение, потому что на сравнении идентичности объектов основано довольно много кода. Если мы не придумаем способ сделать IsIdentic(ref1, ref2), то дотнет так и не заработает. A>>Равенство ссылок C# — более сильное условие, чем необходимо в ООП для определения идентичности. G>В чем? Покажешь пример равенства ссылок без идентичности? более сильное
Здравствуйте, gandjustas, Вы писали:
ANS>>>>Это зависит от трактовки дефиниций. Если посмотреть на изначальную трактовку, то это явно не ООП.
G>>>Ага, фаулер говорит что anemic — не ООП, и все сразу верят.
ANS>>Ну, я как бы, думал, что ты что-то своё под этим понимаешь. Я тут у многих заметил склонность к изобретению своих трактовок терминов и их ниспровержению. То примитивный мапер лёгким ОРМ обзовут, то еще что. Даже ссылку дал, дабы прояснить горизонты. И любому здравомыслящему человеку сразу видно, что описанное по ссылке не ОО-подход
G>Там написано что это не ОО-подход, но доказательств этому нету. Более того по формальным признакам anemic не менее ОО, чем rich.
То, что описано во втором абзаце выглядит не красиво.
По теории код отдельно от данных это не ОО. Если говорить о практической стороне, то ты же сам знаешь, что если в качестве параметра передать в метод структуру из сотни элементов, то метод получает связь со всеми элементами. А если там есть мутаторы, то вообще "Ой".
Как Это можно защищать я не понимаю. Отсюда делаю вывод, что защищают какое-то своё понимание термина "анемик".
Здравствуйте, artelk, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, artelk, Вы писали:
A>>>Все же, наличие операции сравнения ссылок для определения идентичности не является необходимым для того, чтобы на конкретном языке программирования можно было писать в ООП стиле. Если из .NET/C# выкинуть object.ReferenceEquals, то разрабатывать в ООП стиле все еще будет возможно. G>>А как тогда узнать что пара объектов — один и тот же? Ведь на эту операцию завязано много чего. A>А требуется ли это многое, чтобы разработка в ООП стиле была возможна?
Это философский вопрос. Но судя по реализации стандартных библиотек java и .net — требуется.
A>>>Что касается object.ReferenceEquals, то, если он возвращает true, то ссылки гарантированно ссылаются на "один и тот же объект". Однако он может и вернуть false для ссылок на идентичные объекты. Т.е. он накладывает более сильные требования к ссылкам, чем этого требуется для обеспечения идентичности, необходимой для возможности писать в ООП стиле (aka "логической идентичности" в терминологии samius-а). G>>Покажи пример такого. A>Объект и его прокси.
Пример кода покажи, а то непонятно чем ты.
S>>>>>Незачем приводить язык без ссылок. Но если хочется — можно пофантазировать. Пусть будет C#--, который будет в точности C#, но без возможности сравнения ссылок. Обращаться по ссылке можно, сравнивать — нет. S>>>>Вполне возможный язык. Ну, для начала в таком C#-- не скомпилируется FCL. S>>>>Чтобы она скомпилировалась, придётся придумать способ обойти это ограничение, потому что на сравнении идентичности объектов основано довольно много кода. Если мы не придумаем способ сделать IsIdentic(ref1, ref2), то дотнет так и не заработает. A>>>Равенство ссылок C# — более сильное условие, чем необходимо в ООП для определения идентичности. G>>В чем? Покажешь пример равенства ссылок без идентичности? A>более сильное
Ну да, покажи пример идентичности без равенства ссылок.
Формально идентичность это id(object), id(a)==id(b) тогда и только тогда когда a и b совпадают. При этом функция id не опирается на состояние и поведение объекта.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
ANS>>>>>Это зависит от трактовки дефиниций. Если посмотреть на изначальную трактовку, то это явно не ООП.
G>>>>Ага, фаулер говорит что anemic — не ООП, и все сразу верят.
ANS>>>Ну, я как бы, думал, что ты что-то своё под этим понимаешь. Я тут у многих заметил склонность к изобретению своих трактовок терминов и их ниспровержению. То примитивный мапер лёгким ОРМ обзовут, то еще что. Даже ссылку дал, дабы прояснить горизонты. И любому здравомыслящему человеку сразу видно, что описанное по ссылке не ОО-подход
G>>Там написано что это не ОО-подход, но доказательств этому нету. Более того по формальным признакам anemic не менее ОО, чем rich.
ANS>По теории код отдельно от данных это не ОО.
По какой теории?
Здравствуйте, gandjustas, Вы писали:
G>Формально идентичность это id(object), id(a)==id(b) тогда и только тогда когда a и b совпадают. При этом функция id не опирается на состояние и поведение объекта.
Не "не опирается", а не зависит от них (independent). Это значит что функция должна выдавать результат тот же самый для того же объекта в любом состоянии.
var id1 = id(a);
a.UpdateState();
Assert(id1 == id(a));
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
G>>По какой теории?
ANS>Названия не помню
Нет такой теории.
Фаулер опирается на заблуждение
....basic idea of object-oriented design; which is to combine data and process together
Object-oriented Analysis and Design (OOAD) был придуман сильно позже ООП, примерно середина 90-годов и популяризирован двумя людьми — Бертраном Мейером и Гради Бучем. Только у них появилась мысль что объекты — данные+методы, причем обязательно вместе.
К сожалению в это время не было другой литературы по ОО-проектированию и все дружно на слово поверили мейеру и бучу. Это даже при том что примерно в это время появилась книга Design Pattern банды четырех, но там описывается решение конкретных проблем, а не подход к проектированию.
Через 5-7 лет Фаулер и Эванс выпустили свои книги, принеся в мир ООП еще одну волну булшита. Например до смешного популяризировали паттерн Repository, который при наличии мощных ORM почти не нужен.
Еще через 5 лет их поддержал Грег Янг со своим абсолютизированием DDD и выдумыванием CQRS.
Причем это очень далеко ушло от первоначальных идей ООП и преимуществ, которые они давали.
Из всего этого можно понять что исторически все "теории", которым верят миллионы, продвигаются очень ограниченной группой людей. При этом большинство теорий плохо или вообще никак не формализованы.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Формально идентичность это id(object), id(a)==id(b) тогда и только тогда когда a и b совпадают. При этом функция id не опирается на состояние и поведение объекта.
S>Не "не опирается", а не зависит от них (independent).
Это тоже самое.
S>Это значит что функция должна выдавать результат тот же самый для того же объекта в любом состоянии. S>var id1 = id(a); S>a.UpdateState(); S>Assert(id1 == id(a));
Вот только id должно принимать object чтобы не опираться на состояние и поведение. Вот и напиши такую функцию.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, samius, Вы писали:
S>>Здравствуйте, gandjustas, Вы писали:
G>>>Формально идентичность это id(object), id(a)==id(b) тогда и только тогда когда a и b совпадают. При этом функция id не опирается на состояние и поведение объекта.
S>>Не "не опирается", а не зависит от них (independent). G>Это тоже самое.
нет
S>>Это значит что функция должна выдавать результат тот же самый для того же объекта в любом состоянии. S>>var id1 = id(a); S>>a.UpdateState(); S>>Assert(id1 == id(a)); G>Вот только id должно принимать object чтобы не опираться на состояние и поведение. Вот и напиши такую функцию.
Написать не возьмусь. Я допускаю существование функции, о которой говорю. Соответственно, допуская это, я никому не обязан ее предоставить. Если ты утверждаешь что ее не может существовать, то что бы убедить в этом кого-нибудь, тебе следует показать это формально, а не требовать с меня реализацию на C#.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, artelk, Вы писали:
G>>>А как тогда узнать что пара объектов — один и тот же? Ведь на эту операцию завязано много чего. A>>А требуется ли это многое, чтобы разработка в ООП стиле была возможна? G>Это философский вопрос. Но судя по реализации стандартных библиотек java и .net — требуется.
Приведи пример задачи, которую, оставаясь в рамках ООП парадигмы, нельзя решить без операции сравнения ссылок.
A>>>>Что касается object.ReferenceEquals, то, если он возвращает true, то ссылки гарантированно ссылаются на "один и тот же объект". Однако он может и вернуть false для ссылок на идентичные объекты. Т.е. он накладывает более сильные требования к ссылкам, чем этого требуется для обеспечения идентичности, необходимой для возможности писать в ООП стиле (aka "логической идентичности" в терминологии samius-а). G>>>Покажи пример такого. A>>Объект и его прокси. G>Пример кода покажи, а то непонятно чем ты.
Берем http://exposedobject.codeplex.com/
Код:
dynamic a = new A {X = 42};
dynamic d = ExposedObject.From(a);
Console.WriteLine(d.X);//42
Console.WriteLine(object.ReferenceEquals(a, d));//false!!!
Идентичность в .NET — более узкое понятие, чем в ООП.
Или ты будешь утверждать, что a и d не идентичны?
S>>>>>>Незачем приводить язык без ссылок. Но если хочется — можно пофантазировать. Пусть будет C#--, который будет в точности C#, но без возможности сравнения ссылок. Обращаться по ссылке можно, сравнивать — нет. S>>>>>Вполне возможный язык. Ну, для начала в таком C#-- не скомпилируется FCL. S>>>>>Чтобы она скомпилировалась, придётся придумать способ обойти это ограничение, потому что на сравнении идентичности объектов основано довольно много кода. Если мы не придумаем способ сделать IsIdentic(ref1, ref2), то дотнет так и не заработает. A>>>>Равенство ссылок C# — более сильное условие, чем необходимо в ООП для определения идентичности. G>>>В чем? Покажешь пример равенства ссылок без идентичности? A>>более сильное G>Ну да, покажи пример идентичности без равенства ссылок. G>Формально идентичность это id(object), id(a)==id(b) тогда и только тогда когда a и b совпадают. При этом функция id не опирается на состояние и поведение объекта.
"Равенство ссылок без идентичности" != "идентичность без равенства ссылок" .
Пример привел выше
Здравствуйте, gandjustas, Вы писали:
G> Например до смешного популяризировали паттерн Repository, который при наличии мощных ORM почти не нужен.
И, кстати,
1. обвинять популяризатора в том, что предлагаемое ими стало популярным — это странно.
2. мне помнится ты, утверждал, что мощные ORM это фигня, а вот "лёгкие" — это вещь.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, samius, Вы писали:
S>>>Здравствуйте, gandjustas, Вы писали:
G>>>>Формально идентичность это id(object), id(a)==id(b) тогда и только тогда когда a и b совпадают. При этом функция id не опирается на состояние и поведение объекта.
S>>>Не "не опирается", а не зависит от них (independent). G>>Это тоже самое. S>нет
С точки зрения математики — да. Функция не зависит от некоторых параметров, это значит что при вычислении функции они не используются, значит что не опирается на них.
Мы же не в лингвистическом клубе, а на техническом форуме.
S>>>Это значит что функция должна выдавать результат тот же самый для того же объекта в любом состоянии. S>>>var id1 = id(a); S>>>a.UpdateState(); S>>>Assert(id1 == id(a)); G>>Вот только id должно принимать object чтобы не опираться на состояние и поведение. Вот и напиши такую функцию. S>Написать не возьмусь. Я допускаю существование функции, о которой говорю. Соответственно, допуская это, я никому не обязан ее предоставить. Если ты утверждаешь что ее не может существовать, то что бы убедить в этом кого-нибудь, тебе следует показать это формально, а не требовать с меня реализацию на C#.
Именно обязан. В математике нет "презумпции невиновности", есть аксиомы, остальное надо доказывать.
Аксиомы две: 1) у каждого объекта есть identity, которая не зависит от состояния и поведения 2)для одинаковых (same) объектов identity совпадает, для разных — нет
Ты доказать существование такой функции id, которая не является object.ReferenceEquals в C# не можешь. Значит нет такой функции. Значит object.ReferenceEquals является функцией сравнения identity, значит ссылка и есть identity.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
G>>Фаулер опирается на заблуждение
ANS>Это не заблуждение, это примитивизация.
Нет, это именно заблужение. До буча с мейером никто не говорил что объекты — данные+методы, обязательно вместе. Откуда это они взяли — неизвестно. Даже design patterns описывает классы и объекты, большинство из которых не имеет данных\состояния.
G>>Причем это очень далеко ушло от первоначальных идей ООП и преимуществ, которые они давали. ANS>например, про преимущества ты поскипал, а придрался к "теории".
Я придрался к "теории" фаулера и компании, а не к ООП.
Здравствуйте, samius, Вы писали:
G>>Вот только id должно принимать object чтобы не опираться на состояние и поведение. Вот и напиши такую функцию. S>Написать не возьмусь. Я допускаю существование функции, о которой говорю. Соответственно, допуская это, я никому не обязан ее предоставить. Если ты утверждаешь что ее не может существовать, то что бы убедить в этом кого-нибудь, тебе следует показать это формально, а не требовать с меня реализацию на C#.
То есть ктото должен приводить формальное доказательство что твои допущения и выводы где то ущербны ?
Во всём мире другой подход — допускатель не просто допускает, а делает своё допущение верифицируемым и фальсифицируемым. И как то эта часть в твоих допущениях отсутствует, потому неудивительно, что в трёх приведеных тобой определениях идентити указано "independent of its state or behavior", но ты всё равно за уши притягиваешь это самое поведение. И уж совсем неудивительно видеть "повсеместное неправильное толкования ".
Здравствуйте, artelk, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, artelk, Вы писали:
G>>>>А как тогда узнать что пара объектов — один и тот же? Ведь на эту операцию завязано много чего. A>>>А требуется ли это многое, чтобы разработка в ООП стиле была возможна? G>>Это философский вопрос. Но судя по реализации стандартных библиотек java и .net — требуется. A>Приведи пример задачи, которую, оставаясь в рамках ООП парадигмы, нельзя решить без операции сравнения ссылок.
Collection.Remove(object), если не переопределять equals, то она вычисляется как сравнение ссылок.
A>dynamic a = new A {X = 42};
A>dynamic d = ExposedObject.From(a);
A>Console.WriteLine(d.X);//42
A>Console.WriteLine(object.ReferenceEquals(a, d));//false!!!
A>
Ты привел пример разных объектов.
A>Идентичность в .NET — более узкое понятие, чем в ООП. A>Или ты будешь утверждать, что a и d не идентичны?
Конечно не идентичны, они даже не эквивалентны. У них даже типы разные.
G>>>>В чем? Покажешь пример равенства ссылок без идентичности? A>>>более сильное G>>Ну да, покажи пример идентичности без равенства ссылок. G>>Формально идентичность это id(object), id(a)==id(b) тогда и только тогда когда a и b совпадают. При этом функция id не опирается на состояние и поведение объекта. A>"Равенство ссылок без идентичности" != "идентичность без равенства ссылок" .
Да, это я ночью писал, ошибся. Тебе нужен пример где два объекта идентичны, то есть это один объект по сути. Но ссылки на него не равны.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
G>> Например до смешного популяризировали паттерн Repository, который при наличии мощных ORM почти не нужен.
ANS>И, кстати, ANS>1. обвинять популяризатора в том, что предлагаемое ими стало популярным — это странно.
Совсем нет, ибо популярной стала идея, которая в наше время не нужна.
ANS>2. мне помнится ты, утверждал, что мощные ORM это фигня, а вот "лёгкие" — это вещь.
Да, вещь. На самом деле почти любой orm делает паттерн repository ненужным.
Я остановился на втором абзаце. И сходу вопрос, почему "Transaction Script" это "чисто процедурное овно"?
