W .NET 4.0 dodano (mało chyba popularną) klasę MemoryCache służącą do buforowania danych. Wcześniej programiści znali podobną klasę w ASP.NET. Od wersji 4.0 została ona wydzielona i można z niej teraz korzystać we wszystkich typach aplikacji – także WPF i WinForms.  Za pomocą MemoryCache można ustawić czas  ważności danych w buforze za pomocą czasu absolutnego,  priorytetu, monitorów, które unieważniają dane np. na podstawie zmiany pliku na dysku lub tzw. SlidingExpiration – czasu który upłynął od ostatniego odpytania bufora.

Same API jest bardzo proste. Na przykład aby dodać element do bufora wystarczy:

CacheItemPolicy cachePolicy = new CacheItemPolicy();
cachePolicy.AbsoluteExpiration = new DateTimeOffset(new DateTime(2012, 11, 1));
MemoryCache.Default.Add("klucz", "dowolna wartosc", cachePolicy);

Z kolei aby odczytać z bufora wartość:

string value = MemoryCache.Default.Get("klucz").ToString();

Kilka wyjaśnień:

1. AbsoluteExpiration – oznacza kiedy dana wartość zostanie skasowana z bufora (absolutny czas ważności).
2. MemoryCache.Default zwraca domyślny bufor – zwykłe aplikacja potrzebuje tylko jednego MemoeryCache i nie ma potrzeby tworzenia własnych obiektów MemoeryCache.
3. Gdy bufor straci ważność metoda Get zwraca NULL – stąd powyższy kod jest niebezpieczny ponieważ może wywołać wyjątek null reference  przez ToString().

Oprócz absolutnego czasu ważności możemy zdefiniować wspomniany SlidingException:

CacheItemPolicy cachePolicy = new CacheItemPolicy();
cachePolicy.SlidingExpiration = new TimeSpan(0, 1, 0);

Powyższy kod oznacza, że jeśli wpis w buforze nie będzie wykorzystany (poprzez metodę Get) ani razu w ciągu minuty to zostanie unieważniony.

Do dyspozycji mamy również kilka różnych monitorów:

List<string> paths=new List<string>();
paths.Add("c:\\1.txt");
HostFileChangeMonitor fileChangeMonitor=new HostFileChangeMonitor(paths);
cachePolicy.ChangeMonitors.Add(fileChangeMonitor);

HostFileChangeMonitor sprawdza  czy przekazane przez parametr paths, pliki lub foldery nie zostały zmienione. Monitorowane są m.in. nazwy plików (lub katalogów), rozmiar, ACL czy pliki w danym katalogu. Ponadto do despocji mamy jeszcze następujący monitory:

1. CacheEntryChangeMonitor – unieważnia wpis w przypadku gdy jakiś inny wpis zostały zmieniony.
2. SqlChangeMonitor – monitorowanie bazy SQL Server.

Do dyspozycji jest również priorytet, który aktualnie przyjmuje dwie wartości (wydaje mi się, że nazwy mówią same za siebie):

cachePolicy.Priority = CacheItemPriority.Default;
cachePolicy.Priority = CacheItemPriority.NotRemovable;

Oprócz poszczególnych elementów w buforze, można również konfigurować bufor jako całość. Domyślny bufor (zwrócony poprzez właściwość Default) można wyłącznie skonfigurować za pomocą XML (np. w App.config dla aplikacji desktop):

<configuration>
  <system.runtime.caching>
    <memoryCache>
      <namedCaches>
          <add name="default" 
               cacheMemoryLimitMegabytes="0" 
               physicalMemoryPercentage="0"
               pollingInterval="00:02:00" />
      </namedCaches>
    </memoryCache>
  </system.runtime.caching>
</configuration>

Własne bufory można konfigurować zarówno z poziomu pliku XML jak i konstruktora.

C# 4.0 dostarcza kilka nowych możliwości jeśli chodzi o parametry i ich przekazywanie. Pierwszym rozszerzeniem jest możliwość zdefiniowania opcjonalnych argumentów (dlaczego musieliśmy tak długo na to czekać?):

private void ShowText(string text="Hello world")
{
  MessageBox.Show(text);
}

Teraz możemy wywołać metodę ShowText dostarczając własny argument lub pomijać go i wykorzystując wartość domyślną (“Hello World”):

ShowText("Custom Text");
ShowText(); // również poprawne

