C# jest językiem wysokiego poziomu, w którym przygotowano liczne gotowe komponenty i usprawnienia, jakich nie znajdziemy u konkurencji. Takie podejście ma sporo zalet, ponieważ nie musimy przejmować się wieloma rzeczami, które w innych językach musielibyśmy napisać sami. Oczywiście takie podejście ma również wady — w sytuacji gdy przydałoby się coś zmienić w gotowym komponencie, do którego kodu nie mamy dostępu. Nie o tym jest jednak dzisiejszy wpis.
Jedną z istotnych zalet tego języka jest rozbudowany mechanizm zarządzania pamięcią, który robi wiele rzeczy za użytkownika. Tak naprawdę przeciętny programista C# nie musi zanadto przejmować się alokacją pamięci. Nie wiemy, kiedy dokładnie zwalniane są określone obiekty i ile zajmują one pamięci. Oczywiście, można uzyskać dostęp do takich informacji, choćby wykorzystując profiler czy niektóre klasy, ale w większości przypadków nie jest to potrzebne w codziennej pracy. Można powiedzieć, że dla wielu programistów C# w ich codziennym działaniu aspekt zarządzania pamięcią nie jest w ogóle problemem.
Nie powinniśmy jednak do końca zapominać o alokacji pamięci w C#. Mimo że wiele się w tym przypadku dzieje poza nami, to w miarę możliwości warto kontrolować ten aspekt. Jest to szczególnie istotne w przypadku aplikacji z interfejsem graficznym, które często przechowują w pamięci kilka ekranów na stosie — użytkownik może do nich wrócić np. za pomocą przycisków zawartych w interfejsie użytkownika.
W takiej sytuacji warto odpinać wszystkie niepotrzebne zdarzenia, odpowiednio używać bindingów (jeśli można, to w ogóle ich nie używać), a także poprawnie implementować interfejs IDisposable. I właśnie temu ostatniemu elementowi chcę poświęcić dzisiejszy wpis.
Interfejs IDisposable
Garbage Collector, dostępny w całym .Net Frameworku, działa na tyle dobrze, że łatwo o nim zapomnieć. Warto jednak nauczyć się z nim dobrze współpracować i wykorzystywać jego możliwości. Niezbędna w tym celu jest poprawna implementacja interfejsu IDisposable, którego bazowa postać bywa niewystarczająca, jeśli rozważamy właściwe zwalnianie zasobów zarządzanych i niezarządzanych.
Poniżej standardowa implementacja:
public class DisposableStandard : IDisposable { #region IDisposable public void Dispose() { // tu zwalniamy wszystkie zasoby } #endregion }
Takie rozwiązanie, choć niesatysfakcjonujące, spełnia założenia interfejsu. Spójrzcie jednak na rozszerzoną i zalecaną implementację:
public class DisposableExtended : IDisposable { private bool isDisposed = false; public void Dispose() { this.Dispose(true); GC.SupressFinalize(this); } protected void Dispose(bool disposing) { if(!this.isDisposed) { if(disposing) { // tu zwalniamy zasoby zarządzane (standardowe klasy) } // tu zwalniamy zasoby niezarządzane (np. strumienie, obiekty COM itp.) } this.isDisposed = true; } ~DisposableExtended() { this.Dispose(false); } }
Mamy tutaj wyraźny podział na zasoby zarządzane oraz niezarządzane. Ponadto pojawił się destruktor, który zwalnia zasoby niezarządzane użyte w naszej klasie.
Powyższą implementację można zastosować w większości rozwiązań pisanych w C#. W rozwiązaniach przeznaczonych dla .Net Core nie będzie można skorzystać z poniższego polecenia:
GC.SupressFinalize(this);
Klasy, która implementuje interfejs IDisposable, możemy używać w bloku using. Sporym plusem takiego rozwiązania jest to, że po wyjściu z bloku automatycznie zostanie wywołana metoda Dispose na utworzonym w tym obszarze obiekcie. W ten sposób możemy używać tylko klas, które implementują interfejs IDisposable.
using(var de = new DisposableExtended()) { // operacje na obiekcie de. Zostanie on zniszczony po wyjściu z bloku }
Szukasz informacji o C#? Kliknij poniżej: