AX2012. Цель атрибутов в расширении наследования классов

[fed]

Я бы переформулировал проблему, затронутую ax_mct следующим образом: Мы занимаемся автоматизацией бизнес процессов. Заметная часть участников этих самых бизнес процессов - люди весьма среднего образования и интеллекта. Поэтому все слишком сложно спроектированные бизнес-процессы, с течением времени либо упрощаются либо умирают.
Поэтому для меня использование в X++ коде слишком большого числа паттернов говорит о том что бизнес-проблема изначально неправильно сформулирована. Если бизнес-процесс описан правильно, то и код не будет выглядеть как набор примеров из Gang Of Four. Классический пример - это архитектура Source Document/Distribution/Subledger. Изначально безумный набор бизнес-требований привел к еще более безумной архитектуре. Вероятно с точки зрения разработчиков, которые этот код писали - никакого overengineering не было. Это еще просто чудо что тот код, который эту фигню реализует, все еще можно понять и как-то описать. Но вот с точки зрения соответствия этого модуля прикладной реальности на внедрениях - имеется overengineering и еще и какой.
Мы ведь в конце концов не биржевой скальпер пишем, не программу игры в Го и не предсказатель погоды. Если у вас разработка без десятка паттернов не получается, попробуйте с постановщиком поговорить.Скорее всего, он просто какой-то бред в спецификации написал, или вы просто половины требований не поняли...

[EVGL]

Цитата:

Сообщение от fed

Классический пример - это архитектура Source Document/Distribution/Subledger. Изначально безумный набор бизнес-требований привел к еще более безумной архитектуре. Вероятно с точки зрения разработчиков, которые этот код писали - никакого overengineering не было. Это еще просто чудо что тот код, который эту фигню реализует, все еще можно понять и как-то описать. Но вот с точки зрения соответствия этого модуля прикладной реальности на внедрениях - имеется overengineering и еще и какой.

Отнюдь. Ничего безумного в требованиях нет. Предварительный просмотр проводок с журналов ГК был сделан по-простому Ушаковым еще 15 лет назад. Прикладной реальности реализация соответствует идеально, жаль лишь что эта реализация покрывает лишь где-то 30% мест, где есть документы и проводки.

[fed]

Цитата:

Сообщение от EVGL

Отнюдь. Ничего безумного в требованиях нет. Предварительный просмотр проводок с журналов ГК был сделан по-простому Ушаковым еще 15 лет назад. Прикладной реальности реализация соответствует идеально, жаль лишь что эта реализация покрывает лишь где-то 30% мест, где есть документы и проводки.

Гм. Про предварительный просмотр я помню конечно. Проблема в том, что вместо предварительного просмотра сделали монстра, который позволяет отвязать проводки от экономического смысла операции. Кроме того - они там почему-то решили оторвать разноску в ГК от разноски по модулю, ввести понятие исходного документа (который вообще-то не само экономическое событие, а просто некий полуслучайный носитель информации об экономическом событии) и тд и тп.
Собственно из за бредовости привязки экономического события к документу и случилось что "только 30% мест" были покрыты.
Кроме того - возможность посмотреть планируемые проводки до разноски - это такая удобная фича. Она полезна конечно, но вряд ли настолько полезна чтобы сломать механизм разноски и отвязать разноску в ГК от разноски по модулю...
В итоге - я бы сказал что 85% багов в финансовом модуле DAX2012 случались как раз из за того что этот монстр как-то не очень хорошо интегрировался с остальными местами системы...

[trud]

Цитата:

Сообщение от fed

. Если бизнес-процесс описан правильно, то и код не будет выглядеть как набор примеров из Gang Of Four. Классический пример - это архитектура Source Document/Distribution/Subledger. Скорее всего, он просто какой-то бред в спецификации написал, или вы просто половины требований не поняли...

Ну кстати есть более простой пример. метод systemDateGet() объявили устаревшим, а вместо него сейчас везде используют конструкцию DateTimeUtil::getSystemDate(DateTimeUtil::getUserPreferredTimeZone());.
т.е. чтобы получить текущую дату(можно сказать простейшая базовая задача) нужно по сути создать класс, передав туда другой класс
т.е. казалось бы - создай одну функцию - текущая дата пользователя, помести туда эту конструкцию из 2 классов и пусть все юзают ее(в одно слово), но видно это какая-то нерешаемая в архитектурном плане задача

[belugin]

Цитата:

Сообщение от trud

Ну кстати есть более простой пример. метод systemDateGet() объявили устаревшим, а вместо него сейчас везде используют конструкцию DateTimeUtil::getSystemDate(DateTimeUtil::getUserPreferredTimeZone());.
т.е. чтобы получить текущую дату(можно сказать простейшая базовая задача) нужно по сути создать класс, передав туда другой класс

Где там "создать класс"? Тут два вызова, возращающих примитивы был один.

Цитата:

т.е. казалось бы - создай одну функцию - текущая дата пользователя, помести туда эту конструкцию из 2 классов и пусть все юзают ее(в одно слово), но видно это какая-то нерешаемая в архитектурном плане задача

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