Named arguments umożliwiają przekazanie parametrów do wywołania funkcji za pomocą ich nazwy (przekazywane wartości poprzedzamy nazwą parametru oraz dwukropkiem). Wyobraźmy sobie następującą funkcję:

private void ShowText(string text1, string text2 = "Hello world 2", string text3="Hello world3")
{
  MessageBox.Show(string.Format("text1:{0}", text1));
  MessageBox.Show(string.Format("text2:{0}", text2));
  MessageBox.Show(string.Format("text3:{0}", text3));
}

Jak przekazać funkcji wymagany parametr text1 oraz opcjonalny text3 a jednocześnie wykorzystać domyślną wartość text2? Poniższa próba zakończy się fiaskiem:

ShowText("text1", "text3");

text1 zostanie ustawiony na “text1” z kolei text2 na “text3” – a text3 posiadać będzie wartość domyślną czego nie chcemy. Z pomocą przychodzą wspomniane named arguments:

ShowText("text1", text3:"text3");

Zamiast przekazywać argumenty bazując na ich kolejności, wykorzystujemy po prostu ich nazwę. Ponadto jeśli nasza funkcja przyjmuje dużą liczbę parametrów (np. 5) warto skorzystać z named arguments aby za pomocą nazw wyjaśnić co te argumenty robią. Np. następująca funkcja na pierwszy rzut oka może niewiele mówić:

UpdateZoom(1,5,4);

Z kolei za pomocą named arguments możemy stworzyć samo-komentujący się kod:

UpdateZoom(minZoom:1,maxZoom:5,currentZoom:4);

Jak widać drugie wywołanie jest bardziej czytelne i więcej mówi o tym co funkcja wewnątrz robi.

Wróćmy na chwilę jeszcze do domyślnych argumentów. Opcjonalne wartości  zostały  wprowadzone również z myślą o COM. Wcześniej wdrożenie bibliotek COM do c# było czasami bardzo niewygodne. Klasy z COM mają bardzo dużo metod z wartościami domyślnymi, które zwykle nie są przekazywane przez programistę. Przykład (źródło MSDN):

Document d = new Document();
object filename = "Foo.docx";
object missing = Type.Missing;

d.SaveAs(ref filename, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing);

W c# 4.0 kod uprości się do:

Document d = new Document();

d.SaveAs(FileName: "Foo.docx");

W bibliotekach .NET często widzimy wiele podobnych sygnatur różniących się tylko liczbą parametrów. Programiści w ten sposób (przeładowywaniem metod) radzili sobie z brakiem opcjonalnych argumentów. Od 4.0 możemy znaczącą skrócić kod, dostarczając wyłącznie jedną metodę ale za to z opcjonalnymi wartościami. Czyli zamiast:

private void ShowText(string text1)
{
  ShowText(text1, "Hello world 2", "Hello world 3");
}
private void ShowText(string text1,string text2)
{
  ShowText(text1, text2, "Hello world 3");
}
private void ShowText(string text1, string text2, string text3)
{
  MessageBox.Show(string.Format("text1:{0}", text1));
  MessageBox.Show(string.Format("text2:{0}", text2));
  MessageBox.Show(string.Format("text3:{0}", text3));
}

Wystarczy:

private void ShowText(string text1, string text2 = "Hello world 2", string text3="Hello world3")
{
  MessageBox.Show(string.Format("text1:{0}", text1));
  MessageBox.Show(string.Format("text2:{0}", text2));
  MessageBox.Show(string.Format("text3:{0}", text3));
}

XMLSerializer jest bardzo wygodnym sposobem zapisu klas w formie pliku XML. Rozważmy następujący przykład:

public interface IData
{
    // jakies dekleracje
    string Text{get;set;}
}
public class Data: IData
{
    public string Text{get{...}set{...}}
}
public class ClassA
{
    public IData Data{get;set;}
}

Niestety po próbie serializacji dostaniemy wyjątek mówiący, że nie można zapisywać interfejsu. Jaka jest odpowiedź na pytanie zadanie w poście? NIE da się!

W poście mam zamiar pokazać wyłącznie pewne sposoby obejścia tego – dalekie od ideału. Po pierwsze możemy stworzyć klasę abstrakcyjną zamiast interfejsu:

public abstract class DataBase
{
    // jakies dekleracje
    public abstract string Text{get;set;}
}
public class Data: DataBase
{
    public override string Text{get{...}set{...}}
}
public class ClassA
{
    public DataBase Data{get;set;}
}

