Далее будут приведено подробное обоснование предлагаемых изменений, сделанное на основании обсуждений ситуации 13.07.2005 и 14.07.2005.
Изменения ставят целью создание простого, завершённого интерфейса для написания алгоритмов управления, а также графических интерфейсов и процессов ввода-вывода.
Все допустимые взаимодействия между объектами должно быть жёстко указано, не должно быть возможно несанкционированное вмешательство в объект из кода, к нему не относящегося. Это относится к удалённому вызову функций, удалённому изменению состояния датчиков.
При написании/проектировании интерфейсов следует предусматривать разделение на уровни – интерфейс, предоставляемый пользователю и интерфейс, нужный самой системе.
На данный момент отказаться от этих функций не представляется возможным. Даже если считать, что список заказа формируется в конф. файле, то остаётся вопрос о событии ЗапускПроцесса
saveState НЕ должен быть доступен снаружи объекта.
Функция сохранения состояния не должна быть использована вне процесса, владеющего объектом, для которого меняется состояние. Поэтому из Universal Interface она должна быть вынесена. ?
Поэтому предлагается функцию для прямого получения состояния (значения) отменить. Информация об изменении значений будет доставляться заказанными извещениями о изменении состояния датчиков. Для хранения информации о состоянии в класс вводятся локальные переменные, значение которых заполняется специальной функцией, действующей перед обычным вызовом processingMessage, таким образом, что в любой момент при обращении к этим переменным их значения будут максимально актуальны.
Для облегчения программирования добавление необходимого кода в класс будет осуществляться автоматически. Для каждого заказанного датчика будут созданы локальные переменные name (хранящая состояние датчика) и id_name (хранящая идентификатор датчика).
Для указания конкретного имени переменной, соответствующей датчику, его необходимо явно указать в конф. файле, иначе оно будет сгенерировано по умолчанию (нужно сформулировать правила). Способ передачи имени переменной в конф. файл обсуждается.
Пока не будет чётко определён механизм разделения интерфейсов на доступные конечным разработчикам и доступные библиотечным классам(объектам) это поле предлагаю оставить. Т.к. оно используется в реализации DBServer и по нему определяется в какую таблицу необходимо сохранить запись об изменении состояния датчика. Для БД разделение на аналоговые и дискретные существенно, т.к. связано с оптимизацией хранения (Cейчас аналоговые и дискретные датчики хранятся в разных таблицах. Более того, изменение аналоговых датчиков происходит чаще).