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

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