Oczywiście ma to swoje wady – możemy dziedziczyć tylko po jednej klasie (klasa abstrakcyjna jest typem) itp. Jednak dzięki temu możemy obejść wymogi XMLSerialzer i wciąż mieć bazowy “interfejs”. Jeśli jednak w innych miejscach kodu wciąż chcemy odwoływać się za pomocą interfejsu możemy dodać do naszej hierarchii również interfejs:

public interface IBase
{
    string Text[get;set;}
}
public abstract class DataBase:IBase
{
    // jakies dekleracje
    public abstract string Text{get;set;}
}
public class Data: DataBase
{
    public override string Text{get{...}set{...}}
}
public class ClassA
{
    public DataBase Data{get;set;}
}

Niestety jest to jeden z tych postów, który nie dostarcza odpowiedzi na postawione pytanie . Po prostu jej nie ma… Jeśli faktycznie jest to niezbędne w architekturze pozostaje tylko rozszerzenie lub napisanie od nowa własnego serializatora.

Zanim przejdę do wyjaśnienia kilku usprawnień wprowadzonych w C# 4.0 spróbujmy zdefiniować pojęcia kowariancji oraz kontrawariancji. Te skomplikowane pojęcia odnoszą się po prostu do typów konwersji.

Kowariancja to określenie typu konwersji  z bardziej specyficznego do bardziej ogólnego(klasy). Kontrawariancja to oczywiście przeciwieństwo (bazowa klasa do pochodnej). Jako przykład kowariancji w c# można pokazać np.:

object text = "Hello World!";

Deklaracja text jest kowariancją ponieważ możemy przypisać do zmiennej tylko takie same lub bardziej specyficzne typy (string jest subtypem object). Podobnie tablice są przykładem kowariancji –jesteśmy w stanie użyć następującej deklaracji:

object[] strings = new string[1];

Załóżmy, że mamy 3 klasy (classA, classB, classC):

class classA{}
class classB:classA
class classC:classB

Oraz następującą metodę:

public classB Method(classB parameter)
{
    // logika
}

Typ zwracany jest zawsze kowariancją. Możemy zatem wykorzystać takie konstrukcję:

classB b = Method(par);
classA a = Methhod(par);

Kowariancja czyli konwersja z bardziej precyzyjnego (classA) do bardziej ogólnego(classB). Z kolei argumenty (parametry) są zawsze kontrawariancją:

Method(new classB());
Method(new classC());

Nie możemy przekazać jako parametr wartości bardziej ogólnej (classA). Mamy sytuacje odwrotną i jedynymi dozwolonymi wartościami są klasy bardziej specyficzne.

Typy generyczne w c# 3.0 były  invariant (neutralne, niezmienne). Oznacza to, że nie może nastąpić żadna konwersja. Jeśli metoda zwraca IEnumarable<classB> wyłącznie takowy typ może zostać użyty:

private IEnumerable<classB> Method()
{
    return null;
}
//
IEnumerable<classA> listA = Method(); // Błąd - typy generyczne w c# 3.0 nie są kowariancją
IEnumerable<classB> listB = Method(); // OK - invariant
IEnumerable<classC> listC = Method(); // Błąd - typy generyczne w c# 3.0 nie są kontrawariancją

W c# 4.0 typy generyczne mogą jednak zostać zdefiniowane jako kowariancja. Interfejs IEnumarable jest przykładem kontrawariancji i jeśli utworzymy nowy projekt w VS 2010 w wersji c# 4.0 poniższy kod będzie całkowicie poprawny:

IEnumerable<classA> listA = Method(); // W wersji C# 4.0 poprawne!
IEnumerable<classB> listB = Method();    

Kowariancję w typach generycznych w c# 4.0 oznacza się słowem kluczowym out. Dlatego też, IEnumarable jest zdefiniowany następująco:

public interface IEnumerable<out T> // zamiast public interface IEnumerable<T> 

Warto również wspomnieć, że tylko interfejsy oraz delegates mogą używać słowa kluczowego out.

To nie wszystko jednak… W c# 4.0 można również zdefiniować kontrawariancję za pomocą słowa in:

interface ICustomGenericType<in T>
{
}

Teraz poprawna stanie się następująca konstrukcja:

private ICustomGenericType<classB> Method()
{
    return null;
}

ICustomGenericType<classB> listB = Method();
ICustomGenericType<classC> listC = Method();

Może komuś to się przyda a jeśli nie to przynajmniej będzie wiedział dlaczego pewien kod kompiluje się w c# 4.0 a w c# 3.0 już nie.