Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
V tradičních objektových systémech se životní cyklus objektů – tj. problémy související s vytvářením a odstraňováním objektů – zpracovává implicitně jazykem (nebo dobou běhu jazyka) nebo explicitně programátory aplikací.
Ve vyvíjejícím se, decentrálně vytvořeném systému tvořený opakovaně použitými komponentami už neplatí, že každý klient nebo dokonce každý programátor vždy "ví," jak se vypořádat s životností komponenty. Pro klienta se správnými oprávněními zabezpečení je stále relativně snadné vytvářet objekty prostřednictvím jednoduchého požadavku, ale odstranění objektu je zcela další věc. Není nutně jasné, pokud už objekt není potřeba a měl by být odstraněn. (Čtenáři obeznámení s programovacími prostředími s automatickým uvolňováním paměti, jako je Java, mohou nesouhlasit. Objekty Java však nezasahují do hranic počítače nebo dokonce procesů, a proto je uvolňování paměti omezeno na objekty žijící v prostoru jediného procesu. Kromě toho Java vynucuje použití jednoho programovacího jazyka.) I když původní klient už objekt nepoužívá, nemůže objekt jednoduše vypnout, protože na něj můžou mít stále odkaz některé další klienty.
Jedním ze způsobů, jak zajistit, že objekt už není potřeba, je plně spoléhat na podkladový komunikační kanál, který informuje systém, když všechna spojení na objekt pro meziprocesní či mezinální komunikaci zmizela. Schémata, která tuto metodu používají, jsou však nepřijatelná z několika důvodů. Jedním z problémů je, že by mohlo vyžadovat velký rozdíl mezi programovacím modelem mezi procesy a mezi sítěmi a programovacím modelem s jedním procesem. V programovacím modelu mezi procesy nebo mezi sítěmi by komunikační systém poskytoval háky potřebné ke správě životnosti objektů, zatímco v programovacím modelu s jedním procesem jsou objekty přímo propojené bez jakéhokoli komunikačního kanálu. Dalším problémem je, že toto schéma může také vést k vrstvě softwaru poskytovaného systémem, která by v případě procesu ovlivnila výkon komponent. Mechanismus založený na explicitním monitorování by navíc neměl tendenci škálovat směrem k mnoha tisícům nebo milionům objektů.
Com nabízí škálovatelný a distribuovaný přístup k této sadě problémů. Klienti oznamují objektu, když ho používají a kdy s ním skončí, a objekty se samy odstraní, když už nejsou potřeba. Tento přístup vyžaduje, aby všechny objekty počítaly odkazy na sebe. Programovací jazyky, jako je Java, které v sobě zahrnují vlastní schémata správy životnosti, jako je například uvolňování paměti, můžou využít referenční počítání COM k interní implementaci a použití objektů COM, což programátorovi umožňuje vyhnout se jejich řešení.
Stejně jako aplikace musí uvolnit paměť, která byla přidělena, jakmile se paměť už nepoužívá, klient objektu je zodpovědný za uvolnění svých odkazů na objekt, pokud už tento objekt není potřeba. V objektově orientovaném systému to klient může provést pouze tím, že objektu poskytne pokyn, aby se osvobodil.
Je důležité, aby byl objekt uvolněn, když se už nepoužívá. Potíže spočívá v určení, kdy je vhodné uvolnit objekt. To je snadné pomocí automatických proměnných (těch přidělených v zásobníku) – nedají se použít mimo blok, ve kterém jsou deklarovány, takže je kompilátor uvolní při dosažení konce bloku. U objektů MODELU COM, které se dynamicky přidělují, je na klientech objektu, aby se rozhodli, kdy už objekt nepotřebují používat – zejména místní nebo vzdálené objekty, které můžou současně používat více klientů. Objekt musí počkat, dokud s ním všichni klienti nedokončí, než se uvolní. Vzhledem k tomu, že objekty MODELU COM jsou manipulovány pomocí ukazatelů rozhraní a mohou být používány objekty v různých procesech nebo na jiných počítačích, systém nemůže sledovat klienty objektu.
Metoda modelu COM určující, kdy je vhodné uvolnit objekt, je ruční počítání odkazů. Každý objekt udržuje počet odkazů, který sleduje, kolik klientů je k němu připojeno – tj. kolik ukazatelů existuje na libovolném rozhraní v jakémkoli klientovi.
Další informace najdete v následujících tématech:
Související témata
-
použití a implementace IUnknown