Asset-Verwaltung

Unveränderlichkeit von Assets

Wählen Sie jede Designoption aus, die die folgende Anforderung erfüllt:

Anforderung: Nach dem Laden sollte ein Asset dauerhaft unveränderlich sein.

Die Unveränderlichkeit von Assets wird durch Typen erzwungen, die keine mutierenden Operationen zulassen. Sowohl eine unveränderliche Ausleihe &Asset als auch ein unveränderlicher Smart-Pointer wie Rc erlauben keine mutierenden Operationen. Daher erfüllen die Optionen 1, 3 und 4 diese Anforderung. Option 2 gibt eine veränderliche Ausleihe zurück, was die Anforderung NICHT erfüllt.

Asset-Zugriff über Ausleihen

Wählen Sie jede Designoption aus, die die folgende Anforderung erfüllt:

Anforderung: Clients des Asset-Managers müssen den Zugriff auf Assets über mehrere kurzfristige Ausleihen des Asset-Managers hinweg behalten können.

“Zugriff über Ausleihen hinweg behalten” bedeutet, dass der Client ein Programm wie dieses schreiben möchte:

let asset = {
    let manager = get_manager();
    manager.load("some/path")
};
process_asset(asset);
let another_asset = {
    let manager = get_manager();
    manager.load("another/path")
};

In diesem Fall darf die Lebensdauer des von load zurückgegebenen Wertes nicht an die Lebensdauer des AssetManager gebunden sein. Optionen 1 und 2 erfordern, dass &Asset und &mut Asset nur so lange leben wie &mut self. Daher würde der Borrow-Checker Programme wie das oben genannte ablehnen, bei denen ein Asset die Manager-Referenz überdauert. Optionen 1 und 2 erfüllen die Anforderung NICHT.

Optionen 3 und 4 erfüllen die Anforderung. Die Lebensdauer von Rc<Asset> ist nicht an die Lebensdauer von &mut self gebunden. Ähnlich ist die Lebensdauer von AssetHandle nicht an die Lebensdauer von &mut self gebunden.

Vorhersehbare Asset-Deallokation

Wählen Sie jede Designoption aus, die die folgende Anforderung erfüllt:

Anforderung: Es ist wichtig, dass alle Assets zu einem einzigen, vorhersehbaren Zeitpunkt deallokiert werden.

Um alle Assets zu einem einzigen Zeitpunkt zu deallokieren, muss der AssetManager das exklusive Eigentum über sie behalten. Wenn der AssetManager also gelöscht wird (oder anderweitig angewiesen wird, Assets zu deallokieren), ist garantiert, dass alle Assets sicher gelöscht werden können. Optionen 1, 2 und 4 erfüllen diese Anforderung. Option 4 würde erfordern, dass AssetManager::get panikt, wenn der Client manager.get(handle) aufruft, nachdem ein Asset deallokiert wurde. Wenn die reale Möglichkeit besteht, dass ein Client dies tut, wäre eine andere Alternative, dass get Option<&Asset> zurückgibt.

Option 3 erfüllt diese Anforderung NICHT. Referenzgezählte Pointer gehören gemeinsam jedem Eigentümer eines Rc<Asset>. Der AssetManager hat keine gute Möglichkeit sicherzustellen, dass alle Assets zum Zeitpunkt der Deallokation keine anderen Eigentümer haben.