Средства и методы разработки

раздела

экспортируемых имен объектного файла. В C это достигается static модификатором. Тогда о переменной будет знать только её модуль, для остальных на уровне линковки она будет недоступна. Вместо переменной наружу экспортируется функция vartype moduleXYZ_getvarYYY(); которая возвращает копию переменной, но не её саму. Этим решается read only access откуда угодно. Также существует ф.модуля void moduleXYZ_modifyvarYYY(); способная модифицировать переменную. Переменная известна только этой ф. и изменяется только ей. Поставив точку останова (создав лог итд) в этом месте можно отловить изменение переменной, т.е. незамеченным оно на уровне доступа к памяти уже не произойдет (или иначе говоря будет управляемым). Вызвать void moduleXYZ_modifyvarYYY() по прежнему можно откуда угодно. Это можно дополнительно скрыть, не экспортируя void moduleXYZ_modifyvarYYY() явно, принудительно экспортируя её только в местах перед вызовом. Уникальный вызов ф., т.е. предоставить гарантии что инструкция вызова с адресом соответствующим этому имени уникальна, или уникален сам адрес на уровне трансляции/линковки стандартными методами нельзя. Однако такая задача на уровне трансляции и не ставится. Программно ее решать можно (транзакции с access token) но смысла нет.

Теперь мое личное мнение. Казалось бы, проекты построенные таким образом хороши, всё побито на модули, переменные скрыты, вызываются getter/setter'ы итд. Но у этого решения на мой взгляд есть крупный недостаток и проявлят он себя В ОТЛАДКЕ. Отлаживать такой код неудобно, так как придется постоянно заходить в эти функции и ходить по модулям, что причиняет "Yo-Yo эффект". Вместо этого лучше не использовать уединенные переменные, собрав их все в одной структуре (разбитой по функциональности на под-структуры), не использовать методы доступа и не использовать разбиение проекта на мелкие модули, ограничившись группировкой толкьо по естественном функционалу. Такой код выглядит хорошо, чисто, понятно и отлаживать его приятно.