C # Unity - Sprite превращается в белый вместо желаемого цвета [дубликат]

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

Некоторые люди предположили, что владельцы данных, которые являются изменяемыми, не должны быть структурами. Я категорически не согласен. Сущности, которые существуют для хранения данных, во многих случаях должны быть структурами, особенно если они изменяемы. Эрик Липперт неоднократно публиковал, что он считает изменчивые типы значений злыми (поиск по меткам «изменчивый» и «struct»). Конечно, верно, что .net позволяет делать определенные вещи с помощью изменяемых структур, которые он не должен, и не позволяет удобно некоторым вещам, которые он должен, но структурам POD («Обычные старые данные»), которые не имеют мутирующих методов, но вместо этого выставляют все свое состояние через общедоступные поля, имеют очень полезную согласованность в своем поведении, которое не используется ни с каким другим типом данных. Использование структуры POD может смутить кого-то, кто не знаком с тем, как они работают, но сделает программу более читаемой для всех, кто это делает.

Рассмотрим, например, следующий код, если EmployeeInfoStruct не содержит ничего но типы значений и неизменные типы классов, такие как String:

[employeeInfoStruct is a struct containing the following field]
public Decimal YearlyBonus;

[someEmployeeContainer is an instance of a class which includes the following method]
EmployeeInfoStruct GetEmployeeInfo(String id);  // Just the signature--code is immaterial

[some other method uses the following code]
EmployeeInfoStruct anEmployee = someEmployeeContainer.GetEmployeeInfo("123-45-6789");
anEmployee.YearlyBonus += 100;

Эрик Липперт жалуется, что вышеуказанный код изменит значение в anEmployee, но это изменение не повлияет на контейнер. Я бы предположил, что это хорошо - любой, кто знает, как работают структуры, может смотреть на вышеуказанный код и знать, что запись в структурную переменную затронет эту переменную, но не повлияет ни на что другое, если программа позже не использует какой-либо другой метод (возможно, SetEmployeeInfo), чтобы сохранить эту переменную где-то.

Теперь замените EmployeeInfoStruct на EmployeeInfoClass, который имеет свойство read / write типа YearlyBonus. Используя только вышеприведенную информацию, что можно сказать о взаимосвязи между написанием для какого-либо рабочего сервера и anEmployee? В зависимости от реализации класса anEmployee (который, за исключением случаев, когда EmployeeInfoClass запечатан, может быть или не быть фактически EmployeeInfoClass) и someEmployeeContainer, отношения между объектами могут быть любыми. Можно записать:

1. Не влияют на другие
2. Обновить другое в естественном режиме
3. Повреждение другого каким-либо образом

С structs, содержащим только поля любых типов значений или неизменяемых классов, семантика всегда будет # 1. Не нужно смотреть на код самой структуры или код контейнера, чтобы знать это. В отличие от этого, если anEmployee.Salary или someEmployeeContainer.GetEmployee является виртуальным, невозможно понять, что такое семантика.

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