AXForum - Блоги - dech

Паттерн Related Table

dech — Wed, 17 Oct 2018 12:29:50 GMT

Пожалуй уже всем надоело каждый раз выискивать подходящий метод на таблице для поиска подчиненных (ну или просто связанных) записей. Возьмем к примеру таблицу SalesLine, у которой есть такие методы как salesTable(), inventTable(), inventDim() и так далее...
Т.е. у нас есть некоторый внешний ключ, по которому мы хотим найти связанную запись в таблице, для которой данный ключ является первичным. Чтобы не плодить кучу методов, я решил добавить один новый метод, который будет "лучше старых двух".
Как лучше к нему обращаться? Нужно,чтобы метод был универсальным, т.е. мог вернуть любую таблицу, какую хотим. Ну и конечно же необходима совместимость с самими методами, которые мы хотим заместить новым. Т.е. нужно добавить возможность выборки для обновления.
Таким образом, напрашиваются следующие варианты:

X++:

salesTable  = salesLine.related(tablenum(SalesTable));
custTable   = salesLine.related(tablenum(CustTable), true);

Это, конечно, немного длиннее, чем вызывать конкретно salesLine.salesTable(), однако читабельности это совсем не вредит. Второй плюс, уже более очевидный - это стандартизация кода. Когда видишь такие строчки, тебе четко ясно, что хотел донести разработчик. Третий плюс - нам больше не нужны методы salesTable(), inventDim() и им подобные! У нас есть один метод, который будет работать за всех остальных. Дармоеды нам не нужны!)))
Ну вот и сам метод:

X++:

public Common related(TableId _tableId, Boolean _forUpdate = false)
{
    switch (_tableId)
    {
        case tablenum(SalesTable):
            return SalesTable::find(this.SalesId, _forUpdate);

        case tablenum(InventTable):
            return InventTable::find(this.ItemId, _forUpdate);

        case tablenum(InventDim):
            return InventDim::find(this.InventDimId, _forUpdate);
    }

    throw error(strfmt("Relation on %1 to %2 table not implemented yet", tableid2name(this.TableId), tableid2name(_tableId)));
}

Проявляется и четвертый плюс: расширяемость. Всегда можно добавить пару строчек кода и использовать единый метод в кастомном коде.

P.S. Спешу заметить, что могут встречаться несколько полей, ссылающихся на одну и ту же таблицу. Например FromInventDimId, ToInventDimId и т.д. По каждому из них хотелось бы искать связанную запись точно таким же способом. Напрашивается добавление параметра по FieldId, однако... лушчее - враг хорошего. Я предлагаю для таких случаев использовать отдельные методы, иначе данный паттерн потеряет свою простоту, а вместе с тем и свою привлекательность.

Изменяем паттерн construct()

dech — Mon, 19 Mar 2018 12:45:48 GMT

Давайте посмотрим, что нам говорит Best Practices. Используйте метод construct() в каждом классе, чтобы можно было его правильно расширять классами-потомками и вызывать через menu items. Что касается таких классов как SalesLineType - говорить нечего. Метод construct() используется чисто как шаблон проектирования Строитель/Builder. Однако, разработчики решили, что этого мало, и стали использовать Enum для запуска конкретного подкласса из какого-либо семейства классов, например SalesFormLetter. Заполняем в menu item свойства EnumTypeParameter и EnumParameter, запускаем его и через Args наш класс получает нужное значение enum. Далее - дело техники, метод construct() создает нужный экземпляр на основе переданного enum-значения:

X++:

static SalesFormLetter  construct(DocumentStatus    document,
                                  boolean           getParmId = true)
{
    switch(document)
    {
        case DocumentStatus::Confirmation       :   return new SalesFormLetter_Confirm           (getParmId);
        case DocumentStatus::PickingList        :   return SalesFormLetter_PickingList::construct(getParmId);
        case DocumentStatus::PackingSlip        :   return new SalesFormLetter_PackingSlip       (getParmId);
        case DocumentStatus::ProjectPackingSlip :   return new SalesFormLetter_PackingSlipProject(getParmId);
        case DocumentStatus::Invoice            :   return new SalesFormLetter_Invoice           (getParmId);
        case DocumentStatus::ProjectInvoice     :   return new SalesFormLetter_InvoiceProject    (getParmId);

        default : throw error(strfmt("@SYS19306",funcname()));
    }

    throw error(strfmt("@SYS19306",funcname()));
}

