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

A>>>>При этом важно то, что если подумать, всегда можно переписать код так, что хелперы исчезнут. Останутся только классы, отражающие предметную область. Функционал будет в них, и код станет гораздо лучше организован.
G>>>И это неправда.

A>>Это я поленился уточнить: "эмпирическое утверждение по моим наблюдениям". У меня нет теории, из которой бы следовало, что это гарантировано возможно, а просто всегда как-то получалось. Ну и если посмотреть, например, на API крупных продуктов (всяких ОС), на стандартные библиотеки известных ЯП — то как-то и им это удаётся, что косвенно подтверждает. Это я объяснил, почему так считаю, обосновать я не могу.

G>Это означает что на каком-то подмножестве относительно простых задач это возможно, а в общем — нет.

Это означает, что я не могу доказать свою правоту за неразвитостью теории проектирования (и признаю это). Больше ничего. А вот опровергнуть меня возможно — контрпримером (хотя на практике обсуждение может быть очень трудоёмким).

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

>Задача, которую нарисовал липперт, вроде достаточно простая, но уже на ней возникли сложности DDD.

А давай-ка вернёмся к задаче Липперта. Я тут подумал над ней в свободное время... как я уже сказал, я очень его уважаю и найти ошибку в его рассуждениях для меня — ачивка 80-ого уровня. Сразу скажу: из спортивного интереса я пока не читал продолжение (чтобы сначала самому подумать), и не знаю, оставил ли он эту ошибку в учебных целях, или мне действительно удалось подловить маэстро.

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

Так вот: отношения между мечом, посохом, магом и воином — это игровая логика. Она постоянно меняется — в целях достижения игрового баланса, например. Или чтобы тупо было интереснее играть. И во многих других случаях. Поэтому в реальном мире люди зачастую начинают писать одну игру, а заканчивают совсем другую. И это же распространяется и на софт класса... как он там его назвал?.. Papers and Paychecks. Просто "wizards and warriors are more fun to write about". Значицца, игровая логика в реальных проектах меняется постоянно. Как же так получается, что столь изменчивую вещь мы фиксируем настолько, что её аж должен ПРОВЕРЯТЬ КОМПИЛЯТОР, а проверок в рантайме недостаточно? Учитывая, насколько она изменчива по своей природе, её даже в рантайме проверять (выбрасывая исключения) не надо — как описали, так и описали, просто грузи, проверяй, и разрешай или запрещай персонажу взять предмет. Это просто рабочая логика!

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

A>>>>При этом важно то, что если подумать, всегда можно переписать код так, что хелперы исчезнут. Останутся только классы, отражающие предметную область. Функционал будет в них, и код станет гораздо лучше организован.
G>>>И это неправда.

A>>Это я поленился уточнить: "эмпирическое утверждение по моим наблюдениям". У меня нет теории, из которой бы следовало, что это гарантировано возможно, а просто всегда как-то получалось. Ну и если посмотреть, например, на API крупных продуктов (всяких ОС), на стандартные библиотеки известных ЯП — то как-то и им это удаётся, что косвенно подтверждает. Это я объяснил, почему так считаю, обосновать я не могу.

G>Это означает что на каком-то подмножестве относительно простых задач это возможно, а в общем — нет.

Это означает, что я не могу доказать свою правоту за неразвитостью теории проектирования (и признаю это). Больше ничего.

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

>Задача, которую нарисовал липперт, вроде достаточно простая, но уже на ней возникли сложности DDD.

А давай-ка вернёмся к задаче Липперта. Я тут подумал над ней в свободное время... как я уже сказал, я очень его уважаю и найти ошибку в его рассуждениях для меня — ачивка 80-ого уровня. Сразу скажу: из спортивного интереса я пока не читал продолжение (чтобы сначала самому подумать), и не знаю, оставил ли он эту ошибку в учебных целях, или мне действительно удалось подловить маэстро.

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

Так вот: отношения между мечом, посохом, магом и воином — это игровая логика. Она постоянно меняется — в целях достижения игрового баланса, например. Или чтобы тупо было интереснее играть. И во многих других случаях. Поэтому в реальном мире люди зачастую начинают писать одну игру, а заканчивают совсем другую. И это же распространяется и на софт класса... как он там его назвал?.. Papers and Paychecks. Просто "wizards and warriors are more fun to write about". Значицца, игровая логика в реальных проектах меняется постоянно. Как же так получается, что столь изменчивую вещь мы фиксируем настолько, что её аж должен ПРОВЕРЯТЬ КОМПИЛЯТОР, а проверок в рантайме недостаточно? Учитывая, насколько она изменчива по своей природе, её даже в рантайме проверять (выбрасывая исключения) не надо — как описали, так и описали, просто грузи, проверяй, и разрешай или запрещай персонажу взять предмет. Это просто рабочая логика!