MAP vs Class. В чем идейная необходимость в MAP-ах? А что если использовать Class вместо MAP?

[glibs]

А как вы в класс будете передавать буфер различных таблиц и там его обрабатывать?

[MikeR]

Стот отметить, что Map в Axapt-e реализован как две сущности. Одна это класс коллекции, а другая это сущность в АОТ. Одна служит для обработки объектов в оперативной памяти, а вторая для удобства заполнения сущностей с одинаковым набором полей как то Поставщики-Клиенты.
Класс - это некая структура (базовый кирпичик) для постоения модификаций.
Если сравнивать первый Map и class, то здесь есть особенности того, что в мапе присуствует ключ и его можно использовать как некий упорядочный список. Он удобен для кэширования информации.
Множественные ключи в нем могут прикрепляться к одному и тому же значению, но один ключ может прикрепляться только к одному значению за раз. Добавление пары ключа и значения в место, где ключ уже привязан к значению изменит связь так, что ключ будет привязан к новому значению.

Map map = new Map(Types::String, Types::Enum);
Word wordType;
;
map.insert("Car", Word::Noun);
map.insert("Bike", Word::Noun);
map.insert("Walk", Word::Verb);
map.insert("Nice", Word::Adjective);

print map.elements(); //4;

wordType = map.lookup("Car");
print strfmt("Car is a %1", wordType); //Car is a Noun
pause;

[Raven Melancholic]

Цитата:

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

А как вы в класс будете передавать буфер различных таблиц и там его обрабатывать?

Ну, примерно так, как это реализовано в InventMovement и наследниках.

[glibs]

Цитата:

Сообщение от Raven Melancholic

...Ну...

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

[Raven Melancholic]

Цитата:

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

кодить шедевры...

Спасибо за комплимент но. к сожалению, не могу ни принять на свой счёт, ни вписать в резюме, так как автором иерархии классов, в основе которых лежит InventMovement я не являюсь.

Цитата:

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

да и еще вы это делаете без ошибок

В использовании классов, наследников InventMovement есть ошибки, но внёс их не я.

Цитата:

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

и никому потом с этим не придется разбираться

Есть документальные подтверждения, что как минимум один человек разбирался с классами из иерархии InventMovement (в инете есть статья от Fed), поэтому обобщение никому не подходит.

Цитата:

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

вам не жалко времени

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

movement = InventMovement::construct(salesLine, InventMovSubType::None, _childBuffer)
estimated = InventUpd_Estimated::newInventMovement(movement);
estimated.updateNow();

у меня уходит меньше, чем на перепрыгивание из:

this.LineAmount  = this.lineAmountMST(this.Qty);

где this это совсем оказывается не this, а ссылка на строку таблицы. Из метода последней вытягивается красивым синтаксисом другой map:

this.SalesPurchLine::lineAmountMST

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

[Bishop]

Цитата:

Сообщение от Raven Melancholic

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

Наверное, надо исходить от задачи. Одно дело - обобщить три пары полей в двух таблицах, другое - реализовать общие механизмы типа журнализации, работы с адресами и т.д.
Так что здесь на одной чаше весов - удобное "перепрыгивание", а на другой:
- быстродействие (мэппинг - это все таки "ядро", и этим НАДО пользоваться),
- простота (трудозатраты на создание, расширение и поддержку мэппинга классами существенно больше),
- шаблон (разработчики, как художники, непременно реализуют конкретный мэппинг каждый по-своему)

Поэтому, я голосую за MAP (хотя, по чесноку, чаще пишу классы ).
А "перепрыгивание" еще много где не работает (или работает не так как хотелось бы). В тех же классах из метода базового класса уже не "перепрыгнуть" в наследника, и все-равно приходится активно работать с репозитарием.

Да, и еще, InventMovement и Ко я бы не стал относить к попытке реализации мэппинга, все-таки это InventMovement...