L>Если он тривиальный, то и объяснить преимущества будет очень легко. L>Кажется в демагогии этот прием называется "ложная альтернатива", не так ли?
Демагогия — это ваша попытка увести разговор в сторону обсуждения всякой ерунды.
Здравствуйте, Baudolino, Вы писали:
L>>То, что DDD и anemic model — перпендикулярные концепции. B>Ну выскажите свои аргументы, если не согласны. Почему DDD исключает или наоборот обязательно подразумевает anemic model?
Вы меня прям в неловкое положение ставите. Некрасиво как-то предлагать вам открыть Эванса и хотя бы пролистать, глянуть на даиграмки, которые он там приводит. Там практически что не сущность, то с методами.
Тут одно из двух — либо Эванс это уже не ddd, либо в anemic нормальная практика объявлять бизнес-логику в методах сущностей.
Здравствуйте, Baudolino, Вы писали:
L>>Если он тривиальный, то и объяснить преимущества будет очень легко.
Вы забыли ответить на вопрос.
L>>Кажется в демагогии этот прием называется "ложная альтернатива", не так ли? B>Демагогия — это ваша попытка увести разговор в сторону обсуждения всякой ерунды.
Вы увели разговор в сторону частного случая, когда в опреации учавствует более одной сущности. Почему я не могу его увести в другую сторону?
L>Вы меня прям в неловкое положение ставите. Некрасиво как-то предлагать вам открыть Эванса и хотя бы пролистать, глянуть на даиграмки, которые он там приводит. Там практически что не сущность, то с методами.
Вперёд. Открываете Эванса и ищете утверждение, из которого прямо следует, что DDD и anemic model взаимно исключающие понятия. Потом постите сюда цитату и номер страницы.
То, что вы там где-то на диаграммах и в примерах увидели, меня не интересует.
L>Вы увели разговор в сторону частного случая, когда в опреации учавствует более одной сущности. Почему я не могу его увести в другую сторону?
Потому что ваш частный случай не интересен с точки зрения архитектуры. Единственный объект с состоянием эквивалентен программе с несколькими глобальными переменными. ОО подход здесь вырождается в процедурный. Не имеет никакого значения, в каком пространстве имён будут размещены процедуры, работающие с состоянием этого объекта. Тут абсолютно нечего обсуждать, и дальше в этом направлении разговор я поддерживать не буду.
Здравствуйте, Baudolino, Вы писали:
L>>Вы увели разговор в сторону частного случая, когда в опреации учавствует более одной сущности. Почему я не могу его увести в другую сторону? B>Потому что ваш частный случай не интересен с точки зрения архитектуры. Единственный объект с состоянием эквивалентен программе с несколькими глобальными переменными.
Я и не предлагаю такой случай обсуждать. Прочтите внимательнее, речь не об одном объекте, а об операции, в которой учавствиет один объект.
Чтобы было еще понятнее: например, операция "*" требует 2-х аргументов, а операция abs — одного.
B>ОО подход здесь вырождается в процедурный. Не имеет никакого значения, в каком пространстве имён будут размещены процедуры, работающие с состоянием этого объекта.
Не, ну зачем вы так, не надо так уж принижать процедурный подход. Глобальные переменные — далеко не единственный способ передать данные в процедуру.
B>Тут абсолютно нечего обсуждать, и дальше в этом направлении разговор я поддерживать не буду.
Здравствуйте, Baudolino, Вы писали:
L>>Вы меня прям в неловкое положение ставите. Некрасиво как-то предлагать вам открыть Эванса и хотя бы пролистать, глянуть на даиграмки, которые он там приводит. Там практически что не сущность, то с методами. B>Вперёд. Открываете Эванса и ищете утверждение, из которого прямо следует, что DDD и anemic model взаимно исключающие понятия.
На этот раз — манипулирование смыслом высказываний и подмена тезиса. Такое ощущение, что вы прям как по списку идете.
B>Потом постите сюда цитату и номер страницы.
Первое, что попалось: "Figure 11.7. The class diagram after the implementation", страницу не скжу. Найдите на най класс Asset и убедитесь.
B>То, что вы там где-то на диаграммах и в примерах увидели, меня не интересует.
Здравствуйте, Baudolino, Вы писали:
L>>Вы увели разговор в сторону частного случая, когда в опреации учавствует более одной сущности. Почему я не могу его увести в другую сторону? B>Потому что ваш частный случай не интересен с точки зрения архитектуры. Единственный объект с состоянием эквивалентен программе с несколькими глобальными переменными. ОО подход здесь вырождается в процедурный. Не имеет никакого значения, в каком пространстве имён будут размещены процедуры, работающие с состоянием этого объекта. Тут абсолютно нечего обсуждать, и дальше в этом направлении разговор я поддерживать не буду.
Позвольте, шло обсуждение некоторого общего случая на примере с двумя экземплярами аккаунта. Никто на этом не акцентировал внимание, кроме вас
. Теперь вы вашему частному случаю противопоставляете единственный объект со состоянием. Кто ж вас заставляет в крайности кидаться? Ниужели по-вашему между нескольких сущностей и единственным объектом с состоянием ничего нет?
Между прочим, сущности есть и в процедурном подходе. Их там называют "записями". Вполне себе можно иметь несколько экземпляров записей, не ограничиваясь глобальными переменными.
L>Я и не предлагаю такой случай обсуждать. Прочтите внимательнее, речь не об одном объекте, а об операции, в которой учавствиет один объект.
У меня есть привычка внимательно читать, что мне пишут. Цитирую ваши же слова: Откуда взялись "несколько сущностей"?
Если подразумевалась операция, надо было об этом сказать сразу. Впрочем, я бы ответил то же самое. Это вырожденный случай и он не интересен. Если у вас данные из предметной области никак не взаимодействуют между собой и не связаны отношениями, то всё, опять же, сводится к процедурному подходу, и, опять же, не имеет никакого значения, в каком пространстве имён расположены операции над этими данными. Как только появляется отношение и/или взаимодействие — всё, уже можно рассматривать контекст и возможность/необходимость выноса в сервисный слой.
Здравствуйте, Baudolino, Вы писали:
L>>Я и не предлагаю такой случай обсуждать. Прочтите внимательнее, речь не об одном объекте, а об операции, в которой учавствиет один объект. B>У меня есть привычка внимательно читать, что мне пишут. Цитирую ваши же слова: Откуда взялись "несколько сущностей"?
Я бы процитировал другие слова:
Преимущества какие-нибудь есть в "не-вынесении"?
Таки да, я все еще жду ответа на этот вопрос.
B>Если подразумевалась операция, надо было об этом сказать сразу.
Т.е. когда вы писали про "несколько сущностей", вы поняли все правильно. А когда я спросил про вариант с одной сущностью, то вы почему-то решили, что речь идет об экземпляре?
Как-то не вяжется.
B>Впрочем, я бы ответил то же самое. Это вырожденный случай и он не интересен.
Нет, это не вырожденный случай. Откройте Эванса и убедитесь, что эта "вырожденность" — на каждой второй диаграмме с сущностями.
Или понятие "вырожденность" вы тоже как-то индивидуально трактуете и оно меняется от поста к посту?
B>Если у вас данные из предметной области никак не взаимодействуют между собой и не связаны отношениями, то всё, опять же, сводится к процедурному подходу, и, опять же, не имеет никакого значения, в каком пространстве имён расположены операции над этими данными. Как только появляется отношение и/или взаимодействие — всё, уже можно рассматривать контекст и возможность/необходимость выноса в сервисный слой.
"Сервисный слой" — это и есть "поцедурный" подход.
L>На этот раз — манипулирование смыслом высказываний и подмена тезиса. Такое ощущение, что вы прям как по списку идете.
Хорош юлить. Какое нафиг манипулирование? Либо вы опровергаете мои слова, доказывая, что DDD и anemic model — связанные понятия (т.е. DDD требует или наоборот исключает anemic model), либо нет.
B>>Потом постите сюда цитату и номер страницы. L>Первое, что попалось: "Figure 11.7. The class diagram after the implementation", страницу не скжу. Найдите на най класс Asset и убедитесь. L>Да, я так и понял. http://en.wikipedia.org/wiki/Proof_by_example
L>Нет, это не вырожденный случай. Откройте Эванса и убедитесь, что эта "вырожденность" — на каждой второй диаграмме с сущностями.
У вас какой-то особый навык делать могучие логические выводы из картинок в книжке. В данном конкретном случае не имеет никакого значения, что там нарисовал Эванс. Думайте своей головой.
L>Или понятие "вырожденность" вы тоже как-то индивидуально трактуете и оно меняется от поста к посту?
Меняется только у вас в голове, потому что вы не хотите внимательно прочитать, что я писал, и подумать над этим.
L>"Сервисный слой" — это и есть "поцедурный" подход.
Ну это просто растиражированный здесь бред, который легко опровергается мной же приведенным примером, в котором сервис имеет состояние.
S>Ниужели по-вашему между нескольких сущностей и единственным объектом с состоянием ничего нет?
Между единицей и любым числом больше единицы действительно ничего нет.
S>Между прочим, сущности есть и в процедурном подходе. Их там называют "записями".
Спасибо, что открыли мне глаза.
S>Вполне себе можно иметь несколько экземпляров записей, не ограничиваясь глобальными переменными.
Можно. Это что-то меняет?
Здравствуйте, Baudolino, Вы писали:
L>>На этот раз — манипулирование смыслом высказываний и подмена тезиса. Такое ощущение, что вы прям как по списку идете. B>Хорош юлить. Какое нафиг манипулирование? Либо вы опровергаете мои слова, доказывая, что DDD и anemic model — связанные понятия (т.е. DDD требует или наоборот исключает anemic model), либо нет.
Есть ряд практик (бизнес-логика в сущеностях), которые "запрещены" anemic, но вполне приемлемы (судя по примерам Эванса) в ddd.
Упреждая дальнейшую подмену:
противополижностью запрещения делать что-либо являемя не запрет не делать это, а разрешение это делать.
Это не тот случай, чтобы вы не начали говорить, что ddd не запрещает выносить логику из классов.
B>>>Потом постите сюда цитату и номер страницы. L>>Первое, что попалось: "Figure 11.7. The class diagram after the implementation", страницу не скжу. Найдите на най класс Asset и убедитесь. L>>Да, я так и понял. B>http://en.wikipedia.org/wiki/Proof_by_example
Нет, либо ты неудачно пошутил, либо не понял, что там написано.
Для того, чтобы показать, что какое-то явление возможно, достаточно привести 1 пример. "какое-то явление" тут — это наличие бизнес-логики в сущностях.
Здравствуйте, Baudolino, Вы писали:
L>>Нет, это не вырожденный случай. Откройте Эванса и убедитесь, что эта "вырожденность" — на каждой второй диаграмме с сущностями. B>У вас какой-то особый навык делать могучие логические выводы из картинок в книжке. В данном конкретном случае не имеет никакого значения, что там нарисовал Эванс.
То вы просите цитаты, а как вам их дают, то сразу они оказываются не нужны.
B>Думайте своей головой.
Мои опасения про "список" только подтверждаются — вы умело продемонстриовали прием "Переход на личности".
L>>Или понятие "вырожденность" вы тоже как-то индивидуально трактуете и оно меняется от поста к посту? B>Меняется только у вас в голове, потому что вы не хотите внимательно прочитать, что я писал, и подумать над этим.
Вы не ответили на вопрос, как у вас так получилось, что слово "сущность" когда об этом говорите вы и ваш собеседник обозначает для вас не одно и то же.
Это ли не показатель, у кого что и где меняется.
И таки-да, еще вы не ответили на вопрос по поводу преимуществ рекомендуемого вами подхода.
L>>"Сервисный слой" — это и есть "поцедурный" подход. B>Ну это просто растиражированный здесь бред, который легко опровергается мной же приведенным примером, в котором сервис имеет состояние.
А где я писал, что сервим не может иметь состояния? Опять "подмена тезиса"?
Здравствуйте, Baudolino, Вы писали:
S>>Ниужели по-вашему между нескольких сущностей и единственным объектом с состоянием ничего нет? B>Между единицей и любым числом больше единицы действительно ничего нет.
Снова подмена. Речь шла о нескольких сущностях без оговорок, потом о единственном объекте с состоянием, эквивалентным программе с глобальными переменными.
На что подменили — я даже не понял. Что представляет собой величина, определенная как разинца между единицей и любым числом больше единицы? Разница между единицей и наперед заданным числом больше единицы — понимаю. Но эта разница существенна для любого наперед заданного числа.
Сначала было неоговоренное кол-во сущностей. Потом вы сузили до несколько, на что вам справедливо заметили что вы рассматриваете частный случай. В противоположность вашему случаю вы же придумали случай с одним объектом. Причем не просто с одним, а с одним объектом с состоянием (наверное другие без состояния). Эквивалентность такого случая программе с несколькими глобальными переменными не очевидна.
S>>Между прочим, сущности есть и в процедурном подходе. Их там называют "записями". B>Спасибо, что открыли мне глаза.
Не за что
S>>Вполне себе можно иметь несколько экземпляров записей, не ограничиваясь глобальными переменными. B>Можно. Это что-то меняет?
не меняет. Это ставит под сомнение адекватность перехода от нескольких сущностей к процедурному подходу в контексте спора о том, является ли анемик безотносительно кол-ва сущностей шагом от ООП или нет.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Baudolino, Вы писали:
L>>>"Сервисный слой" — это и есть "поцедурный" подход. B>>Ну это просто растиражированный здесь бред, который легко опровергается мной же приведенным примером, в котором сервис имеет состояние.
L>А где я писал, что сервим не может иметь состояния? Опять "подмена тезиса"?
Нет, не подмена. Это попытка http://en.wikipedia.org/wiki/Proof_by_example. Только неудача в том, что процедура тоже может иметь состояние (пусть глобальное), и сервисом с состоянием такую процедуру не напугать.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, gandjustas, Вы писали:
I>>>Это мягко говоря неправда В книге DDD эванс пишет в т.ч. про сервисы
G>>Где именно?
L>В 5-й главе.
