Уровень доступа + функционал. Алгоритмы

[Двоешник]

Есть электронный прибор с микропроцессорным управлением.
К прибору могут прикладываться самые разные люди, с разной квалификацией и полномочиями. Для этого я ввожу в систему такое понятие как уровень доступа (Level_0, Level_1, Level_2,..Level_Х)
Но помимо этого у прибора есть определённый функционал, функции которого обрабатывают например клавиатуру, датчики, ЖПС модуль, элементы индикации, исполнительные ус-ва, реле и т.д.
С разных уровней доступа, человек который работает с прибором, может рассчитывать на разный функционал. Другими словами сами логика и правила управления прибором должны учитывать уровень доступа пользователя в системе.
Скажите, как правильнее реализовать (запрограммировать) обработку и функционала и уровня доступа? Я говорю о решении ,которое будет удобно тестировать и отлаживать.

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

Не факт что так правильно, но если че поправьте. Спасибо!

---
Не знал куда правильнее запостить. и решил тут разместить. Если че - перенесите по месту.

[pyzhman]

перед всеми входными воздействиями поставить как своего рода фильтр другую функцию.

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

[Goldsmith]

Я бы в таком случае воспользовался паттерном GoF Strategy.

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

Экземпляры стратегий можно либо статически заготовить заранее, если категорий пользователей немного, либо генерировать при необходимости посредством Class Factory.

Решения вполне типовые, их легко реализовать, протестировать и отладить.