[trud]

Цитата:

Сообщение от belugin

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

Так вот об этом то и речь. т.е. зачем нагружать разработчика бесполезными размышлениями о технических вещах. в пользовательской спецификации на разработку всегда будет одно понятие дата. она может быть на стороне сервера(это systemDateGet() и на стороне клиента today()). Зачем разработчику часовые пояса и их инициализация?
т.е. новую функцию создать то не проблема, но хотелось бы чтобы все шло из коробки(уже созданное, продуманное что когда и как использовать - т.е. собственно было четкое бест-практис правило - поскольку все разноски идут systemDateGet() то надо всегда использовать ее), а не заниматься созданием базовых библиотек

[belugin]

Цитата:

Сообщение от trud

бесполезными размышлениями о технических вещах. в пользовательской спецификации на разработку всегда будет одно понятие дата.

Это не техническая а логическая вешь. Предположим, что вы из Москвы пишете от руки платежное поручение банку в Нью Йорке - какая там должна быть дата платежа.

[dech]

Цитата:

Сообщение от trud

Ну кстати есть более простой пример. метод systemDateGet() объявили устаревшим, а вместо него сейчас везде используют конструкцию DateTimeUtil::getSystemDate(DateTimeUtil::getUserPreferredTimeZone());.
т.е. чтобы получить текущую дату(можно сказать простейшая базовая задача) нужно по сути создать класс, передав туда другой класс
т.е. казалось бы - создай одну функцию - текущая дата пользователя, помести туда эту конструкцию из 2 классов и пусть все юзают ее(в одно слово), но видно это какая-то нерешаемая в архитектурном плане задача

В AX 2.5 не было понятия таймзоны. Все работали по времени AOS'а. Напомню, что по этой причине не рекомендовалось использовать функцию today(). Вам никто не мешает создать кастомную функцию Global::xx_today(), которая будет понятна, прозрачна, корректна и безошибочна. хх - префикс вашей компании-разработчика.

[belugin]

Цитата:

Сообщение от fed

Поэтому для меня использование в X++ коде слишком большого числа паттернов говорит о том что бизнес-проблема изначально неправильно сформулирована. Если бизнес-процесс описан правильно, то и код не будет выглядеть как набор примеров из Gang Of Four.

Хотелось бы обоснование того, что паттерны это сложно. По моему опыту есть более и менее простые. И некоторые паттерны (типа "фасад") наоборот делают код проще. И еще, если их не знать они все равно будут, просто вразнобой и под несогласованными названиями.

Цитата:

Классический пример - это архитектура Source Document/Distribution/Subledger. Изначально безумный набор бизнес-требований привел к еще более безумной архитектуре.

Тут наверное интересно было бы открыть свою тему про сабледжеры (можно сделать рефакторинг ExtractTopic и перенести сообщения fed ). Я вижу своей программисткой кочки там скорее попытку обобщить логику финансовой разноски. Дополнительных требований там не так много.

[fed]

Цитата:

Сообщение от belugin

Хотелось бы обоснование того, что паттерны это сложно. По моему опыту есть более и менее простые. И некоторые паттерны (типа "фасад") наоборот делают код проще. И еще, если их не знать они все равно будут, просто вразнобой и под несогласованными названиями.

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

Пожалуй единственное место в Аксапте, которое, на мой взгляд, просится на переписывание на интерфейсы, фабрики, и тд и тп - это сводное планирование. Там как раз достаточно простой и наглядный общий алгоритм теряется за сотнями специальных случаев. Если бы его создатели смогли его как-то растащить на множество более простых сущностей, алгоритм был бы более читаем и расширяем.

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

[belugin]

Цитата:

Сообщение от fed

Просто паттерны в большинстве случаев просто позволяют несколько повысить уровень абстракции и за счет этого более наглядно и обозримо сформулировать сложные алгоритмы, которые на уровне C++ 1.0 наглядно не формируются. Но - как я уже сказал - в бизнес-автоматизации сложных алгоритмов не бывает, в противном случае - они бы не смогли бы быть реализованы как бизнес-процессы.

Я бы сказал, что в аксапте есть грандиозная структурная сложность за счет отсутсивя модульности - понять что за код и на что он влияет довольно трудно. Пости все есть интерфейс, нигде не гарантируется что в коде одного модуля не может быть вставки из другого модуля.

Разбираться с прикладным кодом достаточно сложно.

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

К тому же такая фабрика помогает достичь модульности.

К сожалению, тут есть часть недостатков:
- нет визуализации соотвествия ключ-класс
- нет контроля целостности во время компиляции (case в Ax7 проверяется на недублирование ключей в дизайн тайме, правда в Ax6 этого не было, как и рантайма тоже - моя попытка сделать статический анализ выгребла ~30 всяких ошибок, часть из которых были свитчи )
- она медленнее

С кодом не использующим патернов может быть сложее разбираться - при работе с прикладным кодом аксапты часто хочется тул, который сравнивает два выделенных куска, чтобы понять, в чем тут разница.