Является ли DLL с сохранением состояния хорошим кандидатом на шаблон состояния?

Question

У меня есть DLL, которая экспортирует ряд функций для получения или установки различных значений в некоторых базовых объектах данных. В некоторых случаях DLL выдаст уведомление приложению, использующему его, через зарегистрированный указатель функции обратного вызова. Затем приложение должно ответить на уведомление через определенную функцию в интерфейсе DLL (но не обязательно сразу). Пока ответ не получен, объекты данных в DLL могут быть прочитаны, но не записаны.

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

Вдобавок ко всему, я могу придумать два решения: я мог бы реализовать простой механизм состояний на основе флагов и обернуть каждый установщик в оператор if, проверяющий этот флаг. Или я мог бы реализовать два состояния в соответствии с шаблоном State.

Первое решение должно быть дешевым в построении, но требует от всех разработчиков не забывать проверять флаг при реализации новой экспортируемой функции сеттера. И это может стать уродливым, если в какой-то момент состояние «только для чтения» ожидает ответ определенного типа на основе исходного уведомления. Второе решение требует реализации новых экспортируемых функций в обоих состояниях, что побуждает разработчика задуматься о том, что функция делает в режиме только для чтения. Но большинство методов будут делать то же самое в обоих состояниях, а остальные не должны ничего делать или даже генерировать исключения ...

Есть ли еще лучший способ добиться чего-то подобного?

Answer 1

Как насчет этого: перейдите ко второму решению, но не дублируйте свои функции, оставьте их как есть. Вместо этого пусть все они делегируются интерфейсу, реализованному двумя классами: один представляет поведение в нормальном состоянии, а другой - только для чтения. Когда вы переключаетесь в состояние только для чтения, указатель, который вы используете, указывает на реализацию только для чтения. Если вас беспокоит дублирование состояния в обоих классах, используйте абстрактный интерфейс со всеми общими данными вместо интерфейса.

Другой альтернативой могут быть указатели на функции-члены: вместо полиморфных вызовов используйте указатели на функции-члены. При переключении в режим только для чтения измените все указатели, чтобы они указывали на функции-члены режима только для чтения. Таким образом, вы также избегаете дублирования функций в интерфейсе DLL.