[CodeStyle] check* vs validate* методы. в чем разница в X++? какой будет выводить в инфолог?

[sukhanchik]

Поскольку вопрос чисто предпочтений, то я (лично для себя) выработал следующие правила (при условии, что нет правил, установленных используемыми фреймворками):
Методы check* отвечают за одну проверку.
Методы validate* отвечают за комплекс проверок (т.е. грубо говоря состоят из вызовов методов check*).
При этом комплексов может быть много и они могут состоять из разного набора проверок (аналог привилегий и Duty в 2012).
Я люблю делать проверочные методы методами объекта (а не статическими), чтобы иметь возможность обращаться к глобальным переменных классам или внутренним private-методам
Сообщения, исключения, диалоговые окна - это все регулируется параметрами методов в зависимости от потребности (например, иногда вместо инфолога надо писать в таблицу текст ошибки).

Ну и собственно все.
Пример (абстрактный).
Хочу написать алгоритм разноски для своей условной заявки на покупку. Разноска генерит проводку в ГК и приходную проводку в InventTrans.
У меня будет:
1) проверка на открытость периода в ГК
2) проверка на открытость периода по складу (ValueOpen = Да)
3) проверка на наличие товара по необходимым аналитикам
4) проверка на наличие бюджета
... какие-то другие проверки.

По бизнесу (к примеру) сначала выполняется проверка на наличие товара. Если он есть, то закупка не выполняется.
Если товара нет, то выполняется проверка на наличие бюджета. После успешной проверки бюджета - выполняется разноска по складу и ГК.

Я хочу сделать (условно) 4 метода check*, которые в свою очередь будут вызываться в разное время, причем они также могут быть вызваны пользователем по кнопке "Проверить" или "Предварительный просмотр проводок".
При этом у меня будут методы validate*, которые будут вызывать эти методы check*:
1) validate на этапе проверки наличия товара
2) validate на этапе проверки бюджета
3) validate на этапе разноски

Соответственно - наполнение этих validate-методов может быть разным, при этом, к примеру, проверку на открытость периода я могу вызывать в каждом validate-методе, но сама логика проверки у меня будет в едином методе check

[mazzy]

О, интересный подход.

А у тебя check-методы могут вызываться не из validate?
И что насчет инфолога? ты допускаешь, что все они могут что-то выводить в инфолог?

и что насчет диалога с пользователем? Ну, этот пресловутый Book_RU.validateDelete?

[sukhanchik]

Цитата:

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

А у тебя check-методы могут вызываться не из validate?

Конечно. Я же привел пример наличия кнопки "Проверка". validate - это некое событие в алгоритме, по результатам которого отрабатывает основной код (например, разноска).

Цитата:

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

И что насчет инфолога? ты допускаешь, что все они могут что-то выводить в инфолог?

Я бы даже настаивал, чтобы любая проверка выводила какое-то осмысленное сообщение куда-нибудь (инфолог или какая-то таблица для пакетных заданий). Иначе пользователю совершенно неясно, из-за какой конкретно проверки не выполнилась какая-то операция.

Цитата:

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

и что насчет диалога с пользователем? Ну, этот пресловутый Book_RU.validateDelete?

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

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

Пример 1. Разноска товарного расхода. Проверка необходимого в наличии количества выполняется до резервирования, но если резервирование уже прошло, то нет смысла проверять необходимое количество в наличии - оно гарантированно будет - в этом смысл резервирования.

Пример 2 (AX2012). Проверка достаточности бюджетных средств. Если не используется функционал резервирования бюджета (который привязывает резерв к документу) и разносимый документ не указан в настройках контроля бюджета, то по сути бюджет может "пропасть" в любой момент, а значит его есть смысл регулярно проверять.

Пример 3. Аналог примера 2, только речь идет про проверку на закрытость периода. Конечно период могут закрыть в любой момент, но все же нет смысла проверять закрытость периода условно при любом изменении нашей "заявки на покупку", потому что это для пользователя не столь важно, как, к примеру, неожиданная "потеря" бюджета.

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

В общем - общая идея такова, что в некотором алгоритме всегда есть проверки, которые можно выполнять на любом этапе алгоритма, а есть проверки, которые есть смысл выполнять только на определенных этапах. Но в любом случае - мне нравится идея выделять всевозможные проверки в методы с префиксом check*, а уже вызывать из методов validate* только те проверки, которые необходимо выполнить именно в данном validate*. Я также понимаю, что одна и та же проверка может быть вызвана как программно несколько раз (из нескольких validate*), так и условно вручную по нажатию специальной кнопки.