Теперь я допишу то, что я по некоторым причинам не дописал вчера.
На первый взгляд нам не удалось решить вопрос с уникальностью мест
модификации/вызова. Как я заметил по обсуждениям выше есть желание
сделать это место уникальным хотя бы на уровне линковки. Я хочу
показать, что здесь неверен сам подход по обретению такого
контроля. Что мы имеем исходя из исходных условий? Мы имеем некий
spaghetti (или просто неструктурированный) код, который не
контролируем до такой степени,
что у нас откуда-то из мешанины кода может случиться неконтролируемый доступ. Проблема с доступом к переменной вытекает из того что никакой системы/структуры нет. Какая угодно подсистема откуда угодно может совершить доступ. И мы пытаемся имея неструктурированный код/проект/систему "отловить" или предоставить гарантию уникальности доступа/модификации. Верное решение здесь не заниматься предоставлением подобных гарантий решая задачу в лоб окольными силовыми методами. Вместо этого - структурировать всю систему так, чтобы все доступы/обращения были предсказуемы. Систему нужно разбить на подсистемы с организацией разрешенного доступа только между уровнями соответствующих подсистем. Это ключевая мысль данного сообщения и решение задачи. Добиться такого доступа можно либо инкапсуляцией, либо ничего не скрывая, договорно-интерфейсно, создавая межмодульные интерфейсы.
Всё это хорошо, но я выше уже описал к чему приводит инкапсуляция при отладке в простых языках/IDE. Состояние переменных просто так не видно, т.к. оно намеренно скрыто. И для того чтобы прочитать переменную, необходимо степать в get-функции. Сам этот процесс утомляет. Поэтому тут необходима какая-то золотая середина. Межмодульное общение можно скрыть (например модуль индикатора, модуль управления ШД, контроллера клавиатуры), но внутри модуля лучше не заниматься дальнейшей инкапсуляцией, а иметь вполне открытую структуру из структур. Подобная инкапсуляция (разбиение на модули) может поощрять к тому чтобы иметь "модуль" и внутри него набор переменных (одна из которых например глобальная итд). Но исходя из опыта я советую всегда намеренно помещать все переменные исключительно внутри структур. Такое решение удобно во многих случаях.
RxTx (08.05.2020 10:24, просмотров: 334) ответил RxTx на Если определеить задачу иначе, то "глобальная переменная" =>
read only access откуда угодно, каким угодно кодом/инструкциями. Но
изменение/modify => это строго один код/инструкция (не другие
инструкции). Зачем? "Сложность найти по файлам проекта где это
делается". Отсюда - классическая задача инкапсуляции доступа. Для C
решается так: Перейти от работы с переменной к accessor-методам
get/set. Переменную саму по себе скрыть (инкапсулировать), убрав
запись о ней из