Прощай, X++

Цитата:

Сообщение от 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/