Прощай, X++

[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]

Цитата:

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

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

- абзац посвящен описанию структурного дублирования таблицы и поведенческого morphX
- при каждом добавлении поля прижется дублировать эти parmМетоды
- в языке нет никакой конструкции для "стараться не лазить" (нельзя сделать private таблицу) то есть с неизбежностью будут лазить
- форма уже лазит (то есть модификация типа "вынесли поле описание в отдельный справочник" требует изменения всех форм и отчетов)
- для каждой новой таблицы всю эту историю повторять и поддерживать

Я сомневаюсь, что на практике вы так делаете

[Napalm]

Цитата:

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

Я сомневаюсь, что на практике вы так делаете

А в AX 2012 Майкрософт попытался сделать. Получилось на мой взгляд плохо.

Цитата:

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

Я сомневаюсь, что на практике вы так делаете

Не делаем. Проще использовать систему способом, предусмотренным ее создателями.

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

[belugin]

Цитата:

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

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

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

BTW:
- "Как правильно разрабатывать API с поддержкой обратной совместимости. Семинар в Яндексе": http://habrahabr.ru/company/yandex/blog/237459/
- http://semver.org/