Очень часто я нахожусь в ситуации, когда я sh хочу сохранить только один объект из некоторой коллекции, активной в Unity. Это эквивалентно ситуации, когда у вас большой массив логических значений, и вы всегда хотите, чтобы точно один из них был истинным, и при определенных входных данных вы можете изменить индекс этого истинного логического значения.
Теперь я знаю, что очевидное решение этого заключается в том, чтобы просто отслеживать индекс, который в настоящее время является истинным, и, если он должен быть изменен, вы устанавливаете его в ложное значение и устанавливаете желаемый индекс в истинное значение. Но по какой-то причине я просто боюсь, что что-то может в итоге go не так. Я не могу придумать причину, по которой это могло бы произойти (помимо отсутствия безопасности потоков, но это не должно быть проблемой в единстве, по крайней мере, если я не буду возиться с потоками самостоятельно), но результат будет катастрофическим c и проблема никогда не решится сама собой - если два логических значения верны, то это может продолжаться очень долго. Поэтому, чтобы быть уверенным, я обычно сначала выключаю все логические значения, а затем включаю желаемое.
Есть ли причины бояться этого так же сильно, как и я? Какие есть потенциальные проблемы в этой ситуации при использовании «очевидного» решения? В целом - есть ли повод для беспокойства по поводу механических компьютерных ошибок? Что делать, если по какой-либо причине какой-то регистр где-то выходит из строя, и в такой ситуации записывает неверное значение, и я получаю два логических значения, которые являются истинными, и это никогда не исправляется. Почему такого рода проблемы, по-видимому, никогда не случаются, просто ли маловероятно возникновение такой проблемы? Имеет ли эта проблема или эта topi c «очень безопасного кода» имя какого-либо типа?
EDIT - некоторые примеры
Примером является навигация / обход меню, которое имеет только одно интерактивное подменю одновременно. Вы нажимаете кнопку, и открывается интерактивное подменю, и предыдущее меню перестает быть интерактивным (но, возможно, может оставаться видимым и выполнять другие действия). Самый простой способ - отслеживать текущий интерактивный элемент и просто отключать его, когда предполагается включение какого-либо другого элемента. Но если когда-либо случится по какой-то причине, что текущее интерактивное меню не отключится на этом шаге, у нас останется два интерактивных меню, и открытие дальнейших меню никогда не отключит неправильно интерактивное меню (может вызвать проблемы). если в какой-то момент позже более новое меню будет пересекать это неправильно интерактивное). Выключение может, как правило, решить проблему, но это другая топи c.
Еще один очень похожий пример - предположим, что у нас есть конечный автомат, такой как меню, - у нас может быть текущее меню (состояние) и ввод может изменить это. Переход из одного состояния в другое можно выполнить, просто выключив текущее и включив следующее. Но может возникнуть та же проблема, что и описанная выше.
Одним из решений может быть использование ссылки на текущее состояние. Но это может быть грязно - вам придется реализовать собственную функцию для вызова этой ссылки, которая будет иметь желаемый эффект. Поэтому, если вы хотите, чтобы кнопка была интерактивной в текущем меню, вам придется написать свой собственный метод, который каким-то образом вызывает все объекты, которые были бы вызваны, если бы он был интерактивным, как если бы объект был просто активным включенным объектом.
Может быть, это не такая уж большая проблема. Может быть, если я просто переименую Update() во что-то другое (таким образом, меню по умолчанию не очень-то много делают), и вызову это UpdateNew() из current ссылки на каждый кадр. Или я мог бы просто поместить оператор if в Update () и всегда проверять, если current == this.
Но я мог бы просто быть слишком напуган - может быть, я мог бы предположить, что просто отключить текущее состояние и включить новый совершенно безопасен.