Прощай, X++

Цитата:

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

Аргументируйте.
Как вы считаете каковы причины того, что мы можем практически безболезненно перейти на новую версию Windows и при этом обновление версии AX является "проектом"

Потому что Windows - продукт коробочный, сценарии его использования и интерфейсы с другими программными продуктами заранее известны его разработчикам (а точнее ими же и диктуются).
DAX же как правило используется как конструктор "собери сам".

Если Windows выпускали бы как такой же конструктор и конечный продукт формировался для каждого клиента индивидуально, переход на новую версию был бы сопряжен с теми же трудностями.

Примеры для AX 3 - 4- 2009:
1) Внедренцы DAX внедрили стандарт. Они будут переходить более менее безболезненно на новые версии, правда пользователей придется переучивать согласно новым тренингам и надеяться, что новые уникальные индексы уживутся со старыми данными.

2) Внедренцы DAX полностью проигнорировали стандартное приложение и запилили рядом свое с домино и медведями. Они на новые версии DAX будут переходить вообще без проблем.

[belugin]

Цитата:

Сообщение от Кирилл

Потому что Windows - продукт коробочный, сценарии его использования и интерфейсы с другими программными продуктами заранее известны его разработчикам (а точнее ими же и диктуются).
DAX же как правило используется как конструктор "собери сам".

Если Windows выпускали бы как такой же конструктор и конечный продукт формировался для каждого клиента индивидуально, переход на новую версию был бы сопряжен с теми же трудностями.

Проблема как раз в том, что Ax не конструктор, а конструкция из пластилина - у конструктора есть четкие интерфейсы деталек. Например Visual Studio Shell - это конструктор.

Вопрос в том, можно ли сделать прикладной код Ax больше похожим на конструктор

[dech]

Цитата:

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

Проблема как раз в том, что Ax не конструктор, а конструкция из пластилина - у конструктора есть четкие интерфейсы деталек. Например Visual Studio Shell - это конструктор.

Вопрос в том, можно ли сделать прикладной код Ax больше похожим на конструктор

Именно Reflection делает АХ пластилином, в остальном, простите, не соглашусь. Если представлять все четко, то и код будет четким. Если мысли плавают, то и код будет не то чтобы "пластилиновым", а скорее требующим исправлений. И тестировать такой код не так-то просто, т.к. не ожидаешь где может вылезти баг.
Лично для меня на 1 месте UnitTest, на 2-м рефакторинг со всеми БП... Без модульных тестов рефакторинг если и возможен, то нет уверенности в том, что вы ничего не сломаете. И все, никакого пластилина. Пользовательский тест обычно всегда после этого срабатывает.

[belugin]

Цитата:

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

Именно Reflection делает АХ пластилином, в остальном, простите, не соглашусь.

Я имел ввиду что принято менять объекты вместо того, чтобы их расширять.

Цитата:

Лично для меня на 1 месте UnitTest, на 2-м рефакторинг со всеми БП... Без модульных тестов рефакторинг если и возможен, то нет уверенности в том, что вы ничего не сломаете.

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

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

Например нет такой сущности как "Журнал ГК" - его логика реализована в форме, таблицах, LedgerJournalEngine и прочем. Причем то, что реализовано в форме не имеет нормального программного интерфейса.

Цитата:

И все, никакого пластилина. Пользовательский тест обычно всегда после этого срабатывает.

Не могли бы вы написать про то, какие вы тесты обычно пишете на примере какой-нибудь из конкретных разработок?

Цитата:

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

Например нет такой сущности как "Журнал ГК" - его логика реализована в форме, таблицах, LedgerJournalEngine и прочем. Причем то, что реализовано в форме не имеет нормального программного интерфейса.

Это был выбор самих разработчиков стандарта, а не диктат языка программирования или архитектуры системы. При желании можно реализовать сущность "Журнал ГК" в полном соответствии с вашими требованиями и на X++.
Перенести всю логику из таблиц и форм, в классы, оставив там только вызовы соответствующих методов этих классов.

[belugin]

Цитата:

Сообщение от Кирилл

Это был выбор самих разработчиков стандарта, а не диктат языка программирования или архитектуры системы. При желании можно реализовать сущность "Журнал ГК" в полном соответствии с вашими требованиями и на X++.

На текущем X++ и MorphX это нельзя сделать. Например, ничего кроме таблиц и view нельзя привязать к гриду.

Цитата:

Перенести всю логику из таблиц и форм, в классы, оставив там только вызовы соответствующих методов этих классов.

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

Цитата:

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

На текущем X++ и MorphX это нельзя сделать. Например, ничего кроме таблиц и view нельзя привязать к гриду.

Значит будем привязывать к гриду таблицу. У нас задача построить расово чистую систему из одних классов или решить проблему размазывания логики по разным местам?

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

Потом все статические методы просто переносим в базовый класс. Им все равно, лишь бы на сервере исполниться.

Затем смотрим какие методы мы можем перекрывать у таблицы. Их там штук 25, но нам хватит важнейших: insert, update, delete, renamePrimaryKey, initValue, validateField, modifiedField, validateWrite

Перекрываем их. Внутри создаем экземпляр прокси-класса и к примеру для update() до и после super прописываем экземпляр.beforeUpdate(this) и afterUpdate(this). Обрамляем все это дело транзакцией.

Ну и обычные напиленные методы копируем из таблицы в класс, но уже с учетом, что это другой this.

До кучи можно еще озадачиться написанием методов set и get (ну или parm), которые будут транслировать переменные прокси-класса в поля таблицы.
А потом использовать только их для чтения или записи.

Правда в таблице останутся определения индексов, связей и deleteactions.
Но по крайней мере код наследовать уже можно.

Ну и далее стараемся работать с этим прокси-классом, а не с таблицей непосредственно.
Зато залез человек в обозреватель, что-то там поделал, а логика вызвалась уже определенная наследниками прокси-класса.

Делаем эти прокси-классы для шапки и для строк, делаем класс Журнал ГК, который будет использовать экземпляры этих прокси-классов.
Вот как бы и свели код в одно место с возможностью полиморфизма вашего любимого.

С кодом на формах поступаем похожим образом.

Цитата:

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

Проблема как раз в том, что Ax не конструктор, а конструкция из пластилина - у конструктора есть четкие интерфейсы деталек. Например Visual Studio Shell - это конструктор.

Вопрос в том, можно ли сделать прикладной код Ax больше похожим на конструктор

В противопоставлении легкости накатывания новой версии Windows "проекту перевнедрения" DAX суть в том, что код Windows недоступен клиенту для доработки.

В примере Visual Studio Shell - это продукт, потребителем которого является программист, который всю логику потом и запиливает, но потом не может продать конечный продукт никому кроме себя.
Это аналог использования DAX исключительно как средства разработки, в DAX тоже есть прекрасные детальки Tables, Forms, Maps и т.д.

[belugin]

Цитата:

Сообщение от Кирилл

В противопоставлении легкости накатывания новой версии Windows "проекту перевнедрения" DAX суть в том, что код Windows недоступен клиенту для доработки.

Linux, Eclipse доступен клиенту для доработки - многие ли пользуются этим по сравнению с теми, кто используют публичные интерфейсы?

Цитата:

Это аналог использования DAX исключительно как средства разработки, в DAX тоже есть прекрасные детальки Tables, Forms, Maps и т.д.

Почему нельзя использовать те же принципы для прикладного кода?

Цитата:

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

Linux, Eclipse доступен клиенту для доработки - многие ли пользуются этим по сравнению с теми, кто используют публичные интерфейсы?

А многие пользуются коробочными учетными системами по сравнению с теми, кто использует допиливаемые учетные системы?

Все есть яд и и все есть лекарство, вопрос в дозах и условиях применения.

Цитата:

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

Почему нельзя использовать те же принципы для прикладного кода?

Разные потребители.
Прекрасными детальками пользуется программист. Он мыслит категориями "могу".
Деталька предоставляет такие-то сервисы и накладывает такие-то ограничения и область применения. В итоге программист использует детальку только так, как это задумал ее автор, либо не использует.

Потребителем прикладного решения является заказчик. Он мыслит категориями "хочу" и может захотеть что-либо, находящееся вне области применения, заданной нашей прекрасной системой без пластилина.
И тут перед программистом встает дилемма. Либо отказаться от денег, либо от принципов

Учетные системы их разработчиками задуманы как способ рубки бабла, а не абстрактная "вещь в себе", так что от денег отказываться никто не будет.

[belugin]

Цитата:

Сообщение от Кирилл

Разные потребители.
Прекрасными детальками пользуется программист. Он мыслит категориями "могу".
Деталька предоставляет такие-то сервисы и накладывает такие-то ограничения и область применения. В итоге программист использует детальку только так, как это задумал ее автор, либо не использует.

В любом случае детальками пользуется программист (и в коробочном и в пластилиновом).

Цитата:

Потребителем прикладного решения является заказчик. Он мыслит категориями "хочу" и может захотеть что-либо, находящееся вне области применения, заданной нашей прекрасной системой без пластилина.
И тут перед программистом встает дилемма. Либо отказаться от денег, либо от принципов

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

Дилемма всегда будет но при разных инструментах и подходах она встает реже или чаще. Я думаю, что можно серьезно уменьшить количество гнутых деталек, если поменять инструменты.

Цитата:

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

В любом случае детальками пользуется программист (и в коробочном и в пластилиновом).

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

Цитата:

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

Принципы придуманы для денег. Например, чтобы легче было менять и переходить на следующие версии.

Вот я к примеру бизнесмен. DAX внедрили, все работает как я и просил, проблем нет. Убедите меня перейти на новую версию и оплачивать поддержку всю дорогу.

Цитата:

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

Вопрос в том, можно ли сделать прикладной код Ax больше похожим на конструктор

Можно все перевести на полиморфизм, но это будет другой продукт.
И язык тут вторичен. В том же X++ есть удачные примеры типа RunBaseBatch или SalesFormLetter