Итак, каждый раз, когда мы через menu item хотим запустить конкретный подкласс, мы должны следовать букве BP и создавать для каждого нового семейства свой Enum. Я пошел немного другим путём, который немного попроще, да и менее затратный по времени. Всё, что я опишу далее, касается только запуска классов через menu items. При вызове класса в коде лучше создавать свой статический метод construct(), хотя можно извратиться и создавать программно menu item и args. Но это уже перебор. :eek:
ОК, что нам нужно, чтобы упростить создание объектов? Интересный факт, свойство Parameters типа строка используется реже, чем EnumParameter. Я решил через него передавать имя класса для создания нового объекта. Это даст возможность передавать еще и enum для каких-либо дополнительных целей. Я перенёс метод construct() в класс Global, сделав его по существу глобальной функцией. Чтобы он заработал как надо, я добавил следующий код:

X++:

public static Object construct(Args _args)
{
    DictClass       dictClass;
    IdentifierName  className;
    ;

    if (!_args)
        throw error(Error::missingParameter(null));

    className = _args.parm() ? _args.parm() : _args.menuItemName();

    dictClass = new DictClass(classname2id(className));

    if (!dictClass)
        throw error(strfmt("Unable to instantiate \"%1\" class", className));

    return dictClass.makeObject();
}

Кто использует метки, создайте метку для последнего сообщения.
Далее, для проверки можно создать пару классов, пусть они называются Base и Derived:

X++:

class Base 
{
    public static void main(Args _args)
    {
        Base base = construct(_args);
        ;
    
        info(base.getType());
    }

    public ClassDescription getType()
    {
        return "Base";
    }
}

X++:

class Derived extends Base
{
    public ClassDescription getType()
    {
        return "Derived";
    }
}

После того, как классы сделаны, создаем 2 menu items для запуска суперкласса Base. Пусть один называется Base, а второй - Derived. Внимание, оба менюайтема вызывают один и тот же базовый класс. Для менюайтема Derived прописываем имя класса Derived в свойстве Parameters. для менюайтема Base можно ничего не прописывать, если имя класса совпадает с именем менюайтема.
А теперь тест! Запускаем Base, запускаем Derived. Инфолог выдаёт то, что мы и ожидаем. Поздравляю, мы с вами только что уделали Microsoft, который до сих пор указывает в BP использовать статический метод construct(). :D
Однако, для AX2012 и выше этот код уже не актуален. Для запуска батчей теперь используется SysOperation Framework и атрибуты. Так что, если вы всё еще работаете в старой версии аксапты, прошу обкатывать новый паттерн.

Как можно обойтись без методов pack/unpack?

dech — Tue, 13 Dec 2016 14:05:34 GMT

Если честно, то меня достало каждый раз писать одно и то же. Сидишь перекрываешь методы, которые выучил наизусть... И в каждом новом наследнике RunBase делаешь дублирование кода... Каждый раз. Что говорят по этому поводу Банда Четырех, Кент Бек, ну или Мартин Фаулер? Дублирование - это плохо.
А что делать, если из-за макросов #CurrentVersion/#CurrentList попросту по-другому никак? У нас есть ООП, но макрос со списком полей существует только в конкретном классе.
Я решил попытаться обойти эту проблему, создав промежуточный класс, наследник RunBase.
Пусть он будет тоже абстрактным, как и его родитель.

X++:

public abstract class DC_RunBase extends RunBase
{
}

Для начала попробуем избавиться от #CurrentVersion. Пусть это будет статический метод, возвращающий актуальный номер версии. Нужен именно статический, из-за возможности перекрытия метода. И тогда всё поедет. Модификатор final в наследнике будет не к месту, т.к. в этом случае вся ответственность возлагается на автора класса-наследника.

X++:

public static Version version()
{
    return 0;
}

Если же мы сделаем статический метод, то он в принципе будет работать как description(), извлекая версию из конкретного класса. Тогда нам нужен аналог метода getDescription():

X++:

public client server static Version getCurrentVersion(ClassId _classNum)
{
    ExecutePermission   casPerm = new ExecutePermission();
    SysDictClass        classObj;
    IdentifierName      staticName = staticmethodstr(DC_RunBase, version);

    if (! _classNum)
        return 0;

    classObj = new SysDictClass(_classNum);

    if (classObj &&
        classObj.hasStaticMethod(staticName))
    {
        casPerm.assert();

        //BP Deviation Documented
        return classObj.callStatic(staticName);
    }

    return 0;
}

Отлично! С версией разобрались. Теперь можно браться за работу над #CurrentList. По сути его заменит метод, который будет работать как метод доступа parm*. Его мы реализуем в последнюю очередь. А пока займемся парой занудных методов. :-)

X++:

public final container pack()
{
    return [DC_RunBase::getCurrentVersion(classidget(this))] + this.currentList();
}

Метод pack() выглядит достаточно просто. Можно было бы еще немного упростить, если сделать currentList() контейнером в контейнере. Но я решил оставить так для совместимости.
Метод unpack() в принципе тоже несложный. Выглядит проще, чем оригинальный RunBase-овский:

X++:

public final boolean unpack(container _packedClass)
{
    if (RunBase::getVersion(_packedClass) != DC_RunBase::getCurrentVersion(classidget(this)))
        return false;

    this.currentList(condel(_packedClass, 1, 1));

    return true;
}

Делаем запрет на перекрытие, чтобы эти методы больше не болтались. В принципе почти готово. Осталось сделать последний штрих - метод которого не хватает - currentList(). Именно из-за него класс является абстрактным. Внутрь я решил положить шаблон, как это сделано для pack/unpack:

X++:

public abstract container currentList(container _currentList = connull())
{
    #if.never
    if (!prmisdefault(_currentList))
    {
        [#CurrentList] = _currentList;
    }

    return [#CurrentList];
    #endif
}

Вот и всё. Продукт готов к употреблению. ;-) Замечу, что все-таки не удалось полностью избавиться от макросов. #CurrentList у нас все-таки будет присутствовать. Но цель была не в этом, а в упразднении пары методов pack/unpack.
Давайте сделаем пример класса-наследника, который будет использовать все новые преимущества.
Определим в classDeclaration() простой чекбокс:

X++:

class DC_RunBaseChild extends DC_RunBase
{
    NoYesId     checked;

    DialogField dfChecked;
}

Перекроем dialog() и getFromDialog(). Эти методы делаем как обычно.

X++:

protected Object dialog(DialogRunbase dialog, boolean forceOnClient)
{
    ;

    dialog = super(dialog, forceOnClient);

    dfChecked = dialog.addFieldValue(typeId(NoYesId), checked, "Почистить зубы");

    return dialog;
}

Второй метод. Все стандартно.

X++:

public boolean getFromDialog()
{
    boolean ret = super();
    ;

    checked = dfChecked.value();

    return ret;
}

Перекроем метод run(), чтобы условно выполнить задание

X++:

public void run()
{
    ;

    if (checked)
        info("Зубы блестят как новые");
    else
        warning("Изо рта попахивает");
}

Таким же обычным способом пишем точку входа:

X++:

public static void main(Args _args)
{
    DC_RunBaseChild    runbase = new DC_RunBaseChild();
    ;

    if (runbase.prompt() && runbase.init())
    {
        runbase.run();
    }
}

Ну а теперь самое интересное. Пишем два метода, которые делают всю "черную" работу. Первый возвращает номер текущей версии:

X++:

public static Version version()
{
    return 1;
}

Второй строит список полей, который можно как читать, так и записывать.

X++:

public container currentList(container _currentList = connull())
{
    #localmacro.CurrentList
        checked
    #endmacro

    if (!prmisdefault(_currentList))
    {
        [#CurrentList] = _currentList;
    }

    return [#CurrentList];
}

Компилируем, запускаем, все работает.