Skeet J. - C# od podszewki. Wydanie II

b__0. Nazewnictwo jest całkowicie uzależnione od implementacji. Nic nie stoi na przeszkodzie, aby zmienić tę prywatną konwencję, więc być może firma Microsoft zdecyduje się na to w późniejszych wersjach środowiska. Taka zmiana nie powinna niczego zniszczyć, ponieważ nie ma prawa istnieć jakakolwiek zależność od tych nazw metod. Na tym etapie warto również zwrócić uwagę, że listing 5 5 nie odzwierciedla metod anonimowych w rzeczywistym zastosowaniu. Często będziesz je widział jako argumenty innych metod (a nie jako przypisania do zmiennych typu delegatowego) oraz ze znacznie mniejszą liczbą wierszy — w końcu jedną z głównych cech przemawiających za ich użyciem jest zwartość. Zademonstrujemy to na przykładzie metody List.ForEach, która przyjmuje jako parametr Action i wykonuje tę akcję na każdym elemencie listy. Listing 5.6 jest przykładem ekstremalnym — stosuje znaną nam już z listingu 5 5 akcję pierwiastkowania, ale w bardziej zwartej formie. Listing 5.6. Ekstremalny przykład zwartości kodu. Ostrzeżenie: kod mało czytelny! List x = new List(); x.Add(5); x.Add(10); x.Add(15); x.Add(20); x.Add(25); x.ForEach(delegate(int n){Console.WriteLine(Math.Sqrt(n));}); 4

W sekcji 5.5.4 zobaczymy, że chociaż zawsze powstaje nowa metoda, nie zawsze jest ona tworzona w miejscu, w którym się jej spodziewamy.

Akcje delegatów tworzone w miejscu przy użyciu metod anonimowych

183

Wygląda to odrobinę przerażająco, szczególnie że na pierwszy rzut oka sześć ostatnich znaków wygląda, jakby zostały ustawione losowo. Oczywiście widzimy znaczący środek. Przy metodach anonimowych skłaniam się czasem do zerwania z moją codzienną zasadą: „Każdy nawias w swoim własnym wierszu” (tak jak robię to dla właściwości trywialnych), ale nadal pozwalam na odpowiednio dużo białych znaków w wyrażeniu. Ostatni wiersz listingu 5.6 równie dobrze mogłem zapisać w jednaj z dwóch następujących form: x.ForEach(delegate(int n) { Console.WriteLine(Math.Sqrt(n)); } ); x.ForEach(delegate(int n) { Console.WriteLine(Math.Sqrt(n)); });

Oczywiście, pomogłoby już samo dodanie spacji na listingu 5.6. W każdym z tych formatów nawiasy zwykłe i klamrowe są teraz mniej mylące, a część, „która coś robi”, jest teraz odpowiednio uwydatniona. To, jakie formatowanie zastosujesz w swoim kodzie, pozostaje wyłącznie w Twojej gestii, ale zachęcam Cię, abyś przemyślał za każdym razem, w którym miejscu chcesz umieścić akcent, a także przedyskutował to w miarę możliwości z innymi osobami w zespole. Dzięki temu masz szansę osiągnąć spójność w kodzie. Trzeba jednak przyznać, że spójność nie zawsze prowadzi do powstania najbardziej czytelnego kodu — czasami najlepszym rozwiązaniem jest pozostawienie całego wyrażenia w jednym wierszu. Do tej pory nasza interakcja z kodem wywołującym odbywała się przez parametry, a co z wartościami zwracanymi?

5.4.2. Zwracanie wartości z metod anonimowych Delegat Action ma typ zwracany void, zatem nie musieliśmy zwracać czegokolwiek z wnętrza naszych metod anonimowych. Żeby zademonstrować, jak to zrobić, kiedy zajdzie taka potrzeba, posłużymy się delegatem typu Predicate, pochodzącym z .NET 2.0. Jego sygnatura wygląda następująco: public delegate bool Predicate(T obj)

Listing 5.7 przedstawia metodę anonimową tworzącą instancję typu Predicate w celu zwrócenia wyniku mówiącego o tym, czy przekazany argument jest parzysty, czy nie. Predykaty są zwykle stosowane do filtrowania i dopasowywania — kod z listingu 5.7 mógłby na przykład zostać użyty do przefiltrowania listy w taki sposób, aby zawierała jedynie elementy parzyste. Listing 5.7. Zwracanie wartości z metody anonimowej Predicate isEven = delegate(int x) { return x % 2 == 0; }; Console.WriteLine(isEven(1)); Console.WriteLine(isEven(4));

Nowa składnia, którą prezentujemy, jest prawdopodobnie identyczna z tą, której się spodziewałeś — zwracamy wynik, tak jakby metoda anonimowa była zwykłą metodą.

184

ROZDZIAŁ 5

Przyspieszone delegaty

Być może spodziewałeś się deklaracji typu zwracanego w pobliżu słowa kluczowego delegate, ale nie ma takiej potrzeby. Kompilator sprawdza jedynie, czy wszystkie możliwe wartości zwracane są zgodne z zadeklarowanym typem zwracanym delegata, w którego instancję próbuje przekonwertować metodę anonimową. Z CZEGO WŁAŚCIWIE ZWRACAMY WYNIK? Kiedy zwracasz wartość z metody anonimowej, naprawdę robisz to wyłącznie z tej metody, a nie z metody tworzącej instancję delegata. Bądź czujny, bo można łatwo wpaść w pułapkę błędnego założenia, iż napotkanie słowa kluczowego return oznacza wyjście z bieżącej metody. Jak wspomniałem wcześniej, niewiele delegatów w .NET 2.0 zwraca wartości, chociaż — jak zobaczymy w części trzeciej — .NET 3.5 korzysta z tej koncepcji znacznie częściej, szczególnie w LINQ. W przypadku sortowania listy istnieje jeszcze inny, względnie często stosowany typ delegata dostępny w .NET 2.0 — Comparison. Jest to delegatowy odpowiednik interfejsu IComparer. Często potrzebujesz jedynie sortowania według z góry założonego kryterium i tylko w jednym kierunku. W takiej sytuacji wskazana jest możliwość wyspecyfikowania sposobu sortowania w miejscu zamiast udostępniania go całej klasie w postaci metody. Demonstruje to poniższy listing (5.8), którego celem jest wyświetlenie wszystkich plików wewnątrz folderu C:\, posortowanych według nazwy, a następnie (niezależnie) według rozmiaru. Listing 5.8. Używanie metod anonimowych do prostego sortowania plików static void SortAndShowFiles(string title, Comparison sortOrder) { FileInfo[] files = new DirectoryInfo(@"C:\").GetFiles(); Array.Sort(files, sortOrder); Console.WriteLine(title); foreach (FileInfo file in files) { Console.WriteLine(" {0} ({1} bajty)", file.Name, file.Length); }

} ... SortAndShowFiles ("Sortuj po nazwie:", delegate(FileInfo first, FileInfo second) { return first.Name.CompareTo(second.Name); } ); SortAndShowFiles ("Sortuj po rozmiarze:", delegate(FileInfo first, FileInfo second) { return first.Length.CompareTo(second.Length); } );

Gdybyśmy nie korzystali z metod anonimowych, musielibyśmy wydzielić metodę dla każdego typu sortowania. Na szczęście nie musimy — listing 5.8 za każdym razem w miejscu, w którym wywołujemy SortAndShowFiles, jasno stwierdza, co będziemy sortować. Czasami będziesz wywoływał Sort bezpośrednio w miejscu użycia metody anonimowej. W naszym przykładzie wykonywaliśmy tę samą sekwencję operacji — pobieranie, sortowanie i wyświetlanie — dwukrotnie, dlatego umieściłem te kroki (razem z wywołaniem Sort) w metodzie.

Akcje delegatów tworzone w miejscu przy użyciu metod anonimowych

185

Jest pewien skrót syntaktyczny, który czasem może być przydatny, jeżeli nie interesują Cię parametry delegata i nie chcesz ich w ogóle deklarować. Zobaczmy, jak to działa.

5.4.3. Ignorowanie parametrów typu Chcesz zaimplementować delegat, który nie zależy od wartości swoich parametrów. Być może będzie to metoda obsługi zdarzenia, której zachowanie ma sens wyłącznie dla jednego zdarzenia i nie zależy od jego argumentów. Dla przykładu może to być zapisywanie pracy użytkownika. Do tego opisu pasują idealnie metody obsługi zdarzeń z naszego pierwszego przykładu na listingu 5.1. W ich przypadku możesz całkowicie pominąć listę parametrów i użyć jedynie słowa kluczowego delegate, a następnie bloku kodu implementującego akcję. Poniższy listing (5.9) jest odpowiednikiem listingu 5.1 z zastosowaniem skróconej składni. Listing 5.9. Subskrybowanie zdarzeń przy użyciu metod anonimowych z pominięciem parametrów wejściowych Button button = new Button(); button.Text = "Kliknij mnie"; button.Click += delegate { Console.WriteLine("Zwykłe zdarzenie."); }; button.KeyPress += delegate { Console.WriteLine("Zdarzenie klawiatury."); }; button.MouseClick += delegate { Console.WriteLine("Zdarzenie myszy."); }; Form form = new Form(); form.AutoSize = true; form.Controls.Add(button); Application.Run(form);

Normalnie musielibyśmy zapisać każdą subskrypcję tak: button.Click += delegate (object sender, EventArgs e) { ... };

To duże marnotrawstwo miejsca, i to bez żadnego powodu — nie potrzebujemy wartości parametrów, zatem kompilator odpuszcza nam ich specyfikowanie. Uważam ten skrót za szczególnie użyteczny podczas implementowania moich własnych zdarzeń. Irytuje mnie konieczność sprawdzania, czy delegat istnieje (jest różny od null) przed wywołaniem zdarzenia. Jednym ze sposobów na ominięcie tego problemu jest doprowadzenie do sytuacji, w której zdarzenie startuje z przypisaną metodą obsługi, która nie jest potem nigdy usuwana. Tak długo, jak metoda obsługi jest pusta, nie tracimy nic, oprócz niezauważalnego spadku wydajności. Przed C# 2 osiągnięcie takiego efektu wymagało jawnego stworzenia metody z odpowiednią sygnaturą, co raczej nie równoważyło korzyści… ale teraz możesz napisać taki kod: public event EventHandler Click = delegate { };

Od tego momentu możesz wywoływać Click bez konieczności testowania na obecność pustej referencji. Powinieneś mieć świadomość istnienia jednej pułapki, jaka wiąże się z powyższym mechanizmem — jeżeli metoda anonimowa może być przekonwertowana na wiele typów delegatów (na przykład przez wywoływanie różnych przeciążeń metody), kompilator potrzebuje dodatkowej pomocy. Aby pokazać, co mam na myśli, rozważymy

186

ROZDZIAŁ 5

Przyspieszone delegaty

pewien kłopotliwy przypadek — rozpoczynanie nowego wątku — jaki omawialiśmy przy okazji konwersji grupy metod. W .NET 2.0 istnieją cztery konstruktory wątku: public public public public

Thread(ParameterizedThreadStart start) Thread(ThreadStart start) Thread(ParameterizedThreadStart start, int maxStackSize) Thread(ThreadStart start, int maxStackSize)

Dwoma możliwymi typami delegatów są: public delegate void ThreadStart() public delegate void ParameterizedThreadStart(object obj)

Teraz przyjrzyj się następującym trzem próbom utworzenia nowego wątku: new Thread(delegate() new Thread(delegate(object o) new Thread(delegate

{ Console.WriteLine("t1"); } ); { Console.WriteLine("t2"); } ); { Console.WriteLine("t3"); } );

Dwa pierwsze wywołania zawierają listę parametrów — kompilator wie, że nie może przekonwertować metody anonimowej w pierwszym wierszu na ParameterizedThread ´Start ani też metody z drugiego wiersza na ThreadStart. Te dwa wiersze kompilują się, ponieważ istnieje tylko jedno możliwe przeciążenie konstruktora dla każdego z nich. Trzeci wiersz jest niejednoznaczny — metoda anonimowa może być przekonwertowana na jeden lub drugi typ delegata, zatem mogą być zastosowane oba jednoparametrowe konstruktory wątku. W takiej sytuacji kompilator rozkłada ręce i zgłasza błąd. Problem ten możesz rozwiązać przez jawne wskazanie listy parametrów lub zrzutowanie metody anonimowej na odpowiedni typ delegata. Mam nadzieję, że to, co zobaczyłeś do tej pory na temat metod anonimowych, sprowokowało Cię do przemyśleń na temat własnego kodu i rozważenia, gdzie opisane powyżej techniki mógłbyś zastosować z pożytkiem dla siebie. Nawet gdyby metody anonimowe potrafiły wykonywać wyłącznie zadania opisane do tej pory, i tak byłyby bardzo użyteczne. Świat nie kończy się jednak tylko na unikaniu konieczności pisania nadmiarowych metod w kodzie. W C# 2 metody anonimowe — poprzez zmienne przechwycone — implementują mechanizm znany w innych językach jako domknięcia. Nasz następny podrozdział wyjaśnia oba pojęcia i opisuje, jak niesamowicie funkcjonalne (i mylące przy braku dostatecznej uwagi) potrafią być metody anonimowe.

5.5.

Przechwytywanie zmiennych w metodach anonimowych Nie lubię ostrzegać, ale myślę, że w tym miejscu warto to zrobić: jeżeli jest to dla Ciebie nowy temat, rozpocznij go tylko wtedy, gdy jesteś dostatecznie przebudzony i masz czas, żeby zająć się nim na spokojnie. Nie chcę tu wszczynać niepotrzebnego alarmu. Bądź pewien, że nie ma tutaj nic tak niewyobrażalnie trudnego, co przy odrobinie wysiłku z własnej strony miałoby Ci przeszkodzić w zrozumieniu zagadnienia. Chodzi jedynie o to, że przy pierwszym podejściu zmienne przechwycone mogą być trochę mylące, głównie ze względu na pewną niezgodność z posiadaną już wiedzą i intuicją.

Przechwytywanie zmiennych w metodach anonimowych

187

Nie poddawaj się jednak! Wynikający z ich użycia zysk w postaci prostszego i bardziej czytelnego kodu potrafi być niewyobrażalnie wielki. Ten temat będzie miał również kluczowe znaczenie, kiedy dojdziemy do wyrażeń lambda i LINQ w C# 3, warto zatem zainwestować w niego swój czas. Zacznijmy od kilku definicji.

5.5.1. Definicja domknięcia i różnych typów zmiennych Koncepcja domknięcia nie jest nowa. Swoją pierwszą implementację znalazła w języku Scheme, ale ostatnimi czasy zaczęła nabierać większego znaczenia wraz z pojawianiem się w coraz większej liczbie nowoczesnych języków. Podstawowa idea polega na tym, że funkcja5 jest w stanie współdziałać ze środowiskiem poza parametrami, które zostały do niej przekazane. I to właściwie wszystko na tym poziomie abstrakcji, ale żeby zrozumieć, jak domknięcia są stosowane w C# 2, potrzebujemy kilku dodatkowych określeń: Zmienna zewnętrzna to zmienna lokalna lub parametr6, swoim zasięgiem obejmujące metodę anonimową. Referencja this jest również liczona jako

zmienna zewnętrzna względem dowolnej metody anonimowej wewnątrz elementu instancji danej klasy. Przechwycona zmienna zewnętrzna (zwykle skracana do miana zmiennej

przechwyconej) jest zmienną zewnętrzną używaną w kontekście metody anonimowej. Zatem wracając do domknięć, część mówiąca o funkcji dotyczy metod anonimowych, natomiast środowiskiem są przechwycone przez nie zmienne. Są to dosyć suche fakty, przez co trudno sobie to wszystko wyobrazić, ale najważniejszą rzeczą do zapamiętania jest to, że metoda anonimowa może używać zmiennych lokalnych zdefiniowanych w tej samej metodzie, która deklaruje tę metodę anonimową. Nie brzmi to jak coś wyjątkowego, ale w wielu sytuacjach okazuje się bardzo pomocne — masz pod ręką całą wiedzę kontekstową bez konieczności definiowania dodatkowych typów danych tylko po to, aby przekazać dane, które już znasz. Obiecuję, że wkrótce zobaczymy kilka użytecznych przykładów, ale wcześniej warto zajrzeć do kodu, który pozwoli unaocznić przedstawione definicje. Listing 5.10 pokazuje przykład z pewną liczbą zmiennych lokalnych. Jest to samodzielna metoda, można ją zatem uruchomić bez dodatkowych zależności. Na razie nie będę wyjaśniał, co robi i w jaki sposób. Chcę jedynie przedyskutować, jak są klasyfikowane różne zmienne. Dla prostoty skorzystamy ponownie z delegata typu MethodInvoker. Listing 5.10. Przykłady różnych rodzajów zmiennych w odniesieniu do metod anonimowych void EnclosingMethod() Zmienna zewnętrzna { (zmienne nieprzechwycone) int outerVariable = 5; string capturedVariable = "przechwycona"; Zmienna zewnętrzna przechwycona przez metodę anonimową 5

W ogólnym znaczeniu informatycznym (bez związku z terminologią C#).

6

Wyłączając parametry ref i out.

188

ROZDZIAŁ 5

Przyspieszone delegaty if (DateTime.Now.Hour == 23) { int normalLocalVariable = DateTime.Now.Minute; Console.WriteLine(normalLocalVariable); } MethodInvoker x = delegate() { string anonLocal = "anonimowa zmienna lokalna"; Console.WriteLine(capturedVariable + anonLocal); }; x(); }

Zmienna lokalna zwykłej metody

Zmienna lokalna metody anonimowej Przechwycenie zmiennej zewnętrznej

Przeanalizujmy wszystkie zmienne — od najprostszych do najtrudniejszych: normalLocalVariable ( ) nie jest zmienną zewnętrzną, ponieważ w jej zakresie

nie ma metod anonimowych. Zachowuje się identycznie jak każda zmienna lokalna do tej pory. anonLocal ( ) również nie jest zmienną zewnętrzną. Jej zasięg jest lokalny względem metody anonimowej, a nie względem EnclosingMethod. outerVariable ( ) jest zmienną zewnętrzną, ponieważ w jej zasięgu znajduje

się deklaracja metody anonimowej. Nie jest ona jednak zmienną przechwyconą, ponieważ metoda anonimowa nie odwołuje się do niej. capturedVariable ( ) jest zmienną zewnętrzną, ponieważ w jej zasięgu znajduje się metoda anonimowa i jest przechwycona przez fakt użycia jej w miejscu oznaczonym numerem ( ). Znamy już zatem terminologię, ale wciąż nie zbliżyliśmy się do zrozumienia celu istnienia zmiennych przechwyconych. Przypuszczam, że jesteś w stanie przewidzieć wynik działania listingu 5.10, są jednak jeszcze inne przypadki, które mogłyby Cię zaskoczyć. Zaczniemy od prostego przykładu, a następnie na jego podstawie będziemy budować bardziej skomplikowane przypadki.

5.5.2. Analiza zachowania zmiennych przechwyconych W metodzie anonimowej jest przechwytywana faktyczna zmienna, a nie jej wartość w chwili utworzenia instancji delegata. Później zobaczymy, że ma to daleko idące konsekwencje, ale nim to nastąpi, chcemy dokładnie zrozumieć, co to znaczy, i dlatego przyjrzymy się względnie prostej sytuacji. Na listingu 5.11 znajdują się zmienna przechwycona oraz metoda anonimowa, która ją modyfikuje i wyświetla. Zobaczymy, że modyfikacje zmiennej na zewnątrz metody anonimowej są widoczne w jej wnętrzu i na odwrót. Listing 5.11. Odwoływanie się do zmiennej wewnątrz i na zewnątrz metody anonimowej string captured = "przed utworzeniem x"; MethodInvoker x = delegate { Console.WriteLine(captured);

Przechwytywanie zmiennych w metodach anonimowych

189

captured = "zmiana przez x"; }; captured = "bezpośrednio przed wywołaniem x"; x(); Console.WriteLine(captured); captured = "przed drugim wywołaniem"; x();

Wynik działania programu z listingu 5.11 jest następujący: bezpośrednio przed wywołaniem x zmiana przez x przed drugim wywołaniem

Zobaczmy, co się dzieje. Na początku deklarujemy zmienną captured i ustawiamy jej wartość, stosując zupełnie zwyczajny literał łańcuchowy. Do tego momentu nic specjalnego się nie dzieje. Następnie deklarujemy x i ustawiamy jego wartość, używając metody anonimowej, która przechwytuje zmienną captured. Instancja delegata wyświetla zawsze bieżącą wartość zmiennej captured, a następnie zmienia jej wartość na łańcuch "zmiana przez x". Pamiętaj, że utworzenie instancji delegata nie powoduje wykonania metody anonimowej. Teraz, aby się upewnić, że samo utworzenie instancji delegata nie spowodowało odczytania jej wartości i podmiany na nową, zmieniamy wartość captured na łańcuch "bezpośrednio przed wywołaniem x". Następnie wywołujemy pierwszy raz x. Instancja delegata czyta wartość zmiennej captured i wyświetla ją na ekranie — pierwszy wiersz naszego wyniku. Następnie zmienia wartość captured na "zmiana przez x" i wychodzi. Po zakończeniu metody anonimowej jest kontynuowana zwykła metoda. Wyświetla bieżącą wartość captured, dając nam drugi wiersz wyniku. Dalej metoda zmienia ponownie wartość zmiennej captured (tym razem na "przed drugim wywołaniem") i wywołuje kolejny raz x. Wyświetlana jest bieżąca wartość captu ´red i pojawia się ostatni wiersz wyniku. Instancja delegata zmienia wartość captured na "zmiana przez x" i wychodzi. W tym momencie kończy się kod metody i całego programu. Sporo detali odnośnie do działania względnie krótkiego fragmentu kodu, ale istotna jest tak naprawdę jedna rzecz: zmienna przechwycona jest tą samą zmienną, której używa pozostała część metody. Dla niektórych ludzi jest to idea trudna do uchwycenia, inni przyswajają ją bez problemu. Nie przejmuj się, jeżeli nie wyłapałeś tego podstępu za pierwszym razem — wszystko w swoim czasie. Załóżmy, że do tej pory zrozumiałeś wszystko bez problemu, ale pewnie się zastanawiasz, czemu miałoby służyć takie zachowanie. Nadeszła pora, aby przyjrzeć się jakiemuś rzeczywistemu przykładowi.

5.5.3. Jaki cel mają zmienne przechwycone? Ujmując to najprościej, zmienne przechwycone eliminują konieczność pisania nadmiarowych klas wyłącznie w celu zapisania informacji potrzebnych delegatowi, oprócz danych przekazanych przez parametry, do wykonania swojej pracy. Przed pojawieniem się ParameterizedThreadStart uruchomienie nowego wątku (niebędącego elementem

190

ROZDZIAŁ 5

Przyspieszone delegaty

puli wątków — ang. thread pool) i przekazanie mu pewnych informacji — na przykład adresu strony do pobrania — wymagało utworzenia dodatkowego typu do przechowywania adresu URL i umieszczenia akcji instancji delegata ThreadStart wewnątrz tego typu. Nawet mając ParameterizedThreadStart, Twoja metoda musiała przyjąć parametr typu object i zrzutować go do typu, którego oczekiwałeś. Był to dosyć brzydki sposób osiągania czegoś, co powinno być zupełnie proste. W ramach kolejnego przykładu załóżmy, że masz listę osób i chciałbyś napisać metodę, która zwróci drugą listę zawierającą wyłącznie osoby poniżej określonego wieku. List posiada metodę o nazwie FindAll, która zwraca inną listę wszystkich elementów pasujących do pewnego predykatu. Istnienie List.FindAll przed wprowadzeniem metod anonimowych i zmiennych przechwytywanych nie miałoby za bardzo sensu, a to ze względu na przeszkody, jakie trzeba byłoby pokonać w celu stworzenia delegata odpowiadającego naszym potrzebom. Znacznie prościej byłoby napisać ręcznie całą logikę iterującą i kopiującą dane. W C# 2 to zadanie jest zupełnie łatwe: List FindAllYoungerThan(List people, int limit) { return people.FindAll(delegate (Person person) { return person.Age < limit; } ); }

Tutaj wewnątrz instancji delegata przechwytujemy parametr limit. Gdybyśmy posiadali metody anonimowe, ale bez obsługi zmiennych przechwyconych, moglibyśmy wykonać test w oparciu o wartość wpisaną na sztywno, ale nie w oparciu o wartość przekazaną do metody jako parametr. Mam nadzieję, że zgodzisz się ze mną, iż to podejście jest schludniejsze. Wyraża dokładnie to, co chcemy zrobić, przy znacznie mniejszej ilości kodu opisującego, jak ma to być zrobione, w porównaniu do kodu realizującego to samo zadanie w C# 1. (Trzeba jednak przyznać, że C# 3 robi to jeszcze schludniej)7. Sytuacje, w których zachodzi potrzeba zapisania czegoś do przechwyconej zmiennej, należą do rzadkości, ale z całą pewnością mogą mieć miejsce. Nadal wszystko jasne? To dobrze. Do tej pory używaliśmy instancji delegatów wyłącznie w metodach, które je tworzyły. Taka sytuacja nie nastręcza wielu problemów odnośnie do czasu życia przechwyconych zmiennych. Co by się jednak stało, gdyby instancje delegatów mogły się przedostawać do „wielkiego świata”? Jak poradziłyby sobie w sytuacji, kiedy tworząca je metoda zakończyła swoje działanie?

5.5.4. Przedłużone życie zmiennych przechwyconych Najprostszym sposobem poradzenia sobie z tym tematem jest podanie reguły, poparcie jej przykładem, a następnie przemyślenie tego, co mogłoby się stać, gdyby reguła nie istniała. No to jedziemy: Zmienna przechwycona żyje przynajmniej tak długo, jak długo żyje dowolna odwołująca się do niej instancja delegata.

7

Na wypadek gdybyś chciał wiedzieć, robi to tak: return people.Where(person => person.Age < limit);.

Przechwytywanie zmiennych w metodach anonimowych

191

Nie przejmuj się, jeżeli to zdanie do Ciebie nie przemawia. Od czego są przykłady? Listing 5.12 pokazuje metodę, która zwraca instancję delegata. Instancja ta jest tworzona przy użyciu metody anonimowej, która przechwytuje zmienną zewnętrzną. Co się zatem stanie, kiedy delegat zostanie wywołany po powrocie metody? Listing 5.12. Demonstracja przechwyconej zmiennej, której życie zostało wydłużone static MethodInvoker CreateDelegateInstance() { int counter = 5; MethodInvoker ret = delegate { Console.WriteLine(counter); counter++; }; ret(); return ret; } ... MethodInvoker x = CreateDelegateInstance(); x(); x();

Na wynik działania programu z listingu 5.12 składają się liczby 5, 6 i 7, każda w oddzielnym wierszu. Pierwszy wiersz wyniku pochodzi z wywołania instancji delegata wewnątrz metody CreateDelegateInstance, gdzie wartość zmiennej counter jest bezspornie dostępna. Ale co się dzieje po powrocie z metody? Zazwyczaj zakładamy, że counter znajduje się na stosie, zatem kiedy zostaje zniszczona ramka stosu dla CreateDelegate ´Instance, spodziewalibyśmy się, że razem z nią zniknie counter… A jednak kolejne wywołania zwróconej instancji delegata wydają się nadal działać! Sekretem jest, że należy podać w wątpliwość początkowe założenie, iż counter znajduje się na stosie. Nie znajduje się tam. W rzeczywistości kompilator tworzy dodatkową klasę do przechowania tej zmiennej. Metoda CreateDelegateInstance ma referencję do instancji tej klasy, dzięki czemu może używać zmiennej counter. Do tej samej instancji referencję posiada również sam delegat, który jest przechowywany w normalny sposób — na stercie. Zatem instancja klasy nie podlega procesowi sprzątania śmieci tak długo, jak długo sam delegat nie jest gotowy do tego procesu. Niektóre aspekty metod anonimowych są specyficzne dla poszczególnych kompilatorów (różne kompilatory mogą osiągać tę samą semantykę w różny sposób), chociaż trudno sobie wyobrazić, aby to konkretne zachowanie było możliwe do osiągnięcia bez użycia dodatkowej klasy do przechowywania przechwyconej zmiennej. Zauważ, że jeśli przechwycisz jedynie this, nie będą wymagane żadne dodatkowe typy — kompilator stworzy jedynie dodatkową metodę, która będzie działać jak akcja delegata. Tak jak wspominałem wcześniej, nie powinieneś się zbytnio przejmować detalami związanymi ze stosem i stertą, ale warto wiedzieć, czego można się spodziewać po kompilatorze, wyłącznie po to, aby się nie dziwić, jakim sposobem dane zachowanie jest w ogóle możliwe.

192

ROZDZIAŁ 5

Przyspieszone delegaty

Zatem zmienne lokalne mogą żyć nawet po zakończeniu metody. Zastanawiasz się, jaką kolejną rewelację wyciągnę na światło dzienne? A co powiesz na różne delegaty przechwytujące różne instancje tej samej zmiennej? Brzmi niesamowicie, ale do tej pory powinieneś się już do tego przyzwyczaić.

5.5.5. Instancje zmiennej lokalnej Kiedy mam dobry dzień, już po jednym spojrzeniu widzę, że zmienne przechwycone zachowują się dokładnie tak, jak się tego spodziewam. Kiedy mam zły dzień, nadal daję się zaskoczyć, jeśli nie jestem dostatecznie czujny. Gdy pojawiają się problemy, niemal zawsze wynika to z faktu, że zapominam, ile „instancji” zmiennej lokalnej faktycznie utworzyłem. Mówi się, że zmienna lokalna jest instancjonowana za każdym razem, kiedy punkt wykonania dotrze do zasięgu jej deklaracji. Oto prosty przykład porównujący dwa bardzo podobne fragmenty kodu: int single; for (int i = 0; i < 10; i++) { single = 5; Console.WriteLine(single + i); }

for (int I = 0; i < 10; i++) { int multiple = 5; Console.WriteLine(multiple + i); }

Dawniej można było bez namysłu powiedzieć, że oba fragmenty kodu pokazane powyżej są semantycznie identyczne. Rzeczywiście, na ogół zostałyby skompilowane do tej samej postaci kodu IL. Również teraz będzie to prawdą, jeżeli w pobliżu nie znajdą się żadne metody anonimowe. Całe miejsce dla zmiennych lokalnych jest alokowane na stosie w chwili rozpoczęcia metody, zatem nie istnieje żaden dodatkowy koszt wynikający z ponownego deklarowania zmiennej przy każdej iteracji pętli8. W naszej nowej terminologii zmienna single będzie instancjonowana wyłącznie raz, natomiast zmienna multiple będzie miała dziesięć instancji, tak jakby było 10 zmiennych lokalnych, wszystkie o nazwie multiple, utworzonych jedna po drugiej. Jestem pewien, że rozumiesz, dokąd zmierzam — kiedy zmienna zostaje przechwycona, dotyczy to odpowiedniej „instancji” tej zmiennej. Gdybyśmy przechwycili multiple wewnątrz pętli, zmienna przechwycona w pierwszej iteracji byłaby inna od zmiennej przechwyconej za drugim razem itd. Ten efekt pokazuje dokładnie kolejny listing (5.13). Listing 5.13. Przechwytywanie wielokrotnych instancji zmiennej przez wielokrotne delegaty List list = new List(); for (int index = 0; index < 5; index++) { Utworzenie instancji zmiennej counter int counter = index * 10; list.Add(delegate { 8

Moim zdaniem, jeśli nie musisz utrzymywać wartości pomiędzy iteracjami, deklarowanie zmiennej w pętli jest bardziej przejrzyste.

Przechwytywanie zmiennych w metodach anonimowych

Console.WriteLine(counter); counter++; });

Wyświetlenie i zwiększenie przechwyconej zmiennej

foreach (MethodInvoker t in list) { t(); }

Wykonanie wszystkich pięciu instancji delegata

}

list[0](); list[0](); list[0](); list[1]();

193

Ponowne, trzykrotne wykonanie pierwszej instancji delegata

Ponowne wykonanie drugiej instancji delegata

Listing 5.13 tworzy pięć różnych instancji delegata ( ) — po jednym na każdą iterację pętli. Wywołanie instancji delegata powoduje wyświetlenie wartości zmiennej counter, a następnie jej zwiększenie. Ponieważ counter jest zadeklarowana wewnątrz pętli, jest instancjonowana przy każdej iteracji ( ), zatem każdy delegat przechwytuje inną zmienną. W związku z tym, kiedy wywołujemy kolejne instancje delegata ( ), widzimy różne wartości początkowe przypisane do zmiennej counter: 0, 10, 20, 30, 40. Sedno sprawy jest widoczne po powrocie do pierwszej instancji delegata i wykonaniu jej trzy kolejne razy ( ) — wyświetlane wartości (1, 2 i 3) są kontynuowane od miejsca, w którym instancja zmiennej counter została pozostawiona przy ostatnim wywołaniu. Na końcu wykonujemy drugą instancję delegata ( ) i przekonujemy się, że ona również jest kontynuowana od miejsca, w którym zmienna counter tej instancji została pozostawiona, co spowodowało wyświetlenie liczby 11. Zatem każda instancja delegata przechwyciła w tym przypadku inną instancję zmiennej. Zanim opuścimy ten przykład, spieszę dodać, że gdybyśmy zamiast zmiennej counter przechwycili zmienną index (utworzoną na potrzeby pętli), podobna sytuacja nie miałaby miejsca. Wszystkie delegaty współdzieliłyby tę samą zmienną, a wyświetlonym wynikiem byłyby liczby od 5 do 13 (ostatnie przypisanie zmiennej index przed opuszczeniem pętli ustala jej wartość na 5, a następnie każda instancja delegata zwiększa tę samą zmienną). Takie samo zachowanie zobaczylibyśmy dla pętli foreach — zmienna deklarowana w pierwszej części pętli jest instancjonowana wyłącznie raz. W tym miejscu bardzo łatwo można popełnić błąd! Jeżeli chcesz przechwycić wartość zmiennej z deklaracji pętli w jakiejś konkretnej iteracji, wprowadź kolejną zmienną wewnątrz pętli, przypisz jej wartość zmiennej z deklaracji, a następnie przechwyć tę nową zmienną — dokładnie to, co zrobiliśmy ze zmienną counter na listingu 5.13. TO SIĘ MOŻE ZMIENIĆ… Chociaż zachowanie w pętli for ma sens — zmienna wydaje się zadeklarowana wyłącznie raz — w pętli foreach jest ono trochę zaskakujące. Trzeba przyznać, że przechwytywanie zmiennej iterującej w pętli foreach przez metodę anonimową, która będzie istnieć poza bieżącą iteracją, jest niemal zawsze złe. (Wszystko jest w porządku, jeśli instancja delegata jest używana wyłącznie w bieżącej iteracji). Takie zachowanie stało się źródłem problemu, z którym borykają się całe rzesze programistów, co doprowadziło do tego, że zespół C# rozważa zmianę semantyki pętli foreach w przyszłości i doprowadzenie jej do stanu bardziej

194

ROZDZIAŁ 5

Przyspieszone delegaty

intuicyjnego — to znaczy do stanu, w którym każda iteracja posiada swoją lokalną kopię zmiennej. W chwili pisania niniejszej książki jest to nadal jedynie dyskutowana idea, ale warto być czujnym, aby nie przegapić ewentualnej zmiany w zachowaniu. W ramach ostatniego przykładu przyjrzyjmy się czemuś naprawdę paskudnemu — współdzieleniu pewnych zmiennych przechwyconych, ale nie wszystkich.

5.5.6. Mieszanka zmiennych współdzielonych i odrębnych Zanim przejdziemy do przykładu, pozwolę sobie na uwagę, iż nie jest to kod, który polecam. Tak naprawdę moim zamierzeniem jest pokazanie, jak szybko przy zastosowaniu zmiennych przechwyconych w zbyt skomplikowany sposób można dać się złapać w pułapkę. Listing 5.14 tworzy dwie instancje delegata, z których każda przechwytuje „te same” zmienne. Historia nie wygląda już jednak tak różowo, kiedy spojrzymy na to, co dokładnie jest przechwytywane. Listing 5.14. Przechwytywanie zmiennych w różnych zasięgach. Ostrzeżenie: podchwytliwy kod MethodInvoker[] delegates = new MethodInvoker[2]; int outside = 0; for (int i = 0; i < 2; i++) { int inside = 0;

Wywołanie metody poza interfejsem

Wielokrotne instancjonowanie zmiennej

delegates[i] = delegate { Console.WriteLine("({0},{1})", outside, inside); outside++; inside++; };

Przechwycenie zmiennych przez metodę anonimową

} MethodInvoker first = delegates[0]; MethodInvoker second = delegates[1]; first(); first(); first(); second(); second();

Jak długo zajęłoby Ci przewidzenie wyniku działania programu z listingu 5.14 (nawet z uwzględnieniem dopisków)? Powiem szczerze, że mnie zajęłoby dłuższą chwilę — zdecydowanie dłużej, niż chciałbym poświęcić na zrozumienie tego kodu. Spróbujmy to jednak zrobić wspólnie w ramach ćwiczenia. Najpierw spójrzmy na zmienną outside ( ). Program jedynie raz wchodzi w zasięg jej deklaracji, jest to zatem przypadek oczywisty — może istnieć tylko jedna instancja

Przechwytywanie zmiennych w metodach anonimowych

195

tej zmiennej. Inaczej przedstawia się sprawa w przypadku zmiennej inside ( ) — każda iteracja pętli tworzy nową instancję. Oznacza to, że kiedy tworzymy instancję delegata ( ), zmienna outside jest współdzielona przez dwie instancje delegata, ale każda z nich ma swoją własną instancję zmiennej inside. Po zakończeniu pętli wywołujemy trzykrotnie instancję delegata utworzoną jako pierwszą. Ponieważ przy każdym swoim wywołaniu instancja delegata zmienia obie przechwycone zmienne, a pracę zaczęliśmy z wartością zero w obu zmiennych, widzimy wynik w postaci (0, 0), (1, 1) i (2, 2). Różnica w zasięgu obu zmiennych zaczyna być widoczna, kiedy wywołamy drugą instancję delegata. Ma ona inną instancję zmiennej inside, zatem jej wartość nadal wynosi zero, ale zmienna outside to ta, która była już trzykrotnie inkrementowana. Zatem wynikiem dwukrotnego wywołania drugiego delegata jest (3, 0) i (4, 1). Z czystej ciekawości spróbujmy się zastanowić, przynajmniej jeśli chodzi o kompilator C# 2 firmy Microsoft, jak jest zaimplementowany ten mechanizm. Tworzona jest jedna dodatkowa klasa do przechowywania zmiennej outside i kolejna do przechowywania zmiennej inside oraz referencji do pierwszej z utworzonych klas. Mówiąc dokładniej, każdy zasięg posiadający zmienną przechwyconą otrzymuje swój własny typ z referencją do następnego zasięgu wzwyż posiadającego swoją zmienną przechwyconą. W naszym przykładzie są dwie instancje typu przechowującego zmienną inside i obie odwołują się do tej samej instancji typu przechowującego zmienną outside. Inne implementacje tego mechanizmu mogą wyglądać inaczej, ale ten wydaje się najbardziej oczywisty. Rysunek 5.1 pokazuje wartości zmiennych po wykonaniu programu z listingu 5.14. Nazwy nie odpowiadają dokładnie tym, jakie wygenerowałby kompilator, ale są dostatecznie zbliżone. Zauważ, że w rzeczywistym świecie instancje delegata posiadałyby również inne pola — tutaj interesuje nas wyłącznie cel. Rysunek 5.1. Widok zakresu wielu zmiennych przechwyconych w pamięci

Nawet jeśli doskonale rozumiesz ten kod, jest to dobry wzorzec do wykonania innych ćwiczeń ze zmiennymi przechwyconymi. Jak zauważyliśmy wcześniej, pewne elementy zmiennych przechwyconych są specyficzne dla danej implementacji kompilatora, warto

196

ROZDZIAŁ 5

Przyspieszone delegaty

zatem zajrzeć do specyfikacji, aby się przekonać, czego możemy oczekiwać. Równie ważna jest możliwość pobawienia się kodem, dzięki czemu możemy się sami przekonać, co się stanie. Być może istnieją sytuacje, w których kod — taki jak przedstawiony na listingu 5.14 — byłby najprostszą i najbardziej przejrzystą metodą wyrażenia spodziewanego zachowania, ale ja musiałbym to zobaczyć, aby uwierzyć. Ponadto zdecydowanie potrzebowałbym w kodzie komentarzy wyjaśniających zachowanie. Kiedy zatem użycie zmiennych przechwyconych ma sens i na co trzeba uważać?

5.5.7. Wskazówki odnośnie do zmiennych przechwyconych i podsumowanie Mam nadzieję, że poprzednia sekcja przekonała Cię, aby być bardzo ostrożnym ze zmiennymi przechwyconymi. Są one w miarę logiczne (prawdopodobnie każda zmiana mająca na celu ich uproszczenie doprowadziłaby do utraty użyteczności lub sprawiłaby, że ich logika byłaby mniej zrozumiała), ale jednocześnie pozwalają na stworzenie straszliwie skomplikowanego kodu. Nie pozwól, aby zniechęciło Cię to do używania ich w sposób wyważony — dzięki nim zaoszczędzisz sobie konieczności pisania masy nudnego kodu. Użyte w prawidłowy sposób zmienne przechwycone mogą być najbardziej czytelną formą zrealizowania danego zadania. Co należy rozumieć przez słowo wyważony? Wskazówki odnośnie do używania zmiennych przechwyconych Poniżej znajduje się lista sugestii odnośnie do zastosowania zmiennych przechwyconych: Jeżeli kod bez zmiennych przechwyconych jest równie prosty jak kod z tymi zmiennymi, nie używaj ich. Przed przechwyceniem zmiennej zadeklarowanej przez wyrażenie for lub foreach zastanów się, czy Twój delegat będzie istniał poza iteracją pętli i czy chcesz, aby widział kolejne wartości tej zmiennej. Jeśli nie, stwórz kolejną zmienną wewnątrz pętli i skopiuj wartość, której faktycznie potrzebujesz. Jeśli tworzysz wiele instancji delegata (w pętli lub jawnie) przechwytujących zmienne, zwróć uwagę na to, czy chcesz, aby przechwytywały tę samą zmienną. Nie musisz być szczególnie ostrożny, jeżeli przechwytujesz zmienną, która tak naprawdę nie zmienia się (wewnątrz metody anonimowej lub w metodzie deklarującej metodę anonimową). Życie jest o wiele prostsze, jeśli tworzone przez Ciebie instancje delegatów nie wydostają się poza metodę, w której zostały zadeklarowane — innymi słowy, nie zapisujesz ich referencji, nie zwracasz ich jako wyniku ani nie przekazujesz ich nowym wątkom. Rozważ przedłużone życie każdej zmiennej przechwyconej w kontekście kolekcjonowania śmieci. W normalnych warunkach nie stanowi to problemu, ale jeśli przechwycisz obiekt wymagający pod względem pamięciowym, może to być istotny czynnik.

Podsumowanie

197

Pierwszy punkt stanowi złotą zasadę. Prostota to dobra rzecz, zatem jeżeli zmienne przechwycone upraszczają Twój kod — po rozważeniu stopnia skomplikowania związanego z wymuszeniem poznania tego mechanizmu przez osoby utrzymujące kod użyj ich. Nie możesz skupiać się wyłącznie na minimalnej liczbie wierszy kodu — musisz również rozważyć czynnik ludzki. W tym podrozdziale przeszliśmy przez sporą część materiału. Zdaję sobie sprawę, że przyswojenie go sobie może być trudne. Poniżej przedstawiam listę najważniejszych rzeczy do zapamiętania. Kiedy w przyszłości będziesz chciał wrócić do tego tematu, możesz zacząć od jej lektury, zamiast czytać na nowo cały podrozdział: W miejscu instancji delegata jest przechwytywana zmienna, a nie jej wartość. Czas życia zmiennych przechwyconych jest przedłużony minimalnie do czasu

życia przechwytujących je instancji delegatów. Wiele delegatów może przechwytywać te same zmienne… …ale wewnątrz pętli; ta sama deklaracja zmiennej może się odwoływać do wielu

różnych „instancji” zmiennej. Deklaracje pętli for/foreach tworzą zmienne istniejące przez cały czas życia pętli — nie są instancjonowane przy każdej iteracji. Tam, gdzie jest to potrzebne, tworzone są dodatkowe typy danych do zapamiętania

zmiennych przechwyconych. Bądź ostrożny! Proste rozwiązania są niemal zawsze lepsze od tych sprytnych.

Więcej przypadków użycia zmiennych przechwyconych zobaczymy, kiedy przejdziemy do C# 3 i wyrażeń lambda. Teraz zapewne się ucieszysz, słysząc, że skończyliśmy przegląd nowych cech delegatów w C# 2.

5.6.

Podsumowanie C# 2 zmienił radykalnie sposób tworzenia delegatów i dzięki temu otworzył środowisko na zupełnie nowy styl programowania. W .NET 2.0 istnieje znacznie więcej metod przyjmujących jako parametry typy delegatowe, niż miało to miejsce w .NET 1.0/1.1. Ten trend jest widoczny też w .NET 3 5. Najlepszym tego przykładem jest typ List, który jednocześnie stanowi dobry poligon doświadczalny do trenowania swoich umiejętności w zakresie metod anonimowych i zmiennych przechwytywanych. Tego typu programowanie wymaga nieco innego nastawienia umysłu — musisz umieć się zatrzymać i zastanowić nad celem, jaki ma zostać osiągnięty, oraz zdecydować, czy lepiej będzie go wyrazić w tradycyjny sposób, czy też przy użyciu metody programowania funkcyjnego. Wszystkie zmiany w sposobie obsługi delegatów są użyteczne, ale zwiększają stopień skomplikowania języka, szczególnie jeśli chodzi o zmienne przechwycone. Domknięcia zawsze stwarzają problem, gdyż trudno dokładnie przewidzieć zachowanie współdzielonego środowiska — C# nie stanowi tutaj wyjątku. Powodem, dla którego ta koncepcja znajduje swoje miejsce w informatyce, jest szybsze pisanie kodu i łatwiejsze jego zrozumienie. Znalezienie równowagi pomiędzy złożonością a prostotą jest zawsze

198

ROZDZIAŁ 5

Przyspieszone delegaty

trudne i wymaga szczególnej ostrożności już na samym początku pracy. Możesz się jednak spodziewać, że w miarę upływu czasu będziesz coraz lepiej rozumiał zachowanie zmiennych przechwyconych, a praca z nimi stanie się łatwiejsza. Jeszcze większą zachętą do ich stosowania jest LINQ. Również spora część nowoczesnego, idiomatycznego kodu C# opiera się na częstym stosowaniu domknięć. Metody anonimowe nie są jedyną zmianą w C# 2 wymuszającą tworzenie przez kompilator dodatkowych typów „pod maską” i wykonywanie innych zmyślnych rzeczy ze zmiennymi, które wydają się lokalne. Więcej tego typu elementów zobaczymy w następnym rozdziale, w którym kompilator będzie w praktyce budował kompletną maszynę stanową, aby pomóc programiście w implementacji iteratorów.

Implementowanie iteratorów w prosty sposób

Ten rozdział omawia: ♦ implementowanie iteratorów w C# 1, ♦ uproszczenia iteratorów w C# 2, ♦ przykłady użycia iteratorów, ♦ iteratory jako współprogramy.

200

ROZDZIAŁ 6

Implementowanie iteratorów w prosty sposób

Iterator jest przykładem wzorca czynnościowego, czyli wzorca projektowego upraszczającego komunikację pomiędzy obiektami. Jest jednym z najprostszych i najłatwiejszych w użyciu wzorców. Iteratory pozwalają na dostęp do wszystkich elementów sekwencji bez martwienia się o rodzaj tej sekwencji (może to być tablica, lista, lista kierunkowa lub żadna z powyższych). Taki algorytm przydaje się do budowania potoku danych, w którym element danych dostaje się do potoku i przechodzi przez szereg transformacji lub filtrów, zanim ostatecznie pojawi się na wyjściu. Jak się później przekonamy (w trzeciej części książki), jest to jeden z fundamentalnych wzorców LINQ. W środowisku .NET wzorzec iteratora jest kapsułkowany przez interfejsy IEnumerator i IEnumerable oraz ich generyczne odpowiedniki. (Nazewnictwo jest trochę niefortunne — wzorzec jest przeważnie określany jako iteracja, aby uniknąć konfliktu z drugim znaczeniem słowa enumeracja. W dalszej części rozdziału będę używać określeń iterator i iterowalny). Jeżeli typ implementuje IEnumerable, oznacza to, że można po nim iterować. Wywołanie metody GetEnumerator zwraca implementację interfejsu IEnumerator, która jest iteratorem. Iterator możesz traktować jak kursor w bazie danych, czyli pozycję w sekwencji danych. Iterator wewnątrz sekwencji danych może się poruszać jedynie do przodu, ale po tej samej sekwencji może się poruszać jednocześnie wiele iteratorów. C# 1 jako język posiada wbudowaną obsługę iteratorów pod postacią wyrażenia foreach. To pozwala na proste iterowanie po kolekcjach — prostsze niż korzystanie ze zwykłej pętli for — i przyjazne wyrażanie tego zadania. Wyrażenie foreach kompiluje się do postaci wywołań metod GetEnumerator, MoveNext oraz właściwości Current wraz z odpowiednią obsługą niszczenia iteratora na końcu, jeśli został zaimplementowany interfejs IDisposable. Jest to mały, ale użyteczny dodatek syntaktyczny. Pomimo łatwości iterowania w C# 1 sama implementacja iteratora w tej wersji języka jest raczej trudnym zadaniem. O wiele prościej można to zrobić w C# 2, co czasem sprawia, że bardziej opłaca się zaimplementować iterator, niż szukać rozwiązań alternatywnych. W tym rozdziale dowiemy się, czego potrzebujemy, aby móc zaimplementować iterator, oraz jakie wsparcie pod tym względem oferuje C#. Po przyjrzeniu się szczegółowo składni przeanalizujemy kilka przykładów z prawdziwego świata, włączając w to pasjonujące (i odrobinę dziwaczne) użycie składni iteratora w bibliotece wielowątkowej firmy Microsoft. Ponieważ nie ma aż tak dużo do nauki, wstrzymałem się z podawaniem przykładów do końca opisu. Dzięki temu, gdy będziesz już wiedział, co robi dany kod, łatwiej zrozumiesz poszczególne przykłady. Jeżeli chcesz zacząć od analizy przykładów już teraz, znajdują się one w sekcjach 6.3 i 6.4. Jeśli chcesz się skonfrontować z tematem, pomyśl o ostatnim razie, kiedy iterowałeś po wierszach pliku. Zakładając, że nie ładowałeś całego pliku w jednym kroku za pomocą na przykład File.ReadAllLines, prawdopodobnie realizowałeś to zadanie za pomocą nieeleganckiej pętli while. Czy foreach nie byłaby w tej sytuacji lepsza? Gdyby tylko istniał jakiś sposób na „leniwe” iterowanie po wierszach pliku, tak jakby stanowiły one kolejny rodzaj kolekcji... Rozpocznijmy ten rozdział od spojrzenia, jak to wszystko wyglądało przed wprowadzeniem C# 2. Zaimplementujemy iterator trudniejszą metodą.

C# 1 — udręka ręcznego pisania iteratorów

6.1.

201

C# 1 — udręka ręcznego pisania iteratorów Widzieliśmy już jeden przykład implementacji iteratora w sekcji 3.4.3, kiedy przyglądaliśmy się, co się dzieje, kiedy iterujesz po kolekcji generycznej. Pod pewnymi względami było to rozwiązanie trudniejsze niż rzeczywista implementacja iteratora w C# 1, ponieważ zaimplementowaliśmy również interfejsy generyczne, ale jednocześnie łatwiejsze, ponieważ nie iterowaliśmy faktycznie po żadnych użytecznych danych. Aby zaprezentować cechy C# 2, zaczniemy od implementacji najprostszego z możliwych iteratorów, oferującego rzeczywistą funkcjonalność. Załóżmy, że chcemy utworzyć nowy rodzaj kolekcji bazujący na buforze cyklicznym. Zaimplementujemy IEnumerable w taki sposób, aby użytkownicy naszej nowej klasy mogli z łatwością iterować po wszystkich wartościach kolekcji. Pominiemy ciało samej kolekcji i skoncentrujemy się na stronie iteracyjnej. Nasza kolekcja będzie przechowywać swoje wartości w tablicy (użyjemy object[] — żadnych generyków!). Interesującą cechą będzie możliwość ustawienia jej logicznego punktu startowego — jeśli zatem kolekcja będzie miała pięć elementów, będziesz mógł ustawić ten punkt na 2, a następnie oczekiwać zwrócenia elementów 2, 3, 4, 0 i na końcu 1. Nie będę prezentował w książce pełnego kodu bufora cyklicznego, gdyż możesz go znaleźć w źródłach do pobrania. Ponieważ chcę zademonstrować klasę w prosty sposób, zarówno wartości, jak i punkt startowy umieszczę w konstruktorze. Dzięki temu, kiedy będziemy iterować po całej kolekcji, będziemy mogli użyć kodu pokazanego na listingu 6.1. Listing 6.1. Kod używający (niezaimplementowanego jeszcze) nowego typu kolekcji object[] values = { "a", "b", "c", "d", "e" }; IterationSample collection = new IterationSample(values, 3); foreach (object x in collection) { Console.WriteLine(x); }

Uruchomienie kodu z listingu 6.1 powinno (na końcu naszych rozważań) doprowadzić do uzyskania wyniku w postaci sekwencji „d”, „e”, „a”, „b” i „c”, ponieważ wybrany przez nas punkt startowy to 3. Skoro wiemy już, co chcemy osiągnąć, przyjrzyjmy się teraz szkieletowi naszej klasy pokazanej na listingu 6.2. Listing 6.2. Szkielet nowego typu kolekcji bez implementacji iteratora using System; using System.Collections; public class IterationSample : IEnumerable { object[] values; int startingPoint; public IterationSample(object[] values, int startingPoint) { this.values = values; this.startingPoint = startingPoint; }

202

ROZDZIAŁ 6

Implementowanie iteratorów w prosty sposób public IEnumerator GetEnumerator() { throw new NotImplementedException(); } }

Jak widzisz, nie zaimplementowaliśmy jeszcze GetEnumerator, ale cała reszta kodu jest gotowa. Jak zatem zabierzemy się za pisanie kodu GetEnumerator? Pierwszą rzeczą, którą powinniśmy zrozumieć, jest to, że musimy gdzieś zapisać pewien stan. Wzorzec iteratora nie opiera się na przekazywaniu wszystkich informacji za jednym razem — klient przy każdym podejściu pyta tylko o pojedynczy element. Oznacza to, że musimy śledzić, w którym miejscu tablicy znajdujemy się w danej chwili. Zwróć uwagę na to, co będzie się działo ze stanem wymaganym w naszym przykładzie — „stanowa” natura iteratorów okaże się istotna, kiedy przyjrzymy się, jaką pracę wykonuje za nas kompilator C# 2. Gdzie zatem powinien funkcjonować ten stan? Załóżmy, że spróbujemy umieścić go w samej klasie IterationSample, co doprowadzi tym samym do implementacji zarówno IEnumerator, jak i IEnumerable. Na pierwszy rzut oka wygląda to na dobry plan — w końcu dane, włączając w to punkt startowy, są w dobrym miejscu. Nasza metoda GetEnumerator mogłaby zwyczajnie zwracać this. Z tym podejściem wiąże się jednak duży problem — jeżeli GetEnumerator zostanie wywołany kilkakrotnie, powinno zostać zwróconych kilka niezależnych iteratorów. Przykładowo powinniśmy być w stanie użyć dwóch wyrażeń foreach, jednego wewnątrz drugiego, aby uzyskać pary będące kombinacją wszystkich możliwych wartości. Te dwa iteratory powinny być niezależne, co sugeruje, że powinniśmy stworzyć nowy obiekt za każdym razem, kiedy zostanie wywołana metoda GetEnumerator. Nadal moglibyśmy zaimplementować całą funkcjonalność bezpośrednio w IterationSample, ale wtedy otrzymalibyśmy klasę niemającą jasno określonych obowiązków, co byłoby bardzo mylące. Zamiast tego stwórzmy klasę implementującą sam iterator. Skorzystamy z faktu, iż w C# typ zagnieżdżony ma dostęp do prywatnych elementów typu będącego jego właścicielem, co oznacza, że możemy zapamiętać referencję do rodzica klasy IterationSample razem z naszą aktualną pozycją w tablicy. Pokazuje to listing 6.3. Listing 6.3. Klasa zagnieżdżona implementująca iterator kolekcji class IterationSampleIterator : IEnumerator { IterationSample parent; int position;

Kolekcja, po której iterujemy Jak daleko zaszliśmy

internal IterationSampleIterator(IterationSample parent) { Rozpoczęcie przed this.parent = parent; pierwszym elementem position = -1; } public bool MoveNext() { if (position != parent.values.Length) {

Inkrementacja pozycji, jeśli nadal jest taka możliwość

C# 1 — udręka ręcznego pisania iteratorów

}

203

position++; } return position < parent.values.Length;

public object Current { get Uniemożliwienie dostępu przed pierwszym { lub za ostatnim elementem if (position == -1 || position == parent.values.Length) { throw new InvalidOperationException(); } int index = position + parent.startingPoint; Implementacja index = index % parent.values.Length; zawijania wartości return parent.values[index]; } } public void Reset() { position = -1; }

Powrót do pozycji przed pierwszym elementem

}

Bardzo dużo kodu jak na takie proste zadanie! Zapamiętujemy oryginalną kolekcję, po której będziemy iterować ( ), oraz pozycję, na której będziemy się znajdować w tablicy indeksowanej od zera ( ). W celu zwrócenia elementu przesuwamy indeks o wartość pozycji startowej ( ). Dla zgodności z interfejsem zakładamy, że nasz iterator rozpocznie pracę przed pierwszym elementem ( ), co wymusi na użytkowniku wywołanie MoveNext przed pierwszym odwołaniem do właściwości Current. Warunkowa inkrementacja w punkcie ( ) sprawia, że test w punkcie ( ) jest prosty i uzasadniony, nawet jeśli metoda MoveNext zostanie wywołana po otrzymaniu pierwszej informacji zwrotnej o braku kolejnych danych. Stan początkowy iteratora przywracamy przez ustawienie pozycji z powrotem przed pierwszym elementem tablicy ( ). Cała logika jest prosta, chociaż istnieje sporo sytuacji, w których można popełnić błąd „przesunięcia o jeden” (właśnie z tego powodu moja pierwsza implementacja nie przeszła testów jednostkowych). Dobrą wiadomością jest natomiast to, że powyższa implementacja działa, a jedyne, co musimy zrobić, aby dokończyć nasz przykład, to uzupełnić implementację IEnumerable w klasie IterationSample: public IEnumerator GetEnumerator() { return new IterationSampleIterator(this); }

Nie będę powtarzał całego kodu, możesz go pobrać ze strony książki, łącznie z listingiem 6.1, który teraz daje spodziewany wynik. Przypominam, że jest to w miarę prosty przykład — nie ma w nim zbyt wielu danych, które należy śledzić, nie podejmujemy także żadnych działań w związku z możliwą zmianą kolekcji pomiędzy poszczególnymi iteracjami. W związku z tak skomplikowaną implementacją prostego iteratora nie powinniśmy się dziwić, iż wzorzec ten był rzadko

204

ROZDZIAŁ 6

Implementowanie iteratorów w prosty sposób

implementowany w C# 1. Programiści zadowalali się użyciem foreach w połączeniu z kolekcjami dostarczanymi przez środowisko, chociaż te oferowały bardziej bezpośredni dostęp do ich własnych zbiorów danych. Do zaimplementowania iteratora w C# 1 zużyliśmy zatem 40 wierszy kodu. Zobaczmy, czy C# 2 poradzi sobie lepiej.

6.2.

C# 2 — proste iteratory z wyrażeniami yield Już jako dziecko byłem na tyle niecierpliwy, że w Wigilię zawsze czekałem do północy, żeby móc otworzyć prezenty, jak tylko zacznie się Boże Narodzenie. Dlatego nie mogę się powstrzymać, by pokazać Ci wreszcie, jak zmyślne rozwiązanie wprowadza C# 2.

6.2.1. Wprowadzenie do uproszczeń iteratorów i wyrażenia yield return Ten rozdział nie istniałby, gdyby C# 2 nie posiadał niezwykle funkcjonalnej cechy, która w znacznym stopniu redukuje ilość kodu potrzebną do zaimplementowania iteratora. W innych elementach języka objętość kodu została jedynie w niewielkim stopniu zmniejszona lub nieco usprawniona. W tym konkretnym przypadku jest to jednak zjawisko masowe. Kompletną implementację metody GetEnumerator w C# 2 pokazuje listing 6.4. Listing 6.4. Iterowanie po prostej kolekcji z użyciem wyrażenia yield (C# 2) public IEnumerator GetEnumerator() { for (int index = 0; index < values.Length; index++) { yield return values[(index + startingPoint) % values.Length]; } }

Cztery wiersze implementacji, z czego dwa to nawiasy. Dla jasności dodam, że ten kod zastępuje całą klasę IterationSampleIterator. Całkowicie. Przynajmniej w kodzie źródłowym... Później zobaczymy, co za naszymi plecami wykonał kompilator, ale najpierw przyjrzyjmy się temu, co napisaliśmy. Metoda wygląda zupełnie zwyczajnie do momentu wystąpienia słów yield return. To one mówią kompilatorowi C#, że nie jest to zwykła metoda, lecz metoda zaimplementowana z uproszczeniem iteratora. Uproszczenia iteratora mogą być stosowane wyłącznie do metod1, których typami zwracanymi są IEnumerable, IEnumerator (taki typ zwracany ma nasza metoda) lub ich generyczne odpowiedniki. Jeśli zadeklarowanym typem zwracanym metody jest interfejs niegeneryczny, typem wynikowym uprosz-

1

Lub, jak się później przekonamy, do właściwości. Uproszczeń iteratorów nie można zastosować w przypadku metod anonimowych.

C# 2 — proste iteratory z wyrażeniami yield

205

czenia iteratora jest object, w przeciwnym wypadku jest nim argument typu interfejsu generycznego. Przykładowo typem wynikowym metody zadeklarowanej do zwracania IEnumerable byłby string. Wewnątrz uproszczeń iteratorów nie można stosować zwykłych wyrażeń return — dozwolone są jedynie yield return. Wszystkie wyrażenia yield return wewnątrz uproszczenia muszą usiłować zwrócić wartość kompatybilną z typem zwracanym tego uproszczenia. Pozostając przy poprzednim przykładzie, nie mógłbyś napisać yield return 1 w metodzie zadeklarowanej z typem zwracanym IEnumerable. OGRANICZENIA WYRAŻENIA YIELD RETURN. Istnieje kilka dodatkowych ograniczeń wyrażeń yield return. Nie możesz stosować ich wewnątrz bloków try, jeżeli towarzyszą im jakiekolwiek bloki catch. Wyrażenia yield return i yield break (o którym powiemy sobie za chwilę) nie mogą się również pojawić w bloku finally. Nie znaczy to wcale, że nie możesz używać bloków try/catch i try/finally wewnątrz iteratorów — ograniczenie mówi tylko o tym, czego nie możesz zrobić wewnątrz tych bloków2. W przypadku uproszczeń iteratorów przede wszystkim musisz pamiętać, że chociaż napisałeś metodę, która wygląda, jakby wykonywała się sekwencyjnie, tak naprawdę poprosiłeś kompilator o stworzenie dla Ciebie maszyny stanowej. Jest ona niezbędna z dokładnie takich samych powodów, dla których włożyliśmy całkiem sporo wysiłku w implementację iteratora przy użyciu C# 1 — kod wywołujący chce widzieć tylko jeden element przy każdym wywołaniu, zatem my musimy trzymać informację o tym, co robiliśmy przed poprzednim zwróceniem wyniku. Kiedy kompilator napotka uproszczenie iteratora, tworzy typ zagnieżdżony dla maszyny stanowej. Ten typ pamięta dokładnie naszą pozycję oraz wartości zmiennych lokalnych (włączając w to parametry). Wygenerowana klasa jest pod pewnymi względami podobna do napisanej przez nas wcześniej długiej implementacji iteratora. Podobieństwo dotyczy przechowywania niezbędnego stanu iteratora w formie zmiennych wewnątrz instancji. Zastanówmy się, jakie czynności musi wykonywać maszyna stanowa w celu zaimplementowania iteratora: Musi posiadać jakiś stan początkowy. Przy każdym wywołaniu MoveNext musi wykonywać kod metody GetEnumerator

— aż do momentu, kiedy jesteśmy gotowi zwrócić następną wartość (innymi słowy, do momentu napotkania wyrażenia yield return). Przy odwołaniu do właściwości Current musi zwracać ostatni wyprodukowany przez nas wynik. Musi wiedzieć, kiedy skończyliśmy wydawać wartości, dzięki czemu MoveNext będzie mógł zwrócić false.

Drugi punkt tej listy jest podchwytliwy, ponieważ wymaga, aby kod wystartował od miejsca, które zostało osiągnięte przy poprzednim wywołaniu. Problemem nie jest 2

Jeżeli chcesz się dowiedzieć więcej o tym, dlaczego istnieją te ograniczenia, zajrzyj pod adres http://mng.bz/EJ97, gdzie Eric Lippert publikuje całą serię postów opisujących tę i inne decyzje projektowe związane z iteratorami.

206

ROZDZIAŁ 6

Implementowanie iteratorów w prosty sposób

pamiętanie zmiennych lokalnych (tak jak widać je w metodzie) — są one reprezentowane przez zmienne wewnątrz instancji maszyny stanowej. Trudniejszą rzeczą jest samo restartowanie kodu. Na szczęście, o ile nie zajmujesz się pisaniem własnego kompilatora C#, nie musisz się przejmować, jak został rozwiązany ten problem. „Czarna skrzynka” najwyraźniej działa w oczekiwany sposób. Możesz napisać własny kod wewnątrz uproszczenia iteratora i zrzucić na kompilator odpowiedzialność za stworzenie takiego toku wykonania jak w przypadku każdej innej metody. Jedyna różnica będzie polegać na tym, że yield return stworzy wrażenie chwilowego wyjścia z metody (możesz traktować to wywołanie jako wstrzymanie wykonania metody). Przyjrzymy się teraz bliżej i bardziej wizualnie przebiegowi wykonania iteratora.

6.2.2. Wizualizacja toku wykonania iteratora Przy analizowaniu sposobu wykonania iteratora pomocne może być posługiwanie się diagramem interakcji (http://mng.bz/jH7I). Nie będziemy go jednak rysować, zrobi to za nas program z listingu 6 5. Sam iterator dostarcza jedynie sekwencję liczb (0, 1, 2, –1) i kończy swoją pracę. Częścią, która nas interesuje, nie są wartości wydawane przez iterator, ale sam przebieg wykonania kodu. Listing 6.5. Pokaz sekwencji wywołań pomiędzy iteratorem i kodem, który go używa static readonly string Padding = new string(' ', 30); static IEnumerable CreateEnumerable() { Console.WriteLine("{0}Początek CreateEnumerable()", Padding); for (int i = 0; i < 3; i++) { Console.WriteLine("{0}Gotowy do wydania {1}", Padding, i); yield return i; Console.WriteLine("{0}Po wydaniu", Padding); } Console.WriteLine("{0}Wydawanie ostatniej wartości", Padding); yield return -1; Console.WriteLine("{0}Koniec CreateEnumerable ()", Padding); } ... IEnumerable collection = CreateEnumerable(); IEnumerator iterator = collection.GetEnumerator(); Console.WriteLine("Rozpoczynanie iteracji"); while (true) { Console.WriteLine("Wywołanie MoveNext()..."); bool result = iterator.MoveNext(); Console.WriteLine("...MoveNext wynik={0}", result); if (!result) { break; }

C# 2 — proste iteratory z wyrażeniami yield

207

Console.WriteLine("Pobieranie Current..."); Console.WriteLine("...Current wynik={0}", iterator.Current); }

Listing 6.5 nie jest zbyt elegancki, szczególnie w okolicach części iteracyjnej. Prościej byłoby użyć pętli foreach, ale moim celem jest dokładne pokazanie tego, co i kiedy się dzieje, dlatego musiałem podzielić użycie iteratora na fragmenty. Mówiąc ogólnie, ten kod wykonuje to co pętla foreach, za wyjątkiem wywołania metody Dispose. To naprawdę istotne, o czym przekonamy się za chwilę. Jak możesz zauważyć, nie widać różnicy w składni uproszczenia iteratora, mimo że tym razem zwracamy IEnumerator zamiast IEnumerator. Zazwyczaj, jeśli chcesz zaimplementować IEnumerable, wystarczy zwrócić IEnumerator. Jeśli jednak chcesz wyprodukować sekwencję z metody, zwróć IEnumerable. Oto wynik działania programu z listingu 6 5: Rozpoczynanie iteracji Wywołanie MoveNext()... Początek CreateEnumerable() Gotowy do wydania 0 ...MoveNext wynik=True Pobieranie Current... ...Current wynik=0 Wywołanie MoveNext()...

Po wydaniu Gotowy do wydania 1

...MoveNext wynik=True Pobieranie Current... ...Current wynik=1 Wywołanie MoveNext()... Po wydaniu Gotowy do wydania 2 ...MoveNext wynik=True Pobieranie Current... ...Current wynik=2 Wywołanie MoveNext()... Po wydaniu Wydawanie ostatniej wartości ...MoveNext wynik=True Pobieranie Current... ...Current wynik=-1 Wywołanie MoveNext()... Koniec CreateEnumerable() ...MoveNext wynik=False

Jest kilka ważnych rzeczy, na które warto zwrócić uwagę w tym wyniku: Żaden fragment kodu w metodzie CreateEnumerable nie jest wykonywany do chwili pierwszego wywołania MoveNext. Cała praca jest wykonywana podczas wywoływania MoveNext. Odwoływanie się do Current nie powoduje wykonania naszego kodu. Wykonanie kodu zatrzymuje się na wyrażeniu yield return, a następnie podejmuje pracę tuż za tym wyrażeniem, przy kolejnym wywołaniu MoveNext.

208

ROZDZIAŁ 6

Implementowanie iteratorów w prosty sposób Wyrażenie yield return może się pojawiać wielokrotnie w różnych miejscach

metody. Wykonanie kodu nie kończy się na ostatnim wyrażeniu yield return — zamiast tego wywołanie MoveNext zwraca false i tym samym powoduje dotarcie do końca

metody. Szczególnie ważny jest pierwszy punkt, ponieważ oznacza on, że nie możesz użyć uproszczenia iteratora dla kodu, który musi zostać wykonany niezwłocznie po wywołaniu samej metody — może to być na przykład walidacja danych. Jeżeli wstawisz taką logikę do metody zaimplementowanej z uproszczeniem iteratora, nie będzie się ona zachowywać w sposób zadowalający. Prędzej czy później padniesz ofiarą tej reguły — jest to błąd popełniany niezwykle często i trudny do zrozumienia, jeśli nie masz świadomości tego, co faktycznie wykonuje uproszczenie iteratora. Rozwiązanie tego problemu znajdziemy w sekcji 6.3.3. Są jeszcze dwie rzeczy, których do tej pory nie widzieliśmy: alternatywna metoda zatrzymania iteratora i zachowanie bloków finally w tej nieco dziwnej formie wykonania kodu. Teraz się im przyjrzymy.

6.2.3. Zaawansowany tok wykonania iteratora W zwykłych metodach wywołanie wyrażenia return przynosi dwa skutki. Po pierwsze, dostarcza wynik, który kod wywołujący widzi jako wartość zwracaną. Po drugie, kończy wykonanie metody, uruchamiając przy wyjściu wszelkie właściwe dla tego wywołania bloki finally. Widzieliśmy wcześniej, że wyrażenie yield return wychodzi tymczasowo z metody, ale tylko do chwili ponownego wywołania MoveNext, więc nie przejmowaliśmy się w tym momencie zachowaniem bloków finally. W jaki sposób możemy faktycznie zatrzymać metodę i co się wtedy dzieje ze wszystkimi tymi blokami finally? Zaczniemy od względnie prostej konstrukcji — wyrażenia yield break. Kończenie iteratora przez yield break Zawsze można znaleźć sposób na to, aby metoda miała pojedynczy punkt wyjścia. Wiele osób bardzo mocno stara się osiągnąć ten cel3. Taką samą technikę można zastosować do uproszczeń iteratorów. Jeżeli chciałbyś mieć możliwość wcześniejszego wyjścia z iteratora, yield break jest Twoim przyjacielem. Powoduje on faktyczne przerwanie iteratora przez wymuszenie zwrócenia wartości false z bieżącego wywołania metody MoveNext. Zachowanie to demonstruje listing 6.6, który zlicza do 100, ale przerywa swoją pracę wcześniej, jeśli skończy mu się czas. Jest to również demonstracja użycia parametru metody w uproszczeniu iteratora4 oraz dowód na to, że nazwa metody nie ma znaczenia. 3

Uważam, że trudności, przez które trzeba przejść w celu osiągnięcia tego celu, często sprawiają, iż kod staje się mniej czytelny niż w sytuacji, kiedy istnieje kilka punktów wyjścia, zwłaszcza gdy w kodzie pojawiają się bloki try/finally w celu posprzątania po wykonaniu, a my i tak musimy być przygotowani na pojawienie się wyjątków. Sednem powyższego zdania jest jedynie to, że taki cel można osiągnąć.

4

Pamiętaj, że metody przyjmujące parametry z modyfikatorami ref lub out nie mogą być implementowane z użyciem uproszczeń iteratorów.

C# 2 — proste iteratory z wyrażeniami yield

209

Listing 6.6. Demonstracja wyrażenia yield break static IEnumerable CountWithTimeLimit(DateTime limit) { for (int i = 1; i <= 100; i++) { if (DateTime.Now >= limit) Przerwanie iteracji { po przekroczeniu limitu czasu yield break; } yield return i; } } ... DateTime stop = DateTime.Now.AddSeconds(2); foreach (int i in CountWithTimeLimit(stop)) { Console.WriteLine("Doliczyłem do {0}", i); Thread.Sleep(300); }

Po uruchomieniu programu z listingu 6.6 powinieneś zobaczyć około siedmiu wierszy wyniku. Pętla foreach kończy się w typowy sposób — z jej punktu widzenia iteratorowi zwyczajnie skończyły się elementy, po których mógłby dalej przechodzić. Wyrażenie yield break zachowuje się podobnie jak wyrażenie return w zwykłej metodzie. Do tej pory wszystko jest jasne i proste. Do przeanalizowania pozostaje jeszcze jeden aspekt toku wykonania: kiedy i w jaki sposób jest uruchamiany kod bloków finally. Wykonywanie bloków finally Jesteśmy przyzwyczajeni do faktu, iż bloki finally są wykonywane w chwili opuszczenia danego zasięgu kodu. Uproszczenia iteratorów nie zachowują się jednak tak jak zwykłe metody — wyrażenie yield return powoduje raczej zatrzymanie metody niż jej zakończenie. Podążając za tą logiką, oczekiwalibyśmy, że bloki finally nie są wykonywane w tym momencie — i tak faktycznie jest. Bloki finally są jednak wykonywane, kiedy zostanie napotkane wyrażenie yield break, tak jak spodziewałbyś się tego podczas zwykłego powrotu z metody5. Najczęstszym przypadkiem użycia bloku finally jest potrzeba zwolnienia zasobów, zwykle z użyciem wygodnego wyrażenia using. Rzeczywisty przykład takiego zachowania zobaczymy w sekcji 6.3.2, ale teraz skupimy się wyłącznie na tym, jak i kiedy są wykonywane bloki finally. Kolejny listing (6.7) pokazuje połączenie uproszczenia iteratora z użyciem bloku finally. Jest to ten sam kod co na listingu 6.6, ale z dodatkiem bloku finally. Zmiany zostały wytłuszczone. Blok finally na listingu 6.7 jest wykonywany, kiedy iterator skończy swoją pracę, osiągając wartość 100, lub kiedy zostanie przerwany wcześniej ze względu na osiągnięcie

5

Są one wykonywane również wtedy, kiedy punkt wykonania opuści dany zasięg, bez znaczenia, czy zostało osiągnięte wyrażenie yield return, czy yield break. Skupiam się wyłącznie na zachowaniu dwóch wyrażeń yield, ponieważ tutaj zachowanie toku wykonania jest nowe i inne.

210

ROZDZIAŁ 6

Implementowanie iteratorów w prosty sposób Listing 6.7. Przykład wyrażenia yield break pracującego w połączeniu z try/finally static IEnumerable CountWithTimeLimit(DateTime limit) { try { for (int i = 1; i <= 100; i++) { if (DateTime.Now >= limit) { yield break; } yield return i; } } finally { Console.WriteLine("Kończenie!"); } } ... DateTime stop = DateTime.Now.AddSeconds(2); foreach (int i in CountWithTimeLimit(stop)) { Console.WriteLine("Doliczyłem do {0}", i); Thread.Sleep(300); }

limitu czasowego. Zostałby również wykonany w przypadku rzucenia wyjątku przez kod programu. Istnieją także sposoby pozwalające nam na uniknięcie wykonania bloku finally... Spróbujmy małego podstępu. Widzieliśmy, że kod uproszczenia iteratora jest wykonywany jedynie po wywołaniu MoveNext. Co się zatem stanie, jeśli nigdy nie wywołamy MoveNext? Lub kiedy wywołamy tę metodę kilkakrotnie, a następnie przestaniemy? Rozważmy zmianę kodu wywołującego z listingu 6.7 na następujący: DateTime stop = DateTime.Now.AddSeconds(2); foreach (int i in CountWithTimeLimit(stop)) { Console.WriteLine("Doliczyłem do {0}", i); if (i > 3) { Console.WriteLine("Powrót"); return; } Thread.Sleep(300); }

Tutaj nie zatrzymujemy się w kodzie iteratora — zatrzymujemy się w kodzie używającym iteratora. Wynik jest być może zaskakujący: Doliczyłem Doliczyłem Doliczyłem Doliczyłem Powrót Kończenie!

do do do do

1 2 3 4

C# 2 — proste iteratory z wyrażeniami yield

211

W tym przykładzie kod jest wykonywany po napotkaniu wyrażenia return w pętli foreach. Taka sytuacja nie zdarza się w normalnych warunkach, chyba że w grę wchodzi blok finally — tutaj mamy dwa takie bloki! Wiemy, że blok finally jest w metodzie iteratora, ale co sprawia, że jest on wykonywany? Pewną wskazówkę podsunąłem nieco wcześniej — foreach wywołuje Dispose na iteratorze zwróconym przez GetEnumerator w jego własnym bloku finally (tak jakby pojawiło się wyrażenie using). Kiedy wywołasz Dispose na iteratorze stworzonym przez uproszczenie przed końcem iterowania, maszyna stanowa wykona wszelkie bloki finally znajdujące się w aktualnym zasięgu „wstrzymanego” kodu. Jest to dosyć szczegółowe i skomplikowane wyjaśnienie, ale jego wynik można wyrazić o wiele prościej: dopóki kod wywołujący używa pętli foreach, dopóty blok finally wewnątrz uproszczenia zachowuje się zgodnie z naszymi oczekiwaniami. Używając iteratora ręcznie, możemy z łatwością udowodnić, że źródłem tego zachowania jest wywołanie Dispose: DateTime stop = DateTime.Now.AddSeconds(2); IEnumerable iterable = CountWithTimeLimit(stop); IEnumerator iterator = iterable.GetEnumerator(); iterator.MoveNext(); Console.WriteLine("Doliczyłem do {0}", iterator.Current); iterator.MoveNext(); Console.WriteLine("Doliczyłem do {0}", iterator.Current);

Tym razem wiersz oznajmiający zatrzymanie nie jest w ogóle wyświetlany. Pojawiłby się z powrotem w wyniku, gdybyś na końcu kodu dołożył jawne wywołanie metody Dispose. Przerywanie pracy iteratora przed jego zakończeniem należy do rzadkich przypadków, podobnie jak ręczne iterowanie po kolekcji zamiast użycia pętli foreach. Jeśli jednak zdecydujesz się na takie rozwiązanie, nie zapomnij opakować iteratora wyrażeniem using. Omówiliśmy większość z możliwych zachowań uproszczeń iteratorów, zanim jednak zakończymy tę sekcję, warto wspomnieć o kilku osobliwościach w bieżącej implementacji firmy Microsoft.

6.2.4. Dziwactwa w implementacji Jeżeli skompilujesz uproszczenie iteratora, używając kompilatora C# firmy Microsoft, i spojrzysz na kod wynikowy IL (za pomocą narzędzi typu ildasm lub Reflector), zobaczysz typ zagnieżdżony, który kompilator stworzył dla nas wewnątrz programu. W moim przypadku po skompilowaniu pierwszego przykładu uproszczenia iteratora (poddanego wszystkim modyfikacjom) nazwa tego typu to IterationSample.d__0 (nawiasy ostre sprawiają, że jest to nazwa nie do wymówienia, która nie ma nic wspólnego z typami generycznymi). Nie będę się skupiał w tym miejscu na detalach generowanego kodu, ale zachęcam do samodzielnej analizy przy użyciu narzędzia Reflector, choćby po to, aby się przekonać, co dokładnie dzieje się pod maską — najlepiej trzymać przy tym pod ręką specyfikację otwartą na sekcji 10.14. Specyfikacja definiuje różne stany, w jakich może się znajdować typ, a opis pozwala na łatwiejsze śledzenie

212

ROZDZIAŁ 6

Implementowanie iteratorów w prosty sposób

wygenerowanego kodu. Większość pracy jest wykonywana wewnątrz metody MoveNext, która jest po prostu jednym wielkim wyrażeniem switch. Na szczęście jako programiści nie musimy się martwić przeszkodami, jakie ma do pokonania na swojej drodze kompilator. Istnieje jednak kilka dziwactw związanych z implementacją, o których warto wiedzieć: Przed pierwszym wywołaniem metody MoveNext właściwość Current będzie zawsze

zwracać domyślną wartość typu wynikowego iteratora. Po zwróceniu false przez MoveNext właściwość Current będzie zawsze zwracać ostatnią wartość iteratora. Reset, w przeciwieństwie do naszej ręcznej implementacji, powoduje zawsze rzucenie wyjątku. Jest to zachowanie wymagane przez specyfikację. Klasa zagnieżdżona implementuje zawsze generyczną i niegeneryczną formę interfejsu IEnumerator (a tam, gdzie potrzeba, także generyczną i niegeneryczną formę interfejsu IEnumerable).

Brak możliwości zaimplementowania metody Reset jest zrozumiały — kompilator nie jest w stanie wywnioskować, jakie operacje są potrzebne do przywrócenia początkowego stanu operatora, a także logiki informującej o tym, kiedy ma to nastąpić. Rzeczą sporną pozostaje pytanie, czy metoda Reset w ogóle powinna się znaleźć w interfejsie IEnumerator — nie pamiętam, kiedy ostatni raz zdarzyło mi się ją wywołać. Wiele kolekcji nie obsługuje tej metody, zatem użytkownicy tak czy inaczej nie mogą na niej bazować. Nic złego nie ma również w nadmiarowym implementowaniu interfejsów. Interesujące jest to, że jeśli Twoja metoda zwraca IEnumerable, otrzymasz klasę implementującą pięć różnych interfejsów (włącznie z IDisposable). Specyfikacja wyjaśnia to zachowanie szczegółowo, ale jako programista nie musisz się nim specjalnie przejmować. Fakt, iż są implementowane oba interfejsy — IEnumerable i IEnumerator — jest odrobinę nietypowy. Kompilator musi się trochę namęczyć, aby mieć pewność, że — niezależenie od sposobu użycia — zachowanie będzie prawidłowe, ale potrafi sobie poradzić (w najczęściej występującym przypadku, czyli wtedy, kiedy iterujesz po kolekcji w tym samym wątku, który utworzył iterator), tworząc również pojedynczą instancję typu zagnieżdżonego. Zachowanie właściwości Current jest dziwne. Wskazywanie na ostatni element kolekcji po tym, jak niewątpliwie przeszliśmy dalej, sprawia, że nie może on trafić do garbage collectora. Jest możliwe, że to zachowanie zostanie poprawione w przyszłej wersji kompilatora C#, chociaż raczej mało prawdopodobne, gdyż doprowadziłoby do popsucia istniejącego kodu6. Ściślej rzecz biorąc, zachowanie to jest poprawne z punktu widzenia specyfikacji języka C# 2, która mówi, że w tej sytuacji zachowanie właściwości Current jest nieokreślone. Byłoby jednak przyjemniej, gdyby implementacja miała postać sugerowaną przez dokumentację środowiska, czyli rzucała w odpowiednich momentach wyjątki. Istnieje zatem kilka niedociągnięć związanych z używaniem kodu wygenerowanego automatycznie, ale wyczuleni użytkownicy nie powinni mieć z tym żadnych problemów. 6

Kompilatory C# firmy Microsoft wypuszczone w ramach .NET 3.5 i 4 zachowują się w taki sam sposób.

Przykłady z życia

213

Z drugiej strony trzeba przyznać, że oszczędzamy sobie pisania dużej ilości kodu, aby doprowadzić do tej implementacji, a to oznacza, że możemy znacznie częściej korzystać z iteratorów, niż miało to miejsce w C# 1. Kolejny podrozdział przedstawia kilka przykładowych implementacji. Będziesz mógł sprawdzić, jak dobrze zrozumiałeś uproszczenia iteratorów, a także zobaczyć ich przydatność w rzeczywistych warunkach.

6.3.

Przykłady z życia Czy kiedykolwiek zdarzyło Ci się napisać naprawdę prosty w swojej istocie kod, który sprawił, że później Twój projekt był znacznie przyjemniejszy? Mnie zdarza się to od czasu do czasu i sprawia, że czuję się wtedy bardziej szczęśliwy, niż wskazywałyby na to okoliczności — w każdym razie wystarczająco, aby zasłużyć na zdziwione miny moich kolegów z pracy. Tego typu dziecięcy zachwyt jest szczególnie silny w przypadku użycia nowej cechy języka w sposób bezspornie przyjemniejszy od istniejących rozwiązań, i to nie tylko z chęci pobawienia się nowymi zabawkami. Mimo iż używam iteratorów już od kilku lat, nadal zdarzają się sytuacje, kiedy moim oczom ukazuje się rozwiązanie z możliwością użycia uproszczenia iteratora, a powstały w ten sposób kod jest krótki, przejrzysty i łatwy w zrozumieniu. W tej sekcji podzielę się z Tobą trzema takimi scenariuszami.

6.3.1. Iterowanie po datach w harmonogramie Pracując nad projektem, którego częścią były harmonogramy, natknąłem się na kilka pętli zaczynających się mniej więcej tak: for (DateTime day = timetable.StartDate; day <= timetable.EndDate; day = day.AddDays(1))

Pracowałem często nad tym kodem i szczerze nie lubiłem tej pętli, ale dopiero kiedy przeczytałem ją na głos mojemu koledze programiście w formie pseudokodu, zrozumiałem, że brakowało mi pewnej sztuczki. Powiedziałem coś w stylu „dla każdego dnia w harmonogramie”. Dokonując retrospekcji, jasno widać, że to, co naprawdę miałem na myśli, to pętla foreach. (Być może dla Ciebie było to oczywiste od samego początku — przepraszam, jeśli faktycznie tak jest. Na szczęście nie widzę uśmieszku na Twojej twarzy). Powyższa pętla wygląda znacznie lepiej po przepisaniu jej w taki sposób: foreach (DateTime day in timetable.DateRange)

W C# 1 taka konstrukcja wyglądałaby jak ze snu, gdyby nie trzeba było myśleć o implementacji: widzieliśmy już, jak nieprzyjemne jest ręczne implementowanie iteratora, dlatego też w ostatecznym rozrachunku użycie kilku pętli for jest lepszym rozwiązaniem. Inaczej sprawa ma się w C# 2, gdzie iteratory są proste. Wystarczyło znaleźć klasę reprezentującą harmonogram i dodać właściwość: public IEnumerable DateRange { get {

214

ROZDZIAŁ 6

Implementowanie iteratorów w prosty sposób for (DateTime day < StartDate; day <= EndDate; day = day.AddDays(1)) { yield return day; } } }

Ta operacja przesunęła jedynie oryginalną pętlę do klasy harmonogramu, ale to dobrze — kod wygląda o wiele lepiej, kiedy ta pętla znajduje się właśnie tam, we właściwości, która przechodzi tylko po dniach, wydając po jednym z nich przy każdym obrocie, niż kiedy „siedzi” w środku właściwej logiki biznesowej posługującej się jedynie tymi dniami. Gdyby kiedykolwiek przyszło mi skomplikować implementację (na przykład pomijać weekendy i święta państwowe), mógłbym to zrobić raz i zebrać pochwały za poprawę we wszystkich miejscach kodu. Ta mała zamiana wprowadziła ogromną poprawę w czytelności całego kodu. Jak to zwykle bywa, na niej zakończyłem refaktoryzację kodu produkcyjnego. Myślałem jeszcze o wprowadzeniu typu Zakres do reprezentowania ogólnego zakresu wartości, ale ponieważ był on przydatny tylko w tym jednym miejscu, uznałem, że szkoda poświęcać więcej czasu na ten problem. Okazało się, że była to właściwa decyzja. Utworzyłem taki typ w pierwszej części tej książki, ale okazało się, że ma on pewne niedociągnięcia, które trudno było naprawić w sposób akceptowany z punktu widzenia celów postawionych przed książką. Na potrzeby mojej biblioteki całkowicie przeprojektowałem ten typ, a mimo to nadal ma on pewne mankamenty. Tego rodzaju struktury znacznie lepiej prezentują się jako pomysły w głowie niż faktyczne implementacje — prędzej czy później napotkasz jakiś przypadek szczególny, który będzie musiał być obsłużony. Dokładne opisywanie problemów związanych z moim typem wykracza poza zakres tej książki — należą one raczej do kategorii projektowania w ogólności niż samego języka C# (ponieważ jednak same w sobie stanowią dosyć ciekawy problem, poświęciłem im osobny artykuł, dostępny na stronie książki — http://mng.bz/GAms)7. Kolejny przykład należy do moich ulubionych — demonstruje on wszystko to, co kocham w uproszczeniach iteratorów.

6.3.2. Iterowanie po wierszach pliku Jest to tak częste zadanie, że nie zawahałem się wspomnieć o nim we wstępie do tego rozdziału. Strach pomyśleć, jak często pisałem kod w takiej postaci: using (TextReader reader = File.OpenText(filename)) { string line; while ((line = reader.ReadLine()) != null) { // Zrób coś pożytecznego z wierszem } }

7

Odpowiednikiem typu Zakres w omawianym artykule jest Range — przyp. tłum.

Przykłady z życia

215

Mieszają się tutaj cztery różne koncepcje: sposób uzyskiwania dostępu do instancji klasy TextReader, zarządzanie czasem życia instancji klasy TextReader, iterowanie po wierszach zwracanych przez TextReader.ReadLine, wykonywanie użytecznej operacji na każdym wierszu.

Jedynie pierwsze i ostatnie zadanie są specyficzne dla tej konkretnej sytuacji — zarządzanie czasem życia obiektu oraz mechanizm iterowania są ogólnymi elementami kodu. (Zarządzanie czasem życia obiektu w C# jest proste, a to dzięki wyrażeniom using!) Istnieją dwa sposoby poprawienia stanu istniejącego. Moglibyśmy użyć delegata — napisać metodę narzędziową, która jako parametry przyjęłaby instancję klasy TextReader oraz delegat, wywołała delegat dla każdego wiersza w pliku i zamknęła plik na końcu. Jest to częsty przykład demonstrujący użycie domknięć w połączeniu z delegatami, ale jest jeszcze alternatywne rozwiązanie, które ja uznaję za bardziej eleganckie i znacznie lepiej pasujące do LINQ. Zamiast przekazywać naszą logikę do metody w formie delegata, możemy użyć iteratora do zwracania pojedynczego wiersza z pliku, a następnie skorzystać ze zwykłej pętli foreach. Cel ten możesz osiągnąć, używając kompletnego typu implementującego IEnumerable ´ (w mojej bibliotece MiscUtils to zadanie realizuje klasa LineReader), ale użycie samodzielnej metody w istniejącej klasie też będzie zadowalające. Poniższy listing (6.8) pokazuje prostotę tego rozwiązania: Listing 6.8. Iterowanie po wierszach pliku przy użyciu uproszczenia iteratora static IEnumerable ReadLines(string filename) { using (TextReader reader = File.OpenText(filename)) { string line; while ((line = reader.ReadLine()) != null) { yield return line; } } } ... foreach (string line in ReadLines("test.txt")) { Console.WriteLine(line); }

Ciało metody wygląda niemal identycznie jak kod, który widzieliśmy wcześniej. Różnica polega na tym, że teraz wydajemy każdy wiersz wywołującemu nas fragmentowi kodu, który iteruje po całej kolekcji. Tak jak poprzednio, otwarliśmy plik, przeczytaliśmy po jednym wierszu i na końcu zamknęliśmy go, kończąc naszą pracę... chociaż wyrażenie „kończąc naszą pracę” jest teraz bardziej interesujące niż w przypadku użycia wyrażenia using wewnątrz zwykłej metody, gdzie przepływ sterowania był bardziej oczywisty.

216

ROZDZIAŁ 6

Implementowanie iteratorów w prosty sposób

Właśnie dlatego istotne znaczenie ma fakt, iż pętla foreach niszczy iterator, ponieważ dzięki temu mamy pewność, że obiekt czytający plik zostanie posprzątany. Wyrażenie using w metodzie iteratora działa jak blok try/finally, gdzie część finally zostanie wykonana, jeśli dotrzemy do końca pliku lub wywołamy Dispose na IEnumerator ´, będąc gdzieś w środku drogi do końca odczytu. Kod korzystający z iteratora mógłby doprowadzić do nadużycia instancji IEnumerator zwróconej przez ReadLines(...).GetEnumerator() i spowodować tym samym wyciek pamięci, ale jest to znane ryzyko związane z wykorzystaniem interfejsu IDisposable (jeśli nie wywołasz Dispose, możesz doprowadzić do wycieku pamięci). Szansa pojawienia się takiego problemu jest mała, ponieważ foreach dba, aby wszystko było w porządku. Warto jednak być świadomym możliwego nadużycia — jeśli bazujesz na składni try/finally w iteratorze w celu nadania pewnych uprawnień, a następnie odebrania ich później, może to doprowadzić do powstania luki w systemie bezpieczeństwa. Ta metoda zawiera pierwsze trzy z czterech koncepcji wymienionych wcześniej, ale jest odrobinę restrykcyjna. Traktowanie jednakowo aspektów zarządzania czasem życia obiektu i iteracji wydaje się rozsądne, ale co, jeśli nie czytamy z pliku, ale ze strumienia sieciowego? Albo chcemy użyć kodowania innego niż UTF-8? Musimy oddać pierwszą część z powrotem pod kontrolę kodu wywołującego. Najbardziej oczywistym rozwiązaniem byłaby zmiana sygnatury metody na przyjmującą TextReader jako parametr: static IEnumerable ReadLines(TextReader reader)

Jest to jednak zły pomysł. Chcemy przejąć kontrolę na obiektem czytającym, aby móc posprzątać go w sposób wygodny dla kodu wywołującego, oznacza to jednak, że musimy go posprzątać, o ile tylko kod wywołujący używa naszego kodu w odpowiedni sposób. Problem polega na tym, że jeśli coś się stanie przed pierwszym wywołaniem MoveNext(), nie będziemy mieć żadnej szansy na posprzątanie, ponieważ żaden fragment naszego kodu nie zostanie wykonany. Typ IEnumerable nie jest typem obsługującym niszczenie, a mimo to zapisalibyśmy w nim fragment stanu programu, który wymagałby zniszczenia. Inny problem pojawiłby się, gdyby GetEnumerator() został wywołany dwukrotnie. Spodziewanym zachowaniem byłoby utworzenie dwóch niezależnych iteratorów, ale oba używałyby tego samego obiektu do odczytu pliku. Moglibyśmy nieco złagodzić problem przez zmianę typu zwracanego na IEnumerator, ale to oznaczałoby, że zwrócony wynik nie będzie mógł być używany w pętli foreach i nadal będziemy zmuszeni do ręcznego wykonania ewentualnego kodu sprzątającego, jeśli nigdy nie dotrzemy przynajmniej do pierwszego wywołania MoveNext(). Na szczęście istnieje obejście tego problemu. Prawdą jest, że nasz kod nie jest wykonywany natychmiast, ale w związku z tym obiekt odczytujący plik też nie jest potrzebny natychmiast. To, czego potrzebujemy, to sposób na pobranie obiektu czytającego, w chwili kiedy będzie on wymagany do dalszej pracy. Moglibyśmy skorzystać z interfejsu reprezentującego koncepcję: „Jestem w stanie dostarczyć TextReader, kiedy będziesz go potrzebować”, ale myśl o interfejsie z pojedynczą metodą powinna instynktownie podsunąć Ci pomysł użycia delegata. Dokonamy teraz małego oszustwa polegającego na wprowadzeniu delegata będącego częścią .NET 3.5. Ma on wiele przeciążeń w postaci różnej liczby parametrów typu, ale my skorzystamy wyłącznie z jednej wersji:

Przykłady z życia

217

public delegate TResult Func()

Jak widzisz, ten delegat nie ma parametrów, ale zwraca wynik o takim samym typie jak parametr typu. Jest to klasyczny dostawca lub sygnatura fabryki. W naszym przypadku chcemy otrzymać TextReader, zatem użyjemy Func. Zmiany w metodzie są proste: static IEnumerable ReadLines(Func provider) { using (TextReader reader = provider()) { string line; while ((line = reader.ReadLine()) != null) { yield return line; } } }

Teraz nasz zasób (obiekt czytający) jest pobierany tuż przed jego faktycznym użyciem i, kiedy ma to miejsce, jesteśmy już w kontekście IDisposable, dzięki czemu możemy zwolnić go w odpowiednim czasie. Ponadto, jeśli GetEnumerator() zostanie wywołany kilkakrotnie na otrzymanym wyniku, każdy powstały iterator będzie posiadał niezależną kopię obiektu klasy TextReader. Możemy skorzystać z metod anonimowych i z łatwością dodać przeciążenie, które będzie otwierać plik, opcjonalnie ze wskazanym rodzajem kodowania. static IEnumerable ReadLines(string filename) { return ReadLines(filename, Encoding.UTF8); } static IEnumerable ReadLines(string filename, Encoding encoding) { return ReadLines(delegate { return new StreamReader(filename, encoding); }); }

Ten prosty przykład wykorzystuje metody generyczne, metodę anonimową (przechwytującą parametry) i uproszczenie iteratora. Brakuje tylko nullowalnych typów wartościowych i mielibyśmy komplet wszystkich głównych cech C# 2. Z rozwiązań tego typu skorzystałem przy wielu okazjach i za każdym razem otrzymany wynik był o wiele bardziej przejrzysty w porównaniu do kodu, od którego zaczynaliśmy rozdział. Na koniec, mimo że posługujemy się wyłącznie C# 2, posmakujmy odrobinę LINQ.

6.3.3. Leniwe filtrowanie elementów z użyciem uproszczenia iteratora i predykatu Mimo że nie przyglądaliśmy się jeszcze LINQ w należyty sposób, jestem pewny, że masz jakieś pojęcie na temat sedna tej technologii: pozwala ona na wykonywanie zapytań danych w prosty i funkcjonalny sposób w odniesieniu do różnych źródeł danych, takich jak kolekcje w pamięci i bazy danych. C# 2 nie posiada wyrażeń kwerendowych

218

ROZDZIAŁ 6

Implementowanie iteratorów w prosty sposób

wbudowanych w język ani też wyrażeń lambda i metod rozszerzających, dzięki którym są one tak zwięzłe. Nadal jednak możemy osiągnąć podobne efekty, choć w ograniczonym stopniu. Jedną z cech LINQ jest filtrowanie z użyciem metody Where. Dostarczasz kolekcję i predykat, a rezultatem jest leniwie wyliczone zapytanie, którego wynik to wyłącznie elementy w kolekcji pasujące do predykatu. Jest to zachowanie podobne do List ´.FindAll, tyle że leniwe i działające w połączeniu z IEnumerable. Jedną z pięknych rzeczy w LINQ8 jest pomysłowość samego projektu. Zaimplementowanie LINQ dla Obiektów jest całkiem prostym zadaniem, o czym przekonamy się teraz, przynajmniej jeśli chodzi o metodę Where. Chociaż większość cech języka, które pozwalają błyszczeć LINQ, jest częścią C# 3, jak na ironię, są to głównie cechy mówiące raczej, jak możesz uzyskać dostęp do metod typu Where, niż jak są one zaimplementowane. Listing 6.9 prezentuje pełny przykład, łącznie z prostą walidacją argumentów i użyciem filtra w celu wyświetlenia wszystkich dyrektyw using w pliku kodu źródłowego tego przykładu. Listing 6.9. Implementowanie metody LINQ — Where — z użyciem uproszczeń iteratora public static IEnumerable Where(IEnumerable source, Predicate predicate) { if (source == null || predicate == null) Bezzwłoczne { sprawdzenie argumentów throw new ArgumentNullException(); } Leniwe przetworzenie danych return WhereImpl(source, predicate); } private static IEnumerable WhereImpl(IEnumerable source, Predicate predicate) { foreach (T element in source) Sprawdzenie bieżącego elementu { względem predykatu if (predicate(element)) { yield return element; } } } ... IEnumerable lines = ReadLines("../../FakeLinq.cs"); Predicate predicate = delegate(string line) { return line.StartsWith("using"); }; foreach (string line in Where(lines, predicate)) { Console.WriteLine(line); }

Jak widzisz, rozdzieliliśmy implementację na dwie części: walidację argumentów i prawdziwą logikę biznesową. Jest to niezbyt eleganckie, ale potrzebne w celu uzyskania roz8

Lub, mówiąc dokładniej, LINQ dla Obiektów. LINQ dla baz danych jest o wiele bardziej skomplikowany.

Pseudosynchroniczny kod z użyciem biblioteki CCR

219

sądnej obsługi błędów. Załóżmy, że umieścilibyśmy wszystko w tej samej metodzie. Co stałoby się, gdybyśmy wywołali Where(null, null)? Odpowiedź brzmi: nic... oczekiwany wyjątek nie zostałby rzucony. Ma to związek z leniwą semantyką uproszczeń iteratorów: żaden fragment kodu wewnątrz metody z implementacją iteratora nie zostanie wykonany do momentu pierwszego wywołania MoveNext() (mówiliśmy o tym w sekcji 6.2.2). W typowych warunkach chcesz bezzwłocznie sprawdzić założenia metody — nie ma powodu, aby opóźniać rzucenie wyjątku, ponieważ utrudni to jedynie debugowanie programu. Standardowym rozwiązaniem tego problemu jest podzielenie metody na dwie części, tak jak zrobiliśmy to na listingu 6.9. Zaczęliśmy od sprawdzenia argumentów ( ) w zwykłej metodzie, a następnie wywołaliśmy metodę zaimplementowaną z użyciem uproszczenia iteratora do leniwego przetworzenia danych, kiedy pojawi się takie żądanie ( ). Samo uproszczenie iteratora jest porażająco trywialne: sprawdzamy predykat dla każdego elementu w oryginalnej kolekcji ( ) i, jeśli pasuje, zwracamy wartość. Jeśli nie pasuje, sprawdzamy kolejne elementy tak długo, aż znajdziemy coś, co pasuje, lub skończą się elementy w kolekcji. Całość jest prosta, chociaż implementacja tego samego zachowania w C# 1 byłaby o wiele trudniejsza do prześledzenia (i oczywiście nie mogłaby bazować na generykach). Ostatni fragment kodu, demonstrujący praktyczne użycie metody, korzysta z naszego poprzedniego przykładu w celu dostarczenia danych — w tym przypadku kodu źródłowego przykładu. Predykat sprawdza, czy dany wiersz rozpoczyna się od słowa „using”. Oczywiście, nic nie stoi na przeszkodzie, aby jego logika była o wiele bardziej skomplikowana. Chcąc sprawić, by formatowanie kodu było bardziej przejrzyste, stworzyłem oddzielne zmienne dla danych i predykatów, ale całość równie dobrze można było napisać w formie kodu inline. Istotne jest, aby zauważyć fundamentalną różnicę pomiędzy tym przykładem a odpowiednikiem osiągającym ten sam efekt przy użyciu File.ReadAllLines i Array.FindAll: implementacja jest całkowicie leniwa i strumieniowa. W danej chwili w pamięci wymagany jest pojedynczy wiersz danych. Oczywiście, w naszym konkretnym przypadku nie ma to znaczenia, ponieważ rozmiar pliku jest mały, ale jeśli wyobrazisz sobie wielogigabajtowy plik dziennika, od razu dostrzeżesz korzyści z takiego podejścia. Mam nadzieję, że przytoczone przykłady dały Ci odczuć, dlaczego uproszczenia iteratorów są tak ważne, i być może wzmogły pragnienie przyspieszenia i dowiedzenia się więcej na temat LINQ. Zanim to się jednak stanie, chciałbym trochę zamieszać w Twojej głowie, przedstawiając całkowicie dziwaczne (chociaż zmyślne) użycie iteratorów.

6.4.

Pseudosynchroniczny kod z użyciem biblioteki CCR Concurrency and Coordination Runtime (CCR) jest biblioteką stworzoną przez Microsoft w celu zaoferowania alternatywnego sposobu pisania kodu asynchronicznego, który może wymagać skomplikowanej koordynacji. W chwili powstawania niniejszej książki biblioteka ta jest dostępna jedynie jako część Microsoft Robotics Studio (zobacz

220

ROZDZIAŁ 6

Implementowanie iteratorów w prosty sposób

http://www.microsoft.com/robotics) lub Microsoft CCR and DSS Toolkit. Microsoft poświęca sporo swoich zasobów w celu wzbogacenia różnorodnych projektów o elementy konkurencyjności. Z punktu widzenia programistów jednym z najważniejszych jest środowisko Parallel Extensions dołączone do .NET 4. Ja jednak chcę użyć CCR, aby pokazać Ci, jak uproszczenia iteratorów potrafią zmienić cały model wykonania9. Podany w przykładzie kod będzie faktycznie działał (w połączeniu z „atrapami” usług), ale bardziej istotne od szczegółów są same idee. Załóżmy, że piszemy serwer, który musi obsłużyć wiele żądań. W ramach obsługi tych żądań musimy w pierwszej kolejności wywołać usługę sieciową, aby uzyskać token autoryzujący, a następnie użyć tego tokena do pobrania danych z dwóch niezależnych źródeł (powiedzmy, że będzie to inna usługa sieciowa i baza danych). Na końcu przetwarzamy otrzymane dane i zwracamy wynik. Każda z faz pobierania danych może zająć chwilę — prawdopodobnie do kilku sekund. Zazwyczaj w takiej sytuacji rozważylibyśmy zwykłe podejście synchroniczne lub typowy mechanizm asynchroniczny. Wersja synchroniczna mogłaby wyglądać mniej więcej tak: HoldingsValue ComputeTotalStockValue(string user, string password) { Token token = AuthService.Check(user, password); Holdings stocks = DBService.GetStockHoldings(token); StockRates rates = StockService.GetRates(token); return ProcessStocks(stocks, rates); }

Całość jest zrozumiała, ale jeżeli każde żądanie zajmuje dwie sekundy, cała operacja zajmie sześć sekund, a w tym czasie wątek będzie zablokowany. Jeżeli chcemy osiągnąć skalę setek lub tysięcy żądań wykonywanych równolegle, mamy kłopot. Teraz rozważmy względnie prostą wersję asynchroniczną, która unika blokowania wątku, kiedy nic się nie dzieje10, i tam, gdzie to możliwe, używa wywołań równoległych: void StartComputingTotalStockValue(string user, string password) { AuthService.BeginCheck(user, password, AfterAuthCheck, null); } void AfterAuthCheck(IAsyncResult result) { Token token = AuthService.EndCheck(result); IAsyncResult holdingsAsync = DBService.BeginGetStockHoldings (token, null, null); StockService.GetRates(token, AfterGetRates, holdingsAsync); } void AfterGetRates(IAsyncResult result) { IAsyncResult holdingsAsync = (IAsyncResult)result.AsyncState; StockRates rates = StockService.EndGetRates(result);

9

Do osiągnięcia podobnego wyniku w C# 4, choć w nieco odmienny sposób, użyłbyś Task.ContinueWith... lub być może Reactive Extensions.

10

W większości przypadków, ale nie zawsze — o czym przekonamy się za chwilę.

Pseudosynchroniczny kod z użyciem biblioteki CCR

221

Holdings stocks = DBService.EndGetStockHoldings(holdingsAsync); OnRequestComplete(ProcessStocks(stocks, rates)); }

Ten kod jest znacznie trudniejszy do przeczytania i zrozumienia, chociaż jest to tylko prosta wersja! Koordynacja dwóch równoległych wywołań jest możliwa do osiągnięcia bez zbytnich komplikacji jedynie dlatego, iż nie musimy przekazywać żadnego dodatkowego stanu, ale i tak rozwiązanie nie jest idealne. Jeżeli wywołanie usługi akcji zakończy się szybko, nadal doprowadzimy do zablokowania wątku, czekając na wynik z bazy danych. Co ważniejsze, kod źródłowy w żadnym wypadku nie będzie „objaśniał”, co się dzieje, ponieważ punkt wykonania skacze pomiędzy różnymi metodami. Prawdopodobnie zastanawiasz się, gdzie w tym kodzie jest miejsce dla iteratorów. Uproszczenia iteratorów udostępniane przez C# 2 pozwalają Ci na zatrzymanie wykonania w określonych punktach, a następnie powrót do tego samego miejsca z tym samym stanem. Zmyślni inżynierowie projektujący CCR zdali sobie sprawę z tego, co jest niezbędne do umożliwienia kontynuacyjno-przekazującego stylu (ang. continuation-passing style) programowania. Musimy powiedzieć systemowi, że są pewne operacje, które musi wykonać — włączając w to asynchroniczne uruchomienie innych operacji — ale jesteśmy w pełni gotowi zaczekać do momentu, kiedy te asynchroniczne operacje zostaną zakończone, zanim będziemy kontynuować. Robimy to, udostępniając CCR implementację interfejsu IEnumerable (gdzie ITask jest interfejsem zdefiniowanym przez CCR). Oto przykładowy kod, który osiąga te same wyniki przy zastosowaniu powyższego stylu: static IEnumerator ComputeTotalStockValue(string user, string password) { string token = null; yield return Arbiter.Receive(false, AuthService.CcrCheck(user, password), delegate(string t) { token = t;}); IEnumerable stocks = null; IDictionary rates = null; yield return Arbiter.JoinReceive(false, DBService.CcrGetStockHoldings(token), StockService.CcrGetRates(token), delegate(IEnumerable s, IDictionary r) { stocks = s; rates = r; }); OnRequestComplete(ProcessStocks(stocks, rates); }

Zakłopotany? Ja również byłem, kiedy zobaczyłem ten kod pierwszy raz — teraz jednak stoję w zachwycie nad zmyślnością tego rozwiązania. CCR wywołuje nasz kod (wykonując MoveNext na iteratorze), a nasz kod działa do napotkania pierwszego wyrażenia yield return (z nim włącznie). Metoda CcrCheck wewnątrz AuthService rozpoczyna asynchroniczne żądanie. W tym czasie CCR czeka (bez korzystania z dedykowanego wątku) do momentu zakończenia żądania, a następnie wywołuje dostarczony delegat do obsłużenia wyniku. W kolejnym kroku ponownie wywołuje MoveNext, a nasza metoda wznawia działanie. Tym razem wykonujemy równolegle dwa żądania i po ich zakończeniu prosimy CCR o wywołanie kolejnego delegata z wynikami obu operacji. W końcu metoda MoveNext zostaje wywołana ostatni raz, dając nam szansę na zakończenie procesu obsługi.

222

ROZDZIAŁ 6

Implementowanie iteratorów w prosty sposób

Chociaż stopień skomplikowania jest znacznie większy niż w przypadku wersji synchronicznej, wszystko nadal znajduje się wewnątrz jednej metody, jest wykonywane w zapisanym porządku, a metoda sama potrafi utrzymywać stan (w zmiennych lokalnych, które stają się stanem dodatkowym w typie wygenerowanym przez kompilator). Całość jest w pełni asynchroniczna i używa najmniejszej możliwej liczby wątków. Nie pokazałem żadnego kodu do walidacji danych, ale jest on możliwy do wprowadzenia przy zachowaniu ostrożności i przemyśleniu problemu w odpowiednich miejscach. Celowo nie zagłębiałem się w szczegóły klasy Arbiter, interfejsu ITask itp. Moim celem w tej sekcji nie jest promowanie CCR, chociaż jest to fascynująca technologia, o czym można się przekonać, zarówno o niej czytając, jak i praktycznie z nią eksperymentując. Podejrzewam, że wśród programistów bardziej rozpowszechni się inna technologia — Parallel Extensions. Celem było wskazanie, iż iteratory mogą być użyte w sytuacjach radykalnie odmiennych, które mają niewiele wspólnego z tradycyjnymi kolekcjami. Sednem ich użycia w tym przypadku jest maszyna stanowa: dwa z podchwytliwych aspektów programowania asynchronicznego to obsługa stanu i zatrzymywanie wykonania do momentu, kiedy zdarzy się coś interesującego. Uproszczenia iteratora są idealnym rozwiązaniem obu tych problemów.

6.5.

Podsumowanie C# obsługuje wiele wzorców projektowych pośrednio — w sensie realnej możliwości zaimplementowania ich przy użyciu tego języka. Jednak niewiele wzorców jest bezpośrednio obsługiwanych w sensie cech języka stworzonych specjalnie w tym celu. W C# 1 wzorzec iteratora był bezpośrednio obsługiwany z punktu widzenia kodu wywołującego, ale nie z punktu widzenia kolekcji, po której chcieliśmy iterować. Pisanie poprawnego kodu interfejsu IEnumerable było czasochłonne, podatne na błędy i mało interesujące. W C# 2 całą nudną pracę wykonuje za nas kompilator, który buduje maszynę stanową, aby można było sobie poradzić z „callbackową” naturą iteratorów. Warto zauważyć, iż mimo zupełnej odrębności obu cech uproszczenia iteratorów i metody anonimowe, które zobaczyliśmy w rozdziale 5., mają ze sobą coś wspólnego. W obu przypadkach mogą być generowane dodatkowe typy danych i stosowane potencjalnie skomplikowane transformacje oryginalnego kodu źródłowego. Porównaj to z C# 1, gdzie większość transformacji oferowanych przez semantykę języka (takich jak lock, using i foreach) była w miarę prosta. Jak się wkrótce przekonamy, ten trend w kierunku sprytniejszej kompilacji będzie widoczny przy niemal każdym aspekcie C# 3. W tym rozdziale pokazałem Ci jeden fragment funkcjonalności związanej z LINQ — filtrowanie kolekcji. IEnumerable jest jednym z najważniejszych typów w LINQ, a jeśli kiedykolwiek będziesz chciał napisać własne operatory LINQ bazujące na LINQ dla Obiektów11, będziesz dozgonnie wdzięczny zespołowi projektantów C# za dołączenie do języka uproszczeń iteratorów. Oprócz kilku praktycznych zastosowań iteratorów zobaczyliśmy również przypadek ich dosyć radykalnego użycia (w połączeniu z pewną biblioteką), który ma mało

11

To zadanie nie jest trudne i sprawia większą radość, niż można by się spodziewać. Kilka wskazówek na ten temat znajdziemy w rozdziale 12.

Podsumowanie

223

wspólnego z tym, co przychodzi nam do głowy, kiedy myślimy o iterowaniu po kolekcjach. Warto pamiętać, że ten problem był już wcześniej podejmowany przez autorów innych języków, a z koncepcjami tego typu łączy się termin znany w informatyce pod pojęciem współprogramów. Współprogramy były w większym lub mniejszym stopniu obsługiwane w różnych językach, czasami poprzez symulację z użyciem odpowiednich trików — przykładem może być doskonały artykuł Simona Tathama opisujący możliwości wyrażania współprogramów w C przy odpowiednim „naciągnięciu” standardów kodowania (zobacz http://mng.bz/H8YX). My przekonaliśmy się o prostocie pisania i użytkowania współprogramów w C# 2. Po zbadaniu paru głównych i czasem trudnych do pojęcia zmian skupionych wokół kilku kluczowych cech języka w kolejnym rozdziale zwolnimy tempo. Opisuje on szereg małych zmian, które sprawiają, że C# 2 jest w pracy przyjemniejszym językiem od swojego poprzednika. Pozbyto się w nim drobnych błędów z przeszłości i stworzono język z mniejszą liczbą ostrych kantów, większym wsparciem dla nietypowych przypadków kompatybilności wstecz i lepszym scenariuszem pracy z wygenerowanym kodem. Każda z tych cech jest względnie prosta, ale jest ich całkiem sporo.

224

ROZDZIAŁ 6

Implementowanie iteratorów w prosty sposób

Pozostałe cechy C# 2

Ten rozdział omawia: ♦ typy częściowe, ♦ klasy statyczne, ♦ niezależny poziom dostępu do gettera/settera, ♦ aliasy przestrzeni nazw, ♦ dyrektywę pragma, ♦ bufory o stałym rozmiarze, ♦ moduły zaprzyjaźnione.

226

ROZDZIAŁ 7

Pozostałe cechy C# 2

Do tej pory omówiliśmy cztery najistotniejsze cechy C# 2: generyki, typy nullowalne, udoskonalenia delegatów i uproszczenia iteratorów. Każda z nich jest odpowiedzią na w miarę skomplikowany wymóg, dlatego też przyglądaliśmy się im dosyć szczegółowo. Pozostałe nowe cechy C# 2 wygładzają nierówności C# 1. Są to małe niedogodności pozostawione świadomie przez projektantów języka — głównie obszary, w których język potrzebował drobnego ulepszenia lub w których warto było tak usprawnić pracę z wygenerowanym i natywnym kodem, by była ona przyjemniejsza. Z biegiem czasu Microsoft otrzymywał coraz więcej opinii i komentarzy od społeczności C# (i bez wątpienia od swoich własnych programistów) dotyczących obszarów, w których C# „nie błyszczał” tak bardzo, jakby mógł. W celu złagodzenia tych niewielkich, miejscowych dolegliwości do C# 2 wprowadzono szereg mniejszych zmian. Żadna z tych nowych zmian nie jest szczególnie trudna do zrozumienia. Przejdziemy przez nie w miarę szybko. Nie bagatelizuj jednak stopnia ich przydatności — sam fakt, że dany temat można rozpracować na kilku stronach, nie oznacza, że jest on bezużyteczny. Jest wielce prawdopodobne, że niektóre opisane dalej cechy będziesz regularnie stosował w swojej pracy. Żebyś mógł się przekonać, co Cię czeka, przedstawiam krótkie zestawienie cech omawianych w tym rozdziale: Typy częściowe — możliwość zapisania kodu dla typu w wielu plikach źródłowych,

co jest szczególnie użyteczne, kiedy część kodu jest generowana automatycznie, a pozostała część ręcznie. Klasy statyczne — ściślejsze definiowanie klas narzędziowych, pozwalające

kompilatorowi na wykrycie miejsc, w których usiłujesz używać ich w nieodpowiedni sposób, a także jaśniejsze wyrażanie Twoich intencji. Niezależne poziomy dostępu do getterów/setterów — wreszcie, możliwość

posiadania publicznego gettera i prywatnego settera dla właściwości! (Jest to jedyna dostępna możliwość, ale równocześnie najbardziej powszechna). Aliasy przestrzeni nazw — rozwiązanie niejasnych sytuacji, w których nazwy

typów nie są unikalne. Dyrektywy pragma — instrukcje przeznaczone dla kompilatora, pozwalające

zablokować ostrzeżenia dla wybranego fragmentu kodu. Bufory o stałym rozmiarze — większa kontrola nad tym, jak struktury radzą

sobie z tablicami w kodzie niezarządzanym. Klasa InternalsVisibleToAttribute (moduły zaprzyjaźnione) — cecha rozciągająca

się na język, bibliotekę i środowisko, pozwalająca wybranym modułom na szerszy poziom dostępu, kiedy zachodzi taka potrzeba. W tym momencie może Cię korcić, aby przejść do bardziej „seksownych” cech C# 3 — nie mam o to żalu. Nic, co zobaczysz w tym rozdziale, nie jest szczególnie ekscytujące, ale każda z omawianych cech może sprawić, że Twoje życie będzie przyjemniejsze, lub w niektórych przypadkach pozwolić Ci samemu wydostać się z kłopotów. Skoro przyhamowałem już trochę Twoje oczekiwania, przejdźmy do pierwszej cechy, która jest całkiem zmyślna.

Typy częściowe

7.1.

227

Typy częściowe Pierwsza zmiana, której się przyjrzymy, ma związek z walką, jaka miała miejsce podczas używania generatorów kodu w C# 1. Narzędzie do projektowania formularzy okienkowych w Visual Studio wymagało istnienia regionów kodu, które nie mogły być modyfikowane przez programistę, a znajdowały się w tym samym pliku, który programista musiał zmodyfikować, implementując funkcjonalność interfejsu użytkownika. Była to zdecydowanie niestabilna sytuacja. W innych przypadkach generatory tworzyły kod kompilujący się razem z kodem napisanym ręcznie. W C# 1 dokładanie dodatkowej funkcjonalności wymagało dziedziczenia nowych klas po klasach wygenerowanych automatycznie, co jest mało eleganckim rozwiązaniem. Istnieje szereg innych scenariuszy, w których posiadanie nieodpowiedniego połączenia w łańcuchu dziedziczenia może spowodować problemy lub zmniejszyć stopień izolacji. Jeżeli na przykład dwie różne części Twojego kodu chcą wywołać się nawzajem, potrzebujesz metod wirtualnych, aby rodzic mógł wywołać dziecko, i metod chronionych dla sytuacji odwrotnej, podczas gdy normalnie użyłbyś dwóch metod prywatnych i niewirtualnych. C# 2 pozwala na tworzenie typu przez więcej niż jeden plik, a środowiska IDE mogą rozszerzać tę ideę do tego stopnia, iż pewne fragmenty kodu używane do skonstruowania danego typu będą wręcz niewidoczne jako kod źródłowy C#. Typy budowane z wielu plików kodu źródłowego są określane mianem typów częściowych. W tej części poznamy również metody częściowe, które mają sens jedynie w przypadku typów częściowych i pozwalają na dodawanie ręcznie napisanych „kotwic” do automatycznie wygenerowanego kodu w sposób urozmaicony i jednocześnie bardzo wydajny. Tak naprawdę jest to cecha C# 3 (tym razem stworzona w oparciu o komentarze dotyczące C# 2), ale bardziej logiczne wydaje się omówienie jej przy okazji typów częściowych niż czekanie z tym specjalnie do trzeciej części książki.

7.1.1. Tworzenie typu składającego się z kilku plików Tworzenie typu częściowego jest proste — do deklaracji typu w każdym pliku, w którym ten typ występuje, musisz jedynie dołączyć kontekstowe słowo kluczowe partial. Typ częściowy może się rozciągać na dowolną liczbę plików, ale nasze przykłady ograniczą się za każdym razem jedynie do dwóch. Przed kompilacją kompilator łączy wszystkie pliki kodu źródłowego razem. Oznacza to, że kod w jednym z tych plików może wywoływać kod w innym — i odwrotnie (pokazuje to rysunek 7.1). Nie ma potrzeby stosowania deklaracji w przód lub innych trików. Nie możesz napisać połowy elementu w jednym pliku, a drugiej połowy w drugim — każdy element musi się znajdować w całości w jednym pliku1. Istnieje kilka oczywistych restrykcji odnośnie do deklaracji typów — muszą one być kompatybilne. Każdy plik może zawierać interfejsy niezbędne do zaimplementowania (i nie muszą one być implementowane w tym pliku) oraz specyfikować typ bazowy lub ograniczenia na 1

Od tej reguły istnieje wyjątek: typy częściowe mogą zawierać zagnieżdżone typy częściowe rozsiane po tym samym zestawie plików.

228

ROZDZIAŁ 7

Pozostałe cechy C# 2 Rysunek 7.1. Kod w typach częściowych widzi wszystkie elementy typu, niezależnie od tego, w którym pliku się one znajdują

parametrach typu. Jeśli jednak różnorodne pliki specyfikują typ bazowy, typy bazowe muszą być takie same. Podobnie jest z ograniczeniami — muszą być one identyczne we wszystkich plikach. Listing 7.1 pokazuje przykład elastyczności, na jaką można sobie pozwolić (bez skupiania się na robieniu czegokolwiek użytecznego). Listing 7.1. Demonstracja wymieszania deklaracji typu częściowego //Example1.cs using System; partial class Example : IEquatable where TFirst: class { public bool Equals(string second) { return false; } }

Interfejs i ograniczenie parametru typu Określenie liczby rekordów

//Example2.cs using System; partial class Example Klasa bazowa i interfejs : EventArgs, IDisposable { Implementacja IDisposable public void Dispose() { } }

Podkreślam, że powyższy listing powstał wyłącznie na potrzeby dyskusji o tym, co jest dozwolone w deklaracji — użyte typy zostały wybrane jedynie dla wygody oraz ze względu na ich znajomość. Widzimy, że obie deklaracje (( ) i ( )) wymieniają interfejsy, które powinny być zaimplementowane, a każdy plik implementuje interfejsy, które zadeklarował. Jest to typowy scenariusz, ale dopuszczalne jest też przesunięcie implementacji IDisposable ( ) do pliku Example1.cs, a implementacji IEquatable ´ ( ) do pliku Example2.cs. Ja skorzystałem z możliwości wyspecyfikowania interfejsów w oddzieleniu od implementacji, kapsułkując w interfejsie metody o tej samej sygnaturze, wygenerowane dla różnych typów. Generator kodu nie ma pojęcia o tym interfejsie, więc nie wiedziałby, że ten typ go implementuje.

Typy częściowe

229

Część w punkcie ( ) specyfikuje wyłącznie ograniczenia typu, a część w punkcie ( ) wyłącznie klasę bazową. Gdyby punkt ( ) specyfikował klasę bazową, musiałaby to być klasa EventArgs, a jeśli punkt ( ) specyfikowałby jakiekolwiek ograniczenia typu, musiałyby one odpowiadać zawartości z punktu ( ). Warto zauważyć, że nie możemy wyspecyfikować ograniczenia typu dla TSecond w punkcie ( ), nawet jeśli nie został on wspomniany w punkcie ( ). Jeśli został użyty modyfikator dostępu, musi on być jednakowy w obu przypadkach — nie moglibyśmy na przykład zapisać jednej deklaracji jako wewnętrznej (internal), a drugiej jako publicznej (public). Ściśle rzecz biorąc, reguły opisujące łączenie plików w większości przypadków pozwalają na elastyczność, ale jednocześnie wymuszają spójność. Dla typów zawartych w pojedynczych plikach jest gwarantowany porządek inicjalizacji pól i zmiennych statycznych zgodny z ich kolejnością pojawiania się w pliku. Tej gwarancji nie ma w przypadku używania więcej niż jednego pliku dla typu. Już samo przyjmowanie założeń logicznych bazujących na kolejności inicjalizacji jest „śliskie” — kod zostaje otwarty na możliwość pojawiania się subtelnych błędów, jeśli tylko programista zechce „nieszkodliwie” zmienić kolejność elementów wewnątrz klasy. Warto zatem z góry unikać takich sytuacji, jeśli tylko jest to możliwe, a w szczególności kiedy mamy do czynienia z typami częściowymi. Skoro wiemy już, co możemy, a czego nie możemy zrobić, przyjrzymy się bliżej, dlaczego chcielibyśmy to zrobić.

7.1.2. Użycie typów częściowych Jak już wcześniej wspomniałem, użyteczność typów częściowych wiąże się głównie z narzędziami projektowymi oraz innymi generatorami kodu. Jeżeli generator kodu musi zmodyfikować plik będący własnością programisty, niemal zawsze istnieje ryzyko, że coś pójdzie nie tak. W modelu typów częściowych generator kodu posiada na własność plik, w którym będzie wykonywać swoją pracę, z możliwością nadpisania całej jego zawartości, jeśli tylko przyjdzie mu na to ochota. Niektóre generatory kodu w ogóle nie generują pliku z kodem C#, dopóki nie zostanie rozpoczęta budowa projektu. Dla przykładu Snippy posiada pliki XAML (ang. Extensible Application Markup Language) opisujące interfejs użytkownika. Podczas budowy projektu każdy plik XAML jest konwertowany na plik C# w katalogu obj (nazwy plików kończą się rozszerzeniem .g.cs, aby wskazać, iż zostały wygenerowane) i kompilowany z klasą częściową dostarczającą dodatkowy kod dla tego typu (na ogół są to metody obsługi zdarzeń i kod inicjalizujący). Takie rozwiązanie uniemożliwia programistom „podkręcanie” wygenerowanego kodu, chyba że podejmą się żmudnego procesu majstrowania przy pliku definiującym proces budowy. Staram się świadomie używać frazy generator kodu zamiast narzędzie projektowe, ponieważ istnieje wiele generatorów kodów, które nie zawsze są narzędziami do projektowania. Dla przykładu w Visual Studio struktury pośredniczące dla usług sieciowych są generowane jako klasy częściowe, a programiści mogą posiadać własne narzędzia generujące kod na podstawie źródeł danych. Innym powszechnym przykładem jest mapowanie obiektowo-relacyjne (ang. Object-Relational Mapping, ORM) — niektóre narzędzia tego typu używają opisu encji z pliku konfiguracyjnego (lub bezpośrednio

230

ROZDZIAŁ 7

Pozostałe cechy C# 2

z bazy danych) i generują klasy częściowe reprezentujące te encje. Również moja wersja środowiska serializującego Google Protocol Buffer przeniesiona do środowiska .NET generuje klasy częściowe — ta cecha okazała się użyteczna nawet podczas implementacji samego narzędzia. Takie podejście znacznie ułatwia dodawanie „zachowania” do typu przez przeciążanie metod wirtualnych klasy bazowej, dodawanie nowych metod i pól z logiką biznesową itp. Jest to doskonały sposób współpracy programisty i narzędzia w porównaniu do sytuacji, w której trwa ciągła walka o to, kto ma ostateczną kontrolę nad kodem. Jednym z przypadków użycia, który od czasu do czasu okazuje się użyteczny, jest wygenerowanie jednego pliku z kilkoma typami częściowymi, a następnie rozbudowanie ich w innych plikach — po jednym na każdy typ. Wracając do przykładu ORM, narzędzie mogłoby wygenerować pojedynczy plik zawierający definicje wszystkich encji, z których część mogłaby posiadać dodatkowy, napisany przez programistę kod zawarty w jednym pliku na każdą encję. To pozwala na zachowanie małej liczby wygenerowanych plików, ale nadal zapewnia dobrą widoczność kodu napisanego ręcznie. Rysunek 7.2 pokazuje podobieństwo przy zastosowaniu typów częściowych do XAML-a i encji bazy danych, z pewnymi odstępstwami dotyczącymi zależności czasowych w zakresie automatycznie generowanego kodu C#.

Rysunek 7.2. Porównanie między prekompilacją języka XAML i automatycznie generowanymi klasami encji

Trochę odmienną ideą jest użycie typów częściowych do wsparcia procesu refaktoryzacji kodu. Czasami typ zbytnio się rozbudowuje i przyjmuje na siebie zbyt wiele zobowiązań. Jednym z pierwszych kroków przy dzieleniu przesadnie dużego typu na mniejsze i bardziej spójne typy może być przekształcenie go do postaci typu częściowego, rozłożonego w co najmniej dwóch plikach. Takie działanie nie jest obarczone żadnym ryzykiem i może zostać przeprowadzone w sposób eksperymentalny z przenosze-

Typy częściowe

231

niem metod pomiędzy plikami do momentu, kiedy każdy z nich będzie się zajmować rozwiązywaniem wybranego problemu. Mimo że kolejnego kroku rozdzielenia nie można w żaden sposób zautomatyzować, o wiele łatwiej jest wyobrazić sobie cel końcowy. Ostatni przypadek użycia to testy jednostkowe. Często zestaw testów przewidzianych dla klasy potrafi być znacznie większy niż sama jej implementacja. Jednym ze sposobów podzielenia testów na bardziej zrozumiałe zestawy jest użycie typów częściowych. Nadal możesz puścić wszystkie testy dla typu w jednym przebiegu (wciąż istnieje pojedyncza klasa testów), ale teraz testy dla poszczególnych obszarów funkcjonalności widzisz w oddzielnych plikach. Mało tego, edytując ręcznie projekt za pomocą narzędzia Solution Explorer, możesz doprowadzić do takiego samego hierarchicznego rozłożenia plików, jakie widzisz, kiedy typy częściowe zostają użyte w kodzie wygenerowanym przez Visual Studio. Takie podejście nie każdemu przypadnie do gustu, ale ja przekonałem się, że jest to wygodna metoda zarządzania testami. Kiedy typy częściowe pojawiły się w C# 2 po raz pierwszy, mało kto wiedział dokładnie, w jaki sposób należy ich używać. Jedną z cech, której zażądano niemal natychmiast, było umożliwienie dopisywania własnego kodu do metod generowanych automatycznie. Ta potrzeba została zrealizowana w C# 3 pod postacią metod częściowych.

7.1.3. Metody częściowe — tylko w C# 3 Pozwolę sobie powtórzyć wyjaśnienie, którego udzieliłem już wcześniej. Jesteśmy w części książki, która opisuje wyłącznie cechy drugiej wersji C#. Metody częściowe nie pasują jednak do żadnej z cech C# 3, natomiast idealnie się komponują z opisem typów częściowych. Z góry przepraszam za ewentualne zakłopotanie, jakie może spowodować to odstępstwo. Wracając do tematu: czasem chcemy mieć możliwość ręcznego wyspecyfikowania zachowania w samodzielnie stworzonym pliku i połączenia go z zachowaniem będącym wynikiem kodu wygenerowanego automatycznie w innym pliku. Na przykład w klasie posiadającej dużo automatycznie wygenerowanych właściwości chcielibyśmy dopisać kod dokonujący walidacji nowych wartości dla niektórych z tych właściwości. Inny scenariusz to możliwość umieszczenia własnego kodu w automatycznie wygenerowanych konstruktorach w celu przeprowadzenia własnej inicjalizacji zmiennych, dokonania wpisu w dzienniku itp. W C# 2 takie wymagania mogłyby być zrealizowane wyłącznie poprzez użycie zdarzeń subskrybowanych przez ręcznie napisany kod lub zmuszenie automatycznie wygenerowanego kodu do założenia, iż napisany przez programistę kod będzie zawierał metody o określonej nazwie, co doprowadzi do błędu kompilacji, w sytuacji kiedy te metody nie zostaną dostarczone. Jeszcze jedna możliwość to generowanie klasy bazowej z metodami wirtualnymi, które są domyślnie puste. Ręcznie napisany kod może wtedy dziedziczyć po takiej klasie i nadpisywać potrzebne metody. Wszystkie przedstawione sposoby są trochę niechlujne. Metody częściowe C# 3 dają rzeczywiste opcjonalne zakotwiczenia, które przy braku implementacji nie wnoszą żadnego dodatkowego kosztu — wszelkie wywołania niezaimplementowanych metod częściowych są usuwane przez kompilator. Takie rozwiązanie pozwala narzędziom generującym kod na wielką szczodrość pod względem udostępnianych przez nie zakotwiczeń — w skompilowanym kodzie płacisz wyłącznie za to, czego faktycznie

232

ROZDZIAŁ 7

Pozostałe cechy C# 2

użyłeś. Najprościej będzie zrozumieć to, posługując się przykładem. Listing 7.2 pokazuje typ częściowy w dwóch plikach z konstruktorem w wygenerowanym automatycznie kodzie wywołującym dwie metody częściowe, z których jedna została zaimplementowana ręcznie. Listing 7.2. Metoda częściowa wywołana z konstruktora //Generated.cs using System; partial class PartialMethodDemo { public PartialMethodDemo() { OnConstructorStart(); Console.WriteLine("Konstruktor wygenerowany"); OnConstructorEnd(); } partial void OnConstructorStart(); partial void OnConstructorEnd(); } //Handwritten.cs using System; partial class PartialMethodDemo { partial void OnConstructorEnd() { Console.WriteLine("Kod napisany ręcznie"); } }

Jak pokazuje listing 7.2, metody częściowe są deklarowane podobnie do metod abstrakcyjnych, czyli przez umieszczenie sygnatury bez implementacji, ale z użyciem modyfikatora partial. Właściwa implementacja nie różni się niczym od zwykłej metody poza obecnością tego samego modyfikatora w nagłówku. Wywołanie konstruktora bezparametrowego klasy PartialMethodDemo spowodowałoby wypisanie na ekranie zdań Konstruktor wygenerowany i Kod napisany ręcznie. Oglądając kod IL konstruktora, nie znalazłbyś wywołania OnConstructorStart, ponieważ w tym momencie to wywołanie nie byłoby już dostępne — w skompilowanym kodzie nie znalazłbyś po nim żadnego śladu. Ponieważ metoda może nie istnieć, metody częściowe muszą posiadać pusty typ zwracany (void) i nie mogą przyjmować parametrów z modyfikatorem out. Muszą być prywatne, ale mogą być statyczne i/lub generyczne. Jeżeli metoda nie zostanie zaimplementowana w którymkolwiek z plików, wywołujące ją wyrażenie jest usuwane w całości, włącznie z wszelkimi wyrażeniami ewaluującymi argumenty. Jeżeli ewaluacja któregokolwiek z argumentów niesie ze sobą efekt uboczny, który powinien mieć miejsce niezależnie od tego, czy metoda częściowa została zaimplementowana, czy też nie, powinieneś dokonać jej w sposób niezależny od tego wywołania. Dla przykładu załóżmy, że masz przed sobą następujący kod: LogEntity(LoadAndCache(id));

Klasy statyczne

233

LogEntity jest metodą częściową, a LoadAndCache ładuje obiekt z bazy danych i umiesz-

cza go w pamięci podręcznej. Takie operacje lepiej zapisać następująco: MyEntity entity = LoadAndCache(id); LogEntity(entity);

W ten sposób obiekt zostanie załadowany i zapamiętany niezależnie od tego, czy dostarczono implementację metody LogEntity. Oczywiście, jeśli jesteś w stanie załadować obiekt równie małym kosztem później i nie jest on wymagany natychmiast, możesz pozostawić wyrażenie w pierwszej formie i w wybranych przypadkach uniknąć zbędnego procesu ładowania. Mówiąc szczerze, o ile nie zajmiesz się pisaniem własnego generatora kodu, jest bardziej prawdopodobne, że będziesz częściej implementował metody częściowe, niż je deklarował i wywoływał. W takiej sytuacji nie musisz się martwić zagadnieniami ewaluacji argumentów. Podsumowując, metody częściowe C# 3 pozwalają wygenerowanemu kodowi na bardzo bogatą interakcję z kodem napisanym ręcznie, bez ujemnego wpływu na wydajność, w sytuacjach kiedy taka interakcja nie jest wymagana. Jest to naturalna kontynuacja typów częściowych C# 2, które pozwalają na bardziej produktywny związek pomiędzy generatorami kodu i programistami. Nasza kolejna cecha jest zupełnie odmienna i dotyczy przekazywania kompilatorowi dodatkowej wiedzy na temat zamierzonej natury typu, dzięki czemu może on przeprowadzić więcej sprawdzeń zarówno odnośnie do samego typu, jak i kodu, który go używa.

7.2.

Klasy statyczne Kolejna nowa cecha jest pod pewnymi względami zbędna — pozwala jedynie na przedstawienie klas narzędziowych w sposób bardziej zwięzły i elegancki. Każdy ma jakieś klasy narzędziowe. Nie widziałem żadnego większego projektu w Javie czy C#, który nie zawierałby przynajmniej jednej klasy składającej się wyłącznie z funkcji statycznych. Klasycznym przykładem pojawiającym się w kodzie programisty jest typ z metodami pomocniczymi do obsługi łańcuchów, które dekorują, odwracają, sprytnie zastępują itd. Przykładem z biblioteki może być klasa System.Math. A oto kluczowe cechy klasy narzędziowej: Wszystkie pola i metody są statyczne (z wyjątkiem prywatnego konstruktora). Klasa jest wydziedziczona bezpośrednio z object. Zazwyczaj klasa nie utrzymuje swojego stanu, o ile nie mamy do czynienia

z singletonem lub jakąś formą pamięci podręcznej. Nie ma widocznych konstruktorów. Klasa jest zapieczętowana, o ile tylko programista o tym nie zapomni. Dwa ostatnie punkty są opcjonalne — jeśli nie ma widocznych konstruktorów (również chronionych), klasa i tak faktycznie jest zapieczętowana — ale pozwalają jeszcze bardziej uwydatnić cel klasy.

234

ROZDZIAŁ 7

Pozostałe cechy C# 2

Następny listing (7.3) pokazuje przykład klasy narzędziowej w C# 1 — później zobaczymy, jakie udoskonalenia wprowadza C# 2. Listing 7.3. Typowa klasa narzędziowa w C# 1 public sealed class NonStaticStringHelper { private NonStaticStringHelper() { } public static string Reverse(string input) { char[] chars = input.ToCharArray(); Array.Reverse(chars); return new string(chars); }

Zapieczętowanie klasy w celu uniemożliwienia dziedziczenia Uniemożliwienie utworzenia instancji w kodzie Wszystkie metody są statyczne

}

Klasa jest zapieczętowana ( ), aby nikt nie próbował utworzyć typu potomnego. Istotą dziedziczenia jest specjalizacja — w tym przypadku nie ma czego specjalizować, gdyż wszystkie elementy klasy, z wyjątkiem prywatnego konstruktora ( ), są statyczne ( ). Na pierwszy rzut oka sama definicja konstruktora może się wydawać nieco dziwna. Po co w ogóle go mieć, skoro jest prywatny i nigdy nie zostanie użyty? Powód jest taki, że jeśli nie dostarczysz żadnego konstruktora dla klasy, kompilator C# 1 zrobi to za Ciebie, generując bezparametrowy konstruktor domyślny o dostępie publicznym. W naszym przypadku nie chcemy mieć żadnych konstruktorów publicznych, dlatego tworzymy prywatny. Ten wzorzec sprawdza się w miarę dobrze, ale C# 2 pozwala na wskazanie go w sposób jawny i tym samym uniemożliwia wykorzystanie typu w sposób nieprawidłowy. Najpierw zobaczmy, jakie zmiany są potrzebne, aby przekształcić listing 7.3 w poprawną klasę statyczną zgodną z C# 2. Listing 7.4 wskazuje, że potrzeba całkiem niewiele. Listing 7.4. Klasa narzędziowa identyczna jak na listingu 7.3, ale przekonwertowana na statyczną klasę C# 2 using System; public static class StringHelper { public static string Reverse(string input) { char[] chars = input.ToCharArray(); Array.Reverse(chars); return new string(chars); } }

Tym razem w deklaracji klasy zamiast sealed użyliśmy modyfikatora static i w ogóle nie dołączyliśmy konstruktora — są to jedyne różnice w kodzie. Kompilator C# 2 wie, że klasa statyczna nie powinna mieć żadnych konstruktorów, zatem ich nie dostarcza. Oprócz tego wymusza również szereg innych ograniczeń w definicji klasy. A zatem klasa:

Niezależny poziom dostępu do getterów i setterów właściwości

235

Nie może być zadeklarowana jako abstrakcyjna (abstract) lub zapieczętowana (sealed), chociaż niejawnie posiada obie te cechy. Nie może implementować interfejsów. Nie może wskazywać typu bazowego. Nie może zawierać żadnych niestatycznych elementów, włączając

w to konstruktory. Nie może zawierać żadnych operatorów. Nie może zawierać żadnych elementów o dostępie zdefiniowanym jako protected lub protected internal. Warto zauważyć, że chociaż wszystkie elementy klasy muszą być statyczne, każdy z nich musi być jawnie zadeklarowany w ten sposób. Mimo że typy zagnieżdżone są niejawnie statycznymi elementami klasy nadrzędnej, sam typ zagnieżdżony może być typem niestatycznym, jeśli istnieje taka potrzeba. Kompilator nie tylko nakłada ograniczenia na definicje klas statycznych, ale również strzeże przed ich niepoprawnym użyciem. Wie, że nie mogą istnieć jakiekolwiek instancje takich klas i uniemożliwia wszelkie próby użycia ich w sposób wymagający istnienia instancji. Przykładowo w sytuacji kiedy StringHelper jest klasą statyczną, wszystkie poniższe wiersze kodu są nieprawidłowe: StringHelper variable = null; StringHelper[] table = null; public void Method1(StringHelper x) {} public StringHelper Method1() { return null; } List x = new List();

Żadna z tych operacji nie jest zabroniona, kiedy klasa przestrzega wzorca C# 1, chociaż wszystkie są faktycznie bezużyteczne. Mówiąc w skrócie, klasy statyczne w C# 2 nie pozwalają na zrobienie czegokolwiek, czego nie mogłeś zrobić wcześniej, ale uniemożliwiają również robienie rzeczy, których tak czy inaczej nie powinieneś był robić. Oprócz tego jasno wyrażają Twoje intencje. Deklarując klasę jako statyczną, mówisz, że w żadnym przypadku nie chcesz, aby tworzone były jakiekolwiek jej instancje — różnica polega na tym, że nie jest to jakiś wymysł implementacyjny, lecz decyzja projektowa. Następna cecha na naszej liście ma bardziej pozytywny wydźwięk. Została przygotowana na potrzeby specyficznej — chociaż często spotykanej — sytuacji i udostępnia rozwiązanie, które ani nie jest nieeleganckie, ani nie łamie zasady kapsułkowania danych, a tylko takie dwie możliwości mieliśmy w C# 1.

7.3.

Niezależny poziom dostępu do getterów i setterów właściwości Muszę przyznać, że byłem zdziwiony, kiedy przekonałem się, iż C# 1 nie pozwala programiście na posiadanie publicznego gettera i prywatnego settera dla właściwości. Nie jest to jedyna kombinacja modyfikatorów poziomu dostępu zabroniona w C# 1,

236

ROZDZIAŁ 7

Pozostałe cechy C# 2

ale tej programiści używają najczęściej. W C# 1 zarówno getter, jak i setter muszą mieć ten sam poziom dostępu — deklarowany raczej na poziomie samej deklaracji właściwości niż w ramach gettera i settera. Istnieją całkowicie zrozumiałe powody posiadania innych poziomów dostępu do gettera i settera — często potrzebujesz jakiejś walidacji, logowania, blokowania (na potrzeby wątków) lub innego kodu, który zostanie uruchomiony podczas zmiany pola będącego zapleczem właściwości, ale nie chcesz, aby sama właściwość mogła być modyfikowana przez kod poza klasą. W C# 1 dostępne rozwiązania obejmowały zepsucie kapsułkowania przez upublicznienie właściwości (na podstawie własnej oceny sytuacji) lub napisanie w klasie metody SetXXX(), która wykonałaby jakąś pracę, co szczerze mówiąc, wygląda okropnie w sytuacji, kiedy jesteś przyzwyczajony do używania prawdziwych właściwości. C# 2 naprawia ten problem, pozwalając getterowi lub setterowi na jawne zadeklarowanie bardziej restrykcyjnego poziomu dostępu w porównaniu do samej właściwości. Najprościej będzie to zobaczyć w następującym przykładzie: string name; public string Name { get { return name; } private set { //Tutaj walidacja, logowanie itd. name = value; } }

W tym przypadku właściwość Name jest tylko do odczytu dla innych typów2, ale wewnątrz samego typu możemy ją ustawiać, stosując znajomą składnię właściwości. Ta sama składnia jest dostępna dla indekserów. Mógłbyś upublicznić setter bardziej niż getter (np. nadać getterowi dostęp chroniony, a setterowi publiczny), ale jest to dość rzadka sytuacja. Do wyjątków należą również właściwości tylko do zapisu, w przeciwieństwie do właściwości tylko do odczytu. DROBIAZG: JEDYNE MIEJSCE, W KTÓRYM MODYFIKATOR PRIVATE JEST OBOWIĄZKOWY. W całym C# domyślnym modyfikatorem dostępu, niezależnie od sytuacji, jest ten, który jest najbardziej prywatny z możliwych. Jeśli na przykład dany element może być zadeklarowany jako prywatny, a Ty nie nadasz mu jawnie innego poziomu dostępu przez użycie modyfikatora, będzie on miał domyślnie prywatny poziom dostępu. Jest to bardzo dobry element języka, gdyż uniemożliwia przypadkowe popełnienie błędu. Jeśli chcesz, aby coś było bardziej publiczne, niż jest obecnie, przekonasz się o tym przy próbie użycia. Kiedy jednak upublicznisz dany element „zbyt” mocno, kompilator nie będzie w stanie pomóc Ci przy namierzeniu problemu. Wyjątek od tej reguły stanowi specyfikowanie dostępu do getterów i setterów właściwości — jeśli nie wskażesz jawnie poziomu dostępu, getter i setter będą miały taki sam poziom dostępu jak sama właściwość. 2

Z wyjątkiem typów zagnieżdżonych, które zawsze posiadają dostęp do prywatnych pól klasy nadrzędnej.

Aliasy przestrzeni nazw

237

Zauważ, że nie możesz zadeklarować prywatnej właściwości, a następnie upublicznić jej getter — możesz jedynie zmniejszyć poziom dostępu do gettera lub settera poniżej poziomu dostępu do samej właściwości. Ponadto nie możesz wyspecyfikować modyfikatorów dostępu dla gettera i settera jednocześnie — byłoby to trochę śmieszne, tak jakbyś deklarował właściwość na tyle publiczną, na ile pozwala mniej restrykcyjny z obu modyfikatorów. Ta pomoc w kapsułkowaniu jest bardzo mile widziana. Niestety, w C# 2 nadal nie ma przeszkody, która powstrzymałaby kod w tej samej klasie przed pominięciem właściwości i odwoływaniem się bezpośrednio do pól umieszczonych za nimi. Jak zobaczymy w następnym rozdziale, C# 3 naprawia ten specyficzny przypadek, ale nie zapewnia całościowego rozwiązania problemu. Przechodzimy teraz do cechy, której będziesz chciał używać bardzo często, choć nie powinieneś tego w ogóle robić — pozwala ona, aby Twój kod wyrażał używane przez siebie typy danych w sposób absolutnie jawny, ale kosztem znacznego spadku czytelności.

7.4.

Aliasy przestrzeni nazw Nadrzędnym celem przestrzeni nazw jest organizowanie typów w użyteczną hierarchię. Pozwalają Ci one również na zachowanie w pełni kwalifikowanych nazw unikalnych, nawet jeśli nazwy niekwalifikowane są identyczne. Nie należy tego traktować jako zaproszenia do używania nazw niekwalifikowanych w każdej możliwej sytuacji, chociaż w pewnych okolicznościach jest to rzecz zupełnie oczywista. Przykładem może być niekwalifikowany typ Button. W środowisku .NET 2.0 są dwie klasy o tej nazwie: System.Windows.Forms.Button i System.Web.UI.WebControls.Button. Chociaż obie nazywają się Button, bardzo łatwo można je rozróżnić w oparciu o przestrzeń nazw, z której pochodzą. Odpowiada to blisko sytuacjom, jakie mogą mieć miejsce w prawdziwym życiu — możesz znać kilka osób o imieniu Jon, ale jest mało prawdopodobne, abyś znał kogoś innego nazywającego się Jon Skeet. Kiedy rozmawiasz z przyjaciółmi w określonym kontekście, możesz się posługiwać wyłącznie imieniem Jon, bez jawnego wskazywania, o którego z nich chodzi — w innych sytuacjach niezbędne okazuje się podanie bardziej szczegółowych informacji. W C# 1 dyrektywa using (nie mylić z wyrażeniem using powodującym automatyczne wywołanie Dispose) była dostępna w dwóch odmianach: jedna tworzyła alias dla przestrzeni nazw lub typu (na przykład using Wyjscie = System.Console;), a druga dołączała przestrzeń nazw do listy kontekstów przeszukiwanych następnie przez kompilator w celu znalezienia odpowiedniego typu (na przykład using System.IO;). W większości przypadków takie podejście było prawidłowe, ale istniało kilka specyficznych sytuacji, z którymi kompilator nie potrafił sobie poradzić. Z kolei w niektórych przypadkach automatycznie wygenerowany kod musiał się nieźle nagimnastykować, aby niezależnie od okoliczności mieć absolutną pewność, iż zostały użyte prawidłowe przestrzenie nazw i typy. C# 2 naprawia te problemy, wprowadzając do języka nowe możliwości wyrażania się. Możesz pisać kod, który gwarantuje wyrażenie dokładnie tego, co chcesz, niezależnie od tego, jakie inne typy, moduły i przestrzenie nazw zostały w nim wprowadzone. Te ekstremalne środki są rzadko potrzebne poza kodem wygenerowanym automatycznie,

238

ROZDZIAŁ 7

Pozostałe cechy C# 2

ale warto wiedzieć, że są pod ręką, gdyby kiedykolwiek przyszło Ci skorzystać z ich pomocy. W C# 2 są trzy typy aliasów: wywodzące się z C# 1 aliasy przestrzeni nazw, aliasy globalnej przestrzeni nazw i aliasy zewnętrzne. Zaczniemy od omówienia typu dostępnego już w C# 1, ale wprowadzimy nową metodę ich używania, aby mieć pewność, iż kompilator potraktuje je jako aliasy, zamiast sprawdzać, czy są one nazwami innych przestrzeni nazw lub typów.

7.4.1. Kwalifikowanie aliasów przestrzeni nazw Nawet w C# 1 dobrą praktyką było unikanie aliasów przestrzeni nazw wszędzie tam, gdzie było to możliwe. Od czasu do czasu możesz napotkać sytuację, w której nazwa jednego typu koliduje z innym — tak jak w naszym wcześniejszym przykładzie z klasą Button. W takiej sytuacji masz do wyboru użycie pełnej nazwy, łącznie z przestrzenią nazw, przy każdym wystąpieniu typu lub stworzenie aliasu, który rozróżni oba typy, działając mniej więcej jak skrócona forma przestrzeni nazw. Poniższy listing (7 5) pokazuje przykład, w którym zostały użyte oba typy Button rozróżnione poprzez alias. Listing 7.5. Użycie aliasów do rozróżnienia dwóch typów Button pochodzących z różnych przestrzeni nazw using System; using WinForms = System.Windows.Forms; using WebForms = System.Web.UI.WebControls; class Test { static void Main() { Console.WriteLine(typeof(WinForms.Button)); Console.WriteLine(typeof(WebForms.Button)); } }

Listing 7.5 kompiluje się bez żadnych błędów i ostrzeżeń, chociaż całość nie wygląda tak ładnie, jak miałoby to miejsce, gdybyśmy mieli do czynienia wyłącznie z jednym typem przycisku. Pojawia się jednak jeden problem. Co się stanie, jeśli ktoś wprowadzi do użytku przestrzeń nazw WinForms lub WebForms? W takiej sytuacji kompilator nie wiedziałby, co znaczy WinForms.Button, i zacząłby szukać w pierwszej kolejności pasującej przestrzeni nazw lub typu. Musimy mieć sposób na poinstruowanie kompilatora, aby traktował WinForms jako alias, nawet jeśli ta nazwa pojawia się gdzie indziej. W tym celu C# 2 wprowadza kwalifikator aliasu przestrzeni nazw — ::, którego przykład użycia widzimy na listingu 7.6. Listing 7.6. Zastosowanie ::, aby wskazać kompilatorowi użycie aliasów using System; using WinForms = System.Windows.Forms; using WebForms = System.Web.UI.WebControls; class WinForms {} class Test

Aliasy przestrzeni nazw

239

{ static void Main() { Console.WriteLine(typeof(WinForms::Button)); Console.WriteLine(typeof(WebForms::Button)); } }

Na listingu 7.6 zamiast WinForms.Button użyto WinForms::Button, co w zupełności wystarcza kompilatorowi. Jeżeli zmienisz :: z powrotem na ., otrzymasz błąd kompilacji. Stąd wniosek, że jeśli wszędzie, gdzie stosujemy alias, użyjemy ::, wszystko będzie w porządku, tak? No cóż, nie do końca...

7.4.2. Aliasy globalnej przestrzeni nazw Jest jeden obszar — korzeń hierarchii lub globalna przestrzeń nazw — dla którego nie możesz zdefiniować swojego własnego aliasu. Załóżmy, że masz dwie klasy, obie o nazwie Configuration. Jedna z nich znajduje się w przestrzeni MyCompany, a druga nie jest objęta żadną przestrzenią nazw. W jaki sposób odwołasz się do klasy Configuration w globalnej przestrzeni nazw z wnętrza przestrzeni MyCompany? Nie możesz użyć zwykłego aliasu, a jeśli posłużysz się tylko nazwą klasy — Configuration — kompilator będzie przekonany, że masz na myśli MyCompany.Configuration. W C# 1 nie było sposobu obejścia tego problemu. Z pomocą ponownie przychodzi C# 2, pozwalając na użycie global::Configuration w celu przekazania kompilatorowi, czego dokładnie chcesz. Poniższy listing (7.7) demonstruje zarówno problem, jak i jego rozwiązanie. Listing 7.7. Użycie globalnej przestrzeni nazw w celu wyspecyfikowania oczekiwanego typu using System; class Configuration { } namespace MyCompany { class Configuration { } class Test { static void Main() { Console.WriteLine(typeof(Configuration)); Console.WriteLine(typeof(global::Configuration)); Console.WriteLine(typeof(global::MyCompany.Test)); } } }

Większość listingu 7.7 to przygotowanie problemu — interesujące są trzy wiersze wewnątrz metody Main. Pierwszy wypisuje MyCompany.Configuration, gdyż kompilator odnajduje typ Configuration przed przejściem do globalnej przestrzeni nazw. Drugi

240

ROZDZIAŁ 7

Pozostałe cechy C# 2

wiersz wskazuje, iż typ powinien się znajdować w globalnej przestrzeni nazw, zatem wyświetlany jest tekst Configuration. Trzeci umieściłem wyłącznie po to, aby pokazać, że przy użyciu globalnego aliasu nadal można odwoływać się do typów wewnątrz przestrzeni nazw, ale trzeba posługiwać się nazwami w pełni kwalifikowanymi. W tym momencie, posługując się w miarę koniczności aliasem globalnej przestrzeni nazw, jesteśmy w stanie dostać się do dowolnego unikalnie nazwanego typu. Jeśli kiedykolwiek przyjdzie Ci do głowy napisanie generatora kodu, który nie musi produkować czytelnego wyniku, możesz posłużyć się tą cechą, aby mieć absolutną pewność, iż zawsze odnosisz się do właściwego typu, niezależnie od tego, jakie nowe typy pojawią się do chwili kompilacji kodu. Co zrobić, kiedy nazwa typu nie jest unikalna, nawet kiedy dołączymy przestrzeń nazw? Atmosfera gęstnieje...

7.4.3. Aliasy zewnętrzne Na początku tej sekcji posłużyłem się nazwami osób jako przykładami przestrzeni nazw i kontekstów. Powiedziałem między innymi, iż jest mało prawdopodobne, że znasz więcej niż jedną osobę nazywającą się Jon Skeet. Wiem jednak, że istnieje więcej niż jedna osoba nosząca moje imię, zatem niewykluczone, że mógłbyś znać dwóch lub więcej Jonów Skeetów. W takim przypadku oprócz imienia i nazwiska musisz dostarczyć jeszcze dodatkowe informacje wskazujące, kogo masz na myśli — może to być powód, dla którego znasz daną osobę, kraj jej pochodzenia lub coś innego, co pozwoli je rozróżnić. C# 2 pozwala na wyspecyfikowanie dodatkowej informacji w formie aliasu zewnętrznego — nazwy, która istnieje nie tylko w Twoim kodzie źródłowym, ale również w parametrach przekazywanych kompilatorowi. W przypadku kompilatora C# firmy Microsoft jest to moduł (ang. assembly) zawierający problematyczne typy. Załóżmy, że dwa moduły — First.dll i Second.dll — zawierają typ Demo.Example. Nie możemy zwyczajnie użyć w pełni kwalifikowanej nazwy, ponieważ w obu przypadkach jest ona identyczna. Zamiast tego do wskazania typu, który mamy na myśli, możemy posłużyć się aliasami zewnętrznymi. Listing 7.8 pokazuje przykład kodu wykonującego takie zadanie wraz z komendą wiersza poleceń potrzebną do jego kompilacji. Listing 7.8. Praca z różnymi typami o tej samej nazwie w różnych modułach //Skompiluj z //csc Test.cs /r FirstAlias=First.dll /r SecondAlias=Second.dll extern alias FirstAlias; extern alias SecondAlias; using System; using PD = FirstAlias.Demo;

Specyfikacja dwóch aliasów zewnętrznych

Odwołanie do aliasu zewnętrznego poprzez alias przestrzeni nazw

class Test { static void Main() Użycie aliasu { przestrzeni nazw Console.WriteLine(typeof(PD.ID.Example)); Console.WriteLine(typeof(SecondAlias::Demo.Example)); Użycie bezpośrednio } aliasu zewnętrznego }

Dyrektywy pragma

241

Kod na listingu 7.8 jest prosty. Pierwszą rzeczą, którą musimy zrobić, jest wprowadzenie dwóch aliasów zewnętrznych ( ). Następnie możemy ich użyć poprzez alias przestrzeni nazw (( ) i ( )) lub bezpośrednio ( ). Co więcej, zastosowanie zwykłej dyrektywy using bez aliasu (na przykład using FirstAlias::Demo) pozwoliłoby nam użyć nazwy Example bez jakiejkolwiek dodatkowej kwalifikacji. Pojedynczy alias zewnętrzny może obejmować kilka modułów, a kilka zewnętrznych aliasów może odwoływać się do tego samego modułu, chociaż proponowałbym się dobrze zastanowić przed użyciem którejkolwiek z tych dwóch opcji, a w szczególności przed próbą ich połączenia. Aby wyspecyfikować alias zewnętrzny dla modułu w Visual Studio, wybierz jego referencję za pomocą narzędzia Solution Explorer i zmodyfikuj wartość Aliases w oknie właściwości (patrz rysunek 7.3). Rysunek 7.3. Część okna właściwości w Visual Studio 2010 pokazująca alias zewnętrzny (FirstAlias) dla referencji First.dll

Mam nadzieję, że nie muszę Cię przekonywać do unikania takich sytuacji, jeśli to tylko możliwe. Rozwiązanie tego typu może się okazać niezbędne podczas pracy z modułami dostarczanymi przez inne firmy, które przez przypadek użyły tych samych w pełni kwalifikowanych nazw typów. Jeżeli wtedy nie zastosujesz aliasów zewnętrznych, możesz utknąć w martwym punkcie. Tam, gdzie będziesz miał większą kontrolę nad nazewnictwem, postaraj się zapewnić takie nazwy typów, które od samego początku pozwolą uniknąć powyższej sytuacji. Nasza następna cecha jest niemal metacechą. Ponieważ jej celem jest umożliwienie kontroli nad cechami specyficznymi dla kompilatora, jej funkcjonalność zależy od używanego przez Ciebie kompilatora — my będziemy się koncentrować na kompilatorze firmy Microsoft.

7.5.

Dyrektywy pragma Opisanie dyrektyw pragma jest niezwykle proste: są one dyrektywami preprocesora reprezentowanymi przez wiersze kodu zaczynające się od wyrażenia #pragma. Reszta wiersza może zawierać dowolny tekst. Wystąpienie pragmy może zmienić zachowanie programu, naruszając zasady działania wynikające ze specyfikacji C#. Możliwe jest również zachowanie niebędące w ogóle przedmiotem specyfikacji. Jeżeli kompilator nie zrozumie danej dyrektywy pragma, może wystosować ostrzeżenie, ale nie błąd. To w zasadzie wszystko, co specyfikacja ma do powiedzenia na ten temat. Kompilator firmy Microsoft rozumie dwie dyrektywy pragma: ostrzeżenia i sumy kontrolne.

242

ROZDZIAŁ 7

Pozostałe cechy C# 2

7.5.1. Pragmy ostrzeżeń Od czasu do czasu kompilator C# zgłasza ostrzeżenia, które są zrozumiałe, ale jednocześnie irytujące. Właściwą reakcją na ostrzeżenie kompilatora jest niemal zawsze naprawienie kodu będącego jego źródłem — taka poprawka rzadko kiedy prowadzi do powstania gorszego kodu, na ogół jest dokładnie odwrotnie. Czasem istnieje jednak dobry powód, by zignorować ostrzeżenie, i właśnie do tego służą pragmy. Jako przykład stworzymy prywatne pole klasy, które nie będzie nigdy odczytywane ani zapisywane. W większości przypadków takie pole byłoby bezużyteczne, chyba że... będziemy wiedzieć o jego zastosowaniu w refleksji. Demonstruje to listing 7.9. Listing 7.9. Klasa zawierająca nieużywane pole public class FieldUsedOnlyByReflection { int x; }

Próbując skompilować listing 7.9, otrzymasz następujące komunikaty ostrzeżeń: FieldUsedOnlyByReflection.cs(12,13): warning CS0169: The private field 'FieldUsedOnlyByReflection.x' is never used

Jest to tekst wyświetlany podczas kompilacji z wiersza poleceń. Tę samą informację (łącznie z projektem, w którym został znaleziony problem) znajdziesz w oknie listy błędów Visual Studio, ale bez podania numeru ostrzeżenia (CS0169). Aby znaleźć numer ostrzeżenia, musisz wybrać ostrzeżenie i obejrzeć związaną z nim treść pomocy lub zajrzeć do okna Output, w którym jest pokazany pełny tekst komunikatu. Numeru potrzebujemy do doprowadzenia kodu do kompilacji bez ostrzeżeń, tak jak pokazuje to poniższy listing (7.10). Listing 7.10. Wyłączenie (i ponowne włączenie) ostrzeżenia CS0169 public class FieldUsedOnlyByReflection { #pragma warning disable 0169 int x; #pragma warning restore 0169 }

Listing 7.10 jest samokomentujący — pierwsza pragma wyłącza interesujące nas ostrzeżenie, a druga je przywraca. Dobrą praktyką jest wyłączanie ostrzeżeń na najkrótszy możliwy czas. W ten sposób nie przegapimy innych ostrzeżeń, które powinniśmy poprawić. Jeśli w jednym wierszu chcesz wyłączyć kilka ostrzeżeń, oddziel ich numery przecinkami. Pragma warning z pustą listą wartości powoduje włączenie lub wyłączenie wszystkich ostrzeżeń — jest to jednak bardzo niedobre rozwiązanie w niemal każdym możliwym do wyobrażenia przypadku.

Bufory o stałym rozmiarze w kodzie niezarządzanym

243

7.5.2. Pragmy sum kontrolnych Jest mało prawdopodobne, abyś kiedykolwiek musiał skorzystać z drugiej formy pragmy rozpoznawanej przez kompilator Microsoft. Jej celem jest wsparcie debuggera przez umożliwienie mu sprawdzenia, czy znalazł właściwy plik kodu źródłowego. Kiedy jest kompilowany plik kodu źródłowego C#, kompilator generuje sumę kontrolną z tego pliku i umieszcza ją w informacji dla debuggera. Kiedy debugger ma znaleźć plik kodu źródłowego i z jego algorytmu wynika, że istnieje więcej niż jeden potencjalny kandydat, sam generuje sumę kontrolną i na jej podstawie sprawdza, który z możliwych plików jest właściwym kandydatem. Kiedy strona ASP.NET jest konwertowana na C#, to, co widzi kompilator, jest wygenerowanym plikiem kodu źródłowego C#. Generator wylicza sumę kontrolną pliku .aspx i używa pragmy sumy kontrolnej, aby zmusić kompilator do stosowania właśnie jej zamiast wyliczania własnej z wygenerowanego pliku. Składnia pragmy sumy kontrolnej wygląda następująco: #pragma checksum "nazwapliku" "{guid}" "bajty sumy kontrolnej"

GUID wskazuje na algorytm mieszający użyty do wyliczenia sumy kontrolnej. Gdybyś kiedykolwiek doszedł do wniosku, że potrzebujesz własnej implementacji kompilacji dynamicznej ze wsparciem debuggera, dokumentacja klasy CodeChecksumPragma wymienia GUID-y dla algorytmów SHA-1 i MD5. Możliwe, że przyszłe wersje kompilatora C# będą obsługiwać większą liczbę dyrektyw pragma, a inne kompilatory (takie jak pochodzący ze środowiska Mono gmcs) zostaną wzbogacone o swoje własne cechy pod tym względem. Najświeższą wiedzę na ten temat znajdziesz w dokumentacji kompilatora. Kolejna cecha również zalicza się do zbioru rzadko stosowanych, jeśli jednak przyjdzie Ci jej kiedyś użyć, przekonasz się, że potrafi odrobinę uprościć Twoją pracę.

7.6.

Bufory o stałym rozmiarze w kodzie niezarządzanym Wywołując kod natywny przy użyciu usługi P/Invoke, można z dużym prawdopodobieństwem napotkać strukturę zawierającą w środku bufor danych o stałym rozmiarze. Przed pojawieniem się C# 2 trudno było obsługiwać takie struktury w sposób bezpośredni, nawet z pomocą kodu niezarządzanego. Teraz możesz zadeklarować bufor o prawidłowym rozmiarze w taki sposób, aby był on osadzony bezpośrednio z innymi danymi w strukturze. Ta możliwość nie została udostępniona jedynie w celu wywoływania kodu natywnego, chociaż jest to jej głównym zadaniem. Mógłbyś na przykład skorzystać z niej w celu łatwego wypełnienia struktury bezpośrednio z pliku. Składnia wygląda bardzo prosto, a ja kolejny raz posłużę się przykładem. Aby stworzyć pole zawierające tablicę 20 znaków, wewnątrz struktury napisałbyś: fixed byte data[20];

244

ROZDZIAŁ 7

Pozostałe cechy C# 2

To pozwoliłoby na użycie zmiennej data, tak jakby była wskaźnikiem do danych typu byte (byte*). Kompilator w takiej sytuacji tworzy typ zagnieżdżony w deklarowanym typie i stosuje nowy atrybut — FixedBuffer — do samej zmiennej. Od tego momentu właściwym alokowaniem pamięci zajmuje się CLR. Jedyną negatywną stroną tego rozwiązania jest jego dostępność wyłącznie w kodzie niezarządzanym: struktura zawierająca bufor musi być zadeklarowana w kontekście unsafe. Znacznie ogranicza to użyteczność tego mechanizmu, ale i tak warto mieć go pod ręką. Ponadto bufory o stałym rozmiarze mogą być stosowane wyłącznie w połączeniu z typami prymitywnymi i nie mogą być elementami klas (dozwolone są tylko struktury). Liczba interfejsów programistycznych Windows, w których ta cecha mogłaby być bezpośrednio użyteczna, jest niezwykle mała. W wielu przypadkach wywołania ze stałym buforem znaków (przykładem może być struktura TIME_ZONE_INFORMATION) wymagają stałych buforów znaków, z którymi wywołania P/Invoke mają problemy, głównie ze względu na przeszkody, jakie stawia marshalling. Spróbujmy jednak pokazać jakiś przykład. Listing 7.11 jest aplikacją konsolową, która wyświetla kolory dostępne w bieżącym oknie. Używa do tego celu funkcji GetConsole ´ScreenBufferEx, która została wprowadzona do Windowsa w wersjach Vista oraz Server 2008 i pozwala wyciągnąć rozszerzoną informację na temat konsoli. Listing wyświetla wszystkie szesnaście kolorów w formacie szesnastkowym (bbggrr). Listing 7.11. Przykład wykorzystania stałego bufora danych do uzyskania informacji o kolorach dostępnych w oknie konsoli using System; using System.ComponentModel; using System.Runtime.InteropServices; struct COORD { public short X, Y; } struct SMALL_RECT { public short Left, Top, Right, Bottom; } unsafe struct CONSOLE_SCREEN_BUFFER_INFOEX { public int StructureSize; public COORD ConsoleSize, CursorPosition; public short Attributes; public SMALL_RECT DisplayWindow; public COORD MaximumWindowSize; public short PopupAttributes; public int FullScreenSupported; public fixed int ColorTable[16]; } static class FixedSizeBufferDemo {

Udostępnianie wybranych elementów innym modułom

245

const int StdOutputHandle = -11; [DllImport("kernel32.dll")] static extern IntPtr GetStdHandle(int nStdHandle); [DllImport("kernel32.dll")] static extern bool GetConsoleScreenBufferInfoEx (IntPtr handle, ref CONSOLE_SCREEN_BUFFER_INFOEX info); unsafe static void Main() { IntPtr handle = GetStdHandle(StdOutputHandle); CONSOLE_SCREEN_BUFFER_INFOEX info; info = new CONSOLE_SCREEN_BUFFER_INFOEX(); info.StructureSize = sizeof(CONSOLE_SCREEN_BUFFER_INFOEX); GetConsoleScreenBufferInfoEx(handle, ref info); for (int i = 0; i < 16; i++) { Console.WriteLine("{0:x6}", info.ColorTable[i]); } } }

Listing 7.11 używa bufora o stałym rozmiarze dla tablicy kolorów. Zanim bufory te stały się dostępne, mieliśmy możliwość skorzystania z funkcji API przy użyciu pola dla każdego elementu w tablicy kolorów lub przez marshalling zwykłej tablicy jako UnmanagedType.ByValArray. To jednak spowodowałoby powstanie niezależnej tablicy na stercie, choć cała informacja powinna być trzymana wewnątrz struktury. Tutaj nie stanowi to problemu, ale w pewnych sytuacjach, w których jest wymagana wysoka wydajność kodu, dobrze jest trzymać wszystkie elementy danych razem. Inny efekt wydajnościowy wiąże się z koniecznością „podpięcia” bufora przed dostępem do niego, jeśli stanowi on część struktury utworzonej na zarządzanej stercie pamięci. Może to znacząco wpłynąć na garbage collector. Struktury bazujące na stosie nie mają oczywiście takiego problemu. Nie zamierzam twierdzić, iż bufory o stałym rozmiarze są niesamowicie istotną cechą C# 2 — przynajmniej nie dla większości programistów. Omówiłem ją tutaj dla porządku, bo sądzę, że z pewnością znajdzie się ktoś, dla koga ta cecha okaże się nieoceniona. Ostatnią rzecz, którą się zajmiemy, trudno nawet nazwać cechą języka C# 2 — ale mimo to postanowiłem ją również dodać.

7.7.

Udostępnianie wybranych elementów innym modułom Niektóre cechy, na przykład uproszczenia iteratorów, są zupełnie oczywiste w języku, a inne, takie jak na przykład optymalizacje przeprowadzane przez kompilator JIT, w sposób naturalny należą do środowiska wykonawczego. Z kolei jeszcze inne, na przykład generyki, zaliczają się do obu obozów. Ta ostatnia cecha jest na tyle nietypowa, iż nie zasłużyła na swój opis w żadnej specyfikacji. Co więcej, używana w odniesieniu do niej

246

ROZDZIAŁ 7

Pozostałe cechy C# 2

terminologia ma znaczenie odmienne zarówno od tego z C++, jak i tego z VB.NET, mamy zatem do czynienia z trzecią interpretacją. Co prawda wszystkie trzy mają swoje zastosowanie w kontekście praw dostępu, ale wiążą się z nimi inne skutki.

7.7.1. Zaprzyjaźnione moduły w prostym przypadku W NET 1.1 stwierdzenie, że element (typ, metoda, właściwość lub zdarzenie) zdefiniowany jako wewnętrzny mógł być dostępny jedynie z wnętrza modułu, w którym został zadeklarowany, było zupełnie poprawne3. W .NET 2.0 ta zasada jest w większości prawdziwa, ale pojawia się nowy atrybut — InternalsVisibleToAttribute, zwykle skracany do InternalsVisibleTo — pozwalający lekko nagiąć zasady. (Przy stosowaniu atrybutu, którego nazwa kończy się słowem Attribute, kompilator C# automatycznie dołoży tę końcówkę). InternalsVisibleTo może być zastosowany (wielokrotnie) wyłącznie do całego modułu, a nie do jego poszczególnych elementów. Moduł zawierający ten atrybut nazwiemy modułem źródłowym, chociaż jest to terminologia nieoficjalna. Kiedy użyjesz atrybutu, będziesz musiał wskazać inny moduł, znany jako moduł zaprzyjaźniony. W wyniku tego moduł zaprzyjaźniony zobaczy wszystkie wewnętrzne elementy modułu źródłowego w taki sposób, jakby były one publiczne. Na pierwszy rzut oka może to wyglądać niepokojąco, ale czasami okazuje się bardzo użyteczne, o czym przekonamy się już za chwilę. Listing 7.12 pokazuje przykład zaprzyjaźniania przy użyciu trzech klas w trzech różnych modułach. Listing 7.12. Przykład zaprzyjaźnionych modułów //Skompilowany do Source.dll using System.Runtime.CompilerServices; [assembly:InternalsVisibleTo("FriendAssembly")] public class Source { internal static void InternalMethod();

Udzielenie dodatkowych praw dostępu

public static void PublicMethod(); } //Skompilowany do FriendAssembly.dll public class Friend { static void Main() { Source.InternalMethod(); Source.PublicMethod(); } }

Użycie dodatkowego modułu wewnątrz FriendAssembly

//Skompilowany do EnemyAssembly.dll public class Enemy

3

Pomijamy tutaj przypadek użycia refleksji podczas wykonania z odpowiednimi uprawnieniami.

Udostępnianie wybranych elementów innym modułom

247

{ static void Main() { //Source.InternalMethod(); Source.PublicMethod(); }

EnemyAssembly nie ma dodatkowych praw dostępu

}

Na listingu 7.12 istnieje specjalny związek pomiędzy FriendAssembly.dll i Source.dll, chociaż ma on wyłącznie jeden kierunek (Source.dll nie ma dostępu do elementów wewnętrznych FriendAssembly.dll). Gdybyśmy usunęli znaki komentarza w wierszu oznaczonym ( ), klasa Enemy nie skompilowałaby się. Rodzi się pytanie, po co w ogóle chcielibyśmy dawać innym modułom dostęp do naszej dobrze zaprojektowanej biblioteki.

7.7.2. Do czego warto używać InternalsVisibleTo? Nie mogę powiedzieć, że kiedykolwiek zastosowałem InternalsVisibleTo pomiędzy dwoma modułami produkcyjnymi. Nie znaczy to, że nie istnieją całkowicie poprawne przypadki takiego użycia, ale ja się z takimi nie spotkałem. Atrybut przydał mi się natomiast podczas pracy nad testami jednostkowymi. Niektórzy twierdzą, iż należy testować wyłącznie interfejs publiczny. Ja wolę testować wszystko, co tylko jestem w stanie, w najprostszy możliwy sposób. Zaprzyjaźnianie modułów bardzo ułatwia to zadanie: pstryk i testowanie kodu o dostępie wewnętrznym staje się trywialnie proste, a na dodatek nie trzeba podejmować wątpliwych decyzji o upublicznianiu typów wyłącznie ze względu na testy lub dołączaniu kodu testującego do modułu produkcyjnego. (Czasem wiąże się to z koniecznością zmiany dostępu do elementów z poziomu prywatnego na wewnętrzny tylko na potrzeby testowania, ale to nie stanowi tak dużego problemu). Jedyną ujemną stroną tego rozwiązania jest obecność nazwy Twojego modułu testującego wewnątrz modułu produkcyjnego. W teorii może to stanowić pewne zagrożenie dla bezpieczeństwa, jeżeli Twoje moduły nie są podpisane oraz Twój kod w normalnych warunkach pracuje w środowisku o zawężonych prawach dostępu. (Każdy zaufany kod mógłby skorzystać z refleksji i otrzymać dostęp do wewnętrznych elementów modułu. Mógłbyś to zrobić nawet samodzielnie dla testów jednostkowych, chociaż jest to bardziej skomplikowane). Będę bardzo zaskoczony, jeśli okaże się to prawdziwym problemem dla kogokolwiek. Chociaż przy tej okazji zachęcająca wydaje się opcja podpisywania modułów. A już pewnie myślałeś, że jest to miła i prosta cecha...

7.7.3. InternalsVisibleTo i moduły podpisane Jeżeli moduł zaprzyjaźniony jest podpisany, moduł źródłowy musi wyspecyfikować klucz publiczny modułu zaprzyjaźnionego, aby mieć pewność, że „ufa” właściwemu kodowi. Potrzebujesz pełnego klucza publicznego, a nie tylko jego znacznika. Rozważmy dla przykładu następujące polecenie służące do odkrywania klucza publicznego podpisanego modułu FriendAssembly.dll oraz wynik jego działania (zawinięty i lekko zmodyfikowany ze względów drukarskich):

248

ROZDZIAŁ 7

Pozostałe cechy C# 2 c:\Users\Jon\Test\sn –Tp FriendAssembly.dll Microsoft (R) .NET Framework Strong Name Utility Version 3.5.30729.1 Copyright (c) Microsoft Corporation. All rights reserved. Public key is 0024000004800000940000000602000000240000525341310004000001 000100a51372c81ccfb8fba9c5fb84180c4129e50f0facdce932cf31fe 563d0fe3cb6b1d5129e28326060a3a539f287aaf59affc5aabc4d8f981 e1a82479ab795f410eab22e3266033c633400463ee7513378bb4ef41fc 0cae5fb03986d133677c82a865b278c48d99dc251201b9c43edd7bedef d4b5306efd0dec7787ec6b664471c2 Public key token is 647b99330b7f792c

Kod źródłowy klasy Source musiałby teraz posiadać następujący atrybut: [assembly:InternalsVisibleTo("FriendAssembly,PublicKey=" + "0024000004800000940000000602000000240000525341310004000001" "000100a51372c81ccfb8fba9c5fb84180c4129e50f0facdce932cf31fe" "563d0fe3cb6b1d5129e28326060a3a539f287aaf59affc5aabc4d8f981" "e1a82479ab795f410eab22e3266033c633400463ee7513378bb4ef41fc" "0cae5fb03986d133677c82a865b278c48d99dc251201b9c43edd7bedef" "d4b5306efd0dec7787ec6b664471c2")]

+ + + + +

Niestety, musisz zapisać klucz publiczny w jednym wierszu lub użyć operatorów łączenia łańcuchów — pojawienie się białych znaków w treści klucza spowoduje błąd kompilacji. Byłoby o wiele przyjemniej, gdybyśmy mogli wyspecyfikować jedynie znacznik zamiast całego klucza. Na szczęście ta niedogodność jest ograniczona jedynie do pliku AssemblyInfo.cs, zatem nie będziesz miał z nią do czynienia zbyt często. Teoretycznie możliwe jest posiadanie niepodpisanego modułu źródłowego i podpisanego modułu zaprzyjaźnionego. W praktyce jednak takie rozwiązanie nie jest zbyt użyteczne, gdyż zazwyczaj moduł zaprzyjaźniony potrzebuje referencji do modułu źródłowego, a nie możesz stworzyć referencji do modułu niepodpisanego z modułu, który jest podpisany! Podobnie podpisany moduł nie może wskazać modułu, który miałby być niepodpisanym modułem zaprzyjaźnionym, zatem jeśli którykolwiek z modułów jest już podpisany, drugi również będzie musiał być podpisany.

7.8.

Podsumowanie W tym momencie kończymy naszą wycieczkę po nowych cechach C# 2. Omawiane w tym rozdziale zagadnienia można ogólnie podzielić na dwie kategorie: „warte posiadania” poprawki, które ułatwiają programowanie, i cechy, „których mamy nadzieję nigdy nie używać”, pomagające w miarę potrzeby wybrnąć z trudnych sytuacji. Poprzez analogię pomiędzy C# 2 i udoskonalaniem domu główne cechy z poprzednich rozdziałów można porównać do rozbudowy na pełną skalę. Niektóre z cech widzianych w tym rozdziale (takie jak typy częściowe i klasy statyczne) można przyrównać do odmalowania sypialni, podczas gdy inne cechy, jak na przykład aliasy przestrzeni nazw, są czymś w rodzaju zamontowania czujnika dymu — prawdopodobnie nigdy się nie przydadzą, ale warto je mieć.

Podsumowanie

249

Zakres zmian w C# 2 jest szeroki — projektanci zmagali się z wieloma obszarami, w których programiści odczuwali trudności, bez jakiegokolwiek celu nadrzędnego. Nie należy przez to rozumieć, że nowe cechy języka nie potrafią ze sobą współpracować — dla przykładu nullowalne typy wartościowe nie działałyby tak dobrze bez generyków — a jedynie to, iż nie istnieje wspólny cel, któremu miałaby służyć każda z nich, chyba że jako cel nadrzędny przyjmiemy ogólną produktywność. Teraz, kiedy skończyliśmy analizę C# 2, przyszła pora, aby przejść do C# 3, gdyż tutaj sytuacja wygląda zupełnie inaczej. Niemal każda cecha C# 3 formuje jeden z elementów dużego obrazu, jakim jest LINQ — konglomerat technologii mający na celu uproszczenie wielu zadań.

250

ROZDZIAŁ 7

Pozostałe cechy C# 2

Część III C# 3 — rewolucja w metodzie programowania

N

ie ulega wątpliwości, że C# 2 został znacznie ulepszony w porównaniu do C# 1. Korzyści płynące z typów generycznych mają fundamentalne znaczenie dla innych zmian, nie tylko w C# 2, ale również w C# 3. Trzeba jednak przyznać, iż C# 2 stanowi do pewnego stopnia zlepek różnych cech. Nie zrozum mnie źle: wszystkie one pasują do siebie idealnie, ale są one rozwiązaniem poszczególnych problemów języka. Na tym etapie rozwoju C# było to wskazane, ale w przypadku C# 3 sprawa ma się inaczej. Niemal każda cecha C# 3 ma na celu udostępnienie jednej konkretnej technologii — LINQ. Wiele z tych cech znajduje zastosowanie poza tym kontekstem i w żadnym wypadku nie należy ograniczać się do stosowania ich wyłącznie podczas pisania wyrażeń kwerendowych. Z drugiej strony lekkomyślnością byłoby nie doceniać kompletnego obrazu, jaki tworzą poszczególne elementy układanki prezentowane w kolejnych rozdziałach. Byłem pod dużym wrażeniem, kiedy w 2007 roku po raz pierwszy opisywałem C# i LINQ. Im głębiej wnikasz w język, tym lepiej dostrzegasz harmonię pomiędzy poszczególnymi elementami języka, jakie zostały wprowadzone. Elegancja wyrażeń kwerendowych, a zwłaszcza możliwość stosowania tej samej składni do wyrażeń wewnątrzprocesowych oraz wyrażeń w LINQ dla SQL były zachęcające. LINQ wydawał się bardzo obiecującą technologią. Teraz, po dwóch i pół roku, mogę powrócić do tych obietnic, by sprawdzić, jaki los je spotkał. Z moich obserwacji środowiska programistów — szczególnie na forum Stack Overflow — wynika jasno, że LINQ został powszechnie przyjęty i doprowadził do zmiany sposobu realizowania wielu zadań związanych z przetwarzaniem danych. Sterowniki baz danych nie są ograniczone wyłącznie do tych oferowanych przez firmę Microsoft — LINQ dla NHibernate i SubSonic to tylko dwie z wielu dostępnych

opcji. Również Microsoft nie zatrzymał się w ulepszaniu LINQ; w rozdziale 12. zobaczymy Równoległe LINQ i bibliotekę Reactive Extensions — dwie bardzo odmienne techniki obsługi danych, które wciąż bazują na znajomych operatorach LINQ. Jest również — najszerzej stosowany w przemyśle, najprostszy, najbardziej przewidywalny, wręcz „niebiański”— sterownik LINQ dla Obiektów. Już dawno w niepamięć odeszły dni, kiedy codziennością było pisanie kolejnych pętli filtrujących, implementowanie algorytmów wyszukiwania wartości maksymalnej czy spełniania przez obiekty kolekcji określonych kryteriów — wierzę, że takie czasy już nie powrócą. Pomimo rozpowszechnienia LINQ nadal widzę szereg pytań, które jasno pokazują, iż niektórzy programiści postrzegają LINQ jako swego rodzaju magiczną „czarną skrzynkę”. Co się stanie, jeśli użyję wyrażenia kwerendowego zamiast zwykłych metod rozszerzających? Kiedy tak naprawdę są odczytywane dane? Jak mogę poprawić wydajność? Chociaż można poznać LINQ przez zwykłą zabawę i eksperymenty na przykładach z sieci, znacznie więcej dowiesz się, patrząc, jak cały ten mechanizm działa na poziomie języka i jakie zadania realizują za Ciebie różnorodne biblioteki. Książka, którą masz przed sobą, nie jest poświęcona LINQ. Nadal koncentruję się bardziej na cechach języka umożliwiających istnienie LINQ niż na analizie takich tematów jak na przykład problemy konkurencyjności w środowisku Entity Framework itp. Uważam jednak, że kiedy zobaczysz wszystkie elementy języka oddzielnie, a potem sprawdzisz, jak są one do siebie dopasowane, znajdziesz się w o wiele lepszej sytuacji, gdy będziesz chciał samodzielnie zgłębiać detale poszczególnych dostawców danych.

Redukcja nadmiarowości przez zmyślny kompilator

Ten rozdział omawia: ♦ właściwości implementowane automatycznie, ♦ zmienne lokalne o typie niejawnym, ♦ inicjalizatory obiektów i kolekcji, ♦ tablice o typie niejawnym, ♦ typy anonimowe.

254

ROZDZIAŁ 8

Redukcja nadmiarowości przez zmyślny kompilator

Przyglądanie się C# 3 rozpoczniemy w taki sam sposób, w jaki zakończyliśmy oględziny C# 2 — listą w miarę prostych cech języka. Są to pierwsze kroczki na ścieżce do LINQ. Każdą z opisanych dalej cech języka można stosować bez związku z LINQ, jednak niemal wszystkie one mają znaczenie przy upraszczaniu kodu do stanu wymaganego dla efektywnego użycia LINQ. Warto zauważyć, że chociaż dwie spośród najważniejszych cech C# 2 — typy generyczne i typy nullowalne — wymagały zmian w środowisku CLR, to jednak w CLR wypuszczonym w ramach .NET 3 5 nie wprowadzono większych zmian. Niektóre elementy dostrojono, ale obyło się bez rewolucji. Środowisko rozrosło się, aby dać wsparcie dla LINQ i wprowadzić kilka innych cech w bibliotece klas bazowych, ale to zupełnie odmienna sprawa. Warto uzmysłowić sobie, które zmiany dotyczą wyłącznie języka C#, które biblioteki, a które są zmianami środowiska CLR. Oznacza to, że niemal wszystkie nowe cechy języka C# 3 zostały wprowadzone, aby kompilator mógł wykonać więcej pracy za Ciebie. Pewne przesłanki tego widzieliśmy w części drugiej — szczególnie przy okazji metod anonimowych i uproszczeń iteratora — a w części trzeciej przyjrzymy się kolejnym. W tym rozdziale poznamy następujące cechy C# wprowadzone w trzeciej wersji: właściwości implementowane automatycznie — usuwają konieczność pisania

prostych właściwości odnoszących się bezpośrednio do pól; zmienne lokalne o typie niejawnym — zmniejszają redundancję w deklaracji

zmiennych lokalnych przez wywnioskowanie typów tych zmiennych z inicjalizujących je wartości; inicjalizatory obiektów i kolekcji — pozwalają na tworzenie i inicjalizowanie

obiektów w pojedynczych wyrażeniach; tablice o typie niejawnym — zmniejszają redundancję wyrażeń tworzących

tablice przez wnioskowanie typu tablicy z jej zawartości; typy anonimowe — umożliwiają tworzenie typów doraźnych do przechowywania

prostych właściwości. Oprócz opisania przeznaczenia tych nowych cech języka zarekomenduję również sposób ich wykorzystania. Wiele z nowych cech języka C# 3 wymaga od programisty pewnej dozy rozwagi i powściągliwości. Nie chodzi tutaj bynajmniej o to, że cechy te mają małą moc i niewielką użyteczność podczas programowania — wręcz przeciwnie, jednak skłonność do używania najnowszej, „odlotowej” składni nie powinna przysłaniać dążenia do tworzenia przejrzystego i czytelnego kodu. Rozważania, które będę prowadził w tym rozdziale (i w pozostałej części książki), rzadko będą w pełni przejrzyste. Prawdopodobnie bardziej niż kiedykolwiek będziesz miał teraz na uwadze czytelność kodu, a w miarę jak będziesz się oswajał z nowymi cechami, będą się one stawały coraz bardziej czytelne. Powinienem jednak zaznaczyć, że o ile nie masz dobrych powodów, aby zakładać, że będziesz jedyną osobą, która kiedykolwiek będzie oglądać Twój kod, powinieneś starannie rozważyć potrzeby i poglądy swoich kolegów. Chwilowo wystarczy rozważań na ten temat. Zaczniemy od cechy, która nie powinna wzbudzać żadnych kontrowersji. Właściwości implementowane automatycznie zwyczajnie ułatwiają życie.

Właściwości implementowane automatycznie

8.1.

255

Właściwości implementowane automatycznie Nasza pierwsza cecha jest prawdopodobnie najprostsza w całym C# 3. Jest prostsza od wszystkich nowych cech C# 2. Pomimo tego — lub może dzięki temu — nadaje się do natychmiastowego zastosowania w wielu sytuacjach. Czytając o uproszczeniach iteratorów w rozdziale 6., może nie od razu się zorientowałeś, w jaki sposób zastosować je do ulepszenia swojego kodu, jednak w tym przypadku byłbym zaskoczony znalezieniem jakiegokolwiek nietrywialnego programu C#, który nie mógłby być zmodyfikowany poprzez użycie właściwości implementowanych automatycznie. Ta bajecznie prosta cecha pozwoli Ci wyrazić trywialne właściwości przy użyciu mniejszej ilości kodu niż poprzednio. Co mam na myśli, pisząc o trywialnej właściwości? Mam na myśli właściwość zdolną do zapisu i odczytu, która przechowuje swoją wartość w prostym prywatnym polu bez walidacji lub jakiegokolwiek innego kodu. Właściwości trywialne zajmują tylko kilka linii kodu, ale to wciąż sporo, jeśli weźmiesz pod uwagę, że wyrażają najprostsze koncepcje. C# 3 redukuje ilość kodu przez zastosowanie prostej transformacji w czasie kompilacji, jak pokazano na rysunku 8.1. Rysunek 8.1. Transformacja właściwości implementowanej automatycznie

Oczywiście kod pokazany na dole nie jest całkowicie poprawny. Podobnie jak w przypadku przedstawionych wcześniej metod anonimowych i uproszczeń iteratorów, pole ma trudną do wymówienia nazwę, co zapobiega konfliktowi nazw. Jest to jednak kod wygenerowany przez umieszczoną wyżej właściwość implementowaną automatycznie. O ile wcześniej mogło Cię kusić, aby użyć zmiennej publicznej w celu uproszczenia programu, to teraz właściwie nie masz usprawiedliwienia dla powstrzymywania się przed wstawieniem właściwości w to miejsce. Zasada ta jest szczególnie prawdziwa w przypadku kodu „śmieciowego”, który — jak wiemy — zwykle funkcjonuje o wiele dłużej, niż początkowo zakładaliśmy. TERMINOLOGIA: WŁAŚCIWOŚĆ AUTOMATYCZNA CZY AUTOMATYCZNIE IMPLEMENTOWANA? Kiedy pierwszy raz dyskutowano o właściwościach implementowanych automatycznie, a było to na długo przed opublikowaniem pełnej specyfikacji C# 3, nazywano je właściwościami automatycznymi.

256

ROZDZIAŁ 8

Redukcja nadmiarowości przez zmyślny kompilator

Uważam, że ta nazwa jest mniej skomplikowana w porównaniu do pełnej wersji i częściej używana w społeczności użytkowników języka. Ponieważ nie ma ryzyka powstania niejednoznaczności, w pozostałej części tej książki będę stosował naprzemiennie terminy właściwość automatyczna i właściwość implementowana automatycznie. Nadal obowiązuje cecha C# 2, która pozwala na ustalenie innego poziomu dostępu do gettera i settera. Możesz również tworzyć automatyczne właściwości statyczne, chociaż niemal zawsze są one pozbawione sensu. Publiczne właściwości statyczne powinny być „wątkowo bezpieczne”, jednak większość typów nie zapewnia instancji będących „wątkowo bezpiecznymi”. Również kompilator nie zapewnia żadnej pomocy w tym zakresie. Listing 8.1 pokazuje przykład bezpiecznej, chociaż bezużytecznej statycznej właściwości automatycznej, która zlicza utworzone instancje klasy zawierającej właściwości reprezentujące imię i wiek osoby. Listing 8.1. Demonstracja nieporadności statycznej właściwości automatycznej public class Person { public string Name { get; private set; } public int Age { get; private set; } private static int InstanceCounter { get; set; } private static readonly object counterLock = new object(); public InstanceCountingPerson(string name, int age) { Name = name; Age = age; lock (counterLock) { InstanceCounter++; }

Deklaracje prywatnej właściwości statycznej i sekcji krytycznej

Użycie sekcji krytycznej dla zapewnienia bezpiecznego dostępu do właściwości

} }

Używamy sekcji krytycznej, aby uniknąć problemów z wieloma wątkami. Tego samego mechanizmu musielibyśmy użyć przy każdej próbie dostępu do właściwości. Istnieje lepsza alternatywa wykorzystująca klasę Interlocked, ale ta z kolei wymaga dostępu do pól. Mówiąc w skrócie, jedyny scenariusz, w którym widzę przydatność statycznych właściwości automatycznych, to taki, w którym getter jest publiczny, a setter prywatny i wywołany wyłącznie w ramach inicjalizatora typu. Pozostałe właściwości na listingu 8.1, reprezentujące wiek i imię osoby, mają oczywiste zastosowanie — użycie właściwości automatycznych w tym przypadku jest zupełnie zrozumiałe. Tam, gdzie posiadasz właściwości, które zaimplementowałbyś trywialnie w poprzednich wersjach C#, rezygnacja z zastosowania właściwości automatycznych nie przynosi żadnych korzyści. Stosując właściwości automatyczne podczas pisania własnego kodu, napotkasz pewien mały problem: wszystkie Twoje konstruktory muszą jawnie wywołać konstruktor bezparametrowy — this() — dzięki czemu kompilator będzie wiedział, że wszystkie pola

Zmienne lokalne o typie niejawnym

257

na pewno zostały przypisane. Nie możesz przypisać wartości bezpośrednio polom, ponieważ są one anonimowe, i nie możesz użyć właściwości do momentu, aż wszystkie pola nie zostaną ustawione. Jedynym możliwym wyjściem jest wywołanie konstruktora bezparametrowego, który przypisze polom ich wartości domyślne. To wszystko na temat właściwości implementowanych automatycznie. Nie znajdziesz udogodnień w postaci na przykład możliwości deklarowania ich z domyślnymi wartościami początkowymi czy też przekształcenia w prawdziwe właściwości tylko do odczytu (rozwiązaniem najbliższym ideału jest użycie prywatnego settera). Gdyby wszystkie cechy C# 3 były tak proste, moglibyśmy ogarnąć wszystko w jednym rozdziale. Oczywiście tak nie jest — są jednak jeszcze cechy, które łatwo objaśnić. Nasz następny temat rozważań usuwa zduplikowany kod w innej powszechnej, choć specyficznej sytuacji — podczas deklarowania zmiennych lokalnych.

8.2.

Zmienne lokalne o typie niejawnym W rozdziale 2. omówiłem naturę systemu typów w C# 1. Wspomniałem w szczególności o trzech właściwościach: statyczności, jawności i bezpieczeństwie. Te właściwości są nadal prawdziwe w C# 2 i niemal całkowicie prawdziwe w C# 3. Nadal prawdziwe są części dotyczące statyczności i bezpieczeństwa (wyłączając, tak jak to zrobiliśmy w rozdziale 2., kod jawnie niebezpieczny), część dotycząca jawności typu obowiązuje w większości przypadków — możesz jednak poprosić kompilator o wywnioskowanie za Ciebie typu zmiennych lokalnych1.

8.2.1. Zastosowanie var do deklarowania zmiennych lokalnych Wszystko, co musisz zrobić, aby zastosować typ niejawny, to zastąpić część normalnej deklaracji zmiennej lokalnej słowem kluczowym var. Istnieją pewne ograniczenia (o których za moment), ale generalnie cała operacja sprowadza się do zastąpienia tego: MojTyp variableName = someInitialValue;

tym: var variableName = someInitialValue;

Wynik obu linii (w sensie skompilowanego kodu) jest taki sam, przy założeniu, że typem wartości someInitialValue jest MojTyp. Kompilator w trakcie kompilacji pobiera typ wyrażenia inicjalizującego i wymusza ten sam typ na inicjalizowanej zmiennej. Dopuszczalne są wszystkie normalne typy .NET, włączając w to typy generyczne, delegaty i interfejsy. Zmienna nadal posiada typ statyczny — po prostu Ty nie zapisałeś nazwy tego typu w kodzie. Zrozumienie tego, co dokładnie się dzieje, jest bardzo ważne, gdyż większość programistów odnosi początkowo mylne wrażenie, że słowo var zmienia C# na język o typie 1

C# 4 ponownie zmienia zasady gry, pozwalając Ci na dynamiczne stosowanie typu tam, gdzie jest to dla Ciebie wygodne. Przekonasz się o tym w rozdziale 14. Jednak wszystko w swoim czasie — do wersji 3 włącznie C# posiada w pełni statyczny system typów.

258

ROZDZIAŁ 8

Redukcja nadmiarowości przez zmyślny kompilator

dynamicznym lub słabym, co jest całkowitą nieprawdą. Najlepszym sposobem na wytłumaczenie tego jest pokazanie błędnego kodu: circles.Add(new Circle(Point.Empty, 20)); Kod nieprawidłowy

var stringValue = "Witaj, świecie"; stringValue = 0;

Ten kod nie kompiluje się, ponieważ stringValue jest typu System.String, a do zmiennej łańcuchowej nie można przypisać wartości 0. W wielu dynamicznych językach kod ten skompilowałby się, pozostawiając zmienną (z punktu widzenia kompilatora, środowiska IDE i środowiska wykonawczego) bez jakiegokolwiek użytecznego typu. Stosowanie var nie jest tym samym co użycie typu VARIANT w technologii COM lub VB6. Zmienna ma typ statyczny, tyle że typ został wywnioskowany przez kompilator. Przepraszam za szczegółowość tego wywodu, ale jest to bardzo ważna rzecz, stanowiąca źródło wielu nieporozumień. W Visual Studio można poznać typ, jaki kompilator zastosował dla zmiennej, przez umieszczenie kursora nad słowem var w deklaracji — patrz rysunek 8.2. Zwróć uwagę, że podpowiedź uwzględnia również typy składające się na deklarację typu Dictionary.

Rysunek 8.2. Umieszczenie kursora myszki nad słowem var powoduje wyświetlenie typu zadeklarowanej zmiennej

Jeśli rozpoznajesz ten widok, jest tak dlatego, że dokładnie to samo zachowanie ma miejsce w przypadku jawnej deklaracji zmiennej lokalnej. Dymek nie jest pokazywany jedynie w punkcie deklaracji. Jak się pewnie spodziewasz, ten sam dymek jest również wyświetlany, kiedy podświetlisz zmienną w dalszej części kodu. Widać to na rysunku 8.3, gdzie została użyta zadeklarowana wcześniej zmienna, a ja umieściłem kursor nad miejscem tego użycia.

Rysunek 8.3. Umieszczenie kursora myszki nad miejscem użycia zmiennej z typem niejawnym wyświetla jej typ

Kolejny raz widać tutaj zachowanie podobne do tego, jakie ma miejsce w przypadku tradycyjnej deklaracji zmiennej lokalnej. Istnieją dwa powody do wspomnienia w tym kontekście o Visual Studio. Po pierwsze, to wyraźny dowód na użycie statycznego typu — kompilator jednoznacznie informuje o typie zmiennej. Po drugie, możesz łatwo odkryć

Zmienne lokalne o typie niejawnym

259

zastosowany typ, nawet jeśli jest ukryty gdzieś głęboko w metodzie. Będzie to miało znaczenie za chwilę, kiedy będziemy rozmawiać o korzyściach i zagrożeniach płynących ze stosowania typu niejawnego. Najpierw jednak wspomnę o pewnych ograniczeniach.

8.2.2. Ograniczenia w typach niejawnych Nie możesz zastosować typu niejawnego dla każdej zmiennej w każdych warunkach. Typ niejawny może być użyty, jeśli: deklarowana zmienna jest zmienną lokalną (w przeciwieństwie do zmiennych

statycznych i pól obiektów), zmienna jest inicjalizowana w ramach deklaracji, wyrażenie inicjalizujące nie jest grupą metod lub funkcją anonimową2

(bez rzutowania), wyrażeniem inicjalizującym nie jest null, w wyrażeniu jest deklarowana tylko jedna zmienna, typ, który chcesz nadać zmiennej, jest w wyrażeniu inicjalizującym typem

czasu kompilacji, wyrażenie deklarujące nie korzysta ze zmiennej będącej przedmiotem

deklaracji3.

Interesujące są zwłaszcza punkty trzeci i czwarty. Nie możesz napisać czegoś takiego: circles.Add(new Circle(Point.Empty, 20)); circles.Add(new Circle(Point.Empty, 20)); Kod nieprawidłowy

var starter = delegate() { Console.WriteLine(); }

Jest tak dlatego, że kompilator nie wie, jaki typ ma zastosować. Możesz napisać tak: var starter = (ThreadStart) delegate() { Console.WriteLine(); }

ale jeśli faktycznie zamierzasz zrobić coś takiego, będzie lepiej, jeśli zaczniesz od zadeklarowania zmiennej w sposób jawny. To samo dotyczy przypadku przypisania null — mógłbyś dokonać odpowiedniego rzutowania, ale takie podejście nie miałoby sensu. Zauważ, że w wyrażeniach inicjalizujących możesz wykorzystać wyniki zwracane przez wywołania metod oraz właściwości — nie jesteś ograniczony wyłącznie do stałych i wywołań konstruktorów. Możesz na przykład zrobić tak: var args = Environment.GetCommandLineArgs();

W tym przypadku zmienna args przyjęłaby typ string[]. W praktyce inicjalizowanie zmiennej wynikiem wywołania funkcji jest najprawdopodobniej jedną z najczęstszych operacji w ramach LINQ, w której zastosowanie mają typy niejawne. Zobaczymy to wszystko później — na razie pamiętaj o tej uwadze przy kolejnych przykładach. 2

Termin funkcja anonimowa obejmuje zarówno metody anonimowe, jak i wyrażenia lambda, o których będziemy mówić w rozdziale 9.

3

Próba wykonania takiej deklaracji byłaby niezwykle nietypowa, ale możliwa, jeśli mocno się postarasz.

260

ROZDZIAŁ 8

Redukcja nadmiarowości przez zmyślny kompilator

Warto również wspomnieć, że możesz stosować typy niejawne dla zmiennych lokalnych deklarowanych w pierwszej części wyrażeń using, for lub foreach. Wszystkie poniższe przykłady są poprawne (oczywiście w odpowiednim kontekście): for (var i = 0; i < 10; i++) using (var x = File.OpenText("test.dat") foreach (var s in Environment.GetCommandLineArgs())

Zastosowane powyżej zmienne otrzymałyby typy danych (odpowiednio): int, Stream ´Reader i string. Oczywiście sam fakt, że możesz tak zrobić, nie oznacza, że powinieneś. Przyjrzyjmy się argumentom przemawiającym za stosowaniem typów niejawnych i przeciw takiemu rozwiązaniu.

8.2.3. Zalety i wady typów niejawnych Pytanie o to, kiedy warto stosować typy niejawne, jest źródłem wielu dyskusji w społeczności użytkowników C#. Poglądy rozciągają się od stwierdzeń „wszędzie” po stwierdzenia „nigdzie”, ze sporą liczbą głosów bardziej wyważonych, lokujących się gdzieś pośrodku. W sekcji 8 5 przekonamy się, że zastosowanie innej cechy C# 3 — typów anonimowych — będzie wymagało częstego użycia typów niejawnych. Mógłbyś oczywiście unikać również typów anonimowych, ale byłoby to wylewaniem dziecka razem z kąpielą. Głównym argumentem za stosowaniem typów niejawnych (odkładając chwilowo na bok typy anonimowe) nie jest to, że redukują liczbę uderzeń w klawiaturę potrzebną do wprowadzenia kodu, ale to, że dzięki nim kod na ekranie nie jest tak zbity, co poprawia jego czytelność. Za przykład mogą posłużyć typy generyczne, których nazwy bywają bardzo długie. Na rysunkach 8.2 i 8.3 zaprezentowano typ Dictionary>, który zajmuje 32 znaki. Po dwukrotnym wpisaniu tego typu (raz w ramach deklaracji i raz w ramach inicjalizacji) masz przed sobą długą linijkę kodu, która deklaruje i inicjalizuje zaledwie jedną zmienną! Alternatywą jest użycie aliasu, ale to może oznaczać całkowite oderwanie rzeczywistego typu od kodu, w którym został on użyty. Trudno znaleźć powód do oglądania tej samej (długiej) nazwy zmiennej, kiedy wiemy, że w obu miejscach powinno być to samo. Jeżeli deklaracja jest niewidoczna na ekranie, jesteś w takiej samej sytuacji, niezależnie od tego, czy typ niejawny został użyty, czy też nie (wszystkie metody, których użyłbyś do poznania typu, nadal obowiązują). Jeżeli deklaracja jest widoczna, o typie danych dowiesz się tak czy inaczej na podstawie wyrażenia inicjalizującego. Dodatkowo użycie var zmienia wydźwięk kodu. Czasami chcesz, aby czytelnik zwrócił większą uwagę na specyficzne typy danych zastosowane w rozwiązaniu, ponieważ są one znaczące. Na przykład mimo że typy generyczne SortedList i SortedDic ´tionary mają podobne API, ich charakterystyka wydajnościowa jest inna, co może mieć znaczenie dla Twojego szczególnego fragmentu kodu. Innym razem tym, co Cię interesuje, są faktycznie wykonywane operacje (nie zwróciłbyś uwagi na zmienione wyrażenie inicjalizujące, o ile są osiągane te same cele)4. Zastosowanie var pozwala czy4

Zdaję sobie sprawę, że to brzmi trochę jak kacze typizowanie (ang. duck typing): „O ile to może kwakać, jestem szczęśliwy”. Różnica polega na tym, że sprawdzamy, czy „kwakowalność” działa na poziomie kompilacji, a nie na poziomie wykonania.

Zmienne lokalne o typie niejawnym

261

telnikowi skupić się raczej na użyciu zmiennej niż na jej deklaracji — na tym, co kod robi, niż jak to robi. Wszystko to brzmi dobrze. Jakie zatem argumenty przemawiają za odrzuceniem typów niejawnych? Paradoksalnie jest ich wystarczająco dużo. Jednym z podstawowych jest czytelność, mimo że jest to również argument za stosowaniem typów niejawnych! Powstrzymując się od jawnego wskazania typu deklarowanej zmiennej, możesz utrudnić rozpoznanie go w trakcie czytania kodu. Przestaje obowiązywać reguła oddzielająca deklarację od inicjalizacji („zaznacz, co deklarujemy, a następnie wskaż, z jaką wartością zaczynamy”). W jakim stopniu stanowi to problem, zależy zarówno od czytelnika, jak i użytego wyrażenia inicjalizującego. Jeżeli wywołujesz konstruktor jawnie, to, co tworzysz, będzie zawsze całkiem oczywiste. Jeżeli wywołujesz metodę lub odwołujesz się do właściwości, będzie to zależne od tego, jak oczywisty będzie się wydawać zwracany typ — patrząc wyłącznie na to wywołanie. Literały liczb całkowitych stanowią dobry przykład, w którym wywnioskowanie typu na podstawie wyrażenia jest trudniejsze, niż możesz to sobie wyobrazić. Jak szybko potrafisz wskazać typ każdej zmiennej zadeklarowanej poniżej? var var var var var var

a b c d e f

= = = = = =

2147483647; 2147483648; 4294967295; 4294967296; 9223372036854775807; 9223372036854775808;

Odpowiedź to odpowiednio: int, uint, uint, long, long i ulong — zastosowany typ zależy od wartości użytej w wyrażeniu. Nie ma tutaj nic nowego w zakresie obsługi literałów — C# zawsze zachowywał się w ten sposób. W tym przypadku jednak użycie typów niejawnych ułatwia tworzenie niejasnego kodu. Rzadko się mówi o tym publicznie, ale w moim przekonaniu najczęściej przytaczany argument przeciwko typom niejawnym brzmi: „Coś tu jest nie tak”. Jeżeli od wieków pisałeś w językach typu C, niezależnie od tego, jak często będziesz sobie przypominał, że pod maską są to cały czas typy statyczne, będziesz czuł coś niepokojącego w całym tym biznesie. Być może nie jest to obawa mająca racjonalne podstawy, niemniej nadal jest rzeczywista. Brak poczucia komfortu prawdopodobnie wpłynie negatywnie na Twoją produktywność. Jeżeli zalety nie przeważają nad Twoimi negatywnymi odczuciami, trudno. Zależnie od swojej osobowości możesz spróbować przekonać samego siebie do oswojenia się z typami niejawnymi, ale oczywiście nie musisz.

8.2.4. Zalecenia Oto kilka zaleceń opartych na moich doświadczeniach z typami niejawnymi. Tak jak nazwa sugeruje, są to jedynie zalecenia — możesz przyjąć je według własnego uznania: Jeżeli ważne jest, aby osoba czytająca kod mogła szybko rozpoznać typ zmiennej, stosuj typy jawne. Jeżeli zmienna jest bezpośrednio inicjalizowana przez konstruktor, a nazwa typu

jest długa (co często ma miejsce w przypadku typów generycznych), rozważ użycie typu niejawnego.

262

ROZDZIAŁ 8

Redukcja nadmiarowości przez zmyślny kompilator Jeżeli dokładny typ zmiennej nie ma znaczenia, a jego natura jasno wynika

z kontekstu, użyj niejawnego typu w celu odwrócenia uwagi od tego, jak kod osiąga zamierzony cel, i skoncentrowania się na wyższym poziomie, czyli na tym, co kod pozwala osiągnąć. Skonsultuj kwestię użycia niejawnych typów z pozostałymi członkami zespołu przed rozpoczęciem nowego projektu. W przypadku wątpliwości wypróbuj oba warianty i wybierz ten, z którym czujesz się lepiej. Jeżeli zastosowanie uproszczonego kodu daje niewielki zysk, w produkcyjnym

kodzie zwykle stosuję typy jawne. (Typy niejawne przydają się szczególnie w kodzie prototypowym i testowym). Podsumowując: sugeruję, aby nie stosować typów niejawnych tylko dlatego, że są nowością albo że chcemy oszczędzić sobie kilku uderzeń w klawiaturę. Ogranicz ich stosowanie do miejsc, w których uzyskasz zwarty kod, pozwalający się skupić na najważniejszych elementach programu. W pozostałej części książki będę stosował typy niejawne na masową skalę wyłącznie z jednego prostego powodu — formatowanie kodu w druku jest o wiele trudniejsze niż na ekranie ze względu na ograniczoną przestrzeń. Wrócimy do typów niejawnych, kiedy natkniemy się na typy anonimowe i w pewnych sytuacjach będziesz zmuszony poprosić kompilator o wywnioskowanie typu niektórych zmiennych. Zanim to nastąpi, przyjrzyjmy się, jak C# ułatwia konstruowanie i wypełnianie nowego obiektu w pojedynczym wyrażeniu.

8.3.

Uproszczona inicjalizacja Można by pomyśleć, że w językach zorientowanych obiektowo tworzenie obiektów już dawno doprowadzono do stanu optymalnego. W końcu przed użyciem obiektu coś (bezpośrednio Twój kod lub pewna metoda wytwórcza) musi go stworzyć. Mimo to niewiele cech C# 2 jest nakierowanych na ułatwienie życia programistom w zakresie inicjalizacji. Jeżeli nie potrafisz osiągnąć tego, co chcesz, przy użyciu parametrów konstruktora, nie masz szczęścia — musisz stworzyć obiekt, a następnie ręcznie zainicjalizować go między innymi z pomocą właściwości. Jest to szczególnie irytujące, kiedy chcesz za jednym razem utworzyć cały zbiór obiektów, jak w przypadku tablicy lub innej kolekcji. Bez możliwości inicjalizowania obiektu pojedynczym wyrażeniem jesteś zmuszony do korzystania ze zmiennych lokalnych lub stworzenia metody pomocniczej, która wykonuje inicjalizację w oparciu o przekazane parametry. Jak zobaczymy w tej sekcji, C# 3 oferuje pomoc w szerokim zakresie.

8.3.1. Definicja prostych typów Wyrażenia, którymi będziemy się posługiwać w tej sekcji, są określane mianem inicjalizatorów obiektów. Są to jedynie metody definiowania inicjalizacji, która powinna nastąpić po utworzeniu obiektu. Możesz ustawiać właściwości, właściwości właściwości

Uproszczona inicjalizacja

263

(nie martw się, to prostsze, niż myślisz), a także dodawać elementy do kolekcji udostępnianych poprzez właściwości. Do demonstracji użyjemy ponownie klasy Person. Wcześniej używaliśmy imienia i wieku jako właściwości zapisywalnych. Teraz zapewnimy konstruktor bezparametrowy oraz konstruktor przyjmujący imię jako parametr. Dodamy również listę przyjaciół oraz lokalizację w formie właściwości tylko do odczytu, ale z możliwością operowania na obiektach wynikowych. Prosta klasa Location udostępnia właściwości Country i Town, wskazujące położenie domu danej osoby. Kompletny kod klasy znajduje się poniżej (listing 8.2). Listing 8.2. Prosta klasa Person służąca do dalszych demonstracji public class Person { public int Age { get; set; } public string Name { get; set; } List friends = new List(); public List Friends { get { return friends; } } Location home = new Location(); public Location Home { get { return home; } } public Person() { } public Person(string Name) { Name = Name; } } public class Location { public string Country { get; set; } public string Town { get; set; } }

Listing 8.2 jest prosty, ale warto zwrócić uwagę, że zarówno lista przyjaciół, jak i lokalizacja otrzymują pustą wartość początkową (nie mają wartości null). Lista przyjaciół i lokalizacja są również właściwościami tylko do odczytu. Będzie to istotne w dalszej części — teraz jednak przyjrzyjmy się właściwościom reprezentującym imię i wiek osoby.

8.3.2. Ustawianie prostych właściwości Teraz, kiedy mamy już nasz typ Person, chcemy utworzyć jego instancje, korzystając z nowych możliwości C# 3. W tej sekcji będziemy ustawiać właściwości Name i Age — pozostałymi zajmiemy się później. W praktyce użycie inicjalizatorów obiektów nie ogranicza się wyłącznie do właściwości. Wszystko, co tutaj zobaczysz, ma zastosowanie również do pól, jednak w przeważającej większości przypadków będziesz używał właściwości. Przyczyną takiego stanu rzeczy jest to, że w dobrze zaprojektowanych systemach, wykorzystujących

264

ROZDZIAŁ 8

Redukcja nadmiarowości przez zmyślny kompilator

kapsułkowanie danych, nie będziesz miał dostępu do pól, chyba że tworzysz instancję typu wewnątrz kodu tego typu. Warto oczywiście mieć świadomość, że możesz używać pól, dlatego widząc w dalszej części tej sekcji słowo właściwość, czytaj je jako właściwość lub pole. Skoro mamy to już z głowy, zajmijmy się stroną praktyczną. Załóżmy, że chcemy stworzyć osobę o imieniu Tomek, która ma sześć lat. Przed C# 3 istniały dwie możliwości osiągnięcia tego celu: Person tom1 = new Person(); tom1.Name = "Tomek"; tom1.Age = 6; Person tom2 = new Person("Tomek"); tom2.Age = 6;

Pierwsza wersja używa bezparametrowego konstruktora, a następnie ustawia obie właściwości. Druga wersja stosuje przeciążony konstruktor do ustawienia imienia, a następnie ustawia wiek. Oczywiście oba sposoby są nadal dostępne w C# 3, ale istnieją też inne rozwiązania: Person tom3 = new Person() { Name = "Tomek", Age = 6 }; Person tom4 = new Person { Name = "Tomek", Age = 6 }; Person tom5 = new Person("Tomek") { Age = 6 };

Część w nawiasach na końcu każdej linii to inicjalizator obiektu. Jest to wyłącznie trik kompilatora. W języku IL inicjalizacja obiektów tom3 i tom4 jest identyczna i wygląda niemal5 tak samo jak w przypadku obiektu tom1. Łatwo można przewidzieć, że kod dla obiektu tom5 jest niemal identyczny jak dla tom2. Zwróć uwagę na ominięte nawiasy konstruktora przy tworzeniu tom4. Taki skrót możesz stosować dla typów z konstruktorem bezparametrowym, który zostanie wywołany w skompilowanym kodzie. Po wywołaniu konstruktora kolejne właściwości są ustawiane w oczywisty sposób — według kolejności występowania w inicjalizatorze obiektów. Każda właściwość może się pojawić wyłącznie raz. Dla przykładu nie ma możliwości dwukrotnego ustawienia właściwości Name (chociaż jest to mało sensowne, możliwe jest wywołanie konstruktora przyjmującego imię jako parametr, a następnie kolejne podstawienie wartości tej właściwości w inicjalizatorze obiektów — kompilator nie będzie zgłaszał problemów). Jako wartości właściwości można użyć dowolnego wyrażenia, które samo w sobie nie jest przypisaniem. Możesz wywoływać metody i tworzyć nowe obiekty (potencjalnie z ich własnymi inicjalizatorami obiektów) — dozwolone jest niemal wszystko. Zastanawiasz się zapewne, jak bardzo jest to użyteczne — zaoszczędziliśmy jedną lub dwie linie kodu, ale to zdecydowanie nie jest wystarczającym powodem komplikowania składni języka. A może jednak? Zauważ jedną subtelną różnicę: my nie tylko utworzyliśmy obiekt w jednej linijce — utworzyliśmy go w jednym wyrażeniu. Ta

5

Ściślej rzecz biorąc, nowa wartość zmiennej nie ma przypisanej wartości do momentu, kiedy wszystkie właściwości są ustawione. Do tego czasu jest używana lokalna zmienna tymczasowa. Rzadko ma to istotne znaczenie, ale warto o tym wiedzieć, na wypadek gdybyś przerwał program debuggerem gdzieś w środku inicjalizacji.

Uproszczona inicjalizacja

265

różnica może być bardzo istotna. Załóżmy, że chcesz utworzyć tablicę obiektów typu Person[] z pewnymi predefiniowanymi danymi w każdym z obiektów. Nawet bez używania niejawnego typu tablicy, co zobaczymy dalej, kod jest schludny i czytelny: Person[] family = new { new Person { Name = new Person { Name = new Person { Name = new Person { Name = new Person { Name = };

Person[] "Ewa", Age = 34 }, "Jan", Age = 33 }, "Tomek", Age = 6 }, "Wojtek", Age = 3 }, "Robert", Age = 3 }

W przykładzie tak prostym jak ten moglibyśmy napisać konstruktor przyjmujący zarówno imię, jak i wiek oraz zainicjalizować tablicę w podobny sposób, wykorzystując C# 1 lub 2. Jednak odpowiednie konstruktory nie zawsze są dostępne, a jeśli nawet są i mają po kilka parametrów, nie zawsze można łatwo wywnioskować, który parametr odpowiada danej właściwości. Kiedy liczba parametrów wzrasta powyżej pięciu lub sześciu, często uświadamiam sobie, że jestem uzależniony od IntelliSense bardziej, niż tego chcę. Możliwość użycia nazw zmiennych w takich sytuacjach jest wielkim darem6. Takiej formy inicjalizatora obiektów będziesz najprawdopodobniej używał najczęściej. Istnieją jednak jeszcze dwie inne postacie: jedna dla ustawiania podwłaściwości i jedna dla dodawania do kolekcji. Przyjrzyjmy się najpierw podwłaściwościom, czyli właściwościom właściwości.

8.3.3. Ustawianie właściwości obiektów zagnieżdżonych Do tej pory przekonaliśmy się, że możemy łatwo ustawić właściwości Name i Age, ale nie możemy w ten sam sposób ustawić właściwości Home — jest ona wyłącznie do odczytu. Możemy ustawić miasto i państwo wiążące się z daną osobą przez pobranie właściwości Home, a następnie ustawienie właściwości na otrzymanym wyniku. Specyfikacja języka opisuje taką operację jako ustawianie właściwości obiektu osadzonego (ang. embedded object). Dla zupełnej jasności to, o czym mówimy, przedstawia się jako następujący kod C# 1: Person tom = new Person("Tomek"); tom.Age = 6; tom.Home.Country = "Polska"; tom.Home.Town = "Katowice";

Kiedy wypełniamy lokalizację, każde wyrażenie wykonuje operację pobrania instancji obiektu Location, a następnie ustawia odpowiednią właściwość na tej instancji. Nie jest to nic nowego, warto jednak przeanalizować szczegółowo ten przykład, aby nie umknęło Ci, jakie dokładnie operacje wykonuje powyższy kod.

6

C# 4 wprowadza tutaj alternatywne rozwiązanie — argumenty nazwane, o których będziemy mówić w rozdziale 13.

266

ROZDZIAŁ 8

Redukcja nadmiarowości przez zmyślny kompilator

C# 3 pozwala na skrócenie całości do jednego wyrażenia: Person tom = new Person("Tomek") { Age = 6, Home = { Country = "Polska", Town = "Katowice" } };

Skompilowany kod dla obu tych fragmentów jest taki sam. Kompilator dostrzega, że po prawej stronie znaku równości (=) mamy kolejny inicjalizator obiektu, i stosuje przypisania właściwości do odpowiedniego obiektu zagnieżdżonego. Jedna uwaga odnośnie do użytego przeze mnie formatowania — tak jak w przypadku niemal wszystkich cech C#, białe znaki nie mają znaczenia. Możesz zrezygnować całkowicie z formatowania inicjalizatora obiektów i umieścić wszystko w jednej linii. Do Ciebie należy znalezienie złotego środka pomiędzy długimi liniami a dużą liczbą tych krótkich. Istotny jest brak słowa kluczowego new w części inicjalizującej Home. Jeżeli musisz znaleźć miejsce, w którym kompilator zamierza tworzyć nowe obiekty lub przypisywać właściwości obiektom już istniejącym, szukaj wystąpień new w inicjalizatorze. Zawsze kiedy jest tworzony nowy obiekt, gdzieś musi się pojawić słowo new. Poradziliśmy sobie z właściwością Home, a co z przyjaciółmi Tomka? Istnieją właściwości, które możemy ustawić na typie List, ale żadna z nich nie spowoduje dodania elementu do tej listy. Pora na kolejną cechę — inicjalizatory kolekcji.

8.3.4. Inicjalizatory kolekcji Tworzenie kolekcji zawierających pewne wartości początkowe jest niezwykle powszechnym zadaniem. Przed pojawieniem się C# 3 jedyną cechą języka wspomagającą to zadanie było tworzenie tablic, ale nawet ono w wielu sytuacjach okazywało się nieprzydatne. C# 3 ma inicjalizatory kolekcji, które pozwalają na stosowanie tego samego typu składni jak w przypadku inicjalizatorów tablic, ale z dowolnym typem kolekcji i większą elastycznością. Tworzenie kolekcji z użyciem inicjalizatorów kolekcji Na pierwszy ogień weźmiemy znajomy już typ List. W C# 2 mogłeś wypełnić listę, przekazując istniejącą już kolekcję lub wywołując wielokrotnie metodę Add po utworzeniu pustej listy. Inicjalizatory kolekcji w C# 3 wykorzystują drugie podejście. Załóżmy, że chcemy wypełnić listę łańcuchów pewnymi imionami — oto kod wykonujący to zadanie w C# 2 (po lewej) i bliski odpowiednik w C# 3 (po prawej): List names = new List(); names.Add("Ewa"); names.Add("Jan"); names.Add("Tomek"); names.Add("Wojtek"); names.Add("Robert");

var names = new List { "Ewa", "Jan", "Tomek", "Wojtek", "Robert" };

Podobnie jak w przypadku inicjalizatorów obiektów, możesz określić parametry konstruktora lub użyć konstruktora bezparametrowego (jawnie lub niejawnie). Jednym z powodów użycia w tym miejscu typu niejawnego jest brak miejsca (zmienna names

Uproszczona inicjalizacja

267

równie dobrze mogła być zadeklarowana jawnie). Zredukowanie liczby linii kodu (bez zmniejszenia czytelności) jest miłe, ale istnieją dwie większe korzyści z zastosowania inicjalizatora kolekcji: część tworząca i inicjalizująca liczą się jako pojedyncze wyrażenia, w kodzie jest o wiele mniej bałaganu. Pierwszy punkt staje się istotny, kiedy chcesz użyć kolekcji jako argumentu metody lub jako pojedynczego elementu w większej kolekcji. Taka sytuacja ma miejsce względnie rzadko (chociaż wystarczająco często, aby mówić o użyteczności tego mechanizmu). Za to drugi punkt jest w mojej ocenie prawdziwym powodem do chwalenia tej cechy języka. Kiedy spojrzysz na kod po prawej stronie, przekonasz się, że z łatwością dostrzegasz potrzebne Ci informacje, a każda z nich jest zapisana tylko raz. Nazwa zmiennej pojawia się jeden raz, użyty typ występuje jeden raz i każdy element inicjalizowanej kolekcji pojawia się również tylko jeden raz. Wszystko jest maksymalnie uproszczone i znacznie bardziej przejrzyste niż w kodzie C# 2, który użyteczne fragmenty kodu obkłada dużą ilością tkanki tłuszczowej. Inicjalizatory kolekcji nie są ograniczone jedynie do list. Możesz je stosować w dowolnym typie implementującym IEnumerable, pod warunkiem że zapewnisz odpowiednią metodę Add dla każdego elementu użytego w inicjalizatorze. Metodę Add możesz zastosować z wieloma parametrami, umieszczając je w oddzielnym zestawie nawiasów. Takie podejście ma najczęściej zastosowanie przy tworzeniu słowników. Na przykład do stworzenia mapowania imion na odpowiadający im wiek moglibyśmy użyć następującego kodu: Dictionary nameAgeMap = new Dictionary { { "Ewa", 34 }, { "Jan", 33 }, { "Tomek", 6 } };

W tym przypadku metoda Add(string, int) zostanie wywołana trzy razy. Jeżeli dostępnych jest wiele metod Add, różne elementy inicjalizatora mogą wywołać różne wersje przeciążone metod. Jeżeli dla danego elementu nie istnieje kompatybilna wersja metody przeciążonej, kod się nie skompiluje. Warto zauważyć dwie rzeczy odnośnie do decyzji projektowych podjętych przy tworzeniu tego mechanizmu: Fakt, iż typ musi implementować IEnumerable, nie jest nigdy wykorzystywany przez kompilator. Metoda Add jest wyszukiwana po nazwie — nie ma wymogu implementowania jakiegokolwiek interfejsu. Obie decyzje mają charakter pragmatyczny. Obowiązek implementowania IEnumerable jest rozsądną próbą sprawdzenia, czy konkretny typ jest faktycznie kolekcją. Stosowanie dowolnego dostępnego przeciążenia metody Add (w przeciwieństwie do wymuszania konkretnej sygnatury metody) pozwala na tworzenie prostych inicjalizatorów, jak ten pokazany w przykładzie ze słownikiem. Wczesny projekt specyfikacji C# 3 wymagał implementacji interfejsu ICollection i jednoparametrowej metody Add (zgodnie z wymogiem tego interfejsu), która byłaby wywoływana zamiast wielu metod przeciążonych, jak ma to miejsce w rozwiązaniu

268

ROZDZIAŁ 8

Redukcja nadmiarowości przez zmyślny kompilator

końcowym. Takie podejście wydaje się bardziej przejrzyste, ale z drugiej strony istnieje o wiele więcej typów implementujących IEnumerable niż ICollection, a użycie jednoparametrowej metody Add byłoby bardzo niewygodne. Dla przykładu w naszym przypadku bylibyśmy zmuszeni do jawnego stworzenia instancji typu KeyValuePair ´ dla każdego elementu inicjalizatora. Rezygnacja z akademickiego formalizmu sprawiła, że w praktyce język stał się o wiele bardziej użyteczny. Wypełnianie kolekcji wewnątrz inicjalizatorów innych obiektów Do tej pory widzieliśmy inicjalizatory kolekcji użyte samodzielnie do stworzenia całej kolekcji. Mogą one być również użyte wewnątrz inicjalizatorów obiektów do wypełnienia kolekcji zagnieżdżonych. Aby to pokazać, wróćmy do naszego przykładu klasy Person. Właściwość Friends jest tylko do odczytu, nie możemy więc stworzyć nowej kolekcji i przypisać jej do tej właściwości. Możemy za to dodawać elementy do kolekcji zwracanej przy wywoływaniu metody get właściwości. Składnia służąca do tego celu jest podobna do tej, którą widzieliśmy już przy ustawianiu właściwości obiektów zagnieżdżonych, z tą różnicą, że zamiast kolejnych przypisań do właściwości teraz zastosujemy inicjalizator kolekcji. Zobaczmy, jak to wygląda, tworząc kolejną instancję klasy Person dla Tomka, tym razem z jego przyjaciółmi (listing 8.3). Listing 8.3. Konstruowanie nietrywialnego obiektu przy użyciu inicjalizatorów obiektów i kolekcji Person tom = new Person { Name = "Tomek", Age = 6, Home = { Town = "Katowice", Country = "Polska" }, Friends = { new Person { Name = "Albert" }, new Person("Marek"), new Person { Name = "Zbyszek", Age = 4 }, new Person("Bartek"), new Person("Alicja") { Age = 6, Home = { Town = "Warszawa", Country="Polska" } } } };

Inicjalizator kolekcji z dalszymi inicjalizatorami obiektów

Listing 8.3 wykorzystuje wszystkie cechy inicjalizatorów obiektów i kolekcji, z jakimi spotkaliśmy się do tej pory. Głównym punktem zainteresowania jest inicjalizator kolekcji, który sam w sobie używa wielu różnych inicjalizatorów obiektów. Zwróć uwagę na to, że nie tworzymy tutaj nowej kolekcji, ale dodajemy do już istniejącej. (Jeżeli właściwość posiadałaby metodę ustawiającą — setter — moglibyśmy utworzyć nową kolekcję i nadal korzystać ze składni inicjalizatora kolekcji). Moglibyśmy pójść dalej i określić przyjaciół będących przyjaciółmi przyjaciół Tomka, potem ich przyjaciół itd. Nie moglibyśmy wyspecyfikować jednak, że Tomek

Uproszczona inicjalizacja

269

jest przyjacielem Alberta. Wynika to stąd, że podczas inicjalizowania obiektu nie mamy do niego dostępu, nie możemy zatem wyrazić zależności cyklicznej. To może być niewygodne w kilku przypadkach, ale na ogół nie stanowi problemu. Inicjalizowanie kolekcji wewnątrz inicjalizatorów obiektów jest pewnego rodzaju skrzyżowaniem samodzielnych inicjalizatorów kolekcji i ustawiania zagnieżdżonych właściwości obiektu. Dla każdego elementu w inicjalizatorze kolekcji jest wywoływany getter właściwości (w tym przypadku Friends), a następnie (na zwróconym typie) odpowiednia metoda Add. Kolekcja nie jest czyszczona przed dodaniem elementów. Gdybyś na przykład postanowił, że każda osoba powinna być zawsze swoim własnym przyjacielem, i dodał this do listy przyjaciół w konstruktorze Person, inicjalizator kolekcji dopisałby jedynie kolejnych przyjaciół. Jak widzisz, kombinacja inicjalizatorów obiektów i kolekcji może zostać użyta do wypełnienia całych drzew obiektów. Kiedy jednak możemy się spotkać z taką sytuacją w rzeczywistości?

8.3.5. Zastosowanie inicjalizatorów Próba namierzenia sytuacji, w których inicjalizatory są użyteczne, przypomina trochę skecz grupy Monty Python o hiszpańskiej inkwizycji — za każdym razem, kiedy myślisz, że masz przypuszczalnie kompletną listę przypadków, na scenie pojawia się kolejny. Wspomnę tutaj o trzech możliwościach, które, mam nadzieję, zachęcą Cię do rozważenia, gdzie jeszcze mógłbyś znaleźć dla nich zastosowanie. Stałe kolekcje Nierzadko potrzebuję pewnego rodzaju kolekcji (na ogół mapy), która faktycznie powinna być stała. Oczywiście jest ona na tyle stała, na ile pozwala język C#, ale może być zadeklarowana jako statyczna i tylko do odczytu z wyraźnym ostrzeżeniem, że nie powinna być modyfikowana. (Zazwyczaj jest prywatna, i to w zupełności wystarcza, ewentualnie możesz skorzystać z typu ReadOnlyCollection). Osiągnięcie odpowiedniego poziomu prywatności wymagało napisania statycznego konstruktora lub metody pomocniczej wyłącznie do wypełnienia mapy. Inicjalizatory kolekcji C# 3 pozwalają na ustawienie wszystkiego w jednej linii. Tworzenie testów jednostkowych Przy tworzeniu testów jednostkowych często potrzebuję wypełnić jeden obiekt dla jednego testu, prawdopodobnie przekazując go jako parametr do metody będącej przedmiotem testu. Tradycyjna inicjalizacja obiektu może być rozwlekła, przez co esencja obiektu zostanie ukryta przed czytelnikiem kodu. Podobnie jest w przypadku kodu tworzącego XML, który potrafi często zasłonić faktyczną treść tego dokumentu (w porównaniu do tego samego dokumentu oglądanego w edytorze tekstowym, przy założeniu, że jest prawidłowo sformatowany). Przy zachowaniu odpowiednich wcięć w inicjalizatorze obiektów zagnieżdżona struktura hierarchii obiektów staje się bardziej oczywista w samej treści kodu, a wartości wyróżniają się bardziej, niż miałoby to miejsce w tradycyjnym podejściu.

270

ROZDZIAŁ 8

Redukcja nadmiarowości przez zmyślny kompilator

Wzorzec projektowy budowniczego Z różnych powodów potrzebujesz czasem określić dużą liczbę wartości dla pojedynczej metody lub wywołania konstruktora. Najczęstszą sytuacją, z którą ja się spotykam, jest tworzenie obiektów niezmiennych. Zamiast stosować ogromną liczbę parametrów (co często zaburza czytelność kodu ze względu na zacieranie się znaczenia poszczególnych argumentów)7, możesz użyć wzorca projektowego — budowniczego. Stwórz typ zmienny z odpowiednimi właściwościami, a następnie przekaż instancję budowniczego konstruktorowi lub metodzie. Dobrym przykładem takiego działania jest typ Process ´StartInfo — projektanci mogliby przeciążać Process.Start, stosując wiele różnych zestawów parametrów, jednak użycie ProcessStartInfo sprawia, że wszystko jest bardziej czytelne. Inicjalizatory obiektów i kolekcji pozwalają na tworzenie obiektu budowniczego w sposób bardziej przejrzysty — możesz wyspecyfikować go nawet inline podczas wywoływania oryginalnej metody. Wprawdzie musisz najpierw zaimplementować sam typ budowniczego, ale właściwości automatyczne niosą dużą pomoc na tym polu. Oczywiście istnieją jeszcze inne przypadki użycia oprócz trzech opisanych powyżej, a moją intencją w żadnym wypadku nie jest odradzanie stosowania tej nowej cechy w innych sytuacjach. Nie ma żadnego powodu (być może poza wprowadzeniem w zakłopotanie użytkowników, którzy nie mają obeznania z C# 3), by powstrzymywać się od stosowania nowej składni. Możesz uznać, że użycie inicjalizatora obiektu do ustawienia pojedynczej właściwości to lekka przesada — to kwestia estetyki i trudno tutaj podawać jakiekolwiek obiektywne wytyczne. Podobnie jak w przypadku typów niejawnych, warto wypróbować obie metody i zbadać swoje (i swojego zespołu) preferencje odnośnie do czytelności otrzymanego kodu. Do tej pory przyglądaliśmy się całkiem różnym cechom języka: łatwemu implementowaniu właściwości, upraszczaniu deklaracji zmiennych lokalnych i wypełnianiu obiektów przy użyciu pojedynczych wyrażeń. W pozostałej części tego rozdziału będziemy stopniowo łączyć te tematy, stosując deklaracje niejawne, wypełnianie obiektów i tworzenie całych typów bez podawania szczegółów implementacyjnych. Nasz kolejny temat wydaje się, jeśli myślimy o kodzie, bardzo podobny do inicjalizatorów obiektów. Wspominałem wcześniej, że inicjalizacja tablic w C# 1 i C# 2 była odrobinę niezdarna. Z pewnością nie zdziwi Cię, że została ona poprawiona w C# 3. Przyjrzyjmy się temu bliżej.

8.4.

Tablice o typie niejawnym W C# 1 i 2 inicjalizowanie tablic w ramach deklaracji i inicjalizacji zmiennej było całkiem schludne, ale jeśli chciałeś zrobić to w innym miejscu, musiałeś wskazać dokładny typ tablicy. Stąd dla przykładu poniższy kod kompiluje się bez problemu:

7

Pomocą w tym zakresie są argumenty nazwane, dostępne w C# 4.

Tablice o typie niejawnym

271

string[] names = {"Ewa", "Jan", "Tomek", "Robert", "Wojtek" };

Taki zapis nie zadziała jednak dla parametrów. Załóżmy, że chcemy wywołać metodę MyMethod, zadeklarowaną jako void MyMethod(string[] names). Ten kod nie będzie działał: circles.Add(new Circle(Point.Empty, 20)); Kod nieprawidłowy

MyMethod({"Ewa", "Jan", "Tomek", "Robert", "Wojtek" });

Zamiast tego musisz dokładnie wskazać, jakiego typu tablicę chcesz zainicjalizować: MyMethod(new string[] {"Ewa", "Jan", "Tomek", "Robert", "Wojtek" });

C# 3 pozwala na coś pośredniego: MyMethod(new[] {"Ewa", "Jan", "Tomek", "Robert", "Wojtek" });

Wyraźnie widać, że kompilator musi wypracować typ tablicy. Rozpoczyna od stworzenia zbioru typów czasu kompilacji dla wyrażeń wewnątrz nawiasów. Jeżeli w tym zbiorze jest dokładnie jeden typ, do którego wszystkie pozostałe typy mogą być niejawnie przekonwertowane, staje się on typem tablicy. W przeciwnym przypadku lub jeśli wszystkie wyrażenia są wyrażeniami bez typu, takimi jak wartości null lub metody anonimowe bez rzutowania, kod nie będzie się kompilował. Zauważ, że kandydatami do końcowego typu tablicy są jedynie typy samych wyrażeń. Oznacza to, że czasem będziesz zmuszony dokonać jawnego rzutowania wartości na bardziej ogólny typ. Dla przykładu poniższy kod nie skompiluje się: Kod nieprawidłowy

new[] { new MemoryStream(), new StringWriter() };

Nie istnieje konwersja z typu MemoryStream na StringWriter i odwrotnie. Oba mogą być niejawnie zrzutowane na object i IDisposable, ale kompilator uwzględnia jedynie typy będące w oryginalnym zbiorze wyprodukowanym z samych wyrażeń. Jeżeli zmienimy jedno z wyrażeń, tak aby jego typem był object lub IDisposable, kod skompiluje się: new[] { (IDisposable) new MemoryStream(), new StringWriter() };

Ostatnie wyrażenie ma typ niejawny IDisposable[]. Oczywiście, w takiej sytuacji równie dobrze mógłbyś jawnie wskazać typ tablicy, tak jak zrobiłbyś to w C# 1 i 2, aby jednoznacznie określić, co chcesz osiągnąć. W porównaniu do poprzednich cech tablice o typie niejawnym są małym rozczarowaniem. Ja z wielkim trudem znajduję dla nich entuzjazm, mimo że ułatwiają one przekazywanie tablicy jako argumentu. Można się spierać o to, czy ta cecha wpływa pozytywnie na wskaźnik balansu pomiędzy użytecznością a złożonością stosowany przez projektantów języka podczas decydowania, które cechy powinny się w nim znaleźć. Sądzę, że projektanci mieli swoje powody — istnieje przynajmniej jedna ważna sytuacja, w której ten rodzaj niejawnego nadawania typu jest absolutnie kluczowy. Ma to miejsce wtedy, gdy nie znasz (i nie możesz poznać) typu elementów w tablicy. Jakim sposobem można w ogóle doprowadzić do takiej sytuacji? Czytaj dalej…

272

ROZDZIAŁ 8

Redukcja nadmiarowości przez zmyślny kompilator

8.5.

Typy anonimowe Typy niejawne, inicjalizatory obiektów i kolekcji oraz niejawne typy tablic są w większym lub mniejszym stopniu użyteczne same w sobie. Ale te cechy służą również wyższemu celowi — umożliwiają pracę z ostatnim elementem języka prezentowanym w tym rozdziale, czyli typami anonimowymi. Te z kolei służą celowi jeszcze wyższemu — LINQ.

8.5.1. Pierwsze spotkania z gatunkiem anonimowym O wiele łatwiej byłoby wytłumaczyć typy anonimowe, gdybyś na podstawie przykładu miał już jakieś pojęcie o tym, czym są. Przykro mi to mówić, ale bez użycia metod rozszerzających i wyrażeń lambda przykłady w tej sekcji będą prawdopodobnie trochę sztuczne. Pojawia się tutaj problem jajka i kury: typy anonimowe są najbardziej użyteczne w kontekście cech bardziej zaawansowanych, my jednak musimy najpierw poznać podstawy, zanim będziemy mogli spojrzeć na większą całość. Tego będziemy się trzymać — obiecuję, że w dłuższej perspektywie wszystko nabierze sensu. Załóżmy, że nie mamy klasy Person, a jedyne właściwości, które nas interesują, to imię i wiek. Listing 8.4 pokazuje, że możemy budować obiekty z tymi właściwościami bez konieczności deklarowania typu w którymkolwiek momencie. Listing 8.4. Tworzenie obiektów o typie anonimowym z właściwościami Name i Age var tom = new { Name = "Tomek", Age = 6 }; var ewa = new { Name = "Ewa", Age = 34 }; var jan = new {Name = "Jan", Age = 33 }; Console.WriteLine("{0} ma {1} lat(a)", jan.Name, jan.Age);

Na podstawie powyższego kodu łatwo można zauważyć, że typy anonimowe są podobne do inicjalizatorów obiektów, jakie widzieliśmy w sekcji 8.3.2. Różnica polega na tym, że pomiędzy słowem kluczowym new i nawiasem otwierającym brakuje nazwy typu. Używamy zmiennych lokalnych o typie niejawnym, bo tylko takich możemy użyć (oczywiście poza typem object) — nie mamy nazwy typu do zadeklarowania zmiennej. Jak widzisz w ostatniej linijce, utworzony typ ma właściwości Name i Age, które mogą być odczytywane i posiadają wartość określoną przez inicjalizator obiektu anonimowego, użyty do stworzenia tej instancji. Zatem w tym przypadku wynikiem programu będzie: "Jan ma 33 lat(a)". Właściwości mają takie same typy jak wyrażenia użyte w inicjalizatorze — string dla Name i int dla Age. Podobnie jak w przypadku zwykłych inicjalizatorów obiektów, wyrażenia w inicjalizatorach obiektów anonimowych mogą wywoływać metody lub konstruktory, pobierać właściwości lub wykonywać obliczenia — cokolwiek chcesz zrobić. Być może teraz zaczynasz zauważać, dlaczego tablice o typie niejawnym mają znaczenie. Załóżmy, że chcesz stworzyć tablicę zawierającą całą rodzinę, a następnie przejść przez jej zawartość, aby obliczyć sumaryczny wiek8. Poniższy listing (8 5) właśnie to wykonuje i, przy okazji, demonstruje kilka innych interesujących cech typów anonimowych. 8

Jeśli znasz już LINQ, możesz zauważyć, że jest to dosyć osobliwy sposób sumowania wieku. Zgadzam się, wywołanie family.Sum(p => p.Age) byłoby zgrabniejsze — idźmy jednak krok po kroku.

Typy anonimowe

273

Listing 8.5. Wypełnianie tablicy przy użyciu typów anonimowych, a następnie szukanie sumarycznego wieku var family = { new { Name new { Name new { Name new { Name new { Name };

new[] = = = = =

"Ewa", Age = 34 }, "Jan", Age = 33 }, "Tomek", Age = 6 }, "Wojtek", Age = 3 }, "Robert", Age = 3 }

Użycie inicjalizatora tablicy o typie niejawnym Pięciokrotne użycie tego samego typu anonimowego

Użycie typu niejawnego int totalAge = 0; dla zmiennej person foreach (var person in family) { Sumowanie wieku totalAge += person.Age; } Console.WriteLine("Sumaryczny wiek: {0}", totalAge);

Składając razem listing 8.5 i to, czego się nauczyliśmy o tablicach z typem niejawnym w podrozdziale 8.4, możemy wywnioskować coś ważnego: wszystkie osoby w rodzinie są tego samego typu. Gdyby każde użycie inicjalizatora obiektu anonimowego w punkcie odnosiło się do innego typu, kompilator nie byłby w stanie wywnioskować typu tablicy zadeklarowanej w punkcie . W każdym module kompilator traktuje dwa dowolne inicjalizatory obiektów jako jednakowe, jeżeli mają taką samą liczbę właściwości z tymi samymi nazwami i typami oraz pojawiają się w takiej samej kolejności. Inaczej mówiąc, gdybyśmy zamienili miejscami właściwości Name i Age w jednym z inicjalizatorów, mielibyśmy do czynienia z dwoma różnymi typami. Podobnie stałoby się, gdybyśmy wstawili dodatkową właściwość w jednej z linii lub użyli typu long zamiast int dla wieku osoby. W tym momencie próba wywnioskowania typu tablicy by zawiodła. DETAL IMPLEMENTACYJNY: ILE TYPÓW? Jeśli kiedykolwiek zdecydujesz się spojrzeć na kod IL (lub zdekompilowany C#) dla typów anonimowych wygenerowanych przez kompilator Microsoft, musisz być świadomy, że chociaż dwa inicjalizatory obiektów anonimowych z tymi samymi nazwami właściwości ułożonymi w tej samej kolejności, ale używające różnych typów wyprodukują dwa różne typy, to oba będą faktycznie wygenerowane z pojedynczego typu generycznego. Ten typ generyczny jest sparametryzowany, ale najbliższe skonstruowane typy będą inne, ponieważ dla różnych inicjalizatorów będą im nadane inne argumenty. Zauważ, że do przejścia po naszej tablicy, tak jak po każdej innej kolekcji, możemy użyć wyrażenia foreach. Potrzebny typ zostaje wywnioskowany w punkcie , a zmienna person ma taki sam typ anonimowy, jakiego użyliśmy w tablicy. Ponownie możemy używać tej samej zmiennej dla różnych instancji, ponieważ wszystkie one są tego samego typu. Listing 8 5 udowadnia również, że właściwość Age ma w rzeczywistości mocny typ int — w przeciwnym razie próba zsumowania lat w punkcie nie skompilowałaby się. Kompilator wie o typie anonimowym, a Visual Studio jest nawet skłonne podzielić się tą informacją poprzez dymki podpowiedzi (na wypadek gdybyś nie był pewny). Rysunek 8.4 pokazuje wynik umieszczenia kursora nad częścią person wyrażenia person.Age.

274

ROZDZIAŁ 8

Redukcja nadmiarowości przez zmyślny kompilator Rysunek 8.4. Podświetlenie zmiennej zadeklarowanej niejawnie jako typ anonimowy powoduje wyświetlenie szczegółów tego typu anonimowego

Teraz, kiedy zobaczyliśmy już typy anonimowe w akcji, cofnijmy się i zobaczmy, co właściwie kompilator dla nas robi.

8.5.2. Części składowe typów anonimowych Typy anonimowe są tworzone przez kompilator i dołączane do skompilowanego modułu (ang. assembly) w taki sam sposób jak dodatkowe typy tworzone dla metod anonimowych i uproszczeń iteratorów. Środowisko CLR traktuje je jak najzwyklejsze typy, którymi faktycznie są. Jeżeli w przyszłości przejdziesz z typu anonimowego na typ zwykły, zakodowany ręcznie i zachowujący się w sposób opisany w tej sekcji, nie powinieneś zauważyć żadnej różnicy. Na typ anonimowy składają się następujące elementy: konstruktor przyjmujący wszystkie wartości inicjalizacyjne; parametry występują w tym samym porządku, w jakim zostały wyspecyfikowane przez inicjalizator obiektu anonimowego, oraz posiadają te same nazwy i typy; właściwości publiczne tylko do odczytu; stojące za właściwościami prywatne pola tylko do odczytu; przeciążenia metod Equals, GetHashCode i ToString.

To wszystko — nie ma zaimplementowanych interfejsów, klonowania ani serializacji, tylko konstruktor, kilka właściwości i parę metod pochodzących z typu object. Konstruktor i właściwości spełniają oczywiste zadania. Równość pomiędzy dwoma instancjami tego samego typu anonimowego jest określana w tradycyjny sposób, przez porównywanie przy użyciu metody Equals wartości kolejnych właściwości. Podobnie wygląda generowanie skrótu obiektu — dla kolejnych właściwości jest wywoływana metoda GetHashCode, a wszystkie wyniki są łączone w jedną całość. Dokładna metoda łączenia różnych algorytmów skrótu w jedną kompletną całość nie jest zdefiniowana. Tak czy inaczej, nie powinieneś pisać kodu bazującego na tym podejściu — wystarczy, jeśli będziesz świadomy, że dwie równe instancje zwrócą dokładnie ten sam skrót, a dwie różne instancje na ogół zwrócą różny skrót. Całość działa oczywiście tylko wtedy, gdy implementacje metod Equals i GetHashCode wszystkich typów użytych we właściwościach są zgodne z zasadami. Ponieważ właściwości są tylko do odczytu, wszystkie typy anonimowe są niezmienne, o ile tylko typy używane we właściwościach są również niezmienne. To daje Ci wszystkie typowe zalety niezmienności — możliwość przekazywania do metod bez obawy, że zostaną zmienione, proste współdzielenie danych pomiędzy wątkami itd.

Typy anonimowe

275

WŁAŚCIWOŚCI O TYPIE ANONIMOWYM W VB SĄ DOMYŚLNIE ZMIENNE. Typy anonimowe są również dostępne w Visual Basicu 9 i 10, ale ich właściwości są zmienne. Żeby osiągnąć niezmienność właściwości, musisz je zadeklarować z użyciem modyfikatora Key. Jedynie właściwości zadeklarowane jako klucze są używane w skrótach i sprawdzeniach równości. Można to łatwo przegapić podczas konwersji kodu z jednego języka na drugi. Już prawie skończyliśmy z typami anonimowymi. Pozostaje jeszcze jedna mała rzecz do omówienia — skrót dla całkiem powszechnej w LINQ sytuacji.

8.5.3. Inicjalizatory odwzorowujące Inicjalizatory obiektów anonimowych, które do tej pory widzieliśmy, były listami par nazwa-wartość, np. Name="Jan", Age=33 itp. Dla zmniejszenia objętości przykładów stosowałem w nich zawsze stałe, jednak w prawdziwym kodzie będziesz często kopiował właściwości istniejących obiektów. Czasem po drodze będzie wymagana manipulacja danymi, na ogół jednak w zupełności wystarczy bezpośrednia kopia. Kolejny raz trudno jest pokazać przekonywający przykład bez zastosowania LINQ. Spróbujmy powrócić do naszej klasy Person i założyć, że z pewnego słusznego powodu chcemy przekonwertować kolekcję instancji klasy Person na podobną kolekcję, w której każdy element ma wyłącznie imię i flagę informującą o tym, czy osoba jest dorosła. Mając zmienną person, moglibyśmy zrobić rzecz następującą: new { Name = person.Name, IsAdult = (person.Age >= 18) }

Taki kod działa i dla wyłącznie jednej właściwości składnia ustawiająca imię (fragment pogrubiony) jest w miarę przejrzysta — gdybyś miał jednak skopiować kilka właściwości, stałoby się to męczące. C# 3 udostępnia skrót: jeśli nie określisz nazwy właściwości, a jedynie wyrażenie do oszacowania jej wartości, jako nazwa zostanie przyjęta ostatnia część tego wyrażenia, pod warunkiem że jest to zwykłe pole lub właściwość. Mechanizm ten jest nazywany inicjalizatorem odwzorowującym. Oznacza to, że powyższy kod możemy przepisać w następujący sposób: new { person.Name, IsAdult = (person.Age >= 18) }

Przeważnie wszystkie fragmenty inicjalizatora obiektu anonimowego są inicjalizatorami odwzorowującymi — zdarza się to zwykle, kiedy bierzesz pewne właściwości z jednego obiektu, a potem kolejne z drugiego, często w ramach wspólnej operacji. W tej chwili wyprzedzam odrobinę bieg wydarzeń. Kolejny listing (8.6) pokazuje przedstawiony wcześniej kod w akcji przy użyciu metody List.ConvertAll i metody anonimowej. Listing 8.6. Transformacja z typu Person na imię i flagę osoby dorosłej List { new Person new Person new Person new Person new Person };

family = new List { { { { {

Name Name Name Name Name

= = = = =

"Ewa", Age = 34 }, "Jan", Age = 33 }, "Tomek", Age = 6 }, "Wojtek", Age = 3 }, "Robert", Age = 3 }

276

ROZDZIAŁ 8

Redukcja nadmiarowości przez zmyślny kompilator var converted = family.ConvertAll(delegate(Person person) { return new { person.Name, IsAdult = (person.Age >= 18) }; } ); foreach (var person in converted) { Console.WriteLine("{0} jest dorosła? {1}", person.Name, person.IsAdult); }

Listing 8.6, oprócz zastosowania inicjalizatora odwzorowującego dla właściwości Name, pokazuje również prawdziwą wartość interfejsu typu delegacyjnego oraz metod anonimowych. Bez nich nie moglibyśmy zachować mocnego typu zmiennej converted, ponieważ nie bylibyśmy w stanie określić, jakiego typu powinien być parametr TOutput konwertera. W obecnej postaci możemy przejść po całej liście i odczytać właściwości Name i IsAdult, tak jakby stanowiły one część dowolnego typu. Nie poświęcaj zbyt dużo uwagi inicjalizatorom odwzorowującym na tym etapie książki — najważniejszą rzeczą jest wiedzieć o ich istnieniu, tak abyś nie popadł w zakłopotanie, kiedy zobaczysz je później. Tak naprawdę uwaga ta odnosi się do całej części poświęconej typom anonimowym. Teraz przyjrzyjmy się, dlaczego typy anonimowe w ogóle istnieją.

8.5.4. Jaki to ma sens? Mam nadzieję, że nie czujesz się oszukany w tym momencie, a jeśli tak jest — współczuję. Typy anonimowe są w miarę złożonym rozwiązaniem problemu, którego tak naprawdę jeszcze nie spotkaliśmy… może z tym wyjątkiem, że moim zdaniem część tego problemu tak naprawdę już widziałeś. Jeżeli kiedykolwiek wykonywałeś rzeczywistą pracę mającą związek z bazami danych, wiesz, że nie zawsze potrzebujesz danych z wszystkich wierszy, jakie zostały zwrócone w wyniku zapytania. Pobranie większej ilości danych, niż potrzebujesz, nie jest problemem, ale jeśli potrzebujesz wyłącznie dwóch kolumn spośród 50 w tabeli, nie będziesz faktycznie pobierał 50, prawda? Podobny problem pojawia się w kodzie niezwiązanym z bazami danych. Załóżmy, że mamy klasę, która czyta plik dziennika i produkuje sekwencję linii z wieloma polami. Przechowywanie wszystkich informacji może nie być najlepszym rozwiązaniem z punktu widzenia zajętości pamięci, zwłaszcza jeśli interesuje nas tylko kilka pól z tego dziennika. LINQ pozwala odfiltrować te dane z wielką łatwością. Co jednak jest rezultatem tego filtrowania? Jak możemy zachować pewne dane i pozbyć się pozostałych? Jak możemy w prosty sposób przechować pewne wyliczone dane, które nie są bezpośrednio dostępne w oryginalnym formularzu? Jak możemy połączyć elementy danych, które początkowo nie były świadomie powiązane lub były powiązane wyłącznie w pewnej szczególnej sytuacji? Efektem końcowym, jakiego oczekujemy, jest nowy typ danych — jednak tworzenie takiego typu ręcznie w każdej sytuacji jest nudne, szczególnie kiedy pod ręką masz dostępne narzędzia, takie jak LINQ, które sprawiają, że cała procedura jest bardzo prosta. Rysunek 8 5 pokazuje trzy cechy, dzięki którym typy anonimowe są naprawdę przydatne.

Podsumowanie

277

Rysunek 8.5. Typy anonimowe pozwalają na przechowywanie tylko danych, które są potrzebne w konkretnej sytuacji, w dostosowanej do niej formie i bez każdorazowego żmudnego dopisywania typów

Jeżeli znajdziesz się w sytuacji, w której będziesz musiał stworzyć typ na użytek wyłącznie jednej metody i typ ten będzie się składał wyłącznie z pól oraz trywialnych właściwości, rozważ, czy lepszym rozwiązaniem nie byłby typ anonimowy. Przypuszczam, że za każdym razem, kiedy będziesz skłonny użyć typów anonimowych, mógłbyś również skorzystać z pomocy LINQ. Jeżeli jednak używasz tej samej sekwencji właściwości do tego samego celu w kilku różnych miejscach, powinieneś rozważyć stworzenie zwykłego typu, nawet jeśli zawiera on wyłącznie właściwości trywialne. Typy anonimowe w naturalny sposób „infekują” wszystkie źródła typami niejawnymi. Często można to zaakceptować, innym razem będzie to uciążliwe. Oznacza to przede wszystkim, że nie możesz z łatwością stworzyć metody zwracającej instancję typu w sposób zapewniający silny typ. Podobnie jak w przypadku poprzednich cech, używaj typów anonimowych, kiedy faktycznie pozwalają uprościć kod, a nie tylko dlatego, że są nowe i bombowe.

8.6.

Podsumowanie Co za (pozornie) wymieszany worek funkcjonalności! Widzieliśmy cztery cechy języka, które są całkiem podobne, przynajmniej pod względem składni: inicjalizatory obiektów, inicjalizatory kolekcji, tablice o typie niejawnym i typy anonimowe. Dwie pozostałe cechy — właściwości automatyczne i zmienne lokalne o typie niejawnym — są w pewnym stopniu odmienne. Dodatkowo większość z wymienionych cech byłaby użyteczna samodzielnie w C# 2, podczas gdy tablice o typie niejawnym i typy anonimowe warto poznać jedynie wtedy, kiedy obecna jest pozostała część cech C# 3. Co zatem wspólnego mają ze sobą wszystkie te cechy? Wszystkie zwalniają programistów z pisania nudnego kodu. Jestem pewien, że pisanie trywialnych właściwości nie cieszy Cię bardziej niż mnie. Podobnie jest z ustawianiem kilku właściwości jedna po drugiej czy stosowaniem zmiennych lokalnych (zwłaszcza kiedy chcesz utworzyć kolekcję podobnych obiektów). Nowe cechy języka C# nie tylko ułatwiają pisanie kodu, ale również jego czytanie (szczególnie kiedy są stosowane z rozwagą).

278

ROZDZIAŁ 8

Redukcja nadmiarowości przez zmyślny kompilator

W następnym rozdziale spojrzymy na nowe główne cechy języka oraz cechę środowiska, dla której są one bezpośrednim wsparciem. Jeśli myślisz, że metody anonimowe ułatwiły tworzenie delegatów, poczekaj do momentu, kiedy zobaczysz wyrażenia lambda.

Wyrażenia lambda i drzewa wyrażeń

Ten rozdział omawia: ♦ składnię wyrażeń lambda, ♦ konwersje z wyrażeń lambda na delegaty, ♦ klasy tworzące środowisko drzew wyrażeń, ♦ konwersje z wyrażeń lambda na drzewa wyrażeń, ♦ przyczyny dużego znaczenia drzew wyrażeń, ♦ zmiany w interfejsie typów, ♦ zmiany w sposobie rozwiązywania przeciążeń.

280

ROZDZIAŁ 9

Wyrażenia lambda i drzewa wyrażeń

W rozdziale 5. zobaczyliśmy, w jak dużym stopniu C# 2 uprościł użycie delegatów dzięki niejawnym konwersjom grup metod, metodom anonimowym, a także wariancji parametrów i wartości zwracanych. Pozwala to na znacznie prostszą i czytelniejszą subskrypcję zdarzeń, ale delegaty C# 2 są wciąż niewystarczająco poręczne, aby korzystać z nich na okrągło. Strona pełna metod anonimowych jest nadal mało czytelna i jest raczej mało prawdopodobne, abyś chciał regularnie stosować wyrażenia, w których pojawia się kilka metod anonimowych. Jednym z fundamentalnych elementów LINQ jest zdolność do tworzenia potoków operacji razem z całym wymaganym stanem. Operacje te mogą wyrażać wszelką możliwą logikę związaną z danymi: jak je filtrować, sortować, łączyć różne źródła danych i wiele więcej. W wewnątrzprocesowych zapytaniach LINQ operacje te są zwykle reprezentowane przez delegaty. Podczas przetwarzania danych przy użyciu LINQ dla Obiektów powszechną sytuacją jest stosowanie wyrażeń zawierających kilka delegatów1, co w C# 3 umożliwiają, bez utraty czytelności, wyrażenia lambda. (Skoro wspominam już o czytelności, w tym rozdziale stosuję zamiennie określenia wyrażenia lambda i lambdy. Użycie skróconej wersji jest w wielu sytuacjach bardzo pomocne, ponieważ często odwołuję się do zwykłych wyrażeń). ODROBINA GREKI. Lambda to grecka litera zapisywana jako λ. Termin wyrażenie lambda pochodzi od rachunku lambda, który stanowi obszar matematyki i informatyki zajmujący się definiowaniem i stosowaniem funkcji. Idea ta jest znana już od dłuższego czasu i dała początek takim językom jak ML. To, co ucieszy Cię najbardziej, to fakt, iż nie musisz nic wiedzieć o rachunku lambda, aby móc używać wyrażeń lambda w C# 3. Wykonywanie delegatów stanowi tylko część historii LINQ. Aby móc efektywnie wykorzystywać bazy danych i inne narzędzia kwerendowe, potrzebujemy różnych reprezentacji operacji w potoku — musimy znać sposób na traktowanie kodu jako danych, które mogą być sprawdzane w sposób programowy. W ten sposób logika tych operacji może być przekształcona i przyjąć różną formę, taką jak wywołanie usługi sieciowej, zapytanie SQL lub LDAP — cokolwiek będzie potrzebne. Chociaż poszczególne interfejsy programistyczne pozwalają na budowanie zapytań, na ogół są one mało czytelne i pozbawione szerszego wsparcia ze strony kompilatora. W tym miejscu z pomocą przychodzą lambdy — oprócz możliwości tworzenia z ich pomocą delegatów, kompilator C# potrafi również przekształcić je w drzewa wyrażeń, czyli struktury danych reprezentujące logikę wyrażeń lambda w taki sposób, aby mogła ona być analizowana przez inny kod. Mówiąc w skrócie, wyrażenia lambda są idiomatyczną formą wyrażania operacji w potokach danych LINQ. Zanim spróbujemy zrozumieć LINQ w całości, zajmiemy się poszczególnymi zagadnieniami, analizując każde z nich osobno. W tym rozdziale spojrzymy na dwa sposoby użycia wyrażeń lambda, ale chwilowo uprościmy trochę opis drzew wyrażeń — nie będziemy tworzyć jeszcze żadnych zapy1

LINQ dla Obiektów obsługuje sekwencje danych wewnątrz tego samego procesu. Technologie takie jak LINQ dla SQL-a rozkładają ciężar pracy na inne systemy, zewnętrzne względem procesu pierwotnego, na przykład bazy danych.

Wyrażenia lambda i delegaty

281

tań SQL. Z teorią za pasem powinieneś się czuć całkiem komfortowo w odniesieniu do wyrażeń lambda i drzew wyrażeń, zwłaszcza kiedy zajmiemy się naprawdę niesamowitymi zagadnieniami w rozdziale 12. W ostatniej części tego rozdziału przeanalizujemy zmiany w interfejsie typów C# 3, spowodowane głównie koniecznością obsługi niejawnych typów parametrów w lambdach. Będzie to nieco przypominało naukę wiązania sznurowadeł — nic ekscytującego, ale bez tej wiedzy szybko potkniesz się i upadniesz. Przekonajmy się, jak wyglądają wyrażenia lambda. Zaczniemy od metod anonimowych i stopniowo będziemy je przekształcać w coraz krótsze formy.

9.1.

Wyrażenia lambda i delegaty Pod wieloma względami wyrażenia lambda można traktować jako ewolucję metod anonimowych z C# 2. Wyrażenia lambda potrafią zrobić prawie wszystko to co metody anonimowe2, a przy tym niemal zawsze są bardziej spójne i czytelne. Warto zwłaszcza zwrócić uwagę na to, że w obu przypadkach zachowanie zmiennych przechwyconych jest jednakowe. W najbardziej jawnej formie obie funkcjonalności nie różnią się szczególnie między sobą, ale wyrażenia lambda posiadają wiele skrótów pozwalających uprościć je w najczęstszych przypadkach użycia. Podobnie jak w przypadku metod anonimowych, wyrażenia lambda posiadają specjalne reguły konwersji. Typem wyrażenia nie jest sam typ delegata, ale może ono być przekonwertowane na instancję delegata na kilka różnych sposobów — zarówno niejawnie, jak i jawnie. Metody anonimowe i wyrażenia lambda są określane wspólnym mianem funkcji anonimowych — w wielu przypadkach obowiązują te same reguły konwersji. Zaczniemy od prostego przykładu, wyrażonego początkowo jako metoda anonimowa. Stworzymy instancję delegata, który przyjmuje parametr typu string i zwraca wynik typu int (będący długością łańcucha wejściowego). Musimy zacząć od wyboru typu delegata. Na szczęście .NET 3 5 pomaga nam w tym, oferując całą gamę generycznych typów delegatów.

9.1.1. Przygotowanie — wprowadzenie delegatów typu Func<...> W przestrzeni nazw System środowiska .NET 3 5 jest pięć generycznych typów delegatów o nazwie Func. Nie ma w nich nic szczególnego — po prostu dobrze jest mieć pod ręką pewne predefiniowane typy generyczne zdolne do obsługi wielu różnych sytuacji. Każda sygnatura tego typu delegata może zawierać od zera do czterech parametrów typu3. Ostatni parametr typu jest w każdym przypadku używany jako typ zwracany. Oto sygnatury wszystkich typów delegatów Func w .NET 3 5: 2

Cechą dostępną w metodach anonimowych, której nie posiadają wyrażenia lambda, jest możliwość ignorowania parametrów wejściowych. Jeżeli chcesz sobie odświeżyć pamięć, zajrzyj do sekcji 5.4.3. W praktyce nie jest to jednak element, za którym będziesz tęsknił, używając wyrażeń lambda.

3

Być może pamiętasz, że w rozdziale 6. spotkaliśmy się już z wersją bezparametrową i jednym parametrem typu.

282

ROZDZIAŁ 9

Wyrażenia lambda i drzewa wyrażeń TResult TResult TResult TResult TResult

Func() Func(T arg) Func(T1 arg1, T2 arg2) Func(T1 arg1, T2 arg2, T3 arg3) Func(T1 arg1, T2 arg2, T3 arg3, T4 arg4)

Dla przykładu Func jest odpowiednikiem typu delegata o postaci: public delegate int SomeDelegate(string arg1, double arg2)

Zestaw delegatów Action<...> dostarcza podobną funkcjonalność dla przypadku, kiedy nie potrzebujesz wartości zwracanej. Wersja jednoparametrowa Action istniała już w .NET 2.0, ale cała reszta pojawiła się dopiero w .NET 3 5. Jeżeli cztery argumenty to dla Ciebie wciąż za mało, odpowiedzią jest .NET 4, który rozszerza rodziny Action<..> i Func<...> do postaci z maksymalnie szesnastoma argumentami. Najdłuższa wersja — Func — składa się z, przyprawiających o ból głowy, siedemnastu parametrów typu. Głównym powodem takich zmian jest udzielenie wsparcia środowisku DLR (ang. Dynamic Language Runtime), z którym spotkamy się w rozdziale 14. Jest raczej mało prawdopodobne, abyś musiał bezpośrednio korzystać z jego usług. Dla naszego przykładu potrzebujemy typu, który przyjmuje parametr typu string i zwraca int — użyjemy zatem Func.

9.1.2. Pierwsze przekształcenie na wyrażenie lambda Mając już przygotowany typ delegata, możemy użyć metody anonimowej do stworzenia instancji naszego delegata. Pokazuje to poniższy listing (9.1), który dodatkowo prezentuje wykonanie instancji delegata bezpośrednio po jego utworzeniu, dzięki czemu możemy się upewnić, że działa. Listing 9.1. Użycie metody anonimowej do stworzenia instancji delegata Func returnLength; returnLength = delegate(string text) { return text.Length; }; Console.WriteLine(returnLength("Cześć"));

Tak jak się spodziewaliśmy, listing 9.1 wypisuje 5. Oddzieliłem deklarację returnLength od przypisania, dzięki czemu możemy trzymać ją w pojedynczym wierszu — w ten sposób będzie nam łatwiej śledzić kod. Wytłuszczona część stanowi metodę anonimową — i to właśnie ją będziemy przekształcać na wyrażenie lambda. Najbardziej rozwlekła postać wyrażenia lambda ma postać: (lista-parametrów-o-typie-jawnym) => { wyrażenie }

Część => jest nowością w C# 3 i informuje kompilator, że używamy wyrażenia lambda. W większości przypadków wyrażenia lambda są stosowane w połączeniu z typem delegata o niepustym typie zwracanym — przy braku wartości zwracanej składnia jest odrobinę mniej intuicyjna. Jest to kolejna oznaka zmiany w podejściu do stosowania skrótów składniowych pomiędzy C# 1 i C# 3. W C# 1 delegaty były zwykle używane dla zdarzeń i rzadko kiedy zwracały cokolwiek. W LINQ są na ogół stosowane jako część

Wyrażenia lambda i delegaty

283

potoku danych — przyjmują dane wejściowe i zwracają wynik wskazujący na przykład wartość projektowaną lub wartość boolowską mówiącą o pasowaniu elementu do bieżącego filtra itp. Ta wersja, z jawnymi parametrami i nawiasami, wygląda bardzo podobnie do metody anonimowej. Listing 9.2 stanowi odpowiednik listingu 9.1, ale zastosowano w nim wyrażenie lambda. Listing 9.2. Pierwsza (rozwlekła) wersja wyrażenia lambda, podobna do metody anonimowej Func returnLength; returnLength = (string text) => { return text.Length; }; Console.WriteLine(returnLength("Cześć"));

Ponownie użyłem wytłuszczenia, aby wskazać wyrażenie służące do stworzenia instancji delegata. Czytając wyrażenia lambda, dobrze jest myśleć o części => jako „idzie do” — zatem przykład z listingu 9.2 można odczytać jako „text idzie do text.Length”. Ponieważ jest to jedyna część listingu, która będzie nas chwilowo interesować, od tego momentu będę pokazywał tylko ją. Jeżeli zastąpisz wytłuszczony tekst na listingu 9.2 dowolnym wyrażeniem lambda zamieszczonym w tej sekcji, wynik będzie dokładnie taki sam. W przypadku wyrażeń lambda wyrażenia wartości zwracanych są strzeżone przez takie same reguły jak w przypadku metod anonimowych: nie wolno próbować zwracać wartości z wyrażenia lambda o pustym typie zwracanym, natomiast gdy istnieje niepusty typ zwracany, każda ścieżka kodu musi zwrócić wartość kompatybilną z tym typem4. Jest to w miarę intuicyjne rozwiązanie, które rzadko kiedy sprawia kłopoty. Do tej pory nie zaoszczędziliśmy zbyt wiele miejsca ani nie sprawiliśmy, że kod stał się czytelniejszy. Zabierzmy się do skracania.

9.1.3. Używanie pojedynczego wyrażenia jako ciała Zwrócenie wartości w formie, którą widzieliśmy do tej pory, wymagało użycia pełnego bloku kodu. Jest to rozwiązanie bardzo elastyczne — tak jak w przypadku metod anonimowych, możesz mieć kilka wyrażeń, wykonywać pętle, zwracać wartość w różnych miejscach bloku kodu itd. Jednak w większości przypadków możesz z łatwością wyrazić całe ciało w formie pojedynczego wyrażenia, którego wartość jest wynikiem lambdy5. W takich przypadkach możesz wyspecyfikować jedynie wyrażenie, bez nawiasów, słowa kluczowego return czy średnika. Składnia wyrażenia wygląda wtedy następująco: (lista-parametrów-o-typie-jawnym) => wyrażenie

W naszym przypadku oznacza to, że wyrażenie lambda będzie wyglądać tak: (string text) => text.Length 4

Oczywiście ścieżki kodu rzucające wyjątki nie muszą zwracać wartości, podobnie jak wykrywalne pętle nieskończone.

5

Powyższej składni możesz użyć w przypadku delegata z pustym typem zwracanym, jeśli tylko potrzebujesz pojedynczego wyrażenia. W takim przypadku pomijasz jedynie średnik i nawiasy.

284

ROZDZIAŁ 9

Wyrażenia lambda i drzewa wyrażeń

Zaczyna to już wyglądać prościej. Ale co możemy teraz zrobić z typem parametru? Kompilator już wie, że Func przyjmuje pojedynczy parametr typu string, zatem powinno wystarczyć, jeśli nadamy mu tylko nazwę.

9.1.4. Lista parametrów o typie niejawnym W większości przypadków kompilator jest w stanie wywnioskować typy parametrów bez konieczności ich jawnego wskazywania. W takich sytuacjach można zapisać wyrażenie lambda jako: (lista-parametrów-o-typie-niejawnym) => wyrażenie

Lista parametrów o typie niejawnym jest zwykłą, pozbawioną typów listą nazw oddzielonych od siebie przecinkami. Obu rozwiązań nie można ze sobą mieszać dla poszczególnych parametrów — cała lista posiada wyłącznie typy jawne lub wyłącznie typy niejawne. Ponadto, jeśli którykolwiek z parametrów jest parametrem typu out lub ref, jesteś zmuszony do użycia typów jawnych. W naszym przypadku nie ma takiej potrzeby, zatem nasze wyrażenie ma teraz postać: (text) => text.Length

Udało nam się dość mocno skrócić całość — pozostało niewiele elementów, których moglibyśmy się pozbyć, ale nawiasy wydają się nadmiarowe.

9.1.5. Skrót dla pojedynczego parametru C# 3 pozwala na pominięcie nawiasów, kiedy wyrażenie lambda wymaga wyłącznie jednego parametru i parametr ten może posiadać typ niejawny. Jego forma może zatem wyglądać następująco: nazwa-parametru => wyrażenie

a ostateczna forma wyrażenia w naszym przykładzie to: text => text.Length

Możesz się zastanawiać, dlaczego dla wyrażeń lambda istnieje tak wiele przypadków szczególnych — żaden z pozostałych elementów języka nie przejmuje się na przykład, czy metoda ma jeden parametr, czy większą ich liczbę. Okazuje się, że to, co wygląda na przypadek szczególny, w rzeczywistości jest niesamowicie powszechną sytuacją, a usunięcie nawiasów z listy parametrów, kiedy w krótkim fragmencie kodu pojawia się wiele lambd, znacząco poprawia czytelność. Warto zaznaczyć, że tak jak w przypadku innych wyrażeń, jeśli chcesz, możesz otoczyć nawiasami całe wyrażenie lambda. Czasem pomaga to zwiększyć czytelność, zwłaszcza kiedy używasz lambdy do ustawienia zmiennej lub właściwości — w przeciwnym wypadku znaki równości mogą utrudnić zrozumienie całego wiersza kodu (przynajmniej przy pierwszym podejściu). W przeważającej większości przypadków wyrażenia są całkowicie czytelne bez jakiejkolwiek dodatkowej składni. Fragment takiego kodu w kontekście naszego przykładu pokazuje listing 9.3.

Wyrażenia lambda i delegaty

285

Listing 9.3. Spójne wyrażenie lambda Func returnLength; returnLength = text => text.Length; Console.WriteLine(returnLength("Cześć"));

Początkowo listing 9.3 może być dla Ciebie dosyć niezrozumiały, podobnie jak metody anonimowe wielu programistom wydają się nienaturalne, dopóki się do nich nie przyzwyczają. Kiedy jednak przyzwyczaisz się do wyrażeń lambda, będziesz doceniał ich spójność. Trudno byłoby sobie wyobrazić krótszą i bardziej przejrzystą formę tworzenia instancji delegata6. Moglibyśmy zmienić nazwę zmiennej text na coś takiego jak x. W LINQ takie zabiegi są często użyteczne, chociaż dłuższe nazwy dostarczają więcej informacji czytelnikowi. Naszą transformację rozciągnąłem na kilka stron tekstu, ale to, jak sporo składni zaoszczędziliśmy, pokazuje jasno rysunek 9.1. Rysunek 9.1. Skróty składni wyrażeń lambda

Decyzja o tym, czy używać skróconej składni wyrażenia lambda, polegającej na wyspecyfikowaniu jedynie wyrażenia zamiast całego bloku, jest zupełnie niezależna od tego, czy należy używać parametrów jawnych, czy niejawnych. My poszliśmy ścieżką skracania lambdy, ale równie dobrze mogliśmy zacząć od przekształcenia parametrów w niejawne. Przestaniesz myśleć o tego typu problemach, kiedy nabierzesz wprawy w posługiwaniu się wyrażeniami lambda — wtedy wybierzesz po prostu najkrótszą dostępną postać. FUNKCJE WYŻSZEGO RZĘDU. Ciało wyrażenia lambda może samo w sobie zawierać wyrażenie lambda — już to stwierdzenie sugeruje, iż konstrukcje tego typu potrafią być mylące. Ewentualnie parametrem wyrażenia lambda może być inny delegat, co jest równie złym rozwiązaniem. Oba przypadki są przykładem 6

Co wcale nie znaczy, że jest to niemożliwe. Niektóre języki pozwalają na reprezentowanie domknięć przez pojedyncze bloki kodu oraz magiczną nazwę zmiennej, obejmującą wszystkie przypadki pojedynczego parametru.

286

ROZDZIAŁ 9

Wyrażenia lambda i drzewa wyrażeń

funkcji wyższego rzędu. Jeżeli lubisz łamigłówki i inne zagadki, które wymagają intensywnego myślenia, przyjrzyj się kilku przykładom dostępnym w ramach kodu do pobrania. Chociaż jestem wobec nich sceptycznie nastawiony, są powszechne i użyteczne w programowaniu funkcjonalnym. Wymagają jednak pewnej zmiany sposobu myślenia. Do tej pory zajmowaliśmy się pojedynczym wyrażeniem lambda, przekształcając je jedynie w różne formy. Zanim zajmiemy się szczegółową analizą, przyjrzyjmy się kilku przykładom, aby bardziej skonkretyzować naszą wiedzę.

9.2.

Proste przykłady użycia List i zdarzeń Kiedy będziemy się przyglądać metodom rozszerzającym w rozdziale 10., wyrażenia lambda będą nam towarzyszyć na okrągło. Do tego momentu najlepszymi przykładami użycia wyrażeń lambda będą List i metody obsługi zdarzeń. Zaczniemy od list, automatycznie implementowanych właściwości, zmiennych lokalnych o typie niejawnym i inicjalizatorów kolekcji (w celu osiągnięcia oszczędnego kodu). Następnie wywołamy metody przyjmujące delegaty, tworząc je oczywiście z pomocą wyrażeń lambda.

9.2.1. Filtrowanie, sortowanie i operacje na listach Jeśli pamiętasz, metoda FindAll klasy List przyjmuje Predicate i zwraca nową listę ze wszystkimi elementami listy oryginalnej pasującymi do tego predykatu. Metoda Sort przyjmuje Comparison i na tej podstawie odpowiednio sortuje listę. W końcu ForEach przyjmuje akcję typu Action i wykonuje ją na każdym elemencie. Listing 9.4 prezentuje wykorzystanie wyrażeń lambda do stworzenia instancji delegata dla każdej z tych metod. Przykładowe dane to tytuły i daty premiery różnych filmów. W pierwszej kolejności wyświetlamy oryginalną listę, a następnie tworzymy i wyświetlamy listę ograniczoną wyłącznie do starych filmów. W końcu sortujemy po nazwie i wyświetlamy oryginalną listę. (Interesujące jest, o ile więcej kodu byłoby wymagane do przeprowadzenia tej samej operacji w C# 1). Listing 9.4. Przetwarzanie listy filmów przy użyciu wyrażeń lambda class Film { public string Name { get; set; } public int Year { get; set; } } ... var films = new List { new Film {Name="Szczęki", Year=1975}, new Film {Name="Deszczowa piosenka", Year=1952}, new Film {Name="Pół żartem, pół serio", Year=1959}, new Film {Name="Czarnoksiężnik z Oz", Year=1939}, new Film {Name="To wspaniałe życie", Year=1946}, new Film {Name="American Beauty", Year=1999},

Proste przykłady użycia List i zdarzeń

287

new Film {Name="Przeboje i podboje", Year=2000}, new Film {Name="Podejrzani", Year=1995} };

Utworzenie delegata wielokrotnego użytku

do wyświetlania listy Action print = film => Console.WriteLine("Tytuł={0}, Rok={1}", film.Name, film.Year);

films.ForEach(print);

Wyświetlenie oryginalnej listy

films.FindAll(film => film.Year < 1960) .ForEach(print);

Utworzenie przefiltrowanej listy

films.Sort((f1, f2) => f1.Name.CompareTo(f2.Name)); films.ForEach(print);

Posortowanie oryginalnej listy

Pierwsza część listingu 9.4 to przygotowanie danych. Dla ułatwienia stworzyłem typ nazwany — typ anonimowy wymagałby w tym przypadku wykonania kilku dodatkowych zabiegów. Zanim użyjemy listy, tworzymy instancję delegata ( ), za pomocą którego będziemy wyświetlać kolekcję elementów. Z instancji delegata korzystamy trzykrotnie, dlatego przechowuję ją w zmiennej, zamiast stosować za każdym razem oddzielne wyrażenie lambda. Instancja delegata wyświetla tylko pojedynczy element, ale jeśli przekażemy ją do List.ForEach, możemy wyświetlić na ekranie całą listę. Warto zwrócić uwagę na pewien subtelny element — średnik na końcu tego wyrażenia jest częścią przypisania, a nie częścią wyrażenia lambda. Gdybyśmy użyli tej lambdy jako argumentu w wywołaniu metody, nie byłoby średnika bezpośrednio za Console.WriteLine(...). Pierwszą listą, jaką wyświetlamy ( ), jest oryginalna lista bez żadnych modyfikacji. Następnie znajdujemy i wyświetlamy ( ) wszystkie filmy, które zostały nakręcone przed 1960 rokiem. Do tego celu używamy kolejnego wyrażenia lambda wykonywanego dla każdego elementu z listy — jego celem jest stwierdzenie, czy dany film powinien zostać dołączony do przefiltrowanej listy. W kodzie źródłowym wyrażenie lambda pojawia się jako argument metody, ale kompilator tworzy w rzeczywistości metodę w postaci: private static bool SomeAutoGeneratedName(Film film) { return film.Year < 1960; }

Wywołanie metody FindAll przyjmuje wtedy postać: film.FindAll(new Predicate(SomeAutoGeneratedName))

Obsługa wyrażeń lambda wygląda w tym miejscu tak jak obsługa metod anonimowych w C# 2 — wszystko sprowadza się do tego, jak bardzo zmyślny jest kompilator. (W rzeczywistości w tym przypadku kompilator Microsoft jest mądrzejszy — wiedząc, że może wykorzystać instancję delegata, jeśli kod zostanie ponownie wywołany, zapisuje go w pamięci podręcznej). Sortowanie listy ( ) również odbywa się przy użyciu wyrażenia lambda, które porównuje dwa filmy za pomocą ich tytułów. Muszę przyznać, że wywoływanie przez nas CompareTo w sposób jawny wygląda niezbyt elegancko. W następnym rozdziale zobaczymy, w jaki sposób można wyrazić porządkowanie listy w przyjemniejszy sposób za pomocą metody rozszerzającej OrderBy.

288

ROZDZIAŁ 9

Wyrażenia lambda i drzewa wyrażeń

Przyjrzyjmy się następnemu przykładowi, tym razem prezentującemu wykorzystanie wyrażeń lambda jako metod obsługi zdarzeń.

9.2.2. Logowanie w metodach obsługi zdarzeń Wracając na chwilę do rozdziału 5., na listingu 5.9 widzieliśmy prosty sposób użycia metod anonimowych do logowania pojawiających się zdarzeń — wtedy mogliśmy posłużyć się spójną składnią wyłącznie dlatego, że nie przejmowaliśmy się utratą dostępu do parametrów wejściowych. W jaki sposób moglibyśmy zapisać zarówno naturę samego zdarzenia, jak i informacje o nadawcy i argumentach? Umożliwiają to wyrażenia lambda, co pokazuje listing 9.5. Listing 9.5. Logowanie zdarzeń z pomocą wyrażeń lambda static void Log(string title, object sender, EventArgs e) { Console.WriteLine("Zdarzenie: {0}", title); Console.WriteLine(" Nadawca: {0}", sender); Console.WriteLine(" Argumenty: {0}", e.GetType()); foreach (PropertyDescriptor prop in TypeDescriptor.GetProperties(e)) { string name = prop.DisplayName; object value = prop.GetValue(e); Console.WriteLine(" {0}={1}", name, value); } } ... Button button = new Button(); button.Text = "Kliknij mnie"; button.Click += (src, e) => Log("Click", src, e); button.KeyPress += (src, e) => Log("KeyPress", src, e); button.MouseClick += (src, e) => Log("MouseClick", src, e); Form form = new Form(); form.AutoSize = true; form.Controls.Add(button); Application.Run(form);

Listing 9 5 prezentuje użycie wyrażeń lambda do przekazania nazwy zdarzenia i jego parametrów metodzie Log, która wyświetla szczegóły dotyczące zdarzenia. Ze względu na ogromną ilość informacji związanych z kontrolkami nie wyświetlamy szczegółów dotyczących źródła zdarzenia, lecz ograniczamy się jedynie do tego, co zwróci jego metoda ToString. Używamy natomiast refleksji w odniesieniu do deskryptorów właściwości, aby pokazać szczegóły tego, co przekazała nam instancja klasy EventArgs. Oto przykładowy wynik działania programu po kliknięciu przycisku: Zdarzenie: Click Nadawca: System.Windows.Forms.Button, Text: Kliknij mnie Argumenty: System.Windows.Forms.MouseEventArgs Button=Left Clicks=1 X=70 Y=6

Drzewa wyrażeń

289

Delta=0 Location={X=70,Y=6} Zdarzenie: MouseClick Nadawca: System.Windows.Forms.Button, Text: Kliknij mnie Argumenty: System.Windows.Forms.MouseEventArgs Button=Left Clicks=1 X=70 Y=6 Delta=0 Location={X=70,Y=6}

Oczywiście taki sam efekt można osiągnąć bez użycia wyrażeń lambda, ale z nimi całe rozwiązanie jest o wiele zgrabniejsze. Skoro widzieliśmy już lambdy konwertowane na instancje delegatów, przyszła pora na przyjrzenie się drzewom wyrażeń, które reprezentują wyrażenia lambda jako dane, a nie kod.

9.3.

Drzewa wyrażeń Idea „kodu jako danych” jest znana od bardzo dawna, ale nie była stosowana na szeroką skalę w popularnych językach programowania. Mógłbyś argumentować, że z koncepcji tej korzystają wszystkie programy .NET, ponieważ JIT traktuje kod jako dane, które następnie przekształca na kod natywny wykonywany na Twoim procesorze. Sam mechanizm tkwi jednak gdzieś głęboko i chociaż istnieją biblioteki do operowania na kodzie IL w sposób programowy, nie są one szeroko stosowane. Drzewa wyrażeń w .NET 3.5 dostarczają abstrakcyjną metodę reprezentowania pewnego kodu jako drzewa obiektów. Są one czymś podobnym do CodeDOM, ale działającym na nieco wyższym poziomie. Drzewa wyrażeń znajdują zastosowanie głównie w LINQ. W dalszej części tej sekcji przekonamy się, jak fundamentalne znaczenie mają one dla tej technologii. C# 3 posiada wbudowaną funkcjonalność pozwalającą przekształcać wyrażenia lambda na drzewa wyrażeń, ale zanim do tego przejdziemy, przekonajmy się, jak wyrażenia te integrują się ze środowiskiem .NET bez stosowania jakichkolwiek sztuczek kompilatora.

9.3.1. Budowanie drzew wyrażeń w sposób programistyczny Drzewa wyrażeń nie są tak tajemnicze, jak może się wydawać, chociaż niektóre przypadki ich użycia wyglądają naprawdę intrygująco. Jak sugeruje nazwa, są drzewami obiektów, gdzie każdy węzeł w drzewie jest wyrażeniem samym w sobie. Różne typy wyrażeń reprezentują różne operacje, które mogą być wykonywane w kodzie: operacje dwuargumentowe (takie jak dodawanie), operacje jednoargumentowe (takie jak pobieranie długości tablicy), wywołania metod, wywołania konstruktorów itd. Wyrażenia są reprezentowane przez różnorodne klasy zawarte w przestrzeni nazw System.Linq.Expressions. Wszystkie one wywodzą się z abstrakcyjnej klasy Expression, zawierającej głównie statyczne metody wytwórcze służące do tworzenia instancji innych klas wyrażeń. Klasa ta posiada dwie właściwości:

290

ROZDZIAŁ 9

Wyrażenia lambda i drzewa wyrażeń Właściwość Type reprezentuje typ .NET wyliczonego wyrażenia — możesz

traktować go jako typ zwracany. Na przykład typem wyrażenia, które pobiera właściwość Length łańcucha, jest int. Właściwość NodeType zwraca rodzaj reprezentowanego wyrażenia w postaci elementu enumeracji ExpressionType. Może to być na przykład LessThan, Multiply lub Invoke. Posługując się tym samym przykładem co wyżej, w przypadku mojLancuch.Length część związana z dostępem do właściwości miałaby węzeł typu MemberAccess. Istnieje wiele klas wywiedzionych z Expression, a niektóre z nich posiadają różne typy węzłów. Na przykład BinaryExpression reprezentuje dowolną operację arytmetyczną, logiczną, porównanie, indeksowanie tablicy itp. z dwoma operandami. Właśnie w tym miejscu właściwość NodeType nabiera znaczenia, ponieważ pozwala rozróżnić odmienne typy wyrażeń reprezentowane przez tę samą klasę. Nie zamierzam opisywać każdej klasy wyrażenia lub typu węzła — jest ich zbyt wiele i wszystkie są bardzo dobrze wyjaśnione w MSDN-ie (zobacz http://mng.bz/3vW3). Zamiast tego zacznijmy od próby stworzenia jednego z najprostszych możliwych drzew, dodającego do siebie dwie stałe typu całkowitego. Poniższy listing (9.6) tworzy drzewo wyrażeń reprezentujące 2+3. Listing 9.6. Proste drzewo wyrażeń — dodanie 2 do 3 Expression firstArg = Expression.Constant(2); Expression secondArg = Expression.Constant(3); Expression add = Expression.Add(firstArg, secondArg); Console.WriteLine(add);

Uruchomienie programu z listingu 9.6 spowoduje wyświetlenie wyniku (2 + 3), co oznacza, że różnorodne klasy wyrażeń nadpisują ToString w celu wyprodukowania wyniku czytelnego dla człowieka. Drzewo wygenerowane przez powyższy kod przedstawia rysunek 9.2. Rysunek 9.2. Graficzna reprezentacja drzewa wyrażeń stworzonego przez kod na listingu 9.6

Zwracam uwagę, że w kodzie są najpierw tworzone wyrażenia stanowiące liście — budujemy od dołu do góry. Jest to wymuszone przez regułę niezmienności wyrażeń — po utworzeniu wyrażenia nie ulegnie ono zmianie przez cały okres swojego życia. Możesz je zatem zapisać i później wielokrotnie go używać. Skoro zbudowaliśmy drzewo wyrażeń, spróbujmy je wykonać.

Drzewa wyrażeń

291

9.3.2. Kompilowanie drzew wyrażeń do postaci delegatów Jednym z typów wywodzących się z Expression jest LambdaExpression. Z niej wywodzi się następnie klasa generyczna Expression. Dla pełnej jasności przedstawiam tę hierarchię w formie graficznej na rysunku 9.3. Rysunek 9.3. Hierarchia od Expression< ´TDelegate> aż po Expression

Różnica pomiędzy Expression i Expression polega na tym, iż w przypadku klasy generycznej jest znany statyczny typ parametrów oraz typ zwracany. Informacja ta jest zawarta w parametrze typu TDelegate, który musi być typem delegatowym. Dla przykładu nasze proste wyrażenie sumujące nie przyjmuje żadnych parametrów i zwraca wartość całkowitą — takiemu zachowaniu odpowiada sygnatura Func, zatem do reprezentacji naszego wyrażenia w statycznym systemie typów moglibyśmy użyć Expression>. Robimy to poprzez metodę Expression.Lambda. Posiada ona wiele przeciążeń — nasz przykład używa metody generycznej, która korzysta z parametru typu do określenia typu delegata, jaki chcemy reprezentować. Inne przykłady znajdziesz w MSDN-ie. Ale jaki to wszystko ma cel? Otóż LambdaExpression posiada metodę Compile, która tworzy delegat o odpowiednim typie. Podobną metodę, ale w formie statycznej, do zwracania delegata typu TDelegate posiada Expression. Otrzymany w ten sposób delegat może być wykonany na ogólnych zasadach, tak jakby został utworzony ze zwykłej metody lub w inny podobny sposób. Tę koncepcję — przy użyciu tego samego wyrażenia co powyżej — pokazuje w działaniu listing 9.7. Listing 9.7. Kompilacja i uruchomienie drzewa wyrażeń Expression firstArg = Expression.Constant(2); Expression secondArg = Expression.Constant(3); Expression add = Expression.Add(firstArg, secondArg); Func compiled = Expression.Lambda>(add).Compile(); Console.WriteLine(compiled());

Listing 9.7 przedstawia chyba najbardziej zawiły i zarazem najbardziej imponujący sposób wyświetlania łańcucha 5, jaki można sobie wyobrazić. Tworzymy w sposób programistyczny pewne bloki logiczne i przedstawiamy je w formie zwykłych obiektów, a następnie prosimy środowisko o skompilowanie tego tworu do postaci rzeczywistego kodu, który może zostać wykonany. Być może nigdy nie będziesz musiał korzystać

292

ROZDZIAŁ 9

Wyrażenia lambda i drzewa wyrażeń

z drzew wyrażeń w ten sposób, a nawet w ogóle budować ich w sposób programistyczny, ale ta wiedza pomoże Ci lepiej zrozumieć zasady działania LINQ. Zgodnie z tym, co powiedziałem na początku tej sekcji, drzewa wyrażeń nie różnią się zbytnio od CodeDOM — przykładem może być Snippy, który kompiluje i wykonuje kod C# wprowadzony jako zwykły tekst. Niemniej pomiędzy tymi mechanizmami istnieją dwie zasadnicze różnice. Po pierwsze, w .NET 3 5 drzewa wyrażeń mogły reprezentować wyłącznie pojedyncze wyrażenia. Nie zostały one zaprojektowane dla całych klas, metod czy nawet grup wyrażeń. Sytuacja zmieniła się odrobinę w .NET 4, gdzie drzewa wyrażeń biorą udział w obsłudze typów dynamicznych — w tej wersji możesz tworzyć bloki, przypisywać wartości do zmiennych itd. Nadal istnieją jednak jeszcze duże ograniczenia w porównaniu do CodeDOM. Po drugie, C# obsługuje drzewa wyrażeń bezpośrednio w języku poprzez wyrażenia lambda. Przyjrzyjmy się teraz temu tematowi.

9.3.3. Konwersja wyrażeń lambda C# na drzewa wyrażeń Jak już widzieliśmy, wyrażenia lambda mogą być jawnie lub niejawnie konwertowane na odpowiednie instancje delegatów. Nie jest to jedyna możliwa konwersja. Możesz również poprosić kompilator o zbudowanie z Twojej lambdy drzewa wyrażeń i utworzenie w czasie wykonania instancji typu Expression. Dla przykładu kolejny listing (9.8) pokazuje o wiele prostszą wersję tworzenia wyrażenia return 5 z jego jednoczesną kompilacją i uruchomieniem. Listing 9.8. Użycie wyrażenia lambda do stworzenia drzewa wyrażeń Expression> return5 = () => 5; Func compiled = return5.Compile(); Console.WriteLine(compiled());

W pierwszym wierszu listingu 9.8 część () => 5 jest wyrażeniem lambda. Zauważ, że nie potrzebujemy żadnych rzutowań, ponieważ kompilator jest w stanie zweryfikować wszystko w trakcie kompilacji. Moglibyśmy napisać 2+3 zamiast 5, ale kompilator i tak zoptymalizowałby to wyrażenie. Najważniejszą rzeczą w tym przykładzie jest to, że wyrażenie lambda zostało przekonwertowane na drzewo wyrażeń. SĄ PEWNE OGRANICZENIA. Nie wszystkie wyrażenia lambda mogą być przekonwertowane na drzewa wyrażeń. Nie możesz przekonwertować lambdy zawierającej blok wyrażeń (nawet z pojedynczym punktem wyjścia) — musi ona mieć postać, która wylicza pojedyncze wyrażenie, i nie może zawierać przypisań. Są to najbardziej znane ograniczenia, ale nie jedyne — nie będziemy jednak przytaczać tutaj pełnej listy, ponieważ są to przypadki dość rzadkie. Jeżeli pojawi się problem w trakcie zamierzonej konwersji, dowiesz się o nim w czasie kompilacji. Ograniczenie dotyczące konwertowania wyłącznie pojedynczego wyrażenia ma zastosowanie nawet w środowisku .NET 4 z jego rozszerzonymi możliwościami dotyczącymi drzew wyrażeń. Być może przyszła wersja C# będzie bardziej liberalna odnośnie do rodzajów lambd możliwych do przekształcenia, jednak w chwili pisania tej książki żadna informacja na ten temat nie została ogłoszona.

Drzewa wyrażeń

293

Przyjrzyjmy się bardziej skomplikowanemu przykładowi, aby się przekonać, jak działa cały mechanizm, szczególnie w odniesieniu do parametrów. Tym razem napiszemy predykat przyjmujący dwa łańcuchy i sprawdzający, czy pierwszy z nich rozpoczyna się od drugiego. Kod sprawdzający zapisany w postaci wyrażenia lambda jest naprawdę prosty, o czym świadczy kolejny listing (9.9). Listing 9.9. Przykład bardziej złożonego wyrażenia lambda Expression> expression = (x, y) => x.StartsWith(y); var compiled = expression.Compile(); Console.WriteLine(compiled("Pierwszy", "Drugi")); Console.WriteLine(compiled("Pierwszy", "Pier"));

Drzewo wyrażeń samo w sobie jest bardziej skomplikowane, szczególnie kiedy konwertujemy je na instancję LambdaExpression. Kolejny listing (9.10) pokazuje, jak moglibyśmy zbudować to drzewo bezpośrednio w kodzie. Listing 9.10. Budowanie bezpośrednio w kodzie drzewa wyrażeń reprezentującego wywołanie metody MethodInfo method = typeof(string).GetMethod ("StartsWith", new[] { typeof(string) }); var target = Expression.Parameter(typeof(string), "x"); var methodArg = Expression.Parameter(typeof(string), "y"); Expression[] methodArgs = new[] { methodArg }; Expression call = Expression.Call(target, method, methodArgs); var lambdaParameters = new[] { target, methodArg }; var lambda = Expression.Lambda> (call, lambdaParameters); var compiled = lambda.Compile();

Budowanie części składowych wywołania metody Utworzenie wyrażenia wywołania z części składowych Przekształcenie wywołania na instancję wyrażenia lambda

Console.WriteLine(compiled ("Pierwszy", "Drugi")); Console.WriteLine(compiled ("Pierwszy", "Pier"));

Jak widzisz, listing 9.10 jest bardziej skomplikowany od wersji z gotowym wyrażeniem lambda, ale przedstawia w sposób bardziej oczywisty elementy, z jakich składa się drzewo, oraz powiązane z nim parametry. Zaczynamy od wypracowania wszystkiego, co powinniśmy wiedzieć na temat wywołania metody, które tworzy ciało końcowego wyrażenia ( ). Są to cel metody (innymi słowy, łańcuch na którym wywołujemy Starts ´With), sama metoda (jako MethodInfo) i lista jej argumentów (w tym przypadku tylko jeden). Akurat tak się składa, że cel naszej metody i argument będą parametrami przekazywanymi do wyrażenia, ale równie dobrze mogłyby być innymi typami wyrażeń — stałymi, wynikami wywołania innych metod, wyliczeniami właściwości itp. Po zbudowaniu wywołania metody jako wyrażenia ( ) musimy przekonwertować je na wyrażenie lambda ( ), budując po drodze parametry. Używamy tych samych wartości typu ParameterExpression, które stworzyliśmy w ramach informacji o samym

294

ROZDZIAŁ 9

Wyrażenia lambda i drzewa wyrażeń

wywołaniu metody. Porządek, według którego zostały one wyspecyfikowane podczas tworzenia wyrażenia lambda, odpowiada kolejności, w jakiej zostaną użyte podczas wywołania samego delegata. To samo wyrażenie w sposób graficzny przedstawia rysunek 9.4. Jeżeli mielibyśmy być skrupulatni, nie jest to drzewo w najczystszym tego słowa znaczeniu, chociaż nadal nosi taką nazwę, ponieważ wyrażenia parametrów są przez nas używane wielokrotnie (musimy tak zrobić — gdybyśmy stworzyli nowe drzewo o tej samej nazwie i spróbowali je spiąć w przedstawiony sposób, otrzymalibyśmy wyjątek w czasie wykonania programu).

Rysunek 9.4. Graficzna reprezentacja utworzonego z lambdy drzewa wyrażeń wywołującego metodę z parametrami

Przyglądając się złożoności rysunku 9.4 i listingu 9.10 bez zagłębiania się w szczegóły, mógłbym Ci wybaczyć myśl, że robimy tutaj coś bardzo skomplikowanego jak na wywołanie pojedynczej metody. Chodzi jedynie o to, abyś sobie wyobraził złożoność prawdziwego drzewa wyrażeń i wyraził wdzięczność C# 3 za możliwość tworzenia ich z wyrażeń lambda!

Drzewa wyrażeń

295

Jest jeszcze jedna metoda przyglądania się drzewom wyrażeń — za pomocą będącego częścią Visual Studio 2010 narzędzia do wizualizacji drzew wyrażeń7. Może to być przydatne, jeśli próbujesz dojść do tego, jak zbudować drzewo wyrażeń w kodzie, i chcesz uchwycić postać tego drzewa. Napisz wyrażenie lambda realizujące wymagane przez Ciebie zadanie, używając pewnych przykładowych danych, przyjrzyj się jego wizualizacji w debuggerze i na tej podstawie wywnioskuj, jak zbudować podobne drzewa korzystające z rzeczywistych informacji zawartych w Twoim kodzie. Wizualizator bazuje na zmianach zawartych w .NET 4, zatem nie będzie działał z projektami przeznaczonymi dla .NET 3 5. Rysunek 9 5 przedstawia wizualizację dla naszego przykładu z metodą StartsWith.

Rysunek 9.5. Wizualizacja drzewa wyrażeń w programie debugującym

Części .Lambda i .Call w wizualizacji odpowiadają naszym wywołaniom Expression. ´Lambda i Expression.Call, zaś $x i $y to parametry wyrażeń. Wizualizacja wygląda jednakowo, niezależnie od tego, czy drzewo wyrażeń zostało utworzone jawnie przez kod programu, czy przy użyciu wyrażenia lambda. Warto zwrócić uwagę, że chociaż kompilator C# buduje drzewa wyrażeń w skompilowanym kodzie, używając kodu podobnego do tego z listingu 9.10, posiada w zanadrzu jeden skrót: nie musi stosować zwykłej refleksji, aby uzyskać MethodInfo dla string.StartsWith. Zamiast tego stosuje metodę będącą odpowiednikiem operatora typeof. Jest to możliwe wyłącznie w kodzie IL (tego efektu nie można osiągnąć w samym C#). Taki sam operator jest również używany do stworzenia instancji delegatów z grup metod. Teraz, kiedy wiemy już, na czym polega powiązanie pomiędzy drzewami wyrażeń i lambdami, przekonajmy się, skąd się bierze ich użyteczność.

7

Jeżeli używasz Visual Studio 2008, możesz pobrać przykładowy kod i zbudować podobne narzędzie (zobacz http://mng.bz/g6xd), chociaż o wiele prościej będzie użyć narzędzia dystrybuowanego razem z Visual Studio 2010.

296

ROZDZIAŁ 9

Wyrażenia lambda i drzewa wyrażeń

9.3.4. Drzewa wyrażeń w sercu LINQ Bez wyrażeń lambda drzewa wyrażeń miałyby względnie małą wartość. Byłyby jedynie alternatywą dla CodeDOM w przypadkach, kiedy chciałbyś zamodelować wyłącznie pojedyncze wyrażenie zamiast grupy wyrażeń, metod, typów itd. — jednak zysk byłby nadal ograniczony. Do pewnego stopnia prawdziwa jest również sytuacja odwrotna: bez drzew wyrażeń lambdy byłyby zdecydowanie mniej użyteczne. Posiadanie bardziej zwięzłej metody tworzenia instancji delegatów byłoby nadal mile widziane, a przesunięcie w kierunku bardziej funkcjonalnego modelu tworzenia oprogramowania nadal opłacalne. Wyrażenia lambda są szczególnie użyteczne, kiedy zostaną połączone z metodami rozszerzającymi, o czym przekonamy się w kolejnym rozdziale. Jednak o wiele bardziej interesująca sytuacja ma miejsce, gdy na scenie pojawiają się drzewa wyrażeń. Co zatem zyskujemy, łącząc wyrażenia lambda, drzewa wyrażeń i metody rozszerzające? Odpowiedź to (w przybliżeniu) językowa część LINQ. Dodatkowa składnia, którą zobaczymy w rozdziale 11., to tylko lukier — technologię można by uznać za kompletną wyłącznie w oparciu o te trzy składniki. Przez długi czas mielibyśmy ładny mechanizm sprawdzania na etapie kompilacji lub zdolność przekazania innej platformie polecenia wykonania pewnego kodu, zwykle wyrażonego jako tekst (najbardziej oczywistym przykładem są tutaj zapytania SQL). Nie moglibyśmy mieć obu rzeczy w tym samym czasie. Łącząc wyrażenia lambda umożliwiające sprawdzenia na poziomie kompilacji i drzewa wyrażeń, które wprowadzają warstwę abstrakcji pomiędzy model wykonania a oczekiwaną logikę, możemy uzyskać najlepsze możliwe połączenie obu tych światów (w granicach rozsądku). Sercem pozaprocesowych dostawców LINQ jest pomysł, według którego możemy stworzyć drzewo wyrażeń w znanym nam języku źródłowym (w tym przypadku C#) i wykorzystać powstały wynik jako format pośredni, który może być następnie przekonwertowany na język natywny platformy docelowej — dla przykładu SQL. W pewnych przypadkach może nie istnieć prosty język natywny, a jedynie pewne API platformy — dobrym zobrazowaniem tej sytuacji jest wykonywanie różnorodnych wywołań usług sieciowych w zależności od tego, co reprezentuje dane drzewo wyrażeń. Rysunek 9.6 pokazuje różne ścieżki LINQ dla Obiektów i LINQ dla SQL-a. W niektórych przypadkach podczas konwersji może dojść do próby wykonania całej logiki na platformie docelowej, podczas gdy inne przypadki mogą używać mechanizmu kompilacji drzew wyrażeń do wykonania części wyrażenia lokalnie i części w innym miejscu. Wybranym szczegółom etapu konwersji przyjrzymy się w rozdziale 12., ale teraz istotne jest, abyś zapamiętał cel końcowy, gdyż ta wiedza przyda nam się, kiedy będziemy się zajmować metodami rozszerzającymi i składnią LINQ w rozdziałach 10. i 11. NIE WSZYSTKIE SPRAWDZENIA MOGĄ BYĆ WYKONANE PRZEZ KOMPILATOR. Kiedy drzewa wyrażeń są analizowane przez jakiś konwerter, pewne przypadki muszą zostać odrzucone. Dla przykładu możliwe jest przekonwertowanie wszystkich wywołań string.StartsWith na podobne wyrażenie SQL, ale wywołanie string.IsInterned8 nie ma sensu w środowisku bazy danych. 8

IsInterned wyszukuje zadany łańcuch w puli łańcuchów internowanych i, jeśli ten istnieje, zwraca referencję

do jego instancji — przyp. tłum.

Drzewa wyrażeń

297

Rysunek 9.6. LINQ dla Obiektów i LINQ dla SQL-a zaczynają od kodu C#, a kończą na wynikach zapytań. Zdalne wykonanie kodu jest możliwe dzięki drzewom wyrażeń

Drzewa wyrażeń dają duże bezpieczeństwo czasu kompilacji, ale kompilator jest w stanie stwierdzić jedynie, czy wyrażenie lambda może być przekonwertowane na poprawne drzewo wyrażeń. Nie jest w stanie sprawdzić, czy to drzewo wyrażeń nadaje się do ewentualnego użycia. Chociaż drzewa wyrażeń są najczęściej stosowane w kontekście LINQ, istnieją również inne przypadki użycia...

9.3.5. Drzewa wyrażeń poza LINQ Bjarne Stroustrup powiedział kiedyś: „Chciałbym zbudować narzędzie, które mogłoby robić jedynie to, co byłem w stanie dla niego przewidzieć”. Chociaż drzewa wyrażeń zostały wprowadzone do .NET głównie na potrzeby LINQ, od tego czasu zarówno środowisko programistów, jak i Microsoft znaleźli dla nich również inne zastosowania. Niniejsza sekcja nie przedstawia tego tematu w sposób całościowy, ale pozwoli Ci przeanalizować kilka sytuacji, w których drzewa wyrażeń mogą się okazać pomocne. Optymalizacja dynamicznego środowiska wykonania O DLR (ang. Dynamic Language Runtime) będziemy mówić znacznie szerzej w rozdziale 14., kiedy zajmiemy się typami dynamicznymi w C#. Teraz zaznaczę jedynie, że drzewa wyrażeń stanowią jądro tej architektury. Mają one trzy właściwości pożądane z punktu widzenia DLR: Są niezmienne, więc można je bezpiecznie przechowywać w pamięci podręcznej. Przy ich użyciu można budować skomplikowane zachowanie w oparciu o proste bloki jednostkowe. Mogą być przekształcane na delegaty, które są następnie kompilowane zwykłą drogą przez JIT na kod natywny.

298

ROZDZIAŁ 9

Wyrażenia lambda i drzewa wyrażeń

DLR musi podejmować decyzje dotyczące sposobu obsługi różnorodnych wyrażeń w sytuacji, kiedy znaczenie może ulegać subtelnym zmianom w zależności do szeregu zasad. Drzewa wyrażeń pozwalają na przekształcenie tych zasad (i wyników) do postaci kodu bardzo podobnego do tego, jaki napisałbyś ręcznie, gdybyś znał wszystkie te zasady i wyniki. Jest to bardzo funkcjonalna koncepcja, pozwalająca na zaskakująco szybkie wykonanie kodu dynamicznego. Referencje odporne na refaktoryzację W sekcji 9.3.3 wspomniałem, że kompilator może tworzyć referencje do wartości typu MethodInfo w sposób podobny do zachowania operatora typeof. Niestety, C# nie posiada takiej samej możliwości, co oznacza, że jedynym sposobem przekazania danemu, bazującemu na refleksji, fragmentowi kodu, aby „używał właściwości o nazwie BirthDate, zdefiniowanej w moim typie”, było użycie literału łańcuchowego, a następnie zadbanie o to, aby wraz ze zmianą nazwy właściwości został zmodyfikowany także ten literał. Używając C# 3, możesz z pomocą lambdy zbudować odpowiednie drzewo wyrażeń reprezentujące referencję do tej właściwości. Dana metoda może wtedy dokonać analizy drzewa wyrażeń i wywnioskować właściwość, którą masz na myśli. Mając tę informację, moglibyśmy zrobić z nią, co tylko nam się podoba, łącznie ze skompilowaniem tego drzewa wyrażeń do postaci delegata i użyciem go w sposób bezpośredni. Stosując tę zasadę, mógłbyś na przykład napisać: serializationContext.AddProperty(x => x.BirthDate);

Kontekst serializacyjny wiedziałby wtedy, że Twoim zamiarem jest serializowanie właściwości BirthDate, i mógłby zapisać odpowiednie metadane, a także odebrać wartość. Serializacja jest tylko jednym z obszarów, w którym może się przydać referencja metody lub właściwości — jest to w miarę popularne podejście w kodzie sterowanym przez refleksję. Jeśli później postanowisz zmienić nazwę właściwości z BirthDate na DateOfBirth, wyrażenie lambda również ulegnie zmianie. Oczywiście, rozwiązanie to nie jest całkowicie niezawodne — nie ma sprawdzenia czasu kompilacji, które stwierdziłoby, że faktycznie jest używana prosta właściwość. Taka weryfikacja powinna być przeprowadzona w czasie wykonania wewnątrz metody AddProperty. Być może pewnego dnia C# zyska możliwość wykonywania takich operacji wewnątrz kodu. Nadano już nawet nazwę odpowiedniemu operatorowi — ma to być infoof, co można wymawiać, w zależności od Twojego humoru, jako „info-of” lub „in-foof”. Ta funkcjonalność „wisi” już od jakiegoś czasu na utrzymywanej przez zespół C# liście potencjalnych cech — nie dziwi zatem fakt, że Eric Lippert pisze na ten temat na swoim blogu (zobacz http://mng.bz/24y7) — ale wciąż nie trafiła do żadnej oficjalnej wersji języka. Może stanie się to w C# 5. Prosta refleksja Ostatni przypadek użycia, jaki chcę opisać, zanim zagłębimy się w mroki wnioskowania typów, dotyczy również refleksji. Tak jak wspomniałem w rozdziale 3., operatory arytmetyczne niezbyt dobrze współgrają z generykami, co utrudnia pisanie kodu generycznego, który, powiedzmy, dodaje serię wartości. Marc Gravell skorzystał, z dużym

Zmiany we wnioskowaniu typów i rozwiązywaniu przeciążeń

299

powodzeniem, z drzew wyrażeń do stworzenia generycznej klasy Operator i niegenerycznej klasy pomocniczej, które umożliwiają między innymi napisanie następującego kodu: T runningTotal = initialValue; foreach (T element in values) { runningTotal = Operator.Add(runningTotal, element); }

Ten kod będzie działał nawet w przypadkach, kiedy wartości mają inny typ od wyniku końcowego, na przykład przy dodawaniu sekwencji wartości typu TimeSpan do zmiennej typu DateTime. Można spróbować zrobić to w C# 2, ale byłoby to zdecydowanie bardziej zawiłe ze względu na sposób udostępniania operatorów przez refleksję, w szczególności dla typów prymitywnych. Drzewa wyrażeń pozwalają na w miarę czystą implementację tej „magii”, a fakt, iż są one kompilowane do zwykłego kodu IL, który następnie trafia do JIT, zapewnia dużą wydajność rozwiązania. Jest to tylko kilka przykładów i bez wątpienia istnieje całe grono programistów zajętych tworzeniem zupełnie odmiennych rozwiązań. Powyższe przykłady kończą bezpośredni opis wyrażeń lambda i drzew wyrażeń. Znacznie większą ich obfitość znajdziemy przy okazji omawiania LINQ, ale zanim się tym zajmiemy, jest jeszcze kilka zmian w C#, które wymagają dodatkowego wyjaśnienia. Są to zmiany w systemie typów oraz w algorytmie wybierania metod przeciążonych przez kompilator.

9.4.

Zmiany we wnioskowaniu typów i rozwiązywaniu przeciążeń W C# 3 zmianie uległy kroki związane z wnioskowaniem typów i rozwiązywaniem przeciążeń. Jest to związane z wprowadzeniem wyrażeń lambda i usprawnieniem metod anonimowych. Nie są to elementy, które należy traktować jako nowe cechy języka C#, ale warto o nich wiedzieć, aby mieć świadomość, jak się zachowa kompilator. Jeśli uznasz tego typu szczegóły za nudne lub nieistotne, możesz spokojnie przejść do podsumowania rozdziału. Nie zapomnij jednak, że ta sekcja istnieje, abyś mógł do niej wrócić, kiedy napotkasz związany z tym tematem błąd kompilacji i nie będziesz w stanie zrozumieć, dlaczego Twój kod nie chce działać. (Innym powodem do powrotu w to miejsce będzie sytuacja, kiedy Twój kod będzie się kompilował, a Twoim zdaniem nie powinien). Pomimo dodania tej sekcji nie zamierzam w niej zagłębiać się w najdrobniejsze detale — od tego jest specyfikacja języka (szczegóły znajdują się w sekcji 7 5.2 specyfikacji C# 4). Zamiast tego omówię ogólnie nowe zachowanie i przedstawię przykłady najczęstszych przypadków. Głównym powodem do zmiany specyfikacji jest umożliwienie działania wyrażeń lambda w spójny sposób. Dlatego też umieściłem ten temat w tym rozdziale. Przyjrzyjmy się, jakiego typu problemów moglibyśmy się spodziewać, gdyby zespół C# pozostał przy starych zasadach.

Zmiany we wnioskowaniu typów i rozwiązywaniu przeciążeń

301

W naszym przypadku te reguły uniemożliwiłyby nam znalezienie typów TInput i TOutput dla drugiego argumentu, co doprowadziłoby do nieudanej kompilacji. Ostateczny cel, jaki chcemy osiągnąć, to zrozumienie mechanizmu, który pozwala na skompilowanie listingu 9.11 w C# 3 (obiecuję, że jest to możliwe), zaczniemy jednak od czegoś prostszego.

9.4.2. Wnioskowanie typu zwracanego funkcji anonimowych Kolejny listing (9.12) przedstawia przykład kodu, który powinien się kompilować, ale nie robi tego ze względu na reguły wnioskowania typów obowiązujące w C# 2. Listing 9.12. Próba wywnioskowania typu zwracanego metody anonimowej delegate T MyFunc();

Deklaracja typu delegatowego. W .NET 2.0 nie ma Func

static void WriteResult(MyFunc function) Deklaracja { metody generycznej Console.WriteLine(function()); z parametrem typu } Wymaga ... wnioskowania WriteResult(delegate { return 5; }); typu dla T

Próba kompilacji listingu 9.12 w C# 2 kończy się następującym błędem9: error CS0411: Argumentów typu dla metody "Snippet.WriteResult(Snippet.MyFunc)" nie można wywnioskować na podstawie użytkowania. Spróbuj jawnie określić argumenty typu.

Błąd ten możemy naprawić na dwa sposoby: zgodnie z tym, co sugeruje kompilator, możemy podać jawny argument typu, ale możemy też zrzutować metodę anonimową na konkretny typ delegata: WriteResult(delegate { return 5; }; WriteResult((MyFunc)delegate { return 5; });

Oba wywołania działają, ale są brzydkie. Chcielibyśmy, aby kompilator wykonał taki sam rodzaj wnioskowania typu jak w przypadku typów niedelegatowych, używając typu wyrażenia zwracającego wynik do wywnioskowania typu T. Dokładnie to C# 3 robi dla metod anonimowych i wyrażeń lambda — jest jednak pewien haczyk. Chociaż w wielu przypadkach istnieje tylko jedno wyrażenie zwracające wartość, czasem może być ich kilka. Kolejny listing (9.13) — będący lekko zmodyfikowaną wersją listingu 9.12 — przedstawia metodę, która czasem zwraca wartość całkowitą, a czasem obiekt. W tej sytuacji kompilator używa tej samej logiki do określenia typu zwracanego jak w przypadku tablic o typie niejawnym, które zostały opisane w podrozdziale 8.4.

9

Błąd ten może być trudny do uzyskania podczas kompilacji w Visual Studio, np. Visual Studio 2010 Express nie pokaże tego błędu, nawet jeśli w projekcie ustawimy jako środowisko docelowe .NET Framework 2.0. Najlepszym sposobem uzyskania tego błędu jest kompilacja bezpośrednio w wierszu poleceń przy użyciu kompilatora z drugiej wersji środowiska — przyp. tłum.

302

ROZDZIAŁ 9

Wyrażenia lambda i drzewa wyrażeń Listing 9.13. Kod zwracający wartość całkowitą lub obiekt, w zależności od pory dnia delegate T MyFunc(); static void WriteResult(MyFunc function) { Console.WriteLine(function()); } ... WriteResult(delegate { if (DateTime.Now.Hour < 12) { Typem zwracanym jest int return 10; } else { Typem zwracanym jest object return new object(); } });

Formuje zbiór wszystkich typów na podstawie wyrażeń zwracających wartość, zawartych w ciele funkcji anonimowej10 (w tym przypadku int i object), i sprawdza, czy jeden z nich może być osiągnięty przez niejawną konwersję wszystkich pozostałych. Istnieje niejawna konwersja z int na object (przez opakowywanie), ale nie z object na int, zatem wnioskowanie kończy się sukcesem dla typu object jako wypracowanego typu zwracanego. Jeżeli nie ma typów spełniających powyższe kryterium (lub istnieje więcej niż jeden taki typ), żaden typ nie może zostać wywnioskowany i zgłaszany jest błąd kompilacji. Wiemy już zatem, jak wypracować typ zwracany funkcji anonimowej, ale co zrobić z wyrażeniami lambda, w przypadku których typy parametrów mogą być zdefiniowane w sposób niejawny?

9.4.3. Dwufazowe wnioskowanie typu Szczegóły wnioskowania typów w C# 3 są o wiele bardziej skomplikowane niż w C# 2. Jest raczej mało prawdopodobne, abyś kiedykolwiek musiał się odwoływać do specyfikacji w celu określenia dokładnego zachowania, ale jeśli jednak tak się zdarzy, proponuję, abyś zapisał wszystkie typy parametrów, argumentów itp. na kartce, a następnie prześledził krok po kroku specyfikację, notując szczegółowo każde wymagane działanie. Uzyskasz w ten sposób tabelę określonych i nieokreślonych zmiennych typu, z których każda posiada własny zestaw ograniczeń. Przez określoną zmienną typu należy rozumieć zmienną, dla której kompilator określił już wartość, w przeciwnym wypadku jest ona nieokreślona. Ograniczenie jest pewną informacją dotyczącą zmiennej typu. Przypuszczam, że oprócz notatek czeka Cię jeszcze ból głowy — analizowanie tego mechanizmu nie jest niczym przyjemnym. 10

W zbiorze nie są uwzględniane wyrażenia nieposiadające typu, takie jak null, ani inne wyrażenia lambda. Ich poprawność jest sprawdzana później, kiedy została już podjęta decyzja o wyborze typu zwracanego, ale one same nie biorą udziału w podejmowaniu tej decyzji.

Zmiany we wnioskowaniu typów i rozwiązywaniu przeciążeń

303

Ja zamierzam przedstawić mniej szczegółowy sposób myślenia o wnioskowaniu typów, taki, który będzie Ci służył z powodzeniem niemal w takim samym stopniu jak znajomość samej specyfikacji, ale będzie o wiele łatwiejszy. Jeżeli kompilator nie wykonuje wnioskowania typu w przewidziany przez Ciebie sposób, niemal na pewno doprowadzi to do błędu kompilatora, a nie do zbudowania kodu, który następnie będzie się zachowywał w nieprawidłowy sposób. Cała reguła przedstawia się zatem tak: jeśli kompilator nie chce zbudować Twojego kodu, spróbuj dostarczyć mu więcej informacji. Przedstawmy pokrótce, co zmieniło się w C# 3. Pierwsza duża różnica to traktowanie przez C# 3 argumentów metody jako całego zespołu. W C# 2 każdy argument był używany samodzielnie przy próbie dokładnego „namierzenia” typu parametru, a kompilator zgłaszał zastrzeżenia, jeśli dla jakichkolwiek dwóch argumentów były znajdowane inne wyniki (w odniesieniu do tego samego typu parametru), nawet jeśli były one ze sobą kompatybilne. W C# 3 argumenty mogą dostarczać fragmenty informacji, czyli typy, które muszą być niejawnie przekonwertowane na końcową określoną wartość danej zmiennej typu. Logika stosowana przy wypracowywaniu tej końcowej wartości jest taka sama jak w przypadku wnioskowania typu wartości zwracanej i tablic o typie niejawnym. Przykład takiego zachowania pokazuje listing 9.14 (nie korzystamy w nim z żadnych wyrażeń lambda ani metod anonimowych). Listing 9.14. Elastyczne wnioskowanie typów łączące informacje z różnych argumentów static void PrintType(T first, T second) { Console.WriteLine(typeof(T)); } ... PrintType(1, new object());

Kod z listingu 9.14 nie zbuduje się w C# 2, chociaż jest syntaktycznie poprawny. Nie pozwoli na to mechanizm wnioskowania typów, ponieważ przy pierwszym parametrze zdecyduje, iż T powinien być typu int, natomiast przy drugim, że T powinien być typu object. W C# 3 kompilator stwierdzi, że T powinien być typu object, w taki sam sposób, w jaki zrobił to dla typu zwracanego na listingu 9.13. Reguły rządzące wnioskowaniem typu zwracanego są w praktyce jednym z bardziej ogólnych procesów w C# 3. Druga zmiana to wykonywanie wnioskowania w dwóch fazach. Pierwsza faza zajmuje się zwykłymi argumentami, których typy są znane od początku. Dotyczy to również metod anonimowych z listą parametrów o typie jawnym. Druga faza obejmuje wnioskowanie typów dla wyrażeń lambda i grup metod o typie niejawnym. Idea polega na tym, aby sprawdzić, czy zebrane do tej pory informacje są wystarczające, aby wypracować typy parametrów wyrażenia lambda (lub grupy metod). Jeżeli tak, kompilator sprawdza następnie ciało wyrażenia lambda, aby wypracować typ zwracany, który zazwyczaj jest jednym z szukanych przez nas typów parametrów. Jeżeli druga faza dostarczy odrobinę więcej informacji, wykonujemy ją jeszcze raz, powtarzając tak długo, aż skończą nam się wskazówki lub wypracujemy typy wszystkich potrzebnych parametrów. Rysunek 9.7 pokazuje ten algorytm w formie schematu blokowego — pamiętaj, proszę, że jest to mocno uproszczona wersja algorytmu.

304

ROZDZIAŁ 9

Wyrażenia lambda i drzewa wyrażeń Rysunek 9.7. Przepływ dwuetapowego wnioskowania typów

Spójrzmy na dwa przykłady obrazujące cały algorytm. Zaczniemy od kodu, którym rozpoczęliśmy ten podrozdział (listing 9.11): static void PrintConvertedValue (TInput input, Converter converter) { Console.WriteLine(converter(input)); } ... PrintConvertedValue("Jestem łańcuchem", x => x.Length);

Parametry typów, które musimy wypracować na listingu 9.11, to TInput i TOutput. Algorytm poszukiwania przedstawia się następująco: 1. Początek fazy 1. 2. Pierwszy parametr jest typu TInput, a pierwszy argument — typu string. Wnioskujemy, że musi istnieć niejawna konwersja z string na TInput.

Zmiany we wnioskowaniu typów i rozwiązywaniu przeciążeń

305

3. Drugi parametr jest typu Converter, a drugi argument jest wyrażeniem lambda o typie niejawnym. Nie można przeprowadzić wnioskowania, ponieważ mamy za mało informacji. 4. Początek fazy 2. 5. TInput nie zależy od żadnych nieustalonych parametrów typu, zatem zostaje ustalony jako string. 6. Drugi argument posiada teraz ustalony typ wejściowy i nieustalony typ wyjściowy. Możemy traktować go teraz jako (string x) => x.Length i wywnioskować, iż typem zwracanym jest int. 7. Powtórzenie fazy 2. 8. TOutput nie zależy od czegokolwiek nieustalonego, zatem zostaje ustalony jako int. 9. Nie ma innych nieustalonych parametrów typu, zatem wnioskowanie kończy się sukcesem. Trochę skomplikowane, ale mimo wszystko działa — wynik jest zgodny z naszymi oczekiwaniami (TInput=string, TOutput=int) i wszystko kompiluje się bez problemów. Znaczenie drugiej fazy najlepiej będzie pokazać za pomocą innego przykładu. Listing 9.15 pokazuje wykonanie dwóch konwersji, przy czym wynik pierwszej z nich staje się parametrem wejściowym drugiej. Do momentu wypracowania typu wyjściowego pierwszej konwersji nie będziemy znali typu wejściowego drugiej z nich, zatem nie będziemy mogli wywnioskować jej typu wyjściowego. Listing 9.15. Wielostopniowe wnioskowanie typów static void ConvertTwice (TInput input, Converter firstConversion, Converter secondConversion) { TMiddle middle = firstConversion(input); TOutput output = secondConversion(middle); Console.WriteLine(output); } ... ConvertTwice("Kolejny łańcuch", text => text.Length, length => Math.Sqrt(length));

Pierwszą rzeczą, którą zauważamy, jest dosyć monstrualna sygnatura samej metody. Kiedy przełamiemy lęk i przyjrzymy się jej dokładnie, nie wygląda już tak źle. Zdecydowanym ułatwieniem w analizie jest przykład jej użycia. Bierzemy łańcuch i wykonujemy na nim konwersję, tę samą, którą robiliśmy wcześniej — obliczenie długości łańcucha. Następnie bierzemy tę długość (jako int) i wyliczamy jej pierwiastek kwadratowy (jako double). Pierwsza faza wnioskowania mówi kompilatorowi, że musi istnieć konwersja z typu string na TInput. Pierwsze przejście przez fazę drugą ustala TInput na string i dochodzimy do wniosku, że musi istnieć konwersja z int na TMiddle. Przy drugim przejściu fazy 2. parametr TMiddle jest ustalany jako int i dochodzimy do wniosku, że musi istnieć

306

ROZDZIAŁ 9

Wyrażenia lambda i drzewa wyrażeń

konwersja z double na TOutput. Przy trzecim przejściu fazy 2. TOutput jest ustalany na double i wnioskowanie typów kończy się sukcesem. Po zakończeniu wnioskowania kompilator może się w odpowiedni sposób przyjrzeć zawartości wyrażenia lambda. SPRAWDZENIE CIAŁA WYRAŻENIA LAMBDA. Ciało wyrażenia lambda nie może być sprawdzone do momentu, kiedy nie zostaną poznane typy parametrów wejściowych. Wyrażenie lambda x => x.Length jest poprawne, jeśli x jest tablicą lub łańcuchem, ale w wielu innych przypadkach ma błędną postać. Nie jest to problemem, kiedy typy parametrów są wyrażone jawnie, ale przy liście parametrów niejawnych kompilator musi wstrzymać się z analizowaniem znaczenia wyrażenia lambda do momentu, kiedy przeprowadzi poprawne wnioskowanie typów. Powyższe przykłady pokazują pojedynczą zmianę w każdym przebiegu — w praktyce możliwa jest sytuacja, kiedy znanych jest kilka różnych informacji odnośnie do kilku różnych zmiennych typu, być może odkrytych w różnych iteracjach całego procesu. Ze względu na Twoje (i moje) zdrowie nie zamierzam prezentować bardziej skomplikowanych przypadków — liczę na to, że zrozumiałeś ogólny mechanizm działania, nawet jeśli szczegóły pozostają mgliste. Chociaż może się wydawać, że tego typu sytuacje będą się pojawiać na tyle rzadko, iż posiadanie tak skomplikowanego mechanizmu nie jest warte zachodu, w rzeczywistości są one bardzo powszechne w C# 3, szczególnie w LINQ. Może się okazać, że zaczniesz korzystać z wnioskowania typów na dużą skalę, nie będąc nawet tego świadomym — stanie się to Twoją drugą naturą. Jeśli wnioskowanie zawiedzie, a Ty będziesz się zastanawiał dlaczego, zawsze możesz powrócić do tej sekcji lub do specyfikacji języka. Do przeanalizowania pozostała nam jeszcze jedna rzecz. Zapewne z ulgą dowiesz się, że jest ona łatwiejsza od wnioskowania typów. Przyjrzyjmy się przeciążaniu metod.

9.4.4. Wybieranie odpowiedniego przeciążenia metody Przeciążanie ma miejsce, kiedy istnieje wiele metod dostępnych pod tą samą nazwą, ale z różnymi sygnaturami. Czasami wskazanie odpowiedniej metody jest bardzo łatwe, ponieważ jest tylko jedna z odpowiednią liczbą parametrów lub jedna, której wszystkie argumenty mogą być przekonwertowane na odpowiednie typy parametrów. Ta podchwytliwa część pojawia się, kiedy istnieje kilka metod, które mogą być odpowiednie. Reguły w sekcji 7.5.3 specyfikacji są (tak, ponownie) całkiem skomplikowane, ale kluczowym elementem jest sposób konwertowania każdego typu argumentu na typ parametru11. Rozważmy dla przykładu dwie następujące metody, tak jakby były one zadeklarowane w tej samej klasie: void Write(int x); void Write(double y);

Ponieważ nie ma niejawnej konwersji z double na int, znaczenie wywołania Write(1.5) jest oczywiste, ale wywołanie Write(1) jest bardziej podchwytliwe. Istnieje niejawna 11

Zakładam, że wszystkie metody są zadeklarowane w tej samej klasie. Kiedy w grę wchodzi dodatkowo dziedziczenie, całość staje się jeszcze bardziej skomplikowana. Jednak ten aspekt nie zmienił się w C# 3.

Zmiany we wnioskowaniu typów i rozwiązywaniu przeciążeń

307

konwersja z int na double, zatem obie metody są możliwe. W tym momencie kompilator rozważa konwersję z int na int i z int na double. Konwersja z dowolnego typu na ten sam typ jest uznawana za lepszą od konwersji na inny typ, zatem dla tego specyficznego wywołania metod Write(int x) jest lepsza od Write(double y). Przy kilku parametrach kompilator musi się upewnić, która metoda nadaje się najlepiej dla danego wywołania. Dana metoda jest lepsza od innych, jeśli wszystkie zastosowane konwersje argumentów są przynajmniej tak dobre co odpowiadające im konwersje w innej metodzie, a przynajmniej jedna z nich musi być lepsza. Przekładając to na przykład, weźmy takie metody: void Write(int x, double y) void Write(double x, int y)

Wywołanie Write(1, 1) byłoby niejednoznaczne i kompilator wymusiłby na Tobie dodanie rzutowania do przynajmniej jednego parametru, aby uściślić, którą metodę chciałeś faktycznie wywołać. Każde przeciążenie posiada tylko jedną lepszą konwersję argumentu, zatem żadna z nich nie okazuje się lepsza. Ta logika obowiązuje nadal w C# 3, ale z jedną dodatkową zasadą dotyczącą funkcji anonimowych, które nie specyfikują typu zwracanego. W tym przypadku (zgodnie z tym, co powiedzieliśmy w sekcji 9.4.2) wywnioskowany typ zwracany jest znajdowany według zasady lepszej konwersji. Przyjrzyjmy się przykładowej sytuacji, która wymaga nowej zasady. Kolejny listing (9.16) zawiera dwie metody o tej samej nazwie — Execute — oraz wywołanie z użyciem wyrażenia lambda. Listing 9.16. Przykład wyboru przeciążenia metody na podstawie typu zwracanego delegata static void Execute(Func action) { Console.WriteLine("akcja zwraca int: " + action()); } static void Execute(Func action) { Console.WriteLine("akcja zwraca double: " + action()); } ... Execute(() => 1);

Wywołanie metody Execute na listingu 9.16 mogłoby być zapisane z użyciem metody anonimowej lub grupy metod — niezależenie od typu konwersji obowiązują te same zasady. Która metoda Execute powinna zostać zatem uruchomiona? Reguły przeciążania mówią, że kiedy obie metody mogą być użyte po zastosowaniu konwersji argumentów, sprawdzane są same konwersje w celu ustalenia, która z nich jest lepsza. Nie chodzi tutaj o konwersje ze zwykłego typu .NET na parametr typu, ale konwersje z wyrażenia lambda na dwa różne typy delegatowe. Która z nich jest lepsza? Nie zdziwi Cię zapewne, że ta sama sytuacja w C# 2 doprowadziłaby do błędu kompilacji — nie istniała reguła języka obejmująca ten przypadek. W C# 3 zostałaby wybrana metoda z parametrem Func. Dodatkowa reguła, która się pojawiała, może zostać sparafrazowana następująco:

308

ROZDZIAŁ 9

Wyrażenia lambda i drzewa wyrażeń

Jeżeli funkcja anonimowa może być przekonwertowana na dwa typy delegatowe o tej samej liście parametrów, ale różnych typach zwracanych, wtedy konwersje na postać delegatową są oceniane na podstawie konwersji wywnioskowanych typów zwracanych na typy zwracane przez te delegaty. Bez odniesienia do jakiegokolwiek przykładu brzmi to zupełnie obco. Przyjrzyjmy się ponownie listingowi 9.16 — konwertujemy z wyrażenia lambda bez parametrów i wywnioskowanego typu int na Func lub Func. Dla obu delegatów listy parametrów są jednakowe (puste), zatem stosowana jest dla nich powyższa zasada. Musimy więc tylko wskazać lepszą konwersję: int na int lub int na double. To pozwala nam znaleźć się w trochę lepszej sytuacji — tak jak widzieliśmy wcześniej, lepszą konwersją jest int na int. Powoduje to wyświetlenie przez listing 9.16 łańcucha akcja zwraca int: 1.

9.4.5. Podsumowanie wnioskowania typów i rozwiązywania przeciążeń Ta sekcja była dosyć trudna. Chętnie bym ją uprościł, niestety całe zagadnienie jest skomplikowane. Nie upraszcza go również stosowana terminologia, szczególnie iż parametr typu i typ parametru znaczą coś zupełnie innego! Gratuluję, jeśli udało Ci się przebrnąć i faktycznie zrozumieć całość. Jeśli się nie udało, nie martw się. Być może, kiedy będziesz czytał tę sekcję kolejny raz, wszystko będzie jaśniejsze — szczególnie jeśli napotkasz podobne przypadki w swoim kodzie. Oto najważniejsze uwagi: Funkcje anonimowe (metody anonimowe i wyrażenia lambda) posiadają

wnioskowane typy zwracane bazujące na typach wszystkich wyrażeń zwracających wartość. Wyrażenia lambda mogą być zrozumiane przez kompilator wyłącznie wtedy,

kiedy znane są typy wszystkich parametrów. Mechanizm wnioskowania typów nie wymaga, aby każdy argument doszedł niezależnie do tej samej konkluzji odnośnie do parametrów typu, o ile tylko wyniki są ze sobą kompatybilne. Wnioskowanie typów ma teraz formę wieloetapową: wywnioskowany typ zwracany jednej funkcji anonimowej może być użyty jako parametr typu dla innej funkcji. W przypadku kiedy w wywołaniu biorą udział funkcje anonimowe, podczas wyszukiwania najlepszej metody przeciążonej pod uwagę brany jest wywnioskowany typ zwracany.

9.5.

Podsumowanie Wyrażenia lambda w C# 3 niemal całkowicie zastępują metody anonimowe. Oczywiście, metody anonimowe są nadal obsługiwane w ramach kompatybilności wstecz, ale idiomatyczny, świeżo napisany kod C# 3 będzie zawierał niewielką ich ilość. Widzieliśmy, że wyrażenia lambda są czymś więcej niż tylko bardziej spójną składnią do tworzenia delegatów. Mogą one być, z pewnymi ograniczeniami, konwertowane

Podsumowanie

309

na drzewa wyrażeń. Tak utworzone drzewa mogą być następnie przetwarzane przez inny kod, wykonujący na przykład te same polecenia w innych środowiskach. Bez tej możliwości LINQ byłby ograniczony jedynie do zapytań wewnątrzprocesowych. Nasza dyskusja na temat wnioskowania typów i wyszukiwania przeciążeń była swego rodzaju złem koniecznym. Bardzo niewiele osób naprawdę lubi dyskutować na temat tego typu reguł, warto jednak mieć przynajmniej pasywną wiedzę na temat tego, co się dzieje. Zanim popadniemy w zbytni pesymizm, pomyślmy ze współczuciem o wszystkich biednych projektantach języka, którzy muszą zajmować się tego typu rzeczami na co dzień i dbać o to, aby wszystkie reguły były spójne i nie zawiodły w naprawdę nieprzyjemnych sytuacjach! Potem obdarzmy podobnymi uczuciami testerów, którzy z całych sił muszą się starać popsuć implementację! To wszystko w temacie opisywania wyrażeń lambda, ale samych wyrażeń zobaczymy znacznie więcej w pozostałej części książki. Na przykład cały kolejny rozdział jest poświęcony metodom rozszerzającym. Z zewnątrz wydaje się, że są one zupełnie odseparowane od wyrażeń lambda, ale w rzeczywistości obie cechy są często używane razem.

310

ROZDZIAŁ 9

Wyrażenia lambda i drzewa wyrażeń

Metody rozszerzające

Ten rozdział omawia: ♦ pisanie metod rozszerzających, ♦ wywoływanie metod rozszerzających, ♦ łańcuchowe łączenie metod, ♦ metody rozszerzające w .NET 3.5, ♦ inne przypadki użycia metod rozszerzających.

312

ROZDZIAŁ 10

Metody rozszerzające

Nie jestem fanem dziedziczenia. A może raczej nie jestem fanem stosowania dziedziczenia na masową skalę w kodzie, który przyszło mi utrzymywać, lub w bibliotekach, z którymi przyszło mi pracować. Tak jak w przypadku wielu innych rzeczy, dziedziczenie w sposób odpowiedzialny stanowi niezwykle funkcjonalny mechanizm, który przy nieodpowiednim użyciu wymaga jednak nadmiernej uwagi i z czasem staje się uciążliwy. Cecha ta jest wykorzystywana od czasu do czasu jako sposób na dodanie nowego zachowania lub nowej funkcjonalności do klasy, nawet jeśli nie pojawiła się żadna faktycznie nowa informacja związana z obiektem, czyli kiedy niczego nie wyspecjalizowano. Czasem (chociaż rzadko) takie postępowanie jest wskazane, zwłaszcza jeżeli obiekty nowego typu powinny przechowywać szczegóły dodatkowego zachowania. W wielu przypadkach, jeśli korzystasz z typu wartościowego, klasy zamkniętej lub interfejsu, dziedziczenie jest niedostępne od samego początku. Alternatywnie możesz napisać kilka metod statycznych, z których każda przyjmie instancję problematycznego interfejsu jako jeden lub więcej ze swoich parametrów. Takie rozwiązanie działa skutecznie, bez ograniczeń związanych z dziedziczeniem, ale sprawia, że kod wygląda nieładnie. W C# 3 wprowadzono ideę metod rozszerzających, które mają zalety rozwiązania wykorzystującego metody statyczne, ale jednocześnie poprawiają czytelność wywołującego je kodu. Pozwalają one na wywoływanie funkcji statycznych, tak jakby były one metodami kompletnie innej klasy. Spokojnie — nie wygląda to aż tak szalenie, jak brzmi. W tym rozdziale zajmiemy się użyciem metod rozszerzających oraz ich pisaniem. Następnie przyjrzymy się kilku metodom tego typu dostarczanym przez .NET 3.5 i sprawdzimy, jak w łatwy sposób można je połączyć ze sobą. Ta zdolność do łączenia w sposób łańcuchowy jest istotnym elementem, który wpłynął na wprowadzenie metod rozszerzających do języka, a także stanowi istotną część LINQ1. W końcu przyjrzymy się faktom przemawiającym zarówno za stosowaniem metod rozszerzających zamiast zwykłych funkcji statycznych, jak i przeciw takiemu rozwiązaniu. Zacznijmy od sprawdzenia, dlaczego metody rozszerzające są czasem bardziej pożądane od tego, co oferuje C# 1 i 2, szczególnie kiedy tworzysz klasy narzędziowe.

10.1. Życie przed metodami rozszerzającymi Możesz teraz doznać déjà vu, ponieważ klasy narzędziowe pojawiły się już w rozdziale siódmym, kiedy omawialiśmy klasy statyczne. Jeżeli napisałeś sporo kodu w C# 2, zanim przeszedłeś do C# 3, powinieneś się przyjrzeć swoim klasom statycznym — wiele z zawartych w nich metod może być dobrymi kandydatami do zmiany w metody rozszerzające. Nie oznacza to wcale, że wszystkie istniejące klasy statyczne są dobrym kandydatem do takiej zmiany. To, że jesteś na dobrym tropie, może wskazywać wystąpienie poniższych cech:

1

Zrozumiem, jeśli masz już serdecznie dość czytania w kółko o tym, ile to cech jest „istotną częścią LINQ” — to jednak stanowi o wyjątkowości tej technologii. Mamy bowiem wiele małych elementów składowych, ale ich suma jest czymś doskonałym. Wartością dodaną jest możliwość używania każdej z tych cech oddzielnie.

Życie przed metodami rozszerzającymi

313

Chcesz dodać nowe elementy składowe do typu. Nie ma potrzeby dodawania nowych danych do instancji typu. Nie możesz zmienić samego typu, ponieważ znajduje się on w kodzie,

który nie należy do Ciebie. Pewnym wariantem tego podejścia jest chęć pracy z interfejsem zamiast z klasą, kiedy chcesz dodać nową funkcjonalność jedynie przez wywoływanie metod. Dobrym tego przykładem jest IList. Czy nie byłoby miło, gdybyśmy mogli sortować każdą (pozwalającą na zmiany) implementację IList? Niewyobrażalnym zadaniem byłoby wymuszenie na wszystkich interfejsach tego typu implementacji swojego sortowania, chociaż takie podejście byłoby mile widziane z punktu widzenia użytkownika listy. Faktem jest, że IList dostarcza wszystkich elementów składowych potrzebnych do stworzenia zupełnie generycznej metody sortującej (a nawet kilku). Niestety nie masz możliwości umieszczenia implementacji w tym interfejsie. Zamiast tego IList mogłaby zostać wyspecyfikowana jako klasa abstrakcyjna, co umożliwiłoby dodanie funkcjonalności sortującej. Ponieważ jednak C# i .NET pozwalają tylko na pojedyncze dziedziczenie implementacji, wprowadziłoby to znaczne ograniczenie na typy dziedziczące po tej klasie. Metody rozszerzające pozwoliłyby nam na posortowanie dowolnej implementacji IList w formie sprawiającej wrażenie, jakby to ona sama dostarczała tę funkcjonalność. Później przekonamy się, że spora część funkcjonalności LINQ jest oparta na metodach rozszerzających interfejsy. Teraz jednak w naszych przykładach użyjemy innego typu — System.IO.Stream, który jest fundamentem komunikacji binarnej w .NET. Typ Stream jest klasą abstrakcyjną z kilkoma wydziedziczonymi z niej klasami, takimi jak NetworkStream, FileStream i MemoryStream. Jest niestety kilka elementów funkcjonalności, które byłyby bardzo pomocne w ramach klasy Stream, ale których zwyczajnie tam nie ma. Cechy, których brakuje mi najbardziej, to możliwość przeczytania całego strumienia do pamięci jako tablicy bajtów i skopiowania2 zawartości jednego strumienia do drugiego. Oba te zadania są na ogół implementowane w dość kiepski sposób, zwłaszcza że założenia są po prostu niepoprawne (jednym z najczęstszych błędów logicznych jest założenie, że Stream.Read całkowicie wypełni dany bufor, o ile tylko nie zabraknie danych). CECHA, KTÓREJ „AŻ TAK” NIE BRAKUJE. Jedna z tych cech została dodana w .NET 4 — Stream posiada teraz metodę CopyTo. Fakt ten przyda się do zademonstrowania pewnej słabości metod rozszerzających — wrócimy do tego w sekcji 10.2.3. Metoda ReadFully jest nadal niedostępna, ale i tak powinna być używana z dużą rozwagą. Czytania całej zawartości strumienia powinieneś się podejmować wyłącznie wtedy, gdy jesteś pewny, że ma on swój koniec i wszystkie dane zmieszczą się w pamięci. Strumienie nie są zobligowane do posiadania skończonej ilości danych. 2

Ze względu na naturę strumieni kopiowanie niekoniecznie musi duplikować dane — wystarczy, że będzie je czytać z jednego strumienia i zapisywać do drugiego. Chociaż termin kopiowanie nieszczególnie pasuje do wykonywanej w takiej sytuacji operacji, różnica jest na ogół nieistotna.

314

ROZDZIAŁ 10

Metody rozszerzające

Lepiej byłoby mieć tę funkcjonalność w jednym miejscu, niż kopiować ją w każdym kolejnym projekcie. Z tego powodu napisałem w swojej bibliotece narzędziowej klasę StreamUtil. Prawdziwa implementacja zawiera sporą ilość kodu sprawdzającego błędy, a także zapewniającego inną funkcjonalność. Na poniższym listingu (10.1) znajduje się skrócona wersja, która w naszym przypadku jest bardziej adekwatna. Listing 10.1. Prosta klasa narzędziowa dodająca nową funkcjonalność dla strumieni using System.IO; public static class StreamUtil { const int BufferSize = 8192; public static void Copy(Stream input, Stream output) { byte[] buffer = new byte[BufferSize]; int read; while ((read = input.Read(buffer, 0, buffer.Length)) > 0) { output.Write(buffer, 0, read); } } public static byte[] ReadFully(Stream input) { using (MemoryStream tempStream = new MemoryStream()) { Copy(input, tempStream); return tempStream.ToArray(); } } }

Szczegóły implementacyjne nie są szczególnie istotne, chociaż warto zauważyć, że Read ´Fully wywołuje metodę Copy — to przyda nam się później do zademonstrowania pewnej uwagi odnośnie do metod rozszerzających. Klasa jest prosta w użyciu — poniższy listing (10.2) pokazuje przykład zapisywania odpowiedzi usługi sieciowej na dysk. Listing 10.2. Kopiowanie odpowiedzi usługi sieciowej do pliku przy użyciu StreamUtil WebRequest request = WebRequest.Create("http://manning.com"); using (WebResponse response = request.GetResponse()) using (Stream responseStream = response.GetResponseStream()) using (FileStream output = File.Create("response.dat")) { StreamUtil.Copy(responseStream, output); }

Listing 10.2 jest spójny, klasa StreamUtil przejęła na siebie obowiązek pytania w pętli strumienia odpowiedzi o dostarczenie kolejnych danych tak długo, aż zostanie odebrana całość. Jako klasa narzędziowa wykonuje swoją pracę zupełnie dobrze. Pomimo to całość nie wydaje się zorientowana obiektowo. Tak naprawdę chcielibyśmy poprosić

Składnia metod rozszerzających

315

strumień odpowiedzi o skopiowanie samego siebie do strumienia wyjściowego na zasadzie podobnej do wywołania metody WriteTo w klasie MemoryStream. Nie jest to duży problem, ale mimo wszystko jego rozwiązanie wygląda trochę brzydko. W tej sytuacji nie pomogłoby nam dziedziczenie (chcemy, aby to zachowanie było dostępne dla wszystkich strumieni, a nie tylko dla tych, za które jesteśmy odpowiedzialni), a nie mamy możliwości modyfikacji samej klasy Stream. Co zatem możemy zrobić? W C# 2 nie mieliśmy żadnych możliwości — musieliśmy się trzymać metod statycznych i nauczyć się żyć z tą niezgrabnością. C# 3 pozwala nam zmienić naszą klasę statyczną, gdyż udostępnia jej elementy jako metody rozszerzające, dzięki czemu możemy udawać, że były one od zawsze częścią klasy Stream. Zobaczmy, jakie zmiany są potrzebne.

10.2. Składnia metod rozszerzających Metody rozszerzające są wręcz banalne pod względem sposobu tworzenia i użytkowania. O wiele trudniejsze od umiejętności ich pisania jest rozważenie, kiedy i w jaki sposób należy ich użyć. Zacznijmy od przekształcenia naszej klasy StreamUtil w taki sposób, aby posiadała kilka metod rozszerzających.

10.2.1.Deklarowanie metod rozszerzających Nie każda metoda nadaje się do przekształcenia w metodę rozszerzającą — musi ona posiadać następujące cechy: Musi się znajdować w niezagnieżdżonej, niegenerycznej klasie statycznej (a zatem

musi być metodą statyczną). Musi posiadać przynajmniej jeden parametr. Pierwszy parametr musi być poprzedzony słowem kluczowym this. Pierwszy parametr nie może posiadać żadnych innych modyfikatorów (takich jak out i ref). Typem pierwszego parametru nie może być typ wskaźnikowy.

To wszystko. Metoda może być generyczna, zwracać wartość, posiadać parametry out/ref z wyłączeniem pierwszego z nich, być implementowana przez uproszczenie iteratora, należeć do klasy częściowej, używać typów nullowalnych — dozwolone jest wszystko, o ile tylko są spełnione powyższe warunki. Typ pierwszego parametru nazwiemy typem rozszerzanym metody i powiemy, że metoda ta rozszerza ten typ — a zatem w tym przypadku rozszerzamy typ Stream. Nie jest to oficjalna terminologia pochodząca ze specyfikacji, ale stanowi użyteczny skrót. Przedstawiona wcześniej lista podaje nie tylko ograniczenia, ale również określa, co musisz zrobić, aby zmienić zwykłą funkcję statyczną z klasy statycznej w metodę rozszerzającą. My musimy dodać jedynie słowo kluczowe this. Kolejny listing (10.3) pokazuje tę samą klasę co listing 10.1, ale tym razem z metodami rozszerzającymi.

316

ROZDZIAŁ 10

Metody rozszerzające Listing 10.3. Ponownie klasa StreamUtil, ale tym razem z metodami rozszerzającymi public static class StreamUtil { const int BufferSize = 8192; public static void CopyTo(this Stream input, Stream output) { byte[] buffer = new byte[BufferSize]; int read; while ((read = input.Read(buffer, 0, buffer.Length)) > 0) { output.Write(buffer, 0, read); } } public static byte[] ReadFully(this Stream input) { using (MemoryStream tempStream = new MemoryStream()) { CopyTo(input, tempStream); return tempStream.ToArray(); } } }

Tak, jedyną dużą zmianą na listingu 10.3 jest dodanie dwóch modyfikatorów (które zostały wytłuszczone w kodzie). Zmieniłem również nazwę metody z Copy na CopyTo. Jak zobaczymy za chwilę, pozwoli to na wywoływanie kodu w sposób bardziej czytelny, chociaż zawartość metody ReadFully wygląda chwilowo trochę dziwnie. Niewiele przyjdzie nam z posiadania metod rozszerzających, jeśli nie będziemy mogli ich użyć...

10.2.2.Wywoływanie metod rozszerzających Wspomniałem o tym przelotnie, ale nie widzieliśmy jeszcze, co faktycznie robi metoda rozszerzająca. Ujmując to najprościej, udaje, że jest metodą instancji innego typu — typu, będącego jej pierwszym parametrem. Transformacja naszego przykładowego kodu, który używa StreamUtil, jest równie prosta jak transformacja samej klasy narzędziowej. Tym razem zamiast cokolwiek dodawać, zabierzemy coś. Listing 10.4 stanowi powtórzenie listingu 10.2, ale z użyciem nowej składni do wywołania CopyTo. Mówię „nowej”, ale tak naprawdę nie jest ona wcale nowa — jest to składnia, której używaliśmy zawsze do wywoływania metod instancji. Listing 10.4. Kopiowanie strumienia przy użyciu metody rozszerzającej WebRequest request = WebRequest.Create("http://manning.com"); using (WebResponse response = request.GetResponse()) using (Stream responseStream = response.GetResponseStream()) using (FileStream output = File.Create("response.dat")) { responseStream.CopyTo(output); }

Składnia metod rozszerzających

317

Na listingu 10.4 widać przynajmniej, że prosimy strumień odpowiedzi o wykonanie operacji kopiowania. Pod maską całą pracę wykonuje nadal StreamUtil, ale kod wydaje się bardziej naturalny. W rzeczywistości kompilator przekonwertował wywołanie CopyTo na zwykłe wywołanie funkcji statycznej StreamUtil.CopyTo, przekazując jej jako pierwszy argument wartość responseStream (a następnie, tak jak zwykle, output). Teraz, kiedy widzisz już kod, mam nadzieję, że rozumiesz, dlaczego zmieniłem nazwę metody z Copy na CopyTo. Niektóre nazwy metod sprawdzają się równie dobrze zarówno w metodach statycznych, jak i w metodach instancji, ale — o czym zapewne się przekonasz — wymagają pewnej modyfikacji, aby uzyskać najwięcej pod względem czytelności kodu. Jeśli chcesz, aby kod metody StreamUtil stał się bardziej przejrzysty, możesz zmienić wiersz wywołujący CopyTo w metodzie ReadFully na następujący: input.CopyTo(tempStream);

W tym momencie zmiana nazwy funkcji staje się całkowicie odpowiednia dla wszystkich przypadków użycia — chociaż nic nie powstrzymuje Cię przed użyciem jej jako funkcji statycznej, co nie jest bez znaczenia, jeśli Twoim zadaniem jest dokonanie migracji dużej ilości kodu. Być może zauważyłeś, że w użytych przez nas wywołaniach metod nic nie wskazuje na to, iż używamy metod rozszerzających zamiast zwykłych metod instancji klasy Stream. Taka sytuacja może być odebrana w dwojaki sposób: dobrze, jeśli naszym celem jest wmieszanie metod rozszerzających w istniejący kod, tak aby były one niemal nierozpoznawalne, ale źle, jeśli chcesz szybko stwierdzić, co tak naprawdę dzieje się w kodzie. Jeżeli używasz Visual Studio, możesz przesunąć kursor myszki nad wywołanie metody i uzyskać informację w dymku, mówiącą o tym, iż wywołanie dotyczy metody rozszerzającej — pokazuje to rysunek 10.1.

Rysunek 10.1. Podświetlenie wywołania metody w Visual Studio ujawnia, czy wywołanie to dotyczy 3 metody rozszerzającej

IntelliSense podpowiada również, że dana metoda jest metodą rozszerzającą, poprzez odpowiednią ikonkę przy jej nazwie, a także później, po wybraniu metody, przez dodanie odpowiedniego przedrostka w dymku. Oczywiście, nikt nie zmusza Cię do wskazywania 3

Uzyskanie tego dymku w Visual Studio z aktywną czwartą (lub nowszą) wersją środowiska .NET (jak ma to miejsce w Visual Studio 2010) jest niemożliwe, ponieważ IntelliSense podpowiada użycie natywnej metody CopyTo z klasy Stream zamiast metody rozszerzającej z przykładu. Problem ten można ominąć, nazywając funkcję inaczej w samej klasie StreamUtil niż w wywołaniu, na przykład CopyTo1 — przyp. tłum.

318

ROZDZIAŁ 10

Metody rozszerzające

myszą każdego wywołania lub pilnego śledzenia IntelliSense — w większości przypadków nie ma znaczenia, czy wywołujesz metodę instancji, czy też metodę rozszerzającą. Pozostaje jeszcze jeden, raczej nietypowy element w naszym kodzie wywołującym — nigdzie nie widać żadnego śladu prowadzącego do StreamUtil. Skąd kompilator w ogóle wie, że należy użyć metody rozszerzającej?

10.2.3.Wykrywanie metod rozszerzających Ważne jest, aby wiedzieć, jak wywoływać metody rozszerzające, ale równie istotne jest, aby wiedzieć, jak ich nie wywoływać — jak uniknąć sytuacji, w której dostępne są tylko niechciane opcje. Żeby to osiągnąć, musimy wiedzieć, jak kompilator decyduje o wyborze metody rozszerzającej. Metody rozszerzające są dostępne w kodzie na takich samych zasadach jak klasy pozbawione kwalifikacji — bez użycia dyrektywy using. Kiedy kompilator widzi wyrażenie, które wyglądem przypomina próbę użycia metody instancji klasy, ale żadna z metod tej klasy nie jest kompatybilna z napotkanym wywołaniem (np. nie ma metody o takiej samej nazwie lub żadne z przeciążeń nie pasuje do podanych argumentów), rozpoczyna poszukiwanie odpowiedniej metody rozszerzającej. Bierze pod uwagę wszystkie metody rozszerzające we wszystkich zaimportowanych oraz bieżących przestrzeniach nazw i dopasowuje tę, dla której istnieje niejawna konwersja z typu wyrażenia na typ rozszerzony. DETAL IMPLEMENTACYJNY: JAK KOMPILATOR ROZPOZNAJE METODĘ ROZSZERZAJĄCĄ? Aby stwierdzić, czy potrzebne jest użycie metody rozszerzającej, kompilator musi potrafić odróżnić w klasie statycznej metody rozszerzające od pozostałych metod posiadających taką samą sygnaturę. Robi to, sprawdzając, czy do metody i klasy został zastosowany atrybut System. ´Runtime.CompilerServices.ExtensionAttribute. Atrybut ten został wprowadzony do użytku w .NET 3.5, ale kompilator nie sprawdza, z którego modułu on pochodzi. Oznacza to, że możesz nadal używać metod rozszerzających, nawet jeśli Twój projekt jest przeznaczony dla .NET 2.0 — musisz po prostu zdefiniować swój własny atrybut z odpowiednią nazwą w odpowiedniej przestrzeni nazw. Następnie możesz zadeklarować swoje metody rozszerzające jak zwykłe metody, a atrybut zostanie zastosowany automatycznie. Kompilator stosuje również atrybut do modułu zawierającego metodę rozszerzającą, ale na chwilę obecną nie wymaga jego obecności podczas wyszukiwania tych metod. Problematyczne może się okazać wprowadzenie swoich własnych kopii typów systemowych, jeśli później zdecydujesz się na użycie wersji środowiska, która takie typy już posiada. Stosując powyższą technikę, warto użyć symbolu preprocesora, aby deklarować atrybut w sposób warunkowy. W ten sposób będziesz w stanie zbudować jedną wersję kodu przeznaczonego dla .NET 2.0 i drugą dla wersji 3 5 lub nowszej. Jeżeli dla danego typu rozszerzającego jest dostępnych kilka różnych metod rozszerzających (poprzez niejawne konwersje), najbardziej odpowiednia jest wybierana w oparciu o reguły konwersji stosowane przy wyborze przeciążeń. Jeżeli na przykład IChild dziedziczy po IParent i w obu przypadkach istnieje metoda rozszerzająca o takiej samej

Składnia metod rozszerzających

319

nazwie, preferowana jest metoda rozszerzająca z IChild. Ta cecha ma również zastosowanie w LINQ, o czym przekonasz się w sekcji 12.2, kiedy spotkamy się z interfejsem IQueryable. Warto zauważyć, że jeśli jest dostępna odpowiednia metoda instancji, będzie ona miała zawsze pierwszeństwo nad metodami rozszerzającymi. Jeżeli tak się zdarzy, kompilator nie zgłosi ostrzeżenia informującego, że metoda rozszerzająca pasuje do istniejącej metody instancji. Na przykład klasa Stream w .NET 4 posiada nową metodę o nazwie CopyTo. Ma ona dwa przeciążenia, z których jedno jest w konflikcie z naszą metodą rozszerzającą. W wyniku tego nowa metoda jest wybierana przed metodą rozszerzającą. Jeśli zatem skompilujesz listing 10.4 w środowisku .NET 4, Twój kod będzie używał Stream.CopyTo zamiast StreamUtil.CopyTo. Metodę StreamUtil.CopyTo możesz nadal wywoływać statycznie, używając składni StreamUtil.CopyTo(input, output), ale nie zostanie ona nigdy wybrana jako metoda rozszerzająca. W takim przypadku kod istniejący nie jest zagrożony: nowa metoda instancji ma dokładnie takie samo znaczenie jak nasza metoda rozszerzająca, zatem to, która z nich zostanie użyta, nie jest istotne. W innych sytuacjach mogą zaistnieć subtelne różnice w semantyce, które jednak trudno będzie „namierzyć” do momentu powstania awarii wywołanej przez wadliwy kod. Innym potencjalnym problemem występującym podczas udostępniania metod rozszerzających jest ich szeroki zakres widoczności. Jeżeli w danej przestrzeni nazw są dwie klasy zawierające metody z tym samym typem rozszerzanym, nie ma sposobu na użycie metod rozszerzających wyłącznie w jednej z nich. Na podobnej zasadzie nie ma możliwości zaimportowania przestrzeni nazw wyłącznie dla udostępnienia typów poprzez ich nazwy skrócone, bez jednoczesnego uwidocznienia metod rozszerzających z tej przestrzeni. Pewnym rozwiązaniem mogłoby być przeniesienie wszystkich klas zawierających metody rozszerzające do wydzielonej przestrzeni nazw, jeśli tylko pozostała funkcjonalność nie jest już mocno uzależniona od metod rozszerzających (jak w przypadku System.Linq). Bardzo zaskakujący przy pierwszym spotkaniu, ale jednocześnie bardzo użyteczny może być pewien aspekt metod rozszerzających związany z pustymi referencjami. Zobaczmy.

10.2.4.Wywołanie metody na pustej referencji Byłbym szczerze zdziwiony, gdybym spotkał kogokolwiek, kto w swojej pracy zajmował się intensywnie programowaniem dla środowiska .NET i nigdy nie zetknął się z wyjątkiem NullReferenceException, spowodowanym wywołaniem metody poprzez zmienną, której wartością okazała się pusta referencja. W C# nie wolno wywoływać metod instancji na pustych referencjach (chociaż IL udostępnia taką możliwość dla wywołań niewirtualnych), ale wolno wywoływać metody rozszerzające z pustymi referencjami. Przykład takiego działania demonstruje listing 10 5. Listing 10.5. Metody rozszerzające wywoływane na pustej referencji using System; public static class NullUtil { public static bool IsNull(this object x)

320

ROZDZIAŁ 10

Metody rozszerzające { return x == null; }

}

public class Test { static void Main() { object y = null; Console.WriteLine(y.IsNull()); y = new object(); Console.WriteLine(y.IsNull()); } }

Wynikiem działania programu z listingu 10 5 jest True, a następnie False, a gdyby IsNull była zwykłą metodą instancji, w drugim wierszu metody Main zostałby rzucony wyjątek. Zamiast tego metoda IsNull została wywołana z argumentem null. Przed pojawieniem się koncepcji metod rozszerzających C# nie posiadał bardziej czytelnego sposobu, którego mógłbyś użyć do zapisania y.IsNull(). Zamiast tego byłeś zmuszony do zapisu NullUtil.IsNull(y). Istnieje pewne szczególne miejsce w środowisku, w którym można wykazać użyteczność takiego rozwiązania — string.IsNullOrEmpty. C# 3 pozwala na napisanie metody, która posiada taką samą sygnaturę (pomijając dodatkowy parametr dla typu rozszerzanego) jak istniejąca metoda statyczna w tym typie rozszerzanym. Aby zaoszczędzić Ci konieczności wielokrotnej analizy tego zdania, posłużę się przykładem — chociaż klasa string posiada bezparametrową metodę IsNullOrEmpty, nadal możesz stworzyć następującą metodę rozszerzającą i z niej skorzystać: public static bool IsNullOrEmpty(this string text) { return string.IsNullOrEmpty(text); }

Na pierwszy rzut oka wydaje się dziwne, aby można było wywoływać IsNullOrEmpty na pustej zmiennej bez rzucenia wyjątku, szczególnie jeśli z tą statyczną funkcją jesteś obeznany od czasu środowiska .NET 2.0. Według mnie kod używający metody rozszerzającej jest łatwiejszy do zrozumienia. Jeśli na przykład przeczytasz na głos wyrażenie if (name.IsNullOrEmpty()), to, co przeczytałeś, będzie zgodne z faktycznym działaniem. Tak jak zwykle, najlepiej jest poeksperymentować samodzielnie, aby przekonać się, czy takie podejście będzie Ci służyć — debugując kod, pamiętaj jednak, że takiej techniki mogą używać inni programiści. Nie zakładaj, że wywołanie metody spowoduje rzucenie wyjątku, o ile nie jesteś absolutnie pewien, iż nie masz do czynienia z metodą rozszerzającą! Pamiętaj również, aby się porządnie zastanowić przed użyciem istniejącej nazwy dla metody rozszerzającej — poprzednia metoda rozszerzająca mogła wprowadzić w zakłopotanie czytelników, którzy znają jedynie statyczną metodę pochodzącą z środowiska. SPRAWDZANIE PUSTYCH WARTOŚCI. Jestem pewien, że jako świadomy programista przed przestąpieniem do działania w swoich metodach zawsze sprawdzasz argumenty na okoliczność występowania wartości pustych. Pytanie, które pojawia się w przypadku metod rozszerzających, brzmi: „Jaki wyjątek należy

Metody rozszerzające w .NET 3.5

321

rzucić, jeśli pierwszy argument jest pusty?” (zakładając, że nie powinien taki być). Czy powinien to być, tak jak w przypadku zwykłych argumentów, Argument ´NullException, czy może NullReferenceException, który pojawiłby się, gdyby metoda rozszerzająca była zwykłą metodą instancji? Polecam pierwszy z nich. Mimo wszystko jest to nadal argument, nawet jeśli składnia metody rozszerzającej nie wskazuje tego w sposób oczywisty. Takie podejście przyjął Microsoft w przypadku metod rozszerzających w samym środowisku. Zyskamy zatem także spójność ze środowiskiem. I w końcu pamiętaj, że metody rozszerzające mogą być nadal wywoływane jako zwyczajne metody statyczne, a w takiej sytuacji ArgumentNullException jest wynikiem jak najbardziej spodziewanym. Teraz, kiedy znamy już składnię i zachowanie metod rozszerzających, możemy się przyjrzeć ich przykładom udostępnionym jako część środowiska w .NET 3 5.

10.3. Metody rozszerzające w .NET 3.5 Miejscem, w którym metody rozszerzające są używane najczęściej, jest LINQ. Niektórzy dostawcy LINQ posiadają kilka metod rozszerzających, które pomagają im w pracy, ale wśród nich są dwie klasy — obie w przestrzeni nazw System.Linq — które wyraźnie wyróżniają się na tym tle: Enumerable i Queryable. Obie zawierają bardzo dużo metod rozszerzających. W klasie Enumerable większość z nich operuje na IEnumerable, a w klasie Queryable na IQueryable. Przeznaczenie IQueryable poznamy w rozdziale 12., teraz skoncentrujmy się na Enumerable.

10.3.1.Pierwsze kroki z Enumerable Przyglądając się klasie Enumerable, już teraz zbliżamy się do LINQ. W sporej części przypadków nie potrzebujesz pełnej funkcjonalności wyrażeń kwerendowych, aby rozwiązać dany problem. Enumerable posiada wiele metod, ale celem tej sekcji nie jest przedstawienie ich wszystkich, a jedynie pewnego ich wycinka, który pozwoli Ci poczuć się na tyle pewnie, abyś mógł samodzielnie poeksperymentować. Zabawa z całą zawartością Enumerable przynosi dużo radości, chociaż tym razem zamiast Snippy do swoich eksperymentów warto uruchomić Visual Studio lub LINQPad, ponieważ w tego typu pracy przyda się bardzo IntelliSense. Krótki opis zachowania można również znaleźć w dodatku A. Wszystkie kompletne przykłady w tej sekcji odnoszą się do prostej sytuacji: zaczynamy od kolekcji liczb całkowitych i transformujemy ją na różne sposoby. Oczywiście, rzeczywiste przypadki użycia są bardziej złożone i na ogół mają związek z biznesowymi typami danych. Pokażę kilka przykładów odnoszących się wyłącznie do części transformacyjnej, zastosowanej w prawdopodobnej logice biznesowej, z pełnymi przykładami dostępnymi na stronie książki — zaznaczam jednak, że są to przypadki trudniejsze do przeanalizowania niż w sytuacji, kiedy mamy do czynienia ze zwykłą kolekcją liczb. Warto, abyś w trakcie naszych rozważań przypomniał sobie projekty, nad którymi niedawno pracowałeś. Spróbuj przywołać sytuacje, w których mógłbyś uprościć swój kod dzięki użyciu opisanych tutaj operacji.

322

ROZDZIAŁ 10

Metody rozszerzające

W klasie Enumerable jest kilka metod niebędących metodami rozszerzającymi. Jednej z nich — Range —będziemy używać w naszych przykładach w pozostałej części rozdziału. Metoda Range przyjmuje dwa parametry typu int: liczbę, od której należy zacząć, i liczbę wyników do zwrócenia. Wynikiem działania jest IEnumerable, który w znany nam już sposób zwraca po jednej liczbie na wywołanie. Aby zademonstrować metodę Range i stworzyć środowisko do dalszej pracy, wyświetlmy na początek liczby od 0 do 9, tak jak pokazuje to listing 10.6. Listing 10.6. Użycie Enumerable.Range do wyświetlenia liczb od 0 do 9 var collection = Enumerable.Range(0, 10); foreach (var element in collection) { Console.WriteLine(element); }

Na listingu 10.6 nie są wywoływane żadne metody rozszerzające, a wyłącznie jedna zwykła metoda statyczna. Kod wyświetla liczby od 0 do 9 (nie obiecywałem, że będzie to coś porażającego). WYKONANIE ODROCZONE. Metoda Range nie buduje listy z odpowiednimi liczbami, ona wydaje je jedynie w odpowiednim momencie. Innymi słowy, utworzenie obiektu collection nie powoduje wykonania całego zadania, a jedynie przygotowanie infrastruktury, dzięki czemu dane będą mogły być dostarczone w odpowiednim miejscu, kiedy przyjdzie na to pora. Takie zachowanie określa się mianem wykonania odroczonego — widzieliśmy je już przy okazji uproszczeń iteratora w rozdziale szóstym i zobaczymy ponownie w następnym rozdziale. Jedną z najprostszych rzeczy, jakie możemy zrobić w odniesieniu do (uporządkowanej już) sekwencji liczb, jest jej odwrócenie. Zadanie to realizuje przy użyciu metody Reverse listing 10.7. Metoda Reverse zwraca referencję do IEnumerable, która wydaje takie same elementy jak oryginalna sekwencja, ale w odwrotnym porządku. Listing 10.7. Odwracanie kolekcji przy użyciu metody Reverse var collection = Enumerable.Range(0, 10) .Reverse(); foreach (var element in collection) { Console.WriteLine(element); }

Jak można się spodziewać, powyższy kod wyświetla 9, następnie 8, potem 7 i tak dalej aż do 0. Wywołaliśmy Reverse (pozornie) na IEnumerable i otrzymaliśmy ten sam typ. Zwracanie referencji do enumeracji w oparciu o inną enumerację jest zjawiskiem powszechnym dla klasy Enumerable. WYDAJNOŚĆ: BUFOROWANIE KONTRA STRUMIENIOWANIE. Metody rozszerzające dostarczane przez środowisko starają się możliwie jak najczęściej przekazywać dane w formie strumieniowej lub potokowej — kiedy iterator jest

Metody rozszerzające w .NET 3.5

323

proszony o kolejny element, często sam pobiera element z powiązanego iteratora, przetwarza go i zwraca odpowiedni wynik, najchętniej bez samodzielnego przechowywania stanu dodatkowego. Takie podejście z łatwością realizują proste transformacje, jak filtry, i jest to niezwykle funkcjonalny sposób przetwarzania danych. Są jednak operacje, takie jak odwracanie lub sortowanie, w przypadku których potrzebny jest dostęp do wszystkich danych, zatem wszystkie są ładowane do pamięci w celu grupowego przetworzenia. Różnica pomiędzy podejściem buforowym i potokowym jest podobna do różnicy pomiędzy ładowaniem całego zbioru danych przez instancję DataSet a przetwarzaniem rekord po rekordzie przy użyciu obiektu klasy DataReader. Używając LINQ, należy wziąć pod uwagę wymagany rodzaj przetwarzania — pojedyncza metoda może nieść ze sobą ogromny narzut wydajnościowy. Strumieniowanie znane jest również jako wartościowanie leniwe (ang. lazy evaluation), a buforowanie jako wartościowanie zachłanne (ang. eager evaluation). Dla przykładu metoda Reverse używa wykonania odroczonego (nie robi nic do momentu, kiedy pojawi się pierwsze wywołanie MoveNext), ale kiedy ono nastąpi, wartościuje swoje źródło danych w sposób zachłanny. Osobiście nie lubię określeń leniwe i zachłanne, gdyż różne osoby odczytują je w odmienny sposób (zobacz http://mng.bz/3LLM). Spróbujmy zrobić teraz coś bardziej pasjonującego — usuniemy liczby parzyste, używając do tego celu wyrażenia lambda.

10.3.2.Filtrowanie z użyciem Where i spinania wywołań metod Metoda rozszerzająca Where stanowi prosty, ale funkcjonalny sposób filtrowania kolekcji. Przyjmuje jako parametr predykat, który następnie stosuje do każdego z elementów kolekcji źródłowej. Ponownie wynikiem jest IEnumerable, a do kolekcji wynikowej dołączany jest każdy element, który pasuje do predykatu. Przykład takiego działania pokazuje listing 10.8, który przed odwróceniem kolekcji przepuszcza każdą jej wartość przez filtr parzystości/nieparzystości. Nie musimy tutaj korzystać z wyrażenia lambda. Moglibyśmy na przykład skorzystać z utworzonego wcześniej delegata lub z metody anonimowej. W tym przypadku (i w wielu innych rzeczywistych sytuacjach) łatwiej jest umieścić logikę filtrującą w miejscu wywołania, a wyrażenia lambda pozwalają zachować zwięzłość. Listing 10.8. Użycie metody Where w połączeniu z wyrażeniem lambda w celu znalezienia liczb nieparzystych var collection = Enumerable.Range(0, 10) .Where(x => x % 2 != 0) .Reverse(); foreach (var element in collection) { Console.WriteLine(element); }

324

ROZDZIAŁ 10

Metody rozszerzające

Listing 10.8 wyświetla liczby 9, 7, 5, 3 i 1. Mam nadzieję, że widzisz tworzenie się pewnego wzorca — spinamy razem wywołania metod. Sama idea spinania nie jest nowa. Na przykład metoda StringBuilder.Replace zawsze zwraca instancję, na której została wywołana, co pozwala na napisanie kodu takiego jak ten: builder = builder.Replace("<","<") .Replace(">",">") ...

String.Replace zwraca łańcuch, ale jest to za każdym razem nowy łańcuch — to pozwala

na łączenie łańcuchowe, ale w nieco inny sposób. Warto być świadomym obu tych wzorców. Wzorzec „zwróć tę samą referencję” nadaje się dobrze dla typów mutowalnych, podczas gdy wzorzec „zwróć nową instancję będącą kopią oryginalnej ze zmianami” jest wymagany dla typów niemutowalnych. Oba podejścia są dobre dla metod instancji, ale metody rozszerzające pozwalają na łączenie ze sobą metod statycznych. Jest to jeden z głównych powodów, dla których istnieją metody rozszerzające. Są one użyteczne dla innych klas narzędziowych, ale ich prawdziwa siła ujawnia się właśnie przez możliwość łączenia w sposób łańcuchowy funkcji statycznych. Właśnie dlatego metody rozszerzające pojawiają się głównie w klasach Enumerable i Queryable środowiska .NET — LINQ jest wyposażony specjalnie w kierunku takiego przetwarzania danych, w którym informacje „przepływają” przez potoki pojedynczych operacji złączonych ze sobą łańcuchowo. UWAGA NA TEMAT WYDAJNOŚCI: ZMIANA ORGANIZACJI WYWOŁAŃ METOD W CELU OGRANICZENIA STRAT. Nie jestem zwolennikiem „mikrooptymalizacji”, jeżeli nie zachodzi ku temu dobry powód. Warto przyjrzeć się porządkowi wywoływania metod na listingu 10.8. Wywołanie Where mogliśmy umieścić za wywołaniem Reverse i osiągnąć dokładnie taki sam wynik. Jednak zmarnowałoby to nieco nasz wysiłek — metoda Reverse musiałaby wypracować pozycję liczb parzystych w sekwencji, mimo że zostałyby one usunięte z wyniku końcowego. W tym przypadku nie będzie to miało większego znaczenia, ale w rzeczywistych sytuacjach może wyraźnie wpłynąć na wydajność. Dobrze jest, kiedy możesz zredukować niepotrzebną pracę bez utraty czytelności. Nie oznacza to wcale, że filtry powinieneś zawsze umieszczać na początku potoku — przed każdą zmianą porządku wywołań powinieneś się upewnić, czy po zmianie nadal uzyskasz poprawny wynik. Istnieją dwa znane sposoby zapisania pierwszej części listingu 10.8 bez korzystania z faktu, iż Reverse i Where są metodami rozszerzającymi. Jedna z nich to użycie zmiennej tymczasowej do przechowania kolekcji: var collection = Enumerable.Range(0, 10); collection = Enumerable.Where(collection, x => x % 2 != 0); collection = Enumerable.Reverse(collection);

Mam nadzieję, że zgodzisz się ze mną, iż znaczenie kodu jest tutaj o wiele mniej jasne niż na listingu 10.8. Sprawa wygląda jeszcze gorzej w przypadku drugiej opcji, tzn. utrzymania stylu z pojedynczym wyrażeniem:

Metody rozszerzające w .NET 3.5

325

var collection = Enumerable.Reverse (Enumerable.Where (Enumerable.Range(0, 10), x => x % 2 != 0));

Porządek wywołań wydaje się odwrócony, ponieważ jako pierwsze zostanie wykonane wywołanie najbardziej zagnieżdżone (Range), a następnie punkt wykonania będzie się posuwał w kierunku na zewnątrz. Wygląda to nieładnie już przy trzech wywołaniach metod, a będzie jeszcze gorzej w przypadku zapytań wymagających większej liczby operatorów. Zanim przejdziemy dalej, zastanówmy się przez chwilę, co dokładnie robi metoda Where.

10.3.3.Antrakt: czy metody Where nie widzieliśmy już wcześniej? Jeżeli metoda Where wydaje się znajoma, jest tak dlatego, iż zaimplementowaliśmy ją w rozdziale szóstym. Wystarczy, że przekształcimy ją w metodę rozszerzającą oraz zmienimy typ delegatowy z Predicate na Func, a będziemy mieć całkiem dobrą alternatywną implementację Enumerable.Where: public static IEnumerable Where(this IEnumerable source, Func predicate) { if (source == null || predicate == null) { throw new ArgumentNullException(); } return WhereImpl(source, predicate); } private static IEnumerable WhereImpl(IEnumerable source, Func predicate) { foreach (T item in source) { if (predicate(item)) { yield return item; } } }

Możemy również przekonwertować nasz wcześniejszy przykład użycia tych funkcji w połączeniu z naszą metodą ReadLines: foreach (string line in ReadLines("../../FakeLinq.cs") .Where(line => line.StartsWith("using"))) { Console.WriteLine(line); }

Jest to faktyczne użycie zapytania LINQ bez korzystania z przestrzeni nazw System. ´Linq. Gdybyś zadeklarował odpowiedni typ delegatowy Func i [ExtensionAttribute], równie dobrze działałoby ono w .NET 2.0. Implementacji klauzuli where mógłbyś nawet użyć w wyrażeniu kwerendowym (nadal mając za cel .NET 2.0!), o czym przekonamy

326

ROZDZIAŁ 10

Metody rozszerzające

się w następnym rozdziale — nie wybiegajmy jednak zbytnio w przyszłość. Filtrowanie jest jedną z najprostszych operacji w zapytaniu. Inną — ale podobną — jest projekcja wyników.

10.3.4.Projekcja przy użyciu metody Select i typów anonimowych Najpowszechniej używaną metodą projekcyjną w Enumerable jest Select — operuje ona na IEnumerable i dokonuje projekcji na IEnumerable za pomocą — mającej postać delegata — transformacji Func, stosowanej na każdym kroku. Jest to zachowanie podobne do metody ConvertAll w List, ale działające na dowolnej kolekcji, po której można enumerować, i opóźniające projekcję do momentu faktycznego żądania elementu. Kiedy wprowadzałem typy anonimowe, powiedziałem, że są one użyteczne w połączeniu z wyrażeniami lambda i LINQ — tutaj mamy przykład potwierdzający te słowa. W tej chwili mamy nieparzyste liczby od 0 do 9 (w odwróconym porządku) — stwórzmy typ, który kapsułkuje oryginalną liczbę i jej pierwiastek kwadratowy. Poniższy listing (10.9) pokazuje samą projekcję i nieznacznie poprawiony kod wyświetlający wyniki. Listing 10.9. Projekcja przy użyciu wyrażenia lambda i typu anonimowego var collection = Enumerable.Range(0, 10) .Where(x => x % 2 != 0) .Reverse() .Select(x => new { Original = x, SquareRoot = Math.Sqrt(x) } ); foreach (var element in collection) { Console.WriteLine("sqrt({0})={1}", element.Original, element.SquareRoot); }

Tym razem typem kolekcji collection nie jest IEnumerable, ale IEnumerable ´, gdzie Something jest typem anonimowym stworzonym przez kompilator. Nie możemy nadać zmiennej kolekcji żadnego jawnego typu z wyjątkiem niegenerycznego IEnumerable lub object. Użycie typu niejawnego (dzięki var) pozwala nam skorzystać z właściwości Original i SquareRoot podczas wyświetlania wyników. Wynik działania kodu z listingu 10.9 wygląda następująco: sqrt(9)=3 sqrt(7)=2,64575131106459 sqrt(5)=2,23606797749979 sqrt(3)=1,73205080756888 sqrt(1)=1

Oczywiście metoda Select nie musi w ogóle używać typu anonimowego — mogliśmy zwyczajnie wybrać wyłącznie pierwiastek i pominąć oryginalną wartość. W takim przypadku wynik byłby typu IEnumerable. Ewentualnie mogliśmy samodzielnie napisać typ zawierający wartość całkowitą i jej pierwiastek kwadratowy, ale w przypadkach takich jak ten najłatwiej jest użyć typu anonimowego.

Metody rozszerzające w .NET 3.5

327

Na zakończenie naszej analizy Enumerable przyjrzyjmy się jeszcze jednej metodzie tego typu — OrderBy.

10.3.5.Sortowanie przy użyciu OrderBy Sortowanie jest powszechną operacją podczas przetwarzania danych. W LINQ ta operacja jest wykonywana przy użyciu metod OrderBy lub OrderByDescending. Jeśli potrzebujesz posortować po więcej niż jednej właściwości danych, po pierwszym wywołaniu pojawia się ThenBy lub ThenByDescending. Możliwość sortowania po wielu właściwościach była dostępna już wcześniej pod postacią jednego skomplikowanego porównania, ale o wiele prościej jest przedstawić całe zadanie jako serię prostych porównań. Aby to zademonstrować, zamierzam wprowadzić małą zmianę do wykonywanych przez nas operacji. Zaczniemy od ustalenia przedziału danych od –5 do 5 (przedział domknięty — razem 11 wartości), a następnie dokonamy projekcji na typ anonimowy zawierający oryginalną wartość i jej potęgę kwadratową (w przeciwieństwie do użytego wcześniej pierwiastka). Na końcu posortujemy według potęg, a następnie oryginalnych liczb. Pokazuje to listing 10.10. Listing 10.10. Sortowanie sekwencji według dwóch właściwości var collection = Enumerable.Range(-5, 11) .Select(x => new { Original = x, Square = x * x }) .OrderBy(x => x.Square) .ThenBy(x => x.Original); foreach (var element in collection) { Console.WriteLine(element); }

Zauważ, że — pomijając wywołanie Enumerable.Range — treść kodu niemal dokładnie odpowiada opisowi słownemu. Tym razem pozwoliłem, aby formatowanie wyniku zostało wykonane przez implementację ToString typu anonimowego. Wynik jest następujący: { { { { { { { { { { {

Original Original Original Original Original Original Original Original Original Original Original

= = = = = = = = = = =

0, Square = 0 } -1, Square = 1 } 1, Square = 1 } -2, Square = 4 } 2, Square = 4 } -3, Square = 9 } 3, Square = 9 } -4, Square = 16 } 4, Square = 16 } -5, Square = 25 } 5, Square = 25 }

Zgodnie z naszym zamiarem główną właściwością sortującą jest Square, ale dla dwóch tych samych wartości potęgi liczba ujemna jest zawsze umieszczana przed liczbą dodatnią. Napisanie pojedynczego porównania, które zrealizowałoby to samo zadanie (w ogólnym przypadku istnieją triki matematyczne pozwalające na poradzenie sobie z tego typu przykładem), byłoby o wiele trudniejsze, i to do tego stopnia, że nie chciałbyś umieszczać powstałego kodu w miejscu wywołania jako wyrażenia lambda.

328

ROZDZIAŁ 10

Metody rozszerzające

Jedną rzeczą wartą zauważenia jest to, że porządkowanie nie zmienia istniejącej kolekcji — zwracana jest nowa sekwencja, która wydaje te same dane, jakie zwróciłaby oryginalna sekwencja, tyle że posortowane. Porównaj to zachowanie z zachowaniem metod List.Sort i Array.Sort, które zmieniają porządek elementów w samej liście lub tablicy. Zadaniem operatorów LINQ jest unikanie efektów ubocznych: nie wpływają one na swoje dane wejściowe i nie wprowadzają żadnych innych zmian w środowisku, chyba że iterujesz po kolekcji, która ze swojej natury jest wyposażona w pewien stan (przykładem może być czytanie ze strumienia sieciowego), lub źródłem efektu ubocznego jest argument delegatowy. Jest to podejście z programowania funkcjonalnego, które prowadzi do powstania kodu bardziej czytelnego, łatwiejszego w testowaniu, komponowaniu, bardziej przewidywalnego, bezpiecznego wątkowo i odpornego na błędy. Widzieliśmy zaledwie kilka z metod rozszerzających dostępnych w klasie Enumerable, ale mam nadzieję, że jesteś w stanie docenić ich zgrabność wynikającą z połączenia w łańcuch. W następnym rozdziale zobaczymy, jak takie połączenie może zostać wyrażone w inny sposób przy użyciu składni dostarczonej przez C# 3 (wyrażenia kwerendowe), a także innych operatorów, których tutaj nie omówiliśmy. Pamiętaj, że nie ma obowiązku używania wyrażeń kwerendowych — często prościej jest wykonać kilka wywołań metod klasy Enumerable, używając metod rozszerzających do połączenia operacji w łańcuch. Skoro widzieliśmy, jak cały ten mechanizm działa na przykładzie naszej kolekcji liczb, przyszła pora na spełnienie obietnicy i pokazanie bardziej rzeczywistych sytuacji.

10.3.6.Przykłady logiki biznesowej z użyciem łańcuchowania Wiele z naszej pracy programistycznej sprowadza się do przenoszenia danych. Prawdę mówiąc, w wielu aplikacjach jest to jedyna użyteczna rzecz, jaką robimy — interfejs użytkownika, usługi sieciowe, bazy danych i inne komponenty istnieją często wyłącznie w celu pobrania danych z jednego miejsca, przekształcenia ich z jednej formy w inną i przekazania dalej. Nie powinno nas dziwić, iż metody rozszerzające, którym przyglądaliśmy się w tej sekcji, sprawdzają się przy rozwiązywaniu problemów biznesowych. Dam kilka przykładów, które bez wątpienia pozwolą Ci się zastanowić nad swoimi własnymi wymogami logiki biznesowej oraz możliwościami rozwiązania ich w sposób bardziej ekspresyjny przez C# 3 i klasę Enumerable. Każdy przykład będzie opatrzony jednym zapytaniem — powinno ono wystarczyć do zrozumienia przeznaczenia kodu bez zbędnego bagażu. Działająca wersja kodu znajduje się na stronie książki. Agregacja — sumowanie wynagrodzenia Pierwszy przykład dotyczy firmy składającej się z kilku działów. Każdy dział posiada pewną liczbę pracowników, a każdy z pracowników ma swoje wynagrodzenie. Załóżmy, że chcemy wykonać raport całkowitego kosztu wynagrodzeń w każdym dziale, poczynając od generującego największe koszty. Zapytanie jest proste: company.Departments .Select(dept => new { dept.Name,

Metody rozszerzające w .NET 3.5

329

Cost = dept.Employees.Sum(person => person.Salary) }) .OrderByDescending(deptWithCost => deptWithCost.Cost);

To zapytanie używa typu anonimowego do przechowywania nazwy wydziału (używając inicjalizatora projekcji) i sumy wynagrodzeń wszystkich pracowników wewnątrz działu. Sumowanie wynagrodzeń korzysta z niewymagającej tłumaczenia metody rozszerzającej Sum, należącej ponownie do klasy Enumerable. Gdybyś chciał uzyskać oryginalną referencję do wydziału, musiałbyś zmienić tylko typ anonimowy użyty w metodzie Select. Grupowanie — zliczanie błędów przypisanych programistom Jestem pewien, że jeśli jesteś profesjonalnym programistą, z pewnością widziałeś wiele narzędzi do zarządzania projektami, które oferują różnego rodzaju statystyki. Jeżeli masz dostęp do surowych danych, LINQ pozwoli Ci przekształcić je w dowolnie wybrany sposób. W ramach prostego przykładu możemy przyjrzeć się liście programistów oraz liczbie przypisanych im w danej chwili błędów: bugs.GroupBy(bug => bug.AssignedTo) .Select(list => new { Developer = list.Key, Count = list.Count() }) .OrderByDescending(x => x.Count);

Wyrażenie używa metody rozszerzającej GroupBy, która grupuje oryginalną kolekcję według projekcji (w tym przypadku programisty przypisanego do naprawienia błędu), zwracając wynik w postaci IGrouping. GroupBy posiada wiele przeciążeń, ale ja użyłem wersji najprostszej, a następnie wybrałem klucz (nazwisko programisty) i liczbę przypisanych do niego błędów. Na końcu uporządkowałem wynik, aby pokazać w pierwszej kolejności programistów z największą liczbą błędów. Jednym z problemów związanych z analizą klasy Enumerable może być wywnioskowanie, co dokładnie się dzieje — na przykład jedno z przeciążeń metody GroupBy posiada cztery parametry typu i pięć parametrów zwykłych (z których trzy to delegaty). Najważniejsze to nie panikować — podążaj według algorytmu przedstawionego w rozdziale 3., przypisując różne typy do każdego parametru typu, aż osiągniesz konkretny przykład wyglądu metody. Takie podejście zazwyczaj znacznie ułatwia zrozumienie działania. System śledzenia błędów będzie stanowił nasze przykładowe dane, kiedy będziemy się zajmować wyrażeniami kwerendowymi w następnym rozdziale. Przedstawione przykłady nie są szczególnie skomplikowane, ale mam nadzieję, że dzięki nim dostrzeżesz potęgę, jaka tkwi w łańcuchowym łączeniu metod, w którym każda metoda przyjmuje oryginalną kolekcję i zwraca (w takiej lub innej formie) kolejną przez przefiltrowanie pewnych wartości, posortowanie ich, przekształcenie elementu, złączenie wartości lub wykonanie innych operacji. W wielu przypadkach można odczytać powstały kod na głos i natychmiast zrozumieć jego znaczenie. Często też kod ten jest o wiele prostszy od swojego odpowiednika w poprzednich wersjach C#. Zobaczyliśmy metody rozszerzające przygotowane dla nas przez innych. Teraz zastanowimy się, kiedy warto je samodzielnie utworzyć.

330

ROZDZIAŁ 10

Metody rozszerzające

10.4. Wskazówki i uwagi odnośnie do użycia Podobnie jak zmienne lokalne o typie niejawnym, metody rozszerzające wzbudzają kontrowersje. Trudno byłoby utrzymać tezę, że w wielu przypadkach utrudniają one całościowe zrozumienie celu kodu, ale jednocześnie do pewnego stopnia zasłaniają szczegóły wywołań konkretnych metod. Można to ująć w słowa jednego z moich wykładowców na uniwersytecie: „Ukrywam prawdę, aby pokazać ci większą prawdę” — metody rozszerzające są wspaniałe, jeżeli wierzysz, że najważniejszym aspektem kodu jest jego wynik. Jeżeli większe znaczenie ma dla Ciebie implementacja, wtedy bardziej przejrzyste jest jawne wywołanie metody statycznej. Wszystko sprowadza się do różnicy pomiędzy tym, co robi kod, a tym, jak to robi. Przyjrzeliśmy się użyciu metod rozszerzających w klasach narzędziowych, a także podczas łańcuchowego łączenia metod. Zanim przejdziemy od omawiania dalszych wad i zalet, warto przywołać kilka cech metod rozszerzających, które mogą nie być tak oczywiste.

10.4.1.„Rozszerzanie świata” i wzbogacanie interfejsów Wes Dyer, były programista w zespole kompilatora C#, prowadzi fantastyczny blog opisujący różnorakie zagadnienia (zobacz http://mng.bz/1CYo). Moją uwagę przykuł szczególnie jeden z jego wpisów, poświęcony metodom rozszerzającym (zobacz http://mng.bz/I4F2). Wpis ma tytuł „Extending the World” („Rozszerzanie świata”) i mówi o tym, jak metody rozszerzające mogą ułatwić czytanie kodu przez faktyczne zaadaptowanie Twojego środowiska do Twoich potrzeb: Zwykle w przypadku jakiegoś problemu programista ma w zwyczaju rozbudowywać rozwiązanie aż do momentu, kiedy spełni ono określone oczekiwania. Teraz można rozszerzać świat, tak aby spełniał oczekiwania, zamiast rozbudowywać rozwiązania do momentu, kiedy tak się stanie. Jeśli biblioteka nie spełnia Twoich oczekiwań, po prostu ją rozszerz. Ma to swoje implikacje sięgające poza przypadki użycia, w których zastosowałbyś klasę narzędziową. Zazwyczaj programiści zaczynają tworzyć klasy narzędziowe, kiedy zauważają ten sam kod powtarzający się w wielu różnych miejscach, ale celem rozszerzania biblioteki jest nie tylko unikanie duplikacji kodu, ale również dbanie o jego przejrzystość. Obecność metod rozszerzających w kodzie wywołującym może sprawiać wrażenie, jakby używana biblioteka była bogatsza, niż jest w rzeczywistości. Widzieliśmy to już na przykładzie IEnumerable. W przypadku tego typu nawet najprostsza implementacja wydaje się mieć szeroki zakres dostępnych operacji, takich jak sortowanie, grupowanie, projekcja i filtrowanie. Oczywiście korzyści nie są ograniczone jedynie do interfejsów — możesz również „rozszerzać świat” przez enumeracje, klasy abstrakcyjne itd. Środowisko .NET udostępnia dobry przykład jeszcze innego użycia metod rozszerzających — płynne interfejsy.

Wskazówki i uwagi odnośnie do użycia

331

10.4.2.Płynne interfejsy W Wielkiej Brytanii nadawano swego czasu program telewizyjny zatytułowany Catchphrase („Złap frazę”). Zadaniem uczestników było odgadnięcie zaszyfrowanej wersji pewnego wyrażenia lub powiedzenia, przedstawionej w formie animacji wyświetlanej na ekranie. Prowadzący program starał się często pomóc uczestnikom, mówiąc: „Powiedz, co widzisz”. I to jest, mniej więcej, koncepcja stojąca u podstaw płynnych interfejsów (ang. fluent interfaces) — jeśli przeczytasz kod dosłownie, jego przeznaczenie samo rzuci się w oczy z ekranu, tak jakby było zapisane przy użyciu języka naturalnego. Termin został wymyślony przez Martina Fowlera (zobacz http://mng.bz/3T9T) i Erica Evansa. Jeśli znane jest Ci zagadnienie języków dziedzinowych (ang. domain-specific language, DSL), być może zastanawiasz się, jaka różnica występuje pomiędzy tymi językami a interfejsami płynnymi. Wiele napisano na ten temat i wygląda na to, iż osiągnięto konsensus w postaci twierdzenia, że języki dziedzinowe mają większą swobodę pod względem tworzenia własnej składni i gramatyki, podczas gdy płynne interfejsy są ograniczone przez język nadrzędny (w naszym przypadku C#). Dobrymi przykładami płynnych interfejsów w środowisku są metody OrderBy i ThenBy. Przy odrobinie wysiłku włożonego w interpretację wyrażenia lambda kod sam wyjaśnia, co robi. W przypadku naszego poprzedniego przykładu z liczbami mogliśmy bez większego wysiłku przeczytać: „Posortuje po potędze, a następnie po liczbie oryginalnej”. Wyrażenia przedstawiają się jako całe zdania, a nie tylko związki rzeczownika i czasownika. Pisanie płynnych interfejsów może wymagać zmiany sposobu myślenia. Nazwy metod nie mogą dłużej bazować na tradycyjnej formie opisowej z użyciem czasowników. W płynnym interfejsie bardziej odpowiednimi nazwami często okazują się takie słowa jak And, Then i If. Same metody na ogół nie robią nic więcej poza przygotowaniem kontekstu dla kolejnych wywołań, na ogół zwracając typ, który tworzy połączenie pomiędzy kolejnymi wywołaniami. Rysunek 10.2 pokazuje przykład takiego połączenia. Zostały użyte wyłącznie dwie metody rozszerzające (działające na typach int i TimeSpan), ale właśnie one wprowadzają widoczną zmianę w czytelności. Rysunek 10.2. Analiza wyrażenia płynnego interfejsu tworzącego spotkanie. Czas spotkania jest specyfikowany przez metody rozszerzające, które przekształcają int na TimeSpan, a następnie TimeSpan na DateTime

Gramatyka przykładu z rysunku 10.2 mogłaby mieć wiele różnych form. Mógłbyś na przykład dodać uczestników do UntimedMeeting lub stworzyć UnatendedMeeting o określonym czasie przed wskazaniem uczestników. Po więcej wskazówek odnośnie do języków dziedzinowych odsyłam do książki Building Domain-Specific Languages in Boo autorstwa Ayende Rahiena (Manning, 2008).

332

ROZDZIAŁ 10

Metody rozszerzające

C# 3 obsługuje jedynie metody rozszerzające — nie ma obsługi właściwości rozszerzających, co ogranicza odrobinę możliwości płynnych interfejsów. Nie możemy stworzyć wyrażeń takich jak 1.week.from.now lub 2.days + 10.hours (które po zastosowaniu odpowiedniego pakietu są poprawne w Groovy — http://mng.bz/0s2a), ale podobny wynik osiągniemy, dokładając kilka nadmiarowych nawiasów. Na pierwszy rzut oka wywołanie metody na liczbie wydaje się dziwne (np. 2.Dollars() lub 3.Meters()), ale trudno zaprzeczyć twierdzeniu, iż znaczenie jest oczywiste. Bez metod rozszerzających taki rodzaj przejrzystości jest zwyczajnie niemożliwy do osiągnięcia, jeśli operujesz na typach — takich jak liczby — nad którymi nie masz żadnej kontroli. W chwili pisania tej książki w środowisku programistów trwają nadal spory odnośnie do płynnych interfejsów: są one rzadko spotykane w większości obszarów, chociaż niektóre biblioteki prototypowe oraz związane z testami jednostkowymi posiadają przynajmniej pewne elementy płynności. Trudno mówić o ich uniwersalnym zastosowaniu, ale w określonych okolicznościach mogą one radykalnie poprawić czytelność wywoływanego kodu. Przykładowo, używając metod rozszerzających z mojej biblioteki MiscUtil, mogę w czytelny sposób iterować po wszystkich dniach mojego życia: foreach (DateTime day in 19.June(1976).To(DateTime.Today) .Step(1.Days()))

Chociaż implementowanie szczegółów związanych z przedziałami czasu jest skomplikowane, metody rozszerzające pozwalają na ogromne uproszczenia, jak na przykład 19.June(1976) i 1.Days(). Pisanie takiego kodu wynika często z własnych przyzwyczajeń. Być może nie nadaje się on do kodu produkcyjnego, ale podobne wyrażenia z dużą przyjemnością zastosujesz w testach jednostkowych. Nie są to jedyne przypadki użycia dostępne dla metod rozszerzających. Ja używałem ich do walidacji argumentów, implementacji alternatywnych podejść do LINQ, dodawania własnych operatorów w LINQ dla Obiektów, ułatwiania budowy złożonych porównań, dodawania bardziej „flagowego” podejścia w typach enumeracyjnych i wielu innych rozwiązaniach. Wciąż pozostaję pod wrażeniem, jak duży wpływ na czytelność — oczywiście przy odpowiednim użyciu — może mieć tak prosta cecha. Kluczowe jest tutaj słowo „odpowiednim”, które łatwiej wypowiedzieć, niż wytłumaczyć.

10.4.3.Rozważne użycie metod rozszerzających Moją intencją w żadnym wypadku nie jest dyktowanie, jak powinieneś pisać swój kod. Możliwe jest napisanie testów, które będą w sposób obiektywny mierzyć czytelność dla przeciętnego programisty, ale ma to znaczenie wyłącznie dla tych, którzy będą używać i utrzymywać Twój kod. W Twoich rękach pozostaje przeprowadzenie wszelkich możliwych konsultacji z odpowiednimi osobami. Wszytko zależy oczywiście od specyfiki danego projektu, ale dobrze jest przedstawić różne opcje i poprosić o ich skomentowanie. W wielu przypadkach taką możliwość dają metody rozszerzające, ponieważ przy ich użyciu możesz pokazać jednocześnie oba rozwiązania — przekształcenie metody w metodę rozszerzającą nie przeszkadza w jej jawnym wywołaniu, tak jak robiłeś to wcześniej. Podstawowym pytaniem, jakie należy zadać, jest to, które postawiłem na początku tej sekcji: „Czy to, co kod robi, jest ważniejsze od tego, jak to robi?”. Odpowiedź jest różna w zależności od osoby i sytuacji, ale są pewne wskazówki, które warto zachować w pamięci:

Wskazówki i uwagi odnośnie do użycia

Każdy członek zespołu programistów powinien mieć świadomość istnienia

333

metod rozszerzających i miejsc, w których mogą być one użyte. Należy unikać zaskakiwania osób zajmujących się utrzymaniem kodu. Umieszczając rozszerzenia w ich własnych przestrzeniach nazw, utrudnisz ich przypadkowe użycie. Nawet jeśli nie jest to oczywiste podczas czytania kodu, piszący go programista powinien mieć przynajmniej świadomość tego, co robi. Używaj konwencji przyjętych w projekcie lub w całej firmie odnośnie do nadawania nazw przestrzeniom nazw. Możesz pójść jeszcze o krok dalej i użyć jednej przestrzeni nazw dla każdego typu rozszerzanego. Na przykład dla klas rozszerzających System.Type mógłbyś utworzyć przestrzeń nazw TypeExtensions. Zastanów się dobrze, zanim zabierzesz się do rozszerzania powszechnie stosowanych typów, takich jak liczby czy object, lub zaczniesz pisać metodę, w której typ rozszerzany jest parametrem typu. Niektóre wytyczne wskazują wręcz, że w ogóle nie powinieneś tego robić. Moim zdaniem takie rozszerzenia mają sens, ale muszą zasłużyć na swoje miejsce w Twojej bibliotece. W tej sytuacji jeszcze ważniejsze jest, aby metoda rozszerzająca miała charakter wewnętrzny lub znajdowała się w swojej własnej przestrzeni nazw. Nie chciałbym na przykład, aby IntelliSense sugerował metodę June w każdym miejscu, w którym użyłem liczby, a jedynie tam, gdzie przynajmniej użyłem jakichś metod rozszerzających związanych z datą i czasem. Decyzja o napisaniu metody rozszerzającej powinna być zawsze w pełni świadoma. Nie powinna być wynikiem przyzwyczajenia — nie każda metoda statyczna zasługuje na przekształcenie na metodę rozszerzającą. Udokumentuj, czy pierwszy parametr (wartość, na której — jak się wydaje — jest wywoływana Twoja metoda) może mieć wartość pustą. Jeśli nie może, sprawdź wartość wewnątrz metody i w razie potrzeby rzuć ArgumentNullException. Zwróć uwagę, aby nie użyć nazwy metody, która ma już swoje znaczenie w typie rozszerzanym. Jeżeli typ rozszerzany jest częścią środowiska lub pochodzi z obcej biblioteki, sprawdź wszystkie nazwy swoich metod rozszerzających za każdym razem, kiedy zmieniasz wersję środowiska lub biblioteki. Przy odrobinie szczęścia nowe znaczenie metody będzie takie samo jak stare (tak było w moim przypadku metody Stream.CopyTo), ale nawet wtedy warto się zastanowić nad oznaczeniem swojej metody rozszerzającej jako wychodzącej z użycia. Podawaj w wątpliwość swój instynkt, ale jednocześnie przyznaj, że ma on wpływ na Twoją produktywność. Tak jak w przypadku typów niejawnych, nie ma sensu zmuszać się do używania cechy, której instynktownie nie lubisz. Postaraj się pogrupować metody rozszerzające w klasy statyczne odnoszące się do tego samego typu rozszerzanego. Czasami związane ze sobą klasy (takie jak DateTime i TimeSpan) mogą być z wyczuciem połączone razem. Unikaj grupowania w tej samej klasie metod rozszerzających związanych z zupełnie odmiennymi typami, takimi jak Stream i string. Zastanów się szczególnie mocno przed dodaniem metod rozszerzających z tym samym typem rozszerzanym i tą samą nazwą w dwóch różnych przestrzeniach nazw, zwłaszcza jeśli możliwe są sytuacje, w których obie z nich będą miały zastosowanie (obie będą miały taką samą liczbę parametrów). Rozsądne wydaje

334

ROZDZIAŁ 10

Metody rozszerzające

się podejście, w którym program przestaje się budować po dodaniu lub usunięciu dyrektywy using, o wiele gorzej jest, jeśli buduje się nadal, ale zmienia swoje zachowanie. Żadna z tych wytycznych nie wprowadza jednoznacznego podziału na to, co dobre i złe — musisz sam wypracować swoje praktyki najlepszego użycia lub unikania metod rozszerzających. Rozsądnym podejściem jest całkowite powstrzymanie się od samodzielnego pisania metod rozszerzających, ale korzystanie nadal z metod odnoszących się do LINQ, a to ze względu na zysk w postaci czytelności kodu. W każdym wypadku warto się przynajmniej zastanowić nad dostępnymi opcjami.

10.5. Podsumowanie Z technicznego punktu widzenia metody rozszerzające są proste — całą cechę można zademonstrować i opisać w prosty sposób. Trudniej rozprawić się w sposób jednoznaczny z tematem zysków (i kosztów) — jest to bardzo drażliwe zagadnienie, a wartość, jaką wnosi to rozwiązanie, bywa różnie oceniana. W tym rozdziale starałem się pokazać wszystkiego po trochu. Na początku, zanim zobaczyliśmy możliwości oferowane z punktu widzenia środowiska, przyjrzeliśmy się temu, co metody rozszerzające pozwalają osiągnąć w samym języku. Można powiedzieć, iż było to łagodne wprowadzenie do LINQ. Do niektórych widzianych w tym rozdziale metod rozszerzających powrócimy, kiedy będziemy zgłębiać wyrażenia kwerendowe w następnym rozdziale. Wtedy zobaczymy również nowe metody rozszerzające. Szeroki wachlarz metod oferuje klasa Enumerable — w tym rozdziale musnęliśmy zaledwie zakres jej możliwości. Można pobawić się, opracowując własny scenariusz (hipotetyczny lub pochodzący z rzeczywistego projektu), a następnie „grzebiąc” w MSDN-ie, aby przekonać się, na jaką pomoc możemy liczyć przy jego realizacji. Zachęcam Cię do stworzenia odizolowanego projektu i użycia go do zabawy z metodami rozszerzającymi — potraktuj to jako trening, a nie pracę. Nie ograniczaj się wyłącznie do tego, co powinieneś osiągnąć w ramach celu krótkoterminowego. W dodatku A znajduje się lista standardowych operatorów kwerendowych LINQ, która w dużym stopniu pokrywa funkcjonalność metod zawartych w klasie Enumerable. Inżynieria oprogramowania pełna jest pączkujących wzorców i praktyk. Pomysły przedostają się z jednych systemów do innych. Jest to jeden z powodów sprawiających, że programowanie jest tak fascynującym zajęciem. Metody rozszerzające pozwalają na pisanie kodu w sposób, który w C# nie był wcześniej dostępny. Zamiast przystosowywać siebie do środowiska, możemy tworzyć płynne interfejsy i zmieniać środowisko w sposób odpowiadający naszym potrzebom. Tym technikom przyglądaliśmy się w tym rozdziale — stanowią one interesujący kierunek rozwoju i jednocześnie demonstrują użycie nowych cech C# — razem lub niezależnie od siebie. Oczywiście rewolucja nie kończy się w tym miejscu. Metody rozszerzające są w zupełności wystarczające dla kilku wywołań. W następnym rozdziale zajmiemy się naprawdę potężnymi narzędziami: wyrażeniami kwerendowymi i LINQ.

Wyrażenia kwerendowe i LINQ dla Obiektów

Ten rozdział omawia: ♦ strumieniowe przekazywanie sekwencji danych, ♦ opóźnione wykonanie, ♦ standardowe operatory kwerendowe, ♦ tłumaczenie wyrażeń kwerendowych, ♦ zmienne zakresu i identyfikatory przezroczyste, ♦ projekcję, filtrowanie i sortowanie, ♦ łączenie i grupowanie, ♦ wybieranie odpowiedniej składni do użycia.

336

ROZDZIAŁ 11

Wyrażenia kwerendowe i LINQ dla Obiektów

Być może masz już dość hymnów pochwalnych na cześć LINQ. Pewne przykłady tej technologii pojawiły się wcześniej w tej książce, a Ty bez wątpienia czytałeś coś na ten temat w sieci. W tym miejscu oddzielimy mity od rzeczywistości: LINQ nie zamieni najbardziej skomplikowanego zapytania w zapytanie jednolinijkowe. LINQ nie oznacza, że już nigdy nie będziesz musiał się zajmować zwykłym

SQL-em. LINQ nie sprawi magicznie, iż nagle staniesz się geniuszem architektonicznym.

Pomimo wszystkich powyższych stwierdzeń LINQ jest nadal najlepszym sposobem wyrażania zapytań, jaki kiedykolwiek widziałem w środowisku zorientowanym obiektowo. Nie jest to złoty środek, ale bardzo funkcjonalne narzędzie w Twoim arsenale programisty. Zajmiemy się dwoma różnymi aspektami LINQ: wsparciem od strony środowiska oraz tłumaczeniem wyrażeń kwerendowych przez kompilator. Drugie z zagadnień może wyglądać początkowo mało przyjaźnie, ale jestem pewien, że z czasem je pokochasz. Wyrażenia kwerendowe są przetwarzane przez kompilator na „zwykły” kod C# 3, który następnie jest kompilowany na ogólnych zasadach. Jest to bardzo zmyślny sposób integrowania zapytań z językiem bez wprowadzania zmian w specyfikacji poza jedną małą sekcją. Większość tego rozdziału stanowi lista translacji przeprowadzanych przez kompilator w fazie przed kompilacją, a także rezultaty osiągane, kiedy wynik korzysta z metod rozszerzających klasy Enumerable. Nie zobaczysz tutaj żadnych wyrażeń SQL ani kodu XML — to wszystko czeka na nas w rozdziale dwunastym. Niniejszy rozdział stanowi podstawę, dzięki czemu łatwiej będzie Ci zrozumieć operacje wykonywane przez ciekawszych dostawców LINQ, kiedy zetkniemy się z przypadkami ich użycia. Wiem, że psuję całą niespodziankę, ale chcę się pozbyć pewnej aury tajemniczości. Nawet bez niej LINQ nadal pozostaje wspaniałą technologią. Zacznijmy od podstaw LINQ oraz sposobów poznawania tej technologii.

11.1. Wprowadzenie do LINQ Tak duży temat jak LINQ wymaga dłuższego wprowadzenia, zanim będziemy mogli zobaczyć działający kod. W tej sekcji przyjrzymy się kilku podstawowym regułom wyznaczającym LINQ, a także modelowi danych, jakiego będziemy używać w przykładach z tego i kolejnego rozdziału. Wiem, że zapewne świerzbi Cię, żeby przejść bezpośrednio do kodu, dlatego będę się starał pisać zwięźle.

11.1.1.Podstawowe koncepcje w LINQ Większość z tego rozdziału jest poświęcona temu, co dokładnie kompilator C# 3 robi z wyrażeniami kwerendowymi, ale będzie ona pozbawiona sensu do momentu, kiedy nie zrozumiemy lepiej idei stojących u podstaw LINQ jako całości. Jednym z proble-

Wprowadzenie do LINQ

337

mów stojących na drodze do zredukowania barier pomiędzy dwoma modelami danych jest to, iż zazwyczaj zachodzi potrzeba stworzenia trzeciego modelu, działającego jako pomost pomiędzy tymi dwoma. Ta sekcja opisuje model LINQ, poczynając od najbardziej istotnego elementu, czyli sekwencji. Sekwencje Wiesz już, na czym polega koncepcja sekwencji: jest ona kapsułkowana przez interfejsy IEnumerable i IEnumerable, którym przyglądaliśmy się z bliska w rozdziale szóstym, kiedy omawialiśmy iteratory. Sekwencja jest podobna do przenośnika taśmowego z ułożonymi na nim elementami. Pobieramy po jednym z nich aż do momentu, kiedy stracisz nimi zainteresowanie lub w sekwencji skończą się dane. Kluczową różnicą pomiędzy sekwencjami a innymi strukturami danych reprezentującymi kolekcje, takimi jak listy i tablice, jest to, że kiedy czytasz sekwencję, na ogół nie jesteś w stanie stwierdzić, ile jeszcze elementów czeka w kolejce, lub nie masz dostępu do dowolnie wybranych elementów, a jedynie do bieżącego. Faktycznie, niektóre sekwencje mogą teoretycznie być nieskończone — mógłbyś na przykład całkiem łatwo stworzyć nieskończoną sekwencję liczb losowych. Oczywiście listy i tablice mogą działać jak sekwencje — tak jak List implementuje IEnumerable — ale sytuacja odwrotna nie zawsze jest możliwa. Dla przykładu nie możesz stworzyć tablicy lub listy o nieskończonej długości. Sekwencje to chleb powszedni LINQ. Kiedy czytasz wyrażenie kwerendowe, powinieneś myśleć o zaangażowanych w nie sekwencjach. Istnieje przynajmniej jedna sekwencja początkowa, która w kolejnych krokach jest przekształcana na kolejne, a czasami również łączona z innymi. W sieci często można znaleźć przykłady wyrażeń kwerendowych LINQ bez jakiegokolwiek wytłumaczenia. Kiedy podzielisz je na fragmenty i przyjrzysz się kolejno każdej sekwencji, wszystko nabierze większego sensu. Takie podejście jest pomocne podczas czytania kodu, ale może również pomóc w trakcie jego pisania. Myślenie w sposób sekwencyjny może być podchwytliwe — czasami wymaga dokonania pewnego skoku myślowego — ale jeśli potrafisz tego dokonać, będzie dla Ciebie niesamowicie pomocne w trakcie pracy z LINQ. Jako prosty przykład weźmy inne wyrażenie kwerendowe wykonywane na liście osób. Zastosujemy te same transformacje co poprzednio, ale z filtrem, który pozostawia w sekwencji wynikowej jedynie osoby dorosłe. var adultNames = from person in people where person.Age >= 18 select person.Name;

Rysunek 11.1 pokazuje powyższe wyrażenie w formie graficznej, rozłożonej na poszczególne kroki. Każda strzałka reprezentuje sekwencję — po lewej stronie znajduje się opis, a po prawej przykładowe dane. Każdy prostokątny bloczek reprezentuje krok w naszym wyrażeniu kwerendowym. Początkowo mamy całą rodzinę (jako obiekty klasy Person), a po przefiltrowaniu sekwencja zawiera jedynie osoby dorosłe (ponownie jako obiekty klasy Person). Ostateczny wynik to imiona osób reprezentowane przez łańcuchy. Za każdym razem bierzemy jedną sekwencję danych i stosujemy do niej operację w celu

338

ROZDZIAŁ 11

Wyrażenia kwerendowe i LINQ dla Obiektów Rysunek 11.1. Proste wyrażenie kwerendowe rozłożone na sekwencje i transformacje biorące udział w przetwarzaniu danych

wyprodukowania nowej sekwencji. Wynikiem nie są łańcuchy „Ewa” i „Jan”, lecz implementacja interfejsu IEnumerable, która poproszona o swoje elementy wyda w pierwszej kolejności „Ewa”, a następnie „Jan”. To był prosty przykład na początek, ale tę samą technikę zastosujemy później do bardziej skomplikowanych wyrażeń kwerendowych, aby je lepiej zrozumieć. Niektóre bardziej zaawansowane operacje wymagają więcej niż jednej sekwencji na wejściu, ale wiąże się z tym nadal o wiele mniej wysiłku niż przy próbie zrozumienia całego wyrażenia za jednym razem. Dlaczego zatem sekwencje są tak ważne? Stanowią one podstawę strumieniowego modelu obsługi danych, czyli takiego, który pozwala nam pobierać i przetwarzać dane tylko wtedy, kiedy tego potrzebujemy. Wykonanie opóźnione i strumieniowanie Kiedy tworzone jest zapytanie z rysunku 11.1, nie są przetwarzane żadne dane. Nie ma w ogóle1 odwołania do oryginalnej listy osób. Zamiast tego w pamięci jest budowana reprezentacja wyrażenia. Tworzone są instancje delegatów reprezentujące predykaty sprawdzające wiek i dokonujące konwersji z osoby na jej imię. Maszyna jest wprawiana w ruch dopiero wtedy, kiedy wynikowa kolekcja IEnumerable zostanie poproszona o swój pierwszy element. Ten aspekt LINQ jest nazywany wykonaniem opóźnionym. Kiedy zostanie zażądany pierwszy element wyniku, transformacja Select prosi transformację Where o jej pierwszy element. Transformacja Where prosi listę o jej pierwszy element, sprawdza, czy spełniony jest warunek predykatu (w tym przypadku jest), i zwraca ten element z powrotem do Select. Ta z kolei wydobywa imię i zwraca je jako wynik. 1

Sprawdzane są jednak parametry na okoliczność wartości pustych. Warto o tym pamiętać, jeśli zamierzasz implementować swoje własne operatory LINQ, co zobaczymy w rozdziale 12.

Wprowadzenie do LINQ

339

CZY MY JUŻ TEGO NIE WIDZIELIŚMY WCZEŚNIEJ? Możesz doznać w tym miejscu déjà vu. O tym wszystkim wspominałem już w rozdziale dziesiątym. Jest to jednak na tyle ważny temat, że warto omówić go ponownie, tym razem bardziej szczegółowo. Jest tego sporo, ale diagram sekwencji sprawia, że całość jest znacznie przejrzystsza. Zamierzam zwinąć wywołania MoveNext i Current do postaci pojedynczej operacji — w ten sposób diagram wygląda o wiele prościej. Pamiętaj jedynie, że za każdym razem, kiedy następuje pobranie, sprawdzany jest również warunek końca sekwencji. Rysunek 11.2 pokazuje dwie pierwsze fazy naszego wyrażenia kwerendowego w czasie działania, kiedy wyświetlamy każdy element wyniku w pętli foreach.

Rysunek 11.2. Diagram obrazujący sekwencję wykonania wyrażenia kwerendowego

340

ROZDZIAŁ 11

Wyrażenia kwerendowe i LINQ dla Obiektów

Jak widzisz na rysunku 11.2, w danej chwili jest przetwarzany wyłącznie pojedynczy element danych. Gdybyśmy zdecydowali się przerwać wyświetlanie wyniku po wyświetleniu „Ewa”, nie wykonalibyśmy nigdy żadnych operacji na pozostałych elementach oryginalnej kolekcji. Chociaż w grę wchodzi tutaj kilka faz, przetwarzanie danych w sposób strumieniowy jest wydajne i elastyczne. Niezależnie od tego, ile danych znajduje się w źródle, w danej chwili musisz wiedzieć tylko o jednym z nich. Jest to przypadek najlepszy. Istnieją sytuacje, w których pobranie wyniku zapytania wymaga przetworzenia wszystkich elementów kolekcji. Przykład takiego pobierania widzieliśmy już w poprzednim rozdziale: metoda Enumerable.Reverse musi pobrać wszystkie dostępne dane, aby jako pierwszy móc zwrócić ostatni element sekwencji wynikowej. To sprawia, że Reverse jest operacją buforującą, która może mieć ogromny wpływ na wydajność (lub nawet wykonalność) całego Twojego zadania. Jeśli nie możesz sobie pozwolić na jednoczesne przechowywanie wszystkich danych w pamięci, nie możesz używać operacji buforujących. Przetwarzanie strumieniowe zależy od tego, jaką operację wykonujesz — niektóre transformacje nie są odkładane na później, ale wykonywane natychmiast po ich wywołaniu. Takie działanie nazywa się wykonaniem natychmiastowym. Ogólnie operacje, które zwracają kolejną kolekcję (zwykle w formie IEnumerable lub IQueryable), używają wykonania opóźnionego, natomiast operacje zwracające pojedynczą wartość używają wykonania natychmiastowego. Operacje szeroko stosowane w LINQ są określane mianem standardowych operatorów kwerendowych — przyjrzyjmy się im teraz pokrótce. Standardowe operatory kwerendowe Standardowe operatory kwerendowe LINQ są kolekcjami transformacji, których znaczenie jest dobrze znane. Dostawcy LINQ są zachęcani do implementowania jak największej liczby tych operatorów, dzięki czemu ich implementacja przestrzega spodziewanego zachowania. Ma to kluczowe znaczenie w procesie zapewniania spójnego środowiska obejmującego różne źródła danych. Oczywiście niektórzy dostawcy LINQ mogą oferować dodatkową funkcjonalność i nie odzwierciedlać w sposób prawidłowy niektórych operatorów, ale przynajmniej każdemu jest oferowana możliwość zachowania spójności. DETALE IMPLEMENTACYJNE STANDARDOWYCH OPERATORÓW. Chociaż standardowe operatory kwerendowe mają jednakowe znaczenie u różnych dostawców, nie oznacza, że zawsze działają dokładnie tak samo, niezależnie od implementacji. Na przykład niektórzy dostawcy LINQ mogą ładować dane całego zapytania, kiedy tylko będzie potrzebny jego pierwszy element — takie zachowanie może być zupełnie zrozumiałe w przypadku odwołania do usługi sieciowej. Podobnie zapytanie działające w LINQ dla Obiektów może mieć odrobinę inną semantykę niż w LINQ dla SQL-a. Nie oznacza to wcale, że LINQ nie spełnia swoich założeń, a jedynie, że Ty musisz zwracać uwagę na to, do jakiego źródła danych odwołujesz się podczas pisania zapytania. Chociaż wspólny zestaw operatorów nie stanowi panaceum na wszystko, jego istnienie stanowi ogromną zaletę.

Wprowadzenie do LINQ

341

C# 3 obsługuje niektóre standardowe operatory kwerendowe poprzez wyrażenia kwerendowe wbudowane w język, ale zawsze można wywołać je ręcznie. Być może zainteresuje Cię, że znacznie więcej operatorów jest wbudowanych w język VB 9. Oczywiście, jak zwykle wiąże się to z pewnym kompromisem pomiędzy wprowadzeniem dodatkowej złożoności związanej z pojawieniem się nowej cechy języka a zyskiem, jaki cecha ta oferuje. Uważam, że zespół C# wykonał pracę godną podziwu — zawsze byłem zwolennikiem względnie prostego języka ze stojącą za nim dużą biblioteką. PRZECIĄŻENIE SŁOWA „OPERATOR”. Słowo operator jest używane do opisania zarówno operatorów kwerendowych (metod takich jak Select i Where), jak i znanych operatorów, takich jak dodawanie, równość itd. To, który z nich mam na myśli, można na ogół wywnioskować z kontekstu — jeśli mówię o LINQ, operator niemal zawsze będzie oznaczał metodę używaną w części wyrażenia. Niektóre z tych operatorów zobaczymy w przykładach pojawiających się w dalszej części tego i kolejnego rozdziału. Nie zamierzam jednak przedstawiać tutaj wszechstronnego przewodnika po wszystkich operatorach, ta książka jest poświęcona głównie C#, a nie LINQ. Nie musisz znać wszystkich operatorów, aby osiągnąć produktywność w LINQ, a Twoje doświadczenie będzie zapewne rosnąć, w miarę jak będziesz pracował z tą technologią. Krótki opis każdego ze standardowych operatorów kwerendowych znajdziesz w dodatku A, a poszczególne przeciążenia są opisane bardziej szczegółowo w MSDN-ie. Kiedy napotkasz problem, postępuj według następującej procedury: jeżeli czujesz, że powinna istnieć wbudowana metoda, która może Ci pomóc, to najprawdopodobniej istnieje! Są jednak wyjątki — znalazłem projekt open source, MoreLINQ, który dodaje kilka nowych operatorów dla LINQ dla Obiektów (zobacz http://mng.bz/TuXP). Również biblioteka Reactive Extensions (http://mng.bz/R7ip) posiada dodatki do modelu wyciągającego LINQ dla Obiektów, a także dla modelu wpychającego, któremu będziemy się przyglądać później. Jeśli standardowe operatory Cię zawiodą, sprawdź oba te projekty, zanim zabierzesz się do budowy własnego rozwiązania. Nawet jeśli przyjdzie Ci napisać własny operator, nie jest to jeszcze katastrofa, chociaż może być przy tym sporo zabawy. W rozdziale dwunastym podpowiem Ci co nieco na ten temat. Skoro jesteśmy przy temacie przykładów, przyszła pora, aby wprowadzić model danych, którego będziemy używać w większości przykładów z tego rozdziału.

11.1.2.Definiowanie przykładowego modelu danych W sekcji 10.3.4 podałem krótki przykład śledzenia błędów jako jednej z sytuacji, w których można zastosować metody rozszerzające i wyrażenia lambda. Ten sam pomysł zastosujemy do niemal wszystkich przykładów w tym rozdziale — jest to w miarę prosty model, ale można nim manipulować na wiele różnych sposobów, aby otrzymać użyteczne dane. Śledzenie błędów to dziedzina, z którą wszyscy programiści są niestety bardzo dobrze zaznajomieni. Dla naszych potrzeb przyjmiemy, że istnieje fikcyjna, mała firma softwarowa o wielkich ambicjach — SkeetySoft. Jej założyciele zdecydowali się podjąć próbę stworzenia pakietu biurowego, odtwarzacza multimediów i komunikatora. W końcu w tych segmentach rynku nie widać dużej konkurencji, nieprawdaż?

342

ROZDZIAŁ 11

Wyrażenia kwerendowe i LINQ dla Obiektów

SkeetySoft zatrudnia pięć osób: dwóch programistów (Deborah i Darren), dwóch testerów (Tera i Tim) oraz menedżera (Mary). Obecnie jest tylko jeden klient — Colin. Wspomnianymi produktami są SkeetyOffice, SkeetyMediaPlayer i SkeetyTalk2. Będziemy się przyglądać błędom wpisanym w maju 2010 roku, używając modelu danych przedstawionego na rysunku 11.3.

Rysunek 11.3. Diagram klas modelu błędów w firmie SkeetySoft

Jak widzisz, nie zapisujemy zbyt wielu danych. Nie ma rzeczywistej historii błędów, ale jest ich wystarczająco dużo, abyśmy mogli zademonstrować cechy wyrażeń kwerendowych w C# 3. Na potrzeby tego rozdziału wszystkie dane będą przechowywane w pamięci. Mamy klasę o nazwie SampleData z właściwościami AllDefects, AllUsers, AllProjects i AllSubscriptions. Każda z nich zwraca odpowiedni typ interfejsu IEnumerable. Właściwości Start i End zwracają instancje klasy DateTime reprezen2

Dział marketingu SkeetySoft nie jest szczególnie kreatywny.

Prosty początek — wybieranie elementów

343

tujące odpowiednio początek i koniec maja. W SampleData znajdują się dwie klasy zagnieżdżone — Users i Projects — dające łatwy dostęp do danego użytkownika lub projektu. Typem, którego przeznaczenie na pierwszy rzut oka może być trudne do odgadnięcia, jest NotificationSubscription. Jego celem jest wysyłanie wiadomości pocztą elektroniczną pod wskazany adres za każdym razem, kiedy dla danego projektu zostanie utworzony lub zmodyfikowany błąd. Przykładowe dane zawierają 41 błędów stworzonych przy użyciu inicjalizatorów C# 3. Nie zamieszczam ich tutaj, ale cały kod znajdziesz na stronie książki. Skoro czynności wstępne mamy już za sobą, zajmijmy się rozgryzaniem zapytań.

11.2. Prosty początek — wybieranie elementów Wcześniej wprowadziłem już pewne ogólne koncepcje dotyczące LINQ. Koncepcje specyficzne dla C# 3 będę przedstawiał w tym rozdziale, kiedy zaistnieje taka potrzeba. Zaczniemy od prostego zapytania (prostszego nawet od tego, które widzieliśmy wcześniej) i będziemy posuwać się w kierunku bardziej skomplikowanych, dzięki czemu nie tylko poszerzysz swoją wiedzę na temat tego, co robi kompilator C# 3, ale także nauczysz się, jak czytać kod LINQ. Wszystkie nasze przykłady będą przestrzegać tego samego wzorca, polegającego na zdefiniowaniu zapytania, a następnie wyświetleniu wyników w oknie konsoli. Nie interesuje nas bindowanie zapytań do kontrolek interfejsu użytkownika i inne podobne zadania — to ma znaczenie, ale nie jest ściśle związane z nauką C# 3. Za punkt startowy naszej analizy tego, co kompilator robi pod maską, oraz nauki zmiennych zakresu użyjemy prostego wyrażenia, które wyświetla jedynie wszystkich użytkowników.

11.2.1.Rozpoczynanie od źródła i kończenie na selekcji Każde wyrażenie kwerendowe w C# 3 zaczyna się w ten sam sposób — od źródła sekwencji danych: from element in źródło

element jest jedynie identyfikatorem poprzedzonym opcjonalnie nazwą typu. W większości przypadków nie będziesz potrzebował nazwy typu i nie zobaczysz jej również w naszym pierwszym przykładzie. źródło jest zwykłym wyrażeniem. Po pierwszej klauzuli może się wydarzyć wiele rzeczy, ale wcześniej czy później musi się pojawić klauzula select lub group. Zaczniemy od rzeczy prostej i łatwej — klauzuli select. Składnia klauzuli select jest równie prosta: select wyrażenie

Klauzula select jest znana jako projekcja. Łącząc oba elementy razem przy użyciu najbardziej trywialnego wyrażenia, jakie można sobie wyobrazić, możemy podać proste (i niezbyt użyteczne) zapytanie. Przedstawia je listing 11.1.

344

ROZDZIAŁ 11

Wyrażenia kwerendowe i LINQ dla Obiektów Listing 11.1. Trywialne zapytanie wyświetlające listę użytkowników var query = from user in SampleData.AllUsers select user; foreach (var user in query) { Console.WriteLine(user); }

Część wytłuszczona to wyrażenie kwerendowe. Nadpisałem metody ToString wszystkich encji w modelu, dzięki czemu wynik działania programu z listingu 11.1 wygląda następująco: User: User: User: User: User: User:

Tim Trotter (Tester) Tara Tutu (Tester) Deborah Denton (Developer) Darren Dahlia (Developer) Mary Malcop (Manager) Colin Carton (Customer)

Możesz się zastanawiać nad użytecznością tego przykładu. W końcu równie dobrze mogliśmy zwyczajnie użyć SampleData.AllUsers bezpośrednio w naszej pętli foreach. My użyjemy jednak wyrażenia kwerendowego — w jego trywialnej postaci — do wprowadzenia dwóch nowych koncepcji. Po pierwsze, przyjrzymy się ogólnej naturze procesu translacji wykonywanej przez kompilator po napotkaniu wyrażenia kwerendowego, a po drugie, omówimy zmienne zakresu.

11.2.2.Translacja kompilatora jako podstawa wyrażeń kwerendowych Wsparcie dla wyrażeń kwerendowych w C# 3 bazuje na translacji tych wyrażeń przez kompilator do postaci zwykłego kodu C#. Translacja jest wykonywana w sposób mechaniczny, bez próby zrozumienia kodu, zastosowania interfejsu typów, sprawdzenia poprawności wywołań metod lub wykonania innej logiki kompilatora. To wszystko jest wykonywane później, po przeprowadzeniu translacji. Tę pierwszą fazę można pod wieloma względami traktować jako krok preprocesora. Przed kompilacją kompilator tłumaczy kod z listingu 11.1 na postać przedstawioną na listingu 11.2. Listing 11.2. Wyrażenie kwerendowe z listingu 11.1 przetłumaczone na wywołanie metody var query = SampleData.AllUsers.Select(user => user); foreach (var user in query) { Console.WriteLine(user); }

Kompilator C# 3 tłumaczy wyrażenie kwerendowe dokładnie na ten kod przed jego dalszą kompilacją. Nie zakłada, że powinien użyć Enumerable.Select lub że List będzie zawierać metodę Select. Tłumaczy jedynie kod i pozostawia następnej fazie

Prosty początek — wybieranie elementów

345

znalezienie odpowiedniej metody — bezpośrednio w typie lub jako metody rozszerzającej3. Parametr może być odpowiednim typem delegatowym lub Expression dla odpowiedniego typu T. W tym miejscu istotna staje się możliwość konwersji wyrażeń lambda zarówno na instancje delegatów, jak i drzewa wyrażeń. Wszystkie przykłady w tym rozdziale będą korzystać z delegatów. Użycie drzew wyrażeń zobaczymy później, kiedy będziemy się przyglądać innym dostawcom LINQ w rozdziale 12. W dalszej części przedstawiam sygnatury niektórych metod wywoływanych przez kompilator. Pamiętaj, że są one wywoływane akurat w kontekście LINQ dla Obiektów — za każdym razem, kiedy parametr jest typu delegatowego (a jest tak w większości przypadków), kompilator użyje wyrażenia lambda jako argumentu, a następnie spróbuje znaleźć metodę z odpowiednią sygnaturą. Równie ważne jest zapamiętanie, że za każdym razem, kiedy po przeprowadzeniu translacji w wyrażeniu lambda pojawi się zwykła zmienna (może nią być na przykład zmienna lokalna wewnątrz metody), zostanie ona przechwycona w taki sam sposób, jaki widzieliśmy w rozdziale 5. Jest to naturalne zachowanie wyrażeń lambda, ale jeśli nie zrozumiesz, które zmienne zostaną przechwycone, możesz być zakłopotany, kiedy zobaczysz otrzymane wyniki zapytania. Specyfikacja języka podaje szczegóły wzorca wyrażeń kwerendowych, który musi zostać zaimplementowany, aby wszystkie wyrażenia kwerendowe mogły działać. Nie jest on jednak zaimplementowany, jak mógłbyś oczekiwać, w formie interfejsu. Ma to sens — pozwala bowiem na zastosowanie LINQ do interfejsów takich jak IEnumerable przy użyciu metod rozszerzających. W tym rozdziale zajmiemy się kolejno każdym elementem wspomnianego wzorca wyrażeń kwerendowych. Jeżeli chcesz się przekonać, w jaki sposób specyfikacja języka definiuje każdą translację, zajrzyj do sekcji 7.16 specyfikacji C# 4. Listing 11.3 udowadnia, w jaki sposób działa translacja kompilatora. Przedstawia on przykładową implementację metod Select i Where, gdzie Select jest zwykłą metodą instancji, natomiast Where jest metodą rozszerzającą. Nasze przykładowe zapytanie zawiera jedynie klauzulę select, dlatego dołączyłem jeszcze klauzulę where, aby pokazać obie metody w użyciu. Załączam pełen listing, ponieważ metody rozszerzające mogą być deklarowane jedynie w kontekście głównego poziomu klas statycznych. Listing 11.3. Translacja kompilatora wywołująca metody sztucznej implementacji LINQ static class Extensions { public static Dummy Where(this Dummy dummy, Func predicate) { 3

Deklaracja metody rozszerzającej Where

Cały mechanizm jest nawet jeszcze bardziej ogólny — kompilator nie wymaga, aby Select było metodą lub by SampleData.AllUsers było dostępne poprzez właściwość. Dozwolone jest wszystko, o ile tylko przetłumaczony kod kompiluje się. Chociaż w niemal każdym przemyślanym przypadku będziesz odwoływał się do metod standardowych lub rozszerzających, na moim blogu umieściłem wpis ze szczególnie niestandardowymi zapytaniami (zobacz http://mng.bz/7E3i). Nie znalazłem użytecznego zastosowania dla tych rozwiązań, ale lubię je, gdyż doskonale podkreślają mechaniczność procesu translacji i ignorowanie znaczenia tłumaczonego kodu.

346

ROZDZIAŁ 11

Wyrażenia kwerendowe i LINQ dla Obiektów Console.WriteLine ("Wywołano Where"); return dummy; }

}

class Dummy { public Dummy Select(Func selector) { Console.WriteLine ("Wywołano Select"); return new Dummy(); } } class TranslationExample { static void Main() { var source = new Dummy(); var query = from dummy in source where dummy.ToString() == "Zignorowano" select "Cokolwiek"; } }

Deklaracja metody instancji Select

Utworzenie źródła danych do wykonania zapytania

Wywołanie metod poprzez wyrażenie kwerendowe

Uruchomienie listingu 11.3 powoduje, zgodnie z naszymi oczekiwaniami, wyświetlenie "Wywołano Where", a następnie "Wywołano Select", ponieważ wyrażenie kwerendowe zostało przetłumaczone na następujący kod: var query = source.Where(dummy => dummy.ToString() == "Zignorowano") .Select(dummy => "Cokolwiek");

Oczywiście nie wykonujemy tutaj żadnego odpytywania ani transformacji, ale przykład ten pokazuje, w jaki sposób kompilator tłumaczy nasze wyrażenie kwerendowe. Jeśli zastanawiasz się, dlaczego wybieramy "Cokolwiek" zamiast po prostu dummy, jest tak, ponieważ wyłącznie projekcja dummy (będąca projekcją typu „nie rób nic”) byłaby w tym szczególnym przypadku usunięta. Przyjrzymy się temu później, w sekcji 11.3.2, ale w tej chwili ważniejszy jest całościowy rodzaj zastosowanej translacji. Musimy się nauczyć, jakich translacji będzie używał kompilator C#, a potem możemy wziąć dowolne wyrażenie kwerendowe, przekształcić je do postaci, która nie używa takich wyrażeń, i przyjrzeć się z tego punktu widzenia, co się dzieje. Zauważ, że w ogóle nie implementujemy IEnumerable w Dummy. Translacja z wyrażenia kwerendowego na zwykły kod nie wymaga obecności tej implementacji, ale w praktyce większość dostawców LINQ udostępnia dane przez IEnumerable lub IQueryable (o czym przekonamy się w rozdziale 12.). Fakt, że translacja nie zależy od żadnego szczególnego typu, a jedynie od nazw metod i parametrów, jest swego rodzaju kaczym typizowaniem czasu kompilacji. Do pewnego stopnia przypomina to sposób znajdywania metody Add przez przedstawione w rozdziale ósmym inicjalizatory kolekcji przy użyciu zwykłego rozwiązywania nazw zamiast stosowania interfejsu zawierającego tę metodę o określonej sygnaturze. Wyrażenia kwerendowe idą o krok dalej — translacja pojawia się wcześnie w procesie kompilacji w celu umożliwienia kompilatorowi wybrania spośród zwykłych metod i metod rozszerzających. Mógłbyś nawet uznać translację za pracę wykonywaną przez oddzielną maszynę preprocesora. Być może uwa-

Prosty początek — wybieranie elementów

347

żasz, że zbytnio roztrząsam ten problem, ale jest to część procesu usuwania przesądów na temat LINQ. Jeśli przepiszesz wyrażenie kwerendowe na serię wywołań metod, robiąc w praktyce to samo, co zrobiłby kompilator, nie wpłyniesz na wydajność, a Twoje zapytanie nie zmieni ani odrobinę swojego zachowania. Są to po prostu dwa różne sposoby reprezentacji tego samego kodu. DLACZEGO from … where … select ZAMIAST select … from … where? Wielu programistów jest od początku zdziwionych porządkiem klauzul w wyrażeniach kwerendowych. Wyglądają one jak SQL, tyle że pisany od tyłu. Jeśli wrócisz na chwilę do procesu tłumaczenia na metody, zobaczysz główną przyczynę takiej postaci. Wyrażenie kwerendowe jest przetwarzane w takiej samej kolejności, w jakiej jest zapisywane: zaczynamy od źródła przedstawionego w klauzuli from, następnie filtrujemy je w klauzuli where i na końcu dokonujemy projekcji w klauzuli select. Innym sposobem spojrzenia na to jest przeanalizowanie diagramów pojawiających się w tym rozdziale. Dane płyną z góry na dół, a bloki pojawiają się w diagramie w takiej samej kolejności, w jakiej są uszeregowane odpowiadające im klauzule w wyrażeniu kwerendowym. Przekonasz się do tego rozwiązania, kiedy przezwyciężysz początkowy dyskomfort spowodowany jego nieznajomością. Ja już się przekonałem. Być może w pewnym momencie zaczniesz zadawać to samo pytanie odnośnie do SQL-a. Wiemy już zatem, że ma miejsce translacja na poziomie kodu źródłowego — jest jeszcze jedna ważna koncepcja, którą musimy poznać, zanim przejdziemy dalej.

11.2.3.Zmienne zakresu i projekcje nietrywialne Przyjrzyjmy się ponownie, tym razem bardziej szczegółowo, naszemu pierwotnemu zapytaniu. Nie analizowaliśmy identyfikatora w klauzuli from ani wyrażenia w klauzuli select. Rysunek 11.4 pokazuje ponownie całe wyrażenie z etykietą przy każdej części, wyjaśniającą jej przeznaczenie. Rysunek 11.4. Proste wyrażenie kwerendowe rozdzielone na części składowe

Kontekstowe słowa kluczowe są łatwe do wytłumaczenia — mówią one kompilatorowi, co chcemy zrobić z danymi. Wyrażenie źródła jest normalnym wyrażeniem C# — w tym wypadku właściwością, ale równie dobrze mogłoby to być wywołanie metody lub zmienna.

348

ROZDZIAŁ 11

Wyrażenia kwerendowe i LINQ dla Obiektów

Podchwytliwą częścią są deklaracja zmiennej zakresu i wyrażenie projekcji. Zmienne zakresu nie przypominają innych typów zmiennych. Pod pewnymi względami nie są w ogóle zmiennymi! Są dostępne jedynie w wyrażeniach kwerendowych, a ich celem jest przekazanie bieżącego kontekstu z danego wyrażenia do kolejnego. W danej chwili reprezentują jeden element określonej sekwencji i są używane w translacji kompilatora w celu umożliwienia łatwego przekształcenia innych wyrażeń w wyrażenia lambda. Widzieliśmy już, że nasze oryginalne wyrażenie zostało przekształcone do postaci: SampleData.AllUsers.Select(user => user)

Lewa część wyrażenia lambda — ta, która dostarcza nazwę parametru — pochodzi z deklaracji zmiennej zakresu, a prawa strona z klauzuli select. Jak widać, translacja jest trywialna (w tym przypadku). Wszystko zadziałało dobrze, ponieważ użyliśmy tej samej nazwy po obu stronach. Załóżmy, że zapisalibyśmy nasze zapytanie następująco: from user in SampleData.AllUsers select person

W tym przypadku przetransformowana wersja wyglądałaby w ten sposób: SampleData.AllUsers.Select(user => person)

W tym momencie kompilacja nie udałaby się, ponieważ kompilator nie wiedziałby, do czego odnosi się person. Skoro wiemy już, jak prosty jest to proces, łatwiej przyjdzie nam zrozumieć wyrażenie kwerendowe o nieco bardziej skomplikowanej projekcji. Kolejny listing (11.4) wyświetla jedynie imiona naszych użytkowników. Listing 11.4. Zapytanie wybierające jedynie imiona naszych użytkowników. IEnumerable query = from user in SampleData.AllUsers select user.Name; foreach (string user in query) { Console.WriteLine(user); }

Tym razem jako projekcji używamy user.Name, a wynikiem jest sekwencja łańcuchów, a nie obiektów klasy User. (Aby podkreślić tę uwagę, używam zmiennej o typie jawnym). Tłumaczenie wyrażenia kwerendowego podlega takim samym regułom jak poprzednio i staje się: SampleData.AllUsers.Select(user => user.Name)

Kompilator pozwala na taką postać, ponieważ wybrana z klasy Enumerable metoda rozszerzająca Select ma następującą sygnaturę4: static IEnumerable Select (this IEnumerable source, Func selector)

4

Aby zmieścić sygnatury metod z tego rozdziału na stronie drukowanej, pomijam modyfikator public. W rzeczywistości wszystkie one są publiczne.

Prosty początek — wybieranie elementów

349

Do gry wchodzi, opisany w rozdziale 9., mechanizm wnioskowania typu, który konwertuje wyrażenie lambda na Func. W pierwszej kolejności na podstawie typu właściwości SampleData.AllUsers będącej listą generyczną o typie User wnioskuje, iż TSource jest typem User. W tym momencie mechanizm zna już parametr typu wyrażenia lambda, może zatem rozwiązać user.Name jako wyrażenie odwołania do właściwości zwracające typ string. Stąd wnioskuje, że TResult jest typu string. To z tego powodu wyrażenia lambda pozwalają na stosowanie parametrów o typie niejawnym i dlatego właśnie istnieją tak skomplikowane reguły wnioskowania typów. Są to faktyczne elementy składowe silnika LINQ. DLACZEGO MUSISZ O TYM WSZYSTKIM WIEDZIEĆ? W przeważającej części przypadków możesz zignorować to, co dzieje się ze zmiennymi zakresu. Być może widziałeś już całą masę zapytań i rozumiesz, co pozwalają osiągnąć, bez wiedzy na temat tego, co się dzieje w tle. Takie podejście jest zupełnie zrozumiałe, kiedy wszystko działa (jak ma to miejsce dla przykładów w przewodnikach), ale kiedy coś się popsuje, posiadanie szczegółowej wiedzy okazuje się bardzo cenne. Jeżeli wyrażenie kwerendowe nie kompiluje się, ponieważ kompilator „narzeka”, że nie zna danego identyfikatora, powinieneś się przyjrzeć zmiennym zakresu. Do tej pory widzieliśmy jedynie zmienne zakresu o typie niejawnym. Co się stanie, jeśli w deklaracji umieścimy typ? Odpowiedź tkwi w standardowych operatorach kwerendowych Cast i OfType.

11.2.4.Cast, OfType i zmienne zakresu o typie jawnym W większości wypadków zmienne zakresu mogą posiadać typ niejawny. Tam, gdzie wyspecyfikowany typ jest wszystkim, czego potrzebujesz, wystarczy, że będziesz korzystał z kolekcji generycznych. A co w innym przypadku? Co, jeśli mielibyśmy tablicę ArrayList lub może object[], na której chcielibyśmy wykonać zapytanie? Szkoda by było, gdyby LINQ nie mógł być zastosowany w takich sytuacjach. Na szczęście istnieją dwa standardowe operatory kwerendowe, które przychodzą nam z pomocą: Cast i OfType. Tylko Cast jest obsługiwany bezpośrednio w wyrażeniach kwerendowych, ale w tej sekcji przyjrzymy się obu operatorom. Są one do siebie podobne: oba przyjmują arbitralną sekwencję bez typu (są metodami rozszerzającymi na niegenerycznym typie IEnumerable) i zwracają sekwencję o mocnym typie. Cast wykonuje to zadanie przez rzutowanie każdego elementu na typ docelowy (i wymuszanie błędu w każdym przypadku, kiedy element nie posiada odpowiedniego typu), natomiast OfType wykonuje w pierwszej kolejności test, pomijając wszystkie elementy o niewłaściwym typie. Listing 11 5 demonstruje oba te operatory użyte w prostych metodach rozszerzających pochodzących z klasy Enumerable. Dla odmiany nie będziemy tu używać naszego systemu do śledzenia błędów w firmie SkeetySoft — w końcu tam wszystko jest obłożone mocnym typem! Zamiast tego użyjemy po prostu dwóch obiektów typu ArrayList. Pierwsza lista zawiera wyłącznie łańcuchy, możemy zatem bezpiecznie użyć Cast ´ w celu uzyskania sekwencji łańcuchów. Druga lista ma mieszaną zawartość,

350

ROZDZIAŁ 11

Wyrażenia kwerendowe i LINQ dla Obiektów Listing 11.5. Użycie Cast i OfType do pracy z kolekcjami o słabym typie ArrayList list = new ArrayList { "Pierwszy", "Drugi", "Trzeci" }; IEnumerable strings = list.Cast(); foreach (string item in strings) { Console.WriteLine(item); } list = new ArrayList { 1, "to nie jest int", 2, 3 }; IEnumerable ints = list.OfType(); foreach (int item in ints) { Console.WriteLine(item); }

zatem aby wyciągnąć z niej jedynie liczby całkowite, musimy użyć OfType. Gdybyśmy w drugiej liście zastosowali Cast, przy próbie rzutowania zostałby rzucony wyjątek. Zauważ, że stałoby się to dopiero po wyświetleniu „1” — oba operatory działają strumieniowo, konwertując elementy w miarę ich pobierania. TYLKO KONWERSJE PRZEZ REFERENCJE, ODPAKOWYWANIE I TOŻSAMOŚĆ. W .NET 3.5 SP1 zmieniło się nieznacznie zachowanie operatora Cast. Oryginalnie w .NET 3 5 operator wykonałby więcej konwersji — na przykład użycie Cast na List spowodowałoby przekonwertowanie każdej wartości short na int. W pakiecie serwisowym nr 1 zostałby rzucony wyjątek. Jeżeli chcesz przeprowadzić konwersję niebędącą konwersją referencji lub konwersją związaną z odpakowywaniem (bądź konwersją przez tożsamość), zamiast operatora użyj projekcji Select. Jedynie OfType wykonuje tego typu konwersje i nie rzuca wyjątku w przypadku niepowodzenia. Kiedy wprowadzisz zmienną zakresu z jawnym typem, kompilator skorzysta z wywołania operatora Cast, aby mieć pewność, że sekwencja używana w pozostałej części wyrażenia posiada odpowiedni typ. Pokazuje to poniższy listing (11.6) za pomocą projekcji korzystającej z metody Substring w celu udowodnienia, że sekwencja wygenerowana przez klauzulę from jest sekwencją łańcuchów. Listing 11.6. Użycie zmiennej zakresu o jawnym typie w celu automatycznego wywołania operatora Cast ArrayList list = new ArrayList { "Pierwszy", "Drugi", "Trzeci" }; var strings = from string entry in list select entry.Substring(0, 3); foreach (string start in strings) { Console.WriteLine(start); }

Wynikiem działania listingu 11.6 jest „Pie”, „Dru”, „Trz”, ale bardziej interesujące jest przetłumaczone wyrażenie kwerendowe: list.Cast().Select(entry => entry.Substring(0, 3));

Filtrowanie i porządkowanie sekwencji

351

Bez rzutowania w ogóle nie bylibyśmy w stanie wywołać metody Select, ponieważ metoda rozszerzająca jest zdefiniowana jedynie dla IEnumerable, a nie dla IEnumerable. Nawet jeśli używasz kolekcji o mocnym typie, czasem może być wskazane użycie zmiennej zakresu o jawnym typie. Na przykład mógłbyś mieć kolekcję zdefiniowaną jako List, ale wszystkie jej elementy byłyby instancjami typu MyImplemen ´tation. Używając zmiennej zakresu z jawnym typem MyImplementation, masz dostęp do wszystkich jej elementów bez ręcznego dopisywania rzutowań na przestrzeni całego kodu. Chociaż nie osiągnęliśmy do tej pory szczególnie imponujących wyników, przeszliśmy — z punktu widzenia koncepcji całej technologii — przez sporą część ważnego materiału. Podsumujmy pokrótce najważniejsze punkty: LINQ bazuje na sekwencjach danych, które są przetwarzane strumieniowo wszędzie tam, gdzie jest to możliwe. Utworzenie zapytania nie prowadzi zwykle do jego uruchomienia; większość operacji korzysta z opóźnionego wykonania. Wyrażenia kwerendowe w C# 3 podlegają fazie wstępnego przetwarzania.

W tej fazie są przetwarzane na zwykły kod C#, który jest następnie kompilowany z zastosowaniem ogólnych zasad wnioskowania typu, przeciążania, wyrażeń lambda itp. Zmienne deklarowane w wyrażeniach kwerendowych nie zachowują się tak jak inne zmienne: są zmiennymi zakresu, które pozwalają odwoływać się do danych w sposób spójny w obrębie samego wyrażenia kwerendowego. Wiem, że jest tu sporo dosyć abstrakcyjnych informacji do przełknięcia. Jeśli w Twojej głowie zakwitły myśli, że być może LINQ nie jest warty takiego zachodu, nie przejmuj się. Obiecuję, że jest. Mając za sobą sporo pracy u podstaw, możemy zabrać się za rzeczy naprawdę użyteczne, takie jak filtrowanie i porządkowanie danych.

11.3. Filtrowanie i porządkowanie sekwencji Być może zaskoczy Cię wiedza, że te dwie operacje są jednymi z najprostszych do wytłumaczenia w kontekście transformacji wykonywanych przez kompilator. Dzieje się tak, ponieważ zwracają one zawsze sekwencje o takim samym typie elementów jak w sekwencji wejściowej, co oznacza, że nie musimy się martwić wprowadzaniem nowych zmiennych zakresu. Pewną pomoc będzie również stanowić fakt, iż odpowiednie metody rozszerzające widzieliśmy już w rozdziale 10.

11.3.1.Filtrowanie przy użyciu klauzuli where Zrozumienie klauzuli where jest niesamowicie proste. Składnia wygląda tak: where wyrażenie-filtrujące

Kompilator tłumaczy to na wywołanie metody Where z wyrażeniem lambda, używającym jako parametru odpowiedniej zmiennej zakresu, oraz wyrażeniem filtrującym jako ciałem tej metody. Wyrażenie filtrujące jest stosowane jako predykat do każdego

352

ROZDZIAŁ 11

Wyrażenia kwerendowe i LINQ dla Obiektów

elementu w nadchodzącym strumieniu danych i tylko te elementy, dla których wynikiem jest prawda (true), są obecne w sekwencji wynikowej. Użycie wielokrotnych klauzul where powoduje powstanie wielokrotnych łańcuchowych wywołań metody Where — tylko elementy, które spełniają warunki wszystkich predykatów, stają się częścią sekwencji wynikowej. Kolejny listing (11.7) demonstruje wyrażenie kwerendowe, które znajduje wszystkie otwarte błędy przypisane do Tima. Listing 11.7. Wyrażenie kwerendowe używające kilku klauzul where User tim = SampleData.Users.TesterTim; var query = from defect in SampleData.AllDefects where defect.Status != Status.Closed where defect.AssignedTo == tim select defect.Summary; foreach (var summary in query) { Console.WriteLine(summary); }

Wyrażenie kwerendowe z listingu 11.7 jest tłumaczone na następujący kod: SampleData.AllDefects.Where(defect => defect.Status != Status.Closed) .Where(defect => defect.AssignedTo == tim) .Select(defect => defect.Summary)

Wynik działania listingu 11.7 jest następujący: Installation is slow Subtitles only work in Welsh Play button points the wrong way Webcam makes me look bald Network is saturated when playing WAV file

Oczywiście, zamiast pisać kilka klauzul where, moglibyśmy napisać pojedyncze wyrażenie zawierające w środku dwa warunki. W niektórych przypadkach może to poprawić wydajność, ale warto również pamiętać o czytelności wyrażenia. Po raz kolejny dodam, że jest to kwestia bardzo subiektywna. Moje osobiste podejście polega na łączeniu warunków, które są ze sobą logicznie powiązane, ale trzymaniu oddzielnie tych, w których taka relacja nie zachodzi. W tym przypadku obie części wyrażenia wiążą się bezpośrednio z błędem (ponieważ tylko to zawiera nasza sekwencja), więc ich połączenie miałoby sens. Warto spróbować obu podejść, aby się przekonać, które z nich jest bardziej przejrzyste. Za chwilę spróbujemy zastosować pewne reguły porządkowe do naszego zapytania, ale wcześniej powinniśmy się przyjrzeć pewnemu detalowi mającemu związek z klauzulą select.

11.3.2.Zdegenerowane wyrażenia kwerendowe Skoro zajmujemy się w miarę prostą translacją, wróćmy na chwilę do uwagi, którą wygłosiłem wcześniej, w punkcie 11.2.2, kiedy po raz pierwszy wprowadziłem translację kompilatora. Do tej pory wszystkie nasze przetłumaczone wyrażenia kwerendowe zawierały

Filtrowanie i porządkowanie sekwencji

353

wywołanie metody Select. Co się dzieje, kiedy klauzula select nie robi nic i zwraca tę samą sekwencję, jaką otrzymała na wejściu? Kompilator usuwa to wywołanie metody Select, ale tylko wtedy, gdy w wyrażeniu kwerendowym znajdują się inne operacje do wykonania. Na przykład poniższe wyrażenie wybiera wyłącznie wszystkie błędy w systemie: from defect in SampleData.AllDefects select defect

Takie zachowanie jest znane pod pojęciem zdegenerowanego wyrażenia kwerendowego. Kompilator specjalnie generuje wywołanie metody Select, mimo że sprawia ono wrażenie, jakby niczego nie robiło: SampleData.AllDefects.Select(defect => defect)

Jest jednak duża różnica pomiędzy tym wyrażeniem a użyciem bezpośrednio Sample ´Data.AllDefects. Elementy zwrócone przez obie sekwencje są takie same, jednak wynikiem metody Select jest tylko sekwencja elementów, ale nie kolekcja źródłowa. Wynikiem wyrażenia kwerendowego nie jest nigdy ten sam obiekt, który reprezentuje dane wejściowe, chyba że dostawca LINQ został kiepsko zaprojektowany. To może mieć znaczenie z punktu widzenia integralności danych — dostawca może zwrócić mutowalny wynik, gdyż wie, że zmiany w zwróconej sekwencji danych nie wpłyną na dane źródłowe nawet w przypadku zdegenerowanego wyrażenia kwerendowego. W przypadku innych operacji nie ma potrzeby, aby kompilator zachowywał „bezczynną” klauzulę select. Załóżmy na przykład, że zmienimy wyrażenie kwerendowe z listingu 11.7 na wybierające cały błąd zamiast wyłącznie imienia: from defect in SampleData.AllDefects where defect.Status != Status.Closed where defect.AssignedTo == SampleData.Users.TesterTim select defect

W tym momencie nie potrzebujemy końcowego wywołania metody Select, zatem przetłumaczony kod przyjmuje postać: SampleData.AllDefects.Where(defect => defect.Status != Status.Closed) .Where(defect => defect.AssignedTo == tim)

Te reguły rzadko uniemożliwiają pisanie wyrażeń kwerendowych, ale mogą wprawić Cię w zakłopotanie, jeśli zdekompilujesz kod, używając narzędzia takiego jak Reflector — zniknięcie wywołania Select bez żadnego widocznego powodu może Cię zaskoczyć. Mając tę wiedzę pod ręką, spróbujmy poprawić nasze zapytanie tak, aby Tim wiedział, nad czym ma pracować w następnej kolejności.

11.3.3.Porządkowanie przy użyciu klauzuli orderby Często zdarza się, że programiści i testerzy są proszeni o pracowanie w pierwszej kolejności nad najbardziej krytycznymi błędami, zanim zajmą się trywialnymi. Używając prostego zapytania, możemy powiedzieć Timowi, w jakim porządku powinien rozpracowywać otwarte, przypisane do niego błędy. Dokładnie to przy użyciu klauzuli orderby zaprezentowano na kolejnym listingu (11.8), który wyświetla szczegóły wszystkich błędów uporządkowane według priorytetu.

354

ROZDZIAŁ 11

Wyrażenia kwerendowe i LINQ dla Obiektów Listing 11.8. Sortowanie według ciężaru błędów — od najwyższego priorytetu do najniższego User tim = SampleData.Users.TesterTim; var query = from defect in SampleData.AllDefects where defect.Status != Status.Closed where defect.AssignedTo == tim orderby defect.Severity descending select defect; foreach (var defect in query) { Console.WriteLine("{0}: {1}", defect.Severity, defect.Summary); }

Wynik działania listingu 11.8 pokazuje, że odpowiednio posortowaliśmy wyniki: Showstopper: Webcam makes me look bald Major: Subtitles only work in Welsh Major: Play button points the wrong way Minor: Network is saturated when playing WAV file Trivial: Installation is slow

Jak widzisz, mamy dwa główne (ang. major) błędy. W jakiej kolejności powinny one zostać rozwiązane? W tej chwili nie wykazują one żadnego przejrzystego porządku. Zmieńmy nasze zapytanie, tak aby po posortowaniu według ciężaru w porządku malejącym błędy były sortowane po ostatnim czasie modyfikacji w porządku rosnącym. Oznacza to, że Tim zajmie się w pierwszej kolejności błędami poprawionymi dawno temu, zanim zajmie się tymi naprawionymi niedawno. Wymaga to jedynie dodatkowego wyrażenia w klauzuli orderby, tak jak pokazuje to listing 11.9. Listing 11.9. Porządkowanie według ciężaru błędu, a następnie według daty modyfikacji User tim = SampleData.Users.TesterTim; var query = from defect in SampleData.AllDefects where defect.Status != Status.Closed where defect.AssignedTo == tim orderby defect.Severity descending, defect.LastModified select defect; foreach (var defect in query) { Console.WriteLine("{0}: {1} ({2:d})", defect.Severity, defect.Summary, defect.LastModified); }

Poniżej znajduje się wynik działania listingu 11.9. Zauważ odwrócenie porządku dwóch głównych błędów: Showstopper: Webcam makes me look bald (2010-05-27) Major: Play button points the wrong way (2010-05-17) Major: Subtitles only work in Welsh (2010-05-23) Minor: Network is saturated when playing WAV file (2010-05-31) Trivial: Installation is slow (2010-05-15)

Filtrowanie i porządkowanie sekwencji

355

Tak wygląda wyrażenie kwerendowe, ale co dokładnie robi kompilator? Wywołuje metodę OrderBy, a następnie ThenBy (lub w przypadku porządku malejącego — OrderBy ´Descending/ThenByDescending). Nasze wyrażenie kwerendowe zostaje przetłumaczone na postać: SampleData.AllDefects.Where(defect => defect.Status != Status.Closed) .Where(defect => defect.AssignedTo == tim) .OrderByDescending(defect => defect.Severity) .ThenBy(defect => defect.LastModified)

Skoro widzieliśmy już przykład, możemy przyjrzeć się ogólnej składni klauzuli orderby. Składa się ona ze słowa kontekstowego orderby, a następnie jednego lub kilku uporządkowań. Uporządkowanie jest zwykłym wyrażeniem (mogącym używać zmiennych zakresu), za którym opcjonalnie pojawia się słowo ascending lub descending, oznaczające odpowiednio kierunek rosnący lub malejący (domyślnie obowiązuje kierunek rosnący). Główne uporządkowanie jest tłumaczone na wywołanie OrderBy lub OrderBy ´Descending, a kolejne na ThenBy lub ThenByDescending. Ich liczba zależy od tego, ile uporządkowań umieściłeś w zapytaniu. Różnica pomiędzy OrderBy i ThenBy jest prosta: OrderBy zakłada, iż posiada kontrolę nad uporządkowaniem, podczas gdy ThenBy rozumie, że jest podległa względem jednego lub większej liczby poprzednich uporządkowań. W LINQ dla Obiektów wywołanie ThenBy jest zdefiniowane jedynie jako metoda rozszerzająca dla typu IOrdered ´Enumerable, będącego typem zwracanym przez OrderBy (a także przez samo wywołanie ThenBy, co pozwala na łańcuchowe łączenie metod). Warto zauważyć, że chociaż możesz użyć kilku klauzul orderby, każda z nich zacznie się od swojego własnego wywołania OrderBy lub OrderByDescending, co oznacza, że ostatecznie zwycięży ostatnia z nich. Do tej pory nie spotkałem się z sytuacją, kiedy taka konstrukcja byłaby użyteczna. O ile nie wykonujesz dodatkowych operacji pomiędzy klauzulami orderby, niemal zawsze powinieneś używać pojedynczej klauzuli zawierającej wielokrotne uporządkowania. Jak wspomniałem w rozdziale 10., zastosowanie uporządkowania wymaga załadowania wszystkich danych (przynajmniej w LINQ dla Obiektów) — oznacza to na przykład, że nie można posortować sekwencji nieskończonej. Mam nadzieję, że powód takiego zachowania jest jasny: nie wiesz, czy nie zobaczysz czegoś, co powinno się pojawić na początku sekwencji wynikowej, do momentu, kiedy nie przejrzysz wszystkich elementów. Jesteśmy mniej więcej w połowie nauki wyrażeń kwerendowych i być może jesteś odrobinę zaskoczony, że nie pojawiły się jeszcze żadne złączenia. Oczywiście, są one bardzo ważne w LINQ, tak samo jak ważne są w SQL-u, ale są również skomplikowane. Obiecuję, że pojawią się one w czasie tego kursu, ale w celu zachowania reguły prezentacji jednej koncepcji w danej chwili musimy najpierw zrobić mały objazd przez klauzulę let. W ten sposób przed dotarciem do złączeń poznamy identyfikatory przezroczyste.

356

ROZDZIAŁ 11

Wyrażenia kwerendowe i LINQ dla Obiektów

11.4. Klauzule let i identyfikatory przezroczyste Większość operatorów, którym musimy się jeszcze przyjrzeć, wykorzystuje identyfikatory przezroczyste. Tak jak w przypadku zmiennych zakresu, jeśli tylko chcesz posiadać w miarę płytki stopień zrozumienia wyrażeń kwerendowych, możesz sobie doskonale poradzić bez znajomości identyfikatorów przezroczystych. Skoro jednak kupiłeś tę książkę, mam nadzieję, że chcesz poznać C# na głębszym poziomie, który (między innymi) pozwoli Ci spojrzeć prosto w twarz błędom kompilatora, by dowiedzieć się, o czym one mówią. Nie musisz wiedzieć wszystkiego o identyfikatorach przezroczystych — nauczę Cię wystarczająco dużo, abyś nie tracił gruntu pod nogami, kiedy zobaczysz jeden z nich w specyfikacji języka. Zrozumiesz również, dlaczego w ogóle są one potrzebne — bardzo pomocny przy tym okaże się przykład. Klauzula let jest najprostszą z dostępnych transformacji korzystających z identyfikatorów przezroczystych.

11.4.1.Wprowadzenie do wykonania pośredniego z użyciem let Klauzula let wprowadza nową zmienną zakresu, której wartość może bazować na innych zmiennych zakresu. Jej składnia jest bardzo prosta: let identyfikator = wyrażenie

Aby wyjaśnić działanie tego operatora bez odwoływania się do innych skomplikowanych operatorów, posłużę się zupełnie abstrakcyjnym przykładem. Załóżmy na moment, że znalezienie długości łańcucha jest kosztowną operacją. Teraz wyobraźmy sobie, że mamy przed sobą zupełnie dziwny system, którego wymogiem jest sortowanie użytkowników według długości ich imion, a następnie wyświetlanie tych imion wraz z ich długościami. Wiem, że to mało prawdopodobne. Listing 11.10 pokazuje jeden z możliwych sposobów rozwiązania tego problemu bez użycia klauzuli let. Listing 11.10. Sortowanie długości imion użytkowników bez użycia klauzuli let var query = from user in SampleData.AllUsers orderby user.Name.Length select user.Name; foreach (var name in query) { Console.WriteLine("{0}: {1}", name.Length, name); }

Powyższy kod działa poprawnie, ale dwukrotnie używa właściwości Length — raz do posortowania użytkowników i drugi raz w kodzie wyświetlającym wyniki. Wszystko wygląda ładnie, bo nawet najwolniejszy komputer poradzi sobie z dwukrotnym znalezieniem długości sześciu łańcuchów! Nie! Powinniśmy unikać redundantnych obliczeń. Aby to zrobić, należy zastosować klauzulę let, która wylicza wyrażenie i udostępnia je pod postacią nowej zmiennej zakresu. Listing 11.11 wykonuje to samo zdanie co listing 11.10, ale używa właściwości Length wyłącznie jeden raz na każdego użytkownika.

Klauzule let i identyfikatory przezroczyste

Listing 11.11. Użycie klauzuli

357

let do zredukowania zbędnych obliczeń

var query = from user in SampleData.AllUsers let length = user.Name.Length orderby length select new {Name = user.Name, Length = length }; foreach (var entry in query) { Console.WriteLine("{0}: {1}", entry.Length, entry.Name); }

Listing 11.11 wprowadza nową zmienną zakresu o nazwie length, która zawiera długość imienia użytkownika (dla bieżącego użytkownika w sekwencji źródłowej). Tej nowej zmiennej używamy następnie zarówno do sortowania, jak i końcowej projekcji. Czy zauważyłeś już problem? Musimy skorzystać z dwóch zmiennych zakresu, podczas gdy przekazywane do metody Select wyrażenie lambda przyjmuje tylko jeden parametr! W tym miejscu do gry wchodzą niewidoczne identyfikatory.

11.4.2.Identyfikatory przezroczyste Na listingu 11.11 mamy dwie zmienne zakresu biorące udział w końcowej projekcji, ale metoda Select operuje wyłącznie na jednej sekwencji. W jaki sposób możemy połączyć zmienne zakresu? Odpowiedzią jest utworzenie typu anonimowego, który zawiera obie zmienne, a następnie zastosowanie zmyślnej translacji, która sprawi wrażenie, jakbyśmy faktycznie mieli dwa parametry dla klauzul select i orderby. Rysunek 11 5 pokazuje sekwencje biorące udział w tym procesie. Klauzula let realizuje swój cel poprzez dodatkowe wywołanie metody Select, utworzenie typu anonimowego dla sekwencji wynikowej, a następnie utworzenie nowej zmiennej zakresu, której nazwa nie może być widoczna ani używana w kodzie źródłowym. Nasze wyrażenie kwerendowe z listingu 11.11 zostaje przetłumaczone na postać: SampleData.AllUsers .Select(user => new { user, length = user.Name.Length }) .OrderBy(z => z.length) .Select(z => new { Name = z.user.Name, Length = z.length})

Każda część zapytania została odpowiednio dostosowana: tam, gdzie w oryginalnym wyrażeniu kwerendowym znajdowało się bezpośrednie odwołanie do user lub length, zostało ono zamienione we wszystkich miejscach znajdujących się za klauzulą let na z.user i z.length. Wybór z jako nazwy jest tutaj arbitralny — kompilator ukrywa szczegóły. TYPY ANONIMOWE SĄ SZCZEGÓŁEM IMPLEMENTACYJNYM. Ściślej rzecz biorąc, dokładny sposób grupowania różnych zmiennych zakresu w celu umożliwienia działania identyfikatorom przezroczystym zależy od implementacji kompilatora C#. Implementacja firmy Microsoft używa typów anonimowych i tak też przedstawia translację sama specyfikacja — dlatego ja również podążyłem za tym trendem. Nawet jeśli inny kompilator zastosuje inne podejście, nie powinno mieć to wpływu na wyniki.

358

ROZDZIAŁ 11

Wyrażenia kwerendowe i LINQ dla Obiektów Rysunek 11.5. Sekwencje pojawiające się na listingu 11.11, w którym klauzula let wprowadza zmienną zakresu length

Jeżeli prześledzisz klauzulę let w specyfikacji języka (sekcja 7.16.2.4), zobaczysz, że opisywana translacja dotyczy przejścia z jednego wyrażenia kwerendowego na inne. Do reprezentacji wprowadzonego identyfikatora przezroczystego jest używana gwiazdka (*). Identyfikator przezroczysty jest następnie usuwany w ramach ostatniego kroku translacji. Nie będę używał tej notacji w tym rozdziale, ponieważ jest ona trudna do uchwycenia i niepotrzebna na naszym poziomie szczegółowości. Mam nadzieję, że — jeśli kiedykolwiek zajdzie taka potrzeba — ta ilość wiedzy wystarczy Ci do samodzielnego analizowania specyfikacji ze zrozumieniem. Dobrą wiadomością jest to, że możemy się teraz przyjrzeć pozostałym translacjom obsługiwanym przez wyrażenia kwerendowe w C# 3. Nie będę zagłębiał się w szczegóły każdego wprowadzonego identyfikatora, ale zwrócę uwagę na sytuacje, w których się pojawiają. Zacznijmy od wsparcia dla złączeń.

Złączenia

359

11.5. Złączenia Jeżeli kiedykolwiek czytałeś cokolwiek na temat SQL-a, prawdopodobnie masz pojęcie na temat tego, czym są złączenia baz danych. Złączenie bierze dwie5 tabele (lub widoki, funkcje zwracające tabelę itp.) i tworzy wynik, dopasowując jeden zestaw wierszy do drugiego. LINQ jest podobny, z tą różnicą, że działa na sekwencjach. Dostępne są trzy typy złączeń, chociaż nie wszystkie używają w wyrażeniu kwerendowym słowa kluczowego join. Zaczniemy od złączenia najbardziej podobnego do wewnętrznego złączenia SQL.

11.5.1.Złączenia wewnętrzne korzystające z klauzul join Złączenia wewnętrzne wymagają dwóch sekwencji. Jedno wyrażenie wyboru klucza jest stosowane do każdego elementu pierwszej sekwencji, a drugie wyrażenie wyboru klucza (które może być zupełnie inne) — do każdego elementu drugiej sekwencji. Wynikiem złączenia jest sekwencja wszystkich par elementów, w których klucz pierwszego elementu jest taki sam jak klucz drugiego elementu. KONFLIKT TERMINOLOGII! SEKWENCJE WEWNĘTRZNE I ZEWNĘTRZNE. Dokumentacja MSDN metody Join, używanej do wyliczania złączeń wewnętrznych, nazywa sekwencje biorące udział w operacji słowami inner i outer. Również parametry metody bazują na tych nazwach. Nie ma to nic wspólnego ze złączeniami wewnętrznymi (ang. inner join) i zewnętrznymi (ang. outer join) — jest to jedynie sposób na rozróżnienie pomiędzy sekwencjami. Możesz myśleć o nich jak o sekwencjach pierwszej i drugiej, lewej i prawej, Jasiu i Małgosi — może to być cokolwiek, co pomaga je od siebie odróżnić. W rozdziale będę rozróżniał je na sekwencję lewą i prawą, dzięki czemu łatwo będzie można stwierdzić, którą z nich mam na myśli, patrząc na diagram. Zazwyczaj zewnętrzna sekwencja odpowiada lewej, a wewnętrzna — prawej. Dwie sekwencje mogą być, czymkolwiek sobie zażyczysz. Jeśli tylko jest to użyteczne, lewa sekwencja może być tą samą sekwencją co prawa (wyobraź sobie na przykład wynajdywanie par ludzi urodzonych tego samego dnia). Jedną istotną rzeczą jest to, że oba wyrażenia wyboru klucza muszą zwracać wynik będący tym samym typem klucza6. Nie możesz złączyć sekwencji ludzi z sekwencją miast, mówiąc, że data urodzin osoby jest taka sama jak populacja miasta — nie ma to żadnego sensu. Ważnym udogodnieniem jest możliwość reprezentacji klucza przez typ anonimowy. Takie rozwiązanie będzie działać, ponieważ typy anonimowe implementują w odpowiedni sposób funkcje równości i skrótu. Jeśli potrzebujesz utworzyć klucz w oparciu o wiele kolumn, sposobem na to są właśnie metody anonimowe. Takie samo podejście może również zostać zastosowane do operacji grupujących, które zobaczymy później. 5

Złączenia mogą obejmować również więcej niż dwie tabele — przyp. tłum.

6

Dopuszczalną sytuacją jest również istnienie dwóch typów kluczy z niejawną konwersją pomiędzy pierwszym a drugim. Jeden z typów musi być lepszym wyborem od drugiego na takiej samej zasadzie, na jakiej kompilator wnioskuje typ tablicy o typie niejawnym. Z mojego doświadczenia wynika, że konieczność rozważania tego typu zachodzi rzadko.

360

ROZDZIAŁ 11

Wyrażenia kwerendowe i LINQ dla Obiektów

Składnia złączenia wewnętrznego może i wygląda na skomplikowaną, ale w rzeczywistości taka nie jest: [zapytanie wybierające lewą sekwencję] join prawa-zmienna-zakresu in prawa-sekwencja on lewe-wyrazenie-wyboru-klucza equals prawe-wyrazenie-wyboru-klucza

Obecność kontekstowego słowa kluczowego equals zamiast zwykłych symboli może budzić niepokój, ale pozwala na łatwiejsze odróżnienie lewego wyrażenia wyboru klucza od prawego wyrażenia tego typu. Często (ale nie zawsze) przynajmniej jedno z wyrażeń wyboru klucza jest trywialne i wydobywa zaledwie jeden element z tej sekwencji. Kompilator używa kontekstowego słowa kluczowego do wydzielenia wyrażeń wyboru klucza w oddzielne wyrażenia lambda. Zdolność do otrzymania kluczy dla każdej wartości (po każdej stronie złączenia) jest istotna zarówno ze względu na wydajność LINQ dla Obiektów, jak i na samą zdolność tłumaczenia zapytania na inne postacie, takie jak SQL. Przyjrzymy się przykładowi z naszego systemu śledzenia błędów. Załóżmy, że właśnie dodaliśmy funkcję notyfikacji i chcemy wysłać pierwszy zestaw wiadomości e-mail dla istniejących błędów. Musimy złączyć listę notyfikacji z listą błędów w miejscu, gdzie projekty do siebie pasują. Takie złączenie wykonuje poniższy listing (11.12). Listing 11.12. Łączenie błędów i subskrypcji powiadomień w oparciu o projekt var query = from defect in SampleData.AllDefects join subscription in SampleData.AllSubscriptions on defect.Project equals subscription.Project select new { defect.Summary, subscription.EmailAddress }; foreach (var entry in query) { Console.WriteLine("{0}: {1}", entry.EmailAddress, entry.Summary); }

Listing 11.12 pokaże każdy z błędów dotyczących odtwarzacza mediów dwukrotnie — raz dla [email protected] i raz dla [email protected] (ponieważ szef naprawdę troszczy się o projekt odtwarzacza). W tym konkretnym przypadku moglibyśmy wykonać złączenie w odwrotny sposób, zamieniając miejscami sekwencję lewą i prawą. Wynikiem byłyby dokładnie te same elementy, ale w innym porządku. Implementacja LINQ dla Obiektów zwraca elementy następująco: najpierw wszystkie pary z pierwszym elementem lewej sekwencji (w porządku prawej sekwencji), następnie wszystkie pary z drugim elementem lewej sekwencji itd. Prawa sekwencja jest buforowana, ale lewa jest strumieniowana, zatem jeśli chcesz złączyć ogromną sekwencję z zupełnie małą, warto — o ile jest to możliwe — umieścić tę małą po prawej stronie. Mimo to operacja jest nadal opóźniana i wstrzymuje odczyt ze wszystkich sekwencji do momentu, kiedy poprosisz o pierwszą parę. Kiedy to nastąpi, odczytuje całość prawej sekwencji w celu zbudowania tablicy kluczy na wartości odpowiadające tym kluczom. Po tej operacji nie ma konieczności czytania czegokolwiek z prawej sekwencji i można zacząć iterować po lewej sekwencji, wydając odpowiednie pary.

Złączenia

361

Jeden z błędów, który może Ci się przydarzyć, to złe rozmieszczenie wyrażeń wyboru klucza. W lewym wyrażeniu wyboru klucza mogą się znajdować jedynie zmienne zakresu pochodzące z lewej sekwencji, zaś w prawym wyrażeniu — wyłącznie zmienne zakresu z prawej sekwencji. Jeżeli zamienisz miejscami sekwencję lewą z prawą, będziesz musiał odwrócić również miejscami lewe i prawe wyrażenia wyboru klucza. Na szczęście kompilator wie, że jest to powszechny błąd, i sugeruje odpowiednie działania. Dla lepszego zobrazowania tego, co się dzieje, rysunek 11.6 przedstawia sekwencje w kolejnych krokach przetwarzania.

Rysunek 11.6. Złączenie z listingu 11.12 w formie graficznej, pokazujące dwie różne sekwencje (błędy i subskrypcje) użyte jako źródła danych

Często możesz chcieć przefiltrować sekwencję, a filtrowanie przed złączeniem jest bardziej wydajne niż filtrowanie po złączeniu. Na tym etapie wyrażenie kwerendowe jest prostsze, jeśli filtrowania wymaga sekwencja po lewej stronie. Gdybyśmy chcieli na przykład pokazać jedynie te błędy, które zostały zamknięte, moglibyśmy użyć następującego wyrażenia kwerendowego:

362

ROZDZIAŁ 11

Wyrażenia kwerendowe i LINQ dla Obiektów from defect in SampleData.AllDefects where defect.Status == Status.Closed join subscription in SampleData.AllSubscriptions on defect.Project equals subscription.Project select new { defect.Summary, subscription.EmailAddress }

Możemy wykonać to samo zapytanie z sekwencjami zamienionymi miejscami, ale wygląda to niechlujnie: from subscription in SampleData.AllSubscriptions join defect in (from defect in SampleData.AllDefects where defect.Status == Status.Closed select defect) on subscription.Project equals defect.Project select new { defect.Summary, subscription.EmailAddress }

Zauważ, że możesz zagnieździć wyrażenie kwerendowe wewnątrz innego — w taki sposób specyfikacja języka opisuje wiele z translacji kompilatora. Zagnieżdżone wyrażenia kwerendowe są użyteczne, ale jednocześnie pogarszają czytelność. Dla zwiększenia czytelności kodu warto zatem poszukać alternatywnego rozwiązania lub użyć zmiennej dla sekwencji po prawej stronie. CZY ZŁĄCZENIA WEWNĘTRZNE SĄ UŻYTECZNE W LINQ DLA OBIEKTÓW? Złączenia wewnętrzne są powszechnie używane w SQL-u. Są one sposobem na nawigację pomiędzy daną encją a encją powiązaną przez relację, zwykle poprzez złączenie klucza obcego w jednej tabeli z kluczem głównym w drugiej. W modelu zorientowanym obiektowo jesteśmy przyzwyczajeni do poruszania się pomiędzy jednym obiektem a innym przy użyciu referencji. Na przykład wydobycie podsumowania błędu i imienia użytkownika przypisanego do pracy nad nim wymagałoby złączenia w SQL-u — w C# często posługujemy się łańcuchem właściwości. Nie potrzebowalibyśmy również złączenia do osiągnięcia tego samego efektu w przykładzie, gdybyśmy w naszym modelu posiadali odwrotne powiązanie z klasy Project do powiązanej z nim listy obiektów klasy NotificationSubscription. Nie oznacza to wcale, że złączenia wewnętrzne nie przydają się w modelu obiektowym, ale nie pojawiają się one w sposób naturalny tak często jak w modelach relacyjnych. Złączenia wewnętrzne są tłumaczone przez kompilator na wywołania metody Join w następujący sposób: leftSequence.Join(rightSequence, leftKeySelector, rightKeySelector, resultSelector)

Sygnatura przeciążenia metody używanej przez LINQ dla Obiektów wygląda następująco (jest to rzeczywista sygnatura z rzeczywistymi nazwami parametrów — stąd obecność referencji o nazwach inner i outer): static IEnumerable Join ( this IEnumerable outer, IEnumerable inner, Func outerKeySelector,

Złączenia

363

Func innerKeySelector, Func resultSelector )

Pierwsze trzy parametry wyjaśniają się samodzielnie, jeśli pamiętasz, że inner i outer powinieneś traktować jako odpowiednio prawy i lewy. Bardziej interesujący jest ostatni parametr. Jest on projekcją dwóch elementów (jednego z lewej sekwencji i jednego z prawej) na pojedynczy element w sekwencji wynikowej. Kiedy za złączeniem pojawia się coś innego niż klauzula select, kompilator wprowadza identyfikator przezroczysty, aby udostępnić zmienne zakresu używane w obu sekwencjach dla późniejszych klauzul, i tworzy typ anonimowy oraz proste mapowanie dla parametru resultSelector. Jeśli jednak następną częścią wyrażenia kwerendowego jest klauzula select, projekcja z tej klauzuli jest używana bezpośrednio jako parametr resultSelector — nie ma sensu tworzyć pary, a następnie wywoływać Select, kiedy możesz wykonać transformację w jednym kroku. Mimo że te dwie operacje zostały ściśnięte do postaci wywołania pojedynczej metody, nadal możesz myśleć o nich jak o kroku „złączenia”, za którym występuje krok „wyboru”. Dzięki temu moim zdaniem powstaje bardziej spójny model myślowy, w którym łatwiej przeprowadza się wnioskowanie. O ile nie oglądasz wygenerowanego kodu, po prostu pomiń optymalizację, którą wykonuje dla Ciebie kompilator. Zapewne ucieszy Cię wiadomość, że znając wyrażenia wewnętrzne, o wiele łatwiej będzie Ci podejść do następnego typu złączenia.

11.5.2.Złączenia grupowe z użyciem klauzul join … into Widzieliśmy, że sekwencja wynikowa pochodząca ze zwykłej klauzuli join składa się z par elementów, po jednym z każdej sekwencji wejściowej. Złączenie grupowe wygląda podobnie pod względem wyrażenia kwerendowego, ale daje zupełnie inny wynik. Każdy element w wyniku złączenia grupowego składa się z elementu lewej sekwencji (poprzez jej oryginalną zmienną zakresu), a także sekwencji wszystkich pasujących elementów z prawej sekwencji, widocznych jako nowa zmienna zakresu wyspecyfikowana przez identyfikator pojawiający się za słowem into w klauzuli join. Zmieńmy nasz poprzedni przykład na taki, w którym pojawi się złączenie grupowe. Listing 11.13 pokazuje wszystkie błędy i notyfikacje wymagane dla każdego z nich, ale rozdziela je według relacji jeden do wielu. Zwróć szczególną uwagę na sposób wyświetlania wyników z użyciem zagnieżdżonej pętli foreach. Listing 11.13. Łączenie błędów z subskrypcjami przy użyciu złączenia grupowego var query = from defect in SampleData.AllDefects join subscription in SampleData.AllSubscriptions on defect.Project equals subscription.Project into groupedSubscriptions select new { Defect=defect, Subscriptions=groupedSubscriptions }; foreach (var entry in query) { Console.WriteLine(entry.Defect.Summary); foreach (var subscription in entry.Subscriptions) {

364

ROZDZIAŁ 11

Wyrażenia kwerendowe i LINQ dla Obiektów Console.WriteLine ("

{0}", subscription.EmailAddress);

} }

Właściwość Subscriptions każdego elementu jest zagnieżdżoną sekwencją subskrypcji pasujących do błędu z tego elementu. Rysunek 11.7 pokazuje, w jaki sposób te dwie sekwencje są łączone razem.

Rysunek 11.7. Sekwencje biorące udział w złączeniu grupowym z listingu 11.13. Krótkie strzałki wskazują sekwencje zagnieżdżone wewnątrz elementów wynikowych. W wyniku niektóre elementy zawierają kilka adresów e-mail dla tego samego błędu

Istotną różnicą pomiędzy złączeniem wewnętrznym a grupowym — a także między złączeniem grupowym a zwykłym grupowaniem — jest to, że złączenie grupowe posiada zgodność jeden do jednego pomiędzy lewą sekwencją i sekwencją wynikową, nawet jeśli pewne elementy w lewej sekwencji nie pasują do żadnych elementów w sekwen-

Złączenia

365

cji prawej. To może mieć znaczenie i jest czasem wykorzystywane do zasymulowania SQL-owego lewostronnego złączenia zewnętrznego. Zagnieżdżona sekwencja jest pusta, kiedy element po lewej stronie nie pasuje do żadnych elementów po prawej stronie. Podobnie jak w przypadku złączeń wewnętrznych, złączenie grupowe buforuje prawą sekwencję, ale strumieniuje lewą. Przykład takiego działania7 pokazuje listing 11.14, który zlicza błędy utworzone każdego dnia maja. Używa on typu DateTimeRange do wygenerowania sekwencji dat w maju jako sekwencji po lewej stronie i projekcji, która wywołuje Count() na zagnieżdżonej sekwencji będącej wynikiem złączenia grupowego8. Listing 11.14. Zliczanie błędów zgłaszanych każdego dnia w maju var dates = new DateTimeRange(SampleData.Start, SampleData.End); var query = from date in dates join defect in SampleData.AllDefects on date equals defect.Created.Date into joined select new { Date = date, Count = joined.Count() }; foreach (var grouped in query) { Console.WriteLine("{0:d}: {1}", grouped.Date, grouped.Count); }

Metoda Count() używa wykonania bezzwłocznego, iterując przez wszystkie elementy sekwencji, na której została wywołana, ale my wywołujemy ją tylko na części projekcyjnej wyrażenia kwerendowego, przez co staje się częścią wyrażenia lambda. To oznacza, że wykonanie jest nadal odroczone — nic nie jest wyliczane do momentu, kiedy wystartuje pętla foreach. Oto pierwsza część wyniku działania programu z listingu 11.14, pokazująca liczbę błędów utworzonych każdego dnia pierwszego tygodnia maja: 2010-05-01: 2010-05-02: 2010-05-03: 2010-05-04: 2010-05-05: 2010-05-06: 2010-05-07:

1 0 2 1 0 1 1

Translacja wykonywana przez kompilator dla złączenia grupowego sprowadza się do wywołania metody GroupJoin w taki sam sposób jak w przypadku Join. Sygnatura Enumerable.GroupJoin wygląda następująco: static IEnumerable GroupJoin( this IEnumerable outer, IEnumerable inner, Func outerKeySelector, 7

Grupowania z uwzględnieniem pustych sekwencji po prawej stronie — przyp. tłum.

8

Nie jest to w pełni funkcjonalna klasa przedziału ogólnego przeznaczenia, lecz prosta implementacja na potrzeby przykładu.

366

ROZDZIAŁ 11

Wyrażenia kwerendowe i LINQ dla Obiektów Func innerKeySelector, Func,TResult> resultSelector )

Wygląda ona niemal identycznie jak w przypadku złączeń wewnętrznych, z tą różnicą, że parametr resultSelector musi współpracować z sekwencją elementów po prawej stronie, a nie tylko z jednym z nich. Podobnie jak w przypadku złączeń wewnętrznych, jeżeli za złączeniem grupowym znajduje się klauzula select, wartością parametru wyrażenia wybierającego metody GroupJoin staje się projekcja, w przeciwnym wypadku wprowadzany jest parametr przezroczysty. W tym przypadku mamy klauzulę select bezpośrednio za złączeniem grupowym, zatem przetłumaczone wyrażenie wygląda następująco: dates.GroupJoin(SampleData.AllDefects, date => date, defect => defect.Created.Date, (date, joined) => new { Date = date, Count = joined.Count() } )

Nasze ostatnie złączenie jest znane pod nazwą złączenia krzyżowego i nie jest ono takie proste, jak mogłoby się początkowo wydawać.

11.5.3.Złączenia krzyżowe i spłaszczanie sekwencji przy użyciu wielokrotnych klauzul from Do tej pory wszystkie nasze złączenia były złączeniami typu equijoin — dopasowanie było wykonywane pomiędzy elementami lewej i prawej sekwencji. Złączenia krzyżowe nie wykonują żadnego dopasowania pomiędzy sekwencjami — wynik zawiera każdą możliwą parę elementów. Jest to realizowane za pomocą dwóch (lub większej liczby) klauzul from. Chwilowo, dla zachowania prostoty, ograniczymy się wyłącznie do dwóch klauzul from — kiedy jest ich więcej, po prostu wykonaj w pamięci złączenie krzyżowe dwóch pierwszych klauzul from, następnie złącz krzyżowo powstałą sekwencję z kolejną klauzulą from itd. Każda dodatkowa klauzula from dodaje swoją własną zmienną zakresu poprzez identyfikator przezroczysty. Listing 11.15 pokazuje proste (i bezużyteczne) złączenie krzyżowe, generujące sekwencję, w której każdy element składa się z użytkownika i projektu. Specjalnie wybrałem dwie zupełnie niezwiązane ze sobą sekwencje, aby pokazać, że faktycznie nie jest wykonywane żadne dopasowywanie elementów. Listing 11.15. Złączenie krzyżowe użytkowników z projektami var query = from user in SampleData.AllUsers from project in SampleData.AllProjects select new { User = user, Project = project }; foreach (var pair in query) { Console.WriteLine("{0}/{1}", pair.User.Name, pair.Project.Name); }

Złączenia

367

Wynik działania programu z listingu 11.15 rozpoczyna się następująco: Tim Trotter/Skeety Media Player Tim Trotter/Skeety Talk Tim Trotter/Skeety Office Tara Tutu/Skeety Media Player Tara Tutu/Skeety Talk Tara Tutu/Skeety Office

Sekwencje biorące udział w produkcji wyniku zostały przedstawione na rysunku 11.8.

Rysunek 11.8. Sekwencje z listingu 11.15 łączące krzyżowo użytkowników z projektami. W wyniku są zwracane wszystkie możliwe kombinacje

Jeśli znasz SQL-a, wszystko do tej pory powinno być jasne — wygląda to jak iloczyn kartezjański uzyskany z zapytania zawierającego kilka tablic. W miarę potrzeby dostępna jest dodatkowa funkcjonalność — prawa sekwencja może zależeć od bieżącej wartości lewej sekwencji. Innymi słowy, każdy element lewej sekwencji jest używany do wygenerowania prawej sekwencji, a następnie lewy element jest łączony w parę z każdym elementem tej nowej sekwencji. Takie zachowanie nie jest złączeniem krzyżowym

368

ROZDZIAŁ 11

Wyrażenia kwerendowe i LINQ dla Obiektów

w jego standardowym znaczeniu. Jest to raczej spłaszczenie sekwencji w pojedynczą sekwencję. Niezależnie od tego, czy używamy prawdziwego złączenia krzyżowego, czy też nie, translacja wyrażenia kwerendowego wygląda tak samo. Aby pojąć proces translacji, musimy zatem zrozumieć bardziej skomplikowany scenariusz. Zanim zagłębimy się w szczegóły, zobaczmy wynik końcowy. Poniższy listing (11.16) przedstawia prosty przykład używający sekwencji liczb całkowitych. Listing 11.16. Złączenie krzyżowe, w którym prawa sekwencja zależy od elementu lewej sekwencji var query = from left in Enumerable.Range(1, 4) from right in Enumerable.Range(11, left) select new { Left=left, Right=right }; foreach (var pair in query) { Console.WriteLine("Left={0}; Right={1}", pair.Left, pair.Right); }

Listing 11.16 rozpoczyna się utworzeniem prostej sekwencji liczb od 1 do 4. Dla każdej z nich tworzymy nowy przedział zaczynający się od 11 i posiadający tyle liczb, ile ma oryginalna sekwencja. Przy użyciu wielokrotnych klauzul from lewa sekwencja jest łączona z każdą z wygenerowanych prawych sekwencji, co daje następujący wynik: Left=1; Left=2; Left=2; Left=3; Left=3; Left=3; Left=4; Left=4; Left=4; Left=4;

Right=11 Right=11 Right=12 Right=11 Right=12 Right=13 Right=11 Right=12 Right=13 Right=14

Metoda, którą wywołuje kompilator w celu wygenerowania tej sekwencji, nazywa się SelectMany. Przyjmuje ona pojedynczą sekwencję (lewą w naszej terminologii), delegat generujący kolejną sekwencję z każdego elementu lewej sekwencji i delegat tworzący element wyniku na podstawie elementu każdej z tych sekwencji. Oto sygnatura metody Enumerable.SelectMany: static IEnumerable SelectMany( this IEnumerable source, Func> collectionSelector, Func resultSelector )

Tak jak w przypadku innych złączeń, jeżeli za częścią wyrażenia będącą złączeniem znajduje się klauzula select, projekcja ta jest używana jako argument końcowy. W przeciwnym razie jest wprowadzany identyfikator przezroczysty, którego celem jest udostępnienie lewej i prawej sekwencji w dalszej części zapytania. Żeby umieścić to wszystko w bardziej konkretnych ramach, oto kod będący wynikiem przetłumaczenia wyrażenia kwerendowego z listingu 11.16:

Grupowania i kontynuacje

369

Enumerable.Range(1, 4) .SelectMany(left => Enumerable.Range(11, left), (left, right) => new { Left = left, Right = right })

Ciekawą cechą metody SelectMany jest jej wykonanie w sposób całkowicie strumieniowy — ponieważ dla każdego wyodrębnionego elementu lewej sekwencji używa świeżo wygenerowanej prawej sekwencji, w danej chwili potrzebuje tylko po jednym elemencie z każdej sekwencji. Porównaj to ze złączeniami wewnętrznymi i grupowymi: oba ładują całą zawartość prawej sekwencji, zanim jeszcze zaczną wydawać jakiekolwiek wyniki. Wybierając typ złączenia oraz pozycję sekwencji (po lewej lub prawej stronie), powinieneś być świadomy jej rozmiaru, a także kosztu związanego z jej wielokrotnym przeliczaniem. Spłaszczająca funkcjonalność metody SelectMany może być bardzo użyteczna. Rozważ sytuację, kiedy będziesz chciał przetworzyć wiersz po wierszu wiele plików dzienników. Możemy przetworzyć dowolną liczbę wierszy przy niemal zerowym nakładzie pracy. Poniższy pseudokod powinien być zrozumiały i jasno przedstawiać użyteczność rozwiązania (odpowiedni kod źródłowy jest dostępny na stronie książki): var query = from file in Directory.GetFiles(logDirectory, "*.log") from line in ReadLines(file) let entry = new LogEntry(line) where entry.Type == EntryType.Error select entry;

Używając zaledwie kilku wierszy kodu, wyciągnęliśmy, przeanalizowaliśmy i przefiltrowaliśmy całą kolekcję plików logu, zwracając sekwencję wpisów reprezentujących błędy. Co najważniejsze, nie musieliśmy załadować nawet jednego pełnego pliku logu do pamięci w pojedynczym przebiegu, nie wspominając już o wszystkich plikach — wszelkie dane zostały przetworzone strumieniowo. Po przeanalizowaniu złączeń ostatnia rzecz, która nam pozostała do przejrzenia, jest odrobinę łatwiejsza w zrozumieniu. Zajmiemy się grupowaniem elementów według klucza i kontynuacją wyrażenia kwerendowego po klauzulach group ... by lub select.

11.6. Grupowania i kontynuacje Częstym wymogiem jest grupowanie sekwencji elementów według jednej z ich właściwości. LINQ pozwala na wykonanie tej operacji poprzez klauzulę group ... by. Oprócz opisania tego ostatniego typu klauzuli wrócimy do jednej z poprzednich (select), aby zobaczyć cechę zwaną kontynuacjami zapytania, która może być zastosowana zarówno do grupowań, jak i projekcji. Zacznijmy od prostego grupowania.

11.6.1.Grupowanie przy użyciu klauzuli group ... by Grupowanie jest na ogół intuicyjne, a LINQ ułatwia jego wykonanie. Wszystko, co musisz zrobić, aby pogrupować sekwencję w wyrażeniu kwerendowym, to użyć klauzuli group ... by o następującej składni: group projekcja by grupowanie

370

ROZDZIAŁ 11

Wyrażenia kwerendowe i LINQ dla Obiektów

Ta klauzula, podobnie jak select, pojawia się na końcu wyrażenia kwerendowego. Na tym nie kończą się podobieństwa pomiędzy obiema klauzulami: wyrażenie projekcja jest takim samym typem projekcji, jakiego używa select. Wynik jest jednak nieco odmienny. Wyrażenie grupowanie określa, według czego jest grupowana sekwencja — klucz grupowania. Końcowym wynikiem jest sekwencja, której każdy element jest sam w sobie sekwencją projekcji elementów, a także posiada właściwość Key, będącą kluczem tej grupy. Połączenie tych elementów jest kapsułkowane przez interfejs IGrouping, który rozszerza IEnumerable. Jeżeli chcesz grupować przez więcej niż jedną wartość, możesz użyć typu anonimowego. Przyjrzyjmy się prostemu przykładowi z systemu błędów SkeetySoft — grupowaniu błędów po ich aktualnym przypisaniu do użytkownika. Zadanie to wykonuje listing 11.17 prezentujący użycie najprostszej formy projekcji, dzięki której sekwencja wynikowa posiada klucz w postaci użytkownika i sekwencję błędów osadzoną w każdym elemencie. Listing 11.17. Grupowanie błędów po przypisanym użytkowniku — trywialna projekcja var query = from defect in SampleData.AllDefects where defect.AssignedTo != null group defect by defect.AssignedTo;

Przefiltrowanie błędów do wyłącznie przypisanych

Grupowanie po przypisanym użytkowniku Użycie klucza elementu (przypisanego użytkownika)

foreach (var entry in query) { Console.WriteLine(entry.Key.Name); foreach (var defect in entry) Iteracja po zagnieżdżonej { sekwencji elementu Console.WriteLine(" ({0}) {1}", defect.Severity, defect.Summary); } Console.WriteLine(); }

Listing 11.17 może być przydatny w codziennym raporcie z budowania, aby szybko sprawdzić, jakim błędom powinna się przyjrzeć każda osoba. Odfiltrowaliśmy wszystkie błędy, które nie potrzebują już dodatkowej uwagi ( ), a następnie pogrupowaliśmy je, używając właściwości AssignedTo. Chociaż w tym przypadku użyliśmy właściwości, wyrażeniem grupującym może być cokolwiek zechcesz — będzie ono zastosowane wobec każdego elementu w sekwencji wejściowej, a ona sama zostanie pogrupowana na podstawie wyniku tego wyrażenia. Zauważ, że grupowanie nie może strumieniować wyników — stosuje wybór na podstawie klucza i projekcję do każdego elementu na wejściu, buforując pogrupowane sekwencje elementów poddanych projekcji. Mimo braku strumieniowania wykonanie jest opóźnione do momentu rozpoczęcia pobierania wyników. Projekcja, którą zastosowaliśmy w grupowaniu ( ), jest trywialna — wybiera jedynie oryginalny element. W miarę jak przechodzimy przez oryginalną sekwencję, każdy element otrzymuje właściwość Key typu User ( ), ponadto każdy element implementuje IEnumerable — sekwencję błędów przypisanych do tego użytkownika ( ). Początek wyniku działania programu z listingu 11.17 wygląda następująco:

Grupowania i kontynuacje

371

Darren Dahlia (Showstopper) MP3 files crash system (Major) Can't play files more than 200 bytes long (Major) DivX is choppy on Pentium 100 (Trivial) User interface should be more caramelly

Po wyświetleniu wszystkich błędów Darrena widzimy błędy Tary, następnie Tima itd. Implementacja utrzymuje listę przypisanych użytkowników, których „widziała” do tej pory, i dodaje nowego za każdym razem, kiedy zachodzi taka potrzeba. Rysunek 11.9 pokazuje sekwencje generowane na przestrzeni całego wyrażenia kwerendowego, co pozwala się lepiej zorientować w tym porządkowaniu. Rysunek 11.9. Sekwencje użyte podczas grupowania błędów według przypisanych użytkowników. Każdy element wyniku posiada właściwość Key i jest jednocześnie sekwencją błędów

Porządek sekwencji błędów w każdym elemencie odpowiada porządkowi oryginalnej sekwencji. Jeżeli zależy Ci na konkretnym uporządkowaniu, rozważ umieszczenie sortowania w samym wyrażeniu kwerendowym, aby całość była bardziej czytelna. Jeśli uruchomisz program z listingu 11.17, przekonasz się, że Mary Malcop nie pojawia się w wyniku, ponieważ nie posiada żadnych błędów przypisanych do siebie.

372

ROZDZIAŁ 11

Wyrażenia kwerendowe i LINQ dla Obiektów

Jeżeli chcesz wyprodukować pełną listę użytkowników i błędów przypisanych do każdego z nich, musisz skorzystać ze złączenia grupowego, takiego jak na listingu 11.14. Dla klauzul grupujących kompilator używa zawsze metody o nazwie GroupBy. Kiedy projekcja w klauzuli grupującej jest trywialna — inaczej mówiąc, kiedy każdy element w oryginalnej sekwencji odpowiada dokładnie temu samemu obiektowi w sekwencji zagnieżdżonej — kompilator używa prostego wywołania metody, która wymaga jedynie wyrażenia grupującego, aby wiedzieć, jak dokonać mapowania każdego elementu na klucz. Dla przykładu wyrażenie kwerendowe z listingu 11.17 jest tłumaczone na postać: SampleData.AllDefects.Where(defect => defect.AssignedTo != null) .GroupBy(defect => defect.AssignedTo)

Kiedy projekcja jest nietrywialna, używana jest nieco bardziej skomplikowana wersja. Listing 11.18 przedstawia przykład projekcji, w której zamiast całego obiektu klasy Defect przechwytujemy jedynie podsumowanie błędu. Listing 11.18. Grupowanie błędów według przypisanego użytkownika — projekcja zachowuje jedynie podsumowanie błędu var query = from defect in SampleData.AllDefects where defect.AssignedTo != null group defect.Summary by defect.AssignedTo; foreach (var entry in query) { Console.WriteLine(entry.Key.Name); foreach (var summary in entry) { Console.WriteLine(" {0}", summary); } Console.WriteLine(); }

Różnica pomiędzy listingami 11.18 i 11.17 została wytłuszczona. Po dokonaniu projekcji błędu na jego podsumowanie sekwencja zagnieżdżona w każdym elemencie staje się zaledwie IEnumerable. W tym przypadku kompilator używa przeciążenia metody GroupBy z dodatkowym parametrem do reprezentacji projekcji. Wyrażenie kwerendowe z listingu 11.18 zostaje przetłumaczone na następujące: SampleData.AllDefects.Where(defect => defect.AssignedTo != null) .GroupBy(defect => defect.AssignedTo, defect => defect.Summary)

Klauzule grupujące są względnie proste, ale użyteczne. Nawet w naszym systemie śledzenia błędów mógłbyś z łatwością wyobrazić sobie potrzebę pogrupowania błędów według projektu, autora, ciężaru, statusu, a także według osoby przypisanej do pracy nad błędem (ten ostatni przypadek widzieliśmy w naszych przykładach). Do tej pory każde nasze wyrażenie kwerendowe kończyliśmy klauzulą select lub group ... by i tak też kończyło się całe wyrażenie. Są jednak sytuacje, kiedy chcesz zrobić coś więcej z wynikami — wtedy to przydatne stają się kontynuacje zapytań.

Grupowania i kontynuacje

373

11.6.2.Kontynuacje zapytań Kontynuacje zapytań umożliwiają użycie wyniku jednego wyrażenia kwerendowego jako sekwencji wejściowej kolejnego. Mają zastosowanie zarówno w klauzuli group ... by, jak i select. Składnia w obu przypadkach jest taka sama — musisz użyć jedynie kontekstowego słowa kluczowego into, a następnie podać nazwę nowej zmiennej zakresu. Ta zmienna może być następnie użyta w dalszej części wyrażenia kwerendowego. Specyfikacja wyjaśnia to zachowanie w kategoriach translacji z jednego wyrażenia kwerendowego na inne, zmieniając: pierwsze-zapytanie into identyfikator ciało-drugiego-zapytania

na from identyfikator in (pierwsze-zapytanie) ciało-drugiego-zapytania

Przykład powinien rozjaśnić sytuację. Wróćmy do naszego grupowania błędów po przypisanym użytkowniku, ale tym razem wyobraźmy sobie, że chcemy uzyskać liczbę błędów przypisaną do każdej osoby. Nie możemy zrobić tego w projekcji znajdującej się wewnątrz klauzuli grupującej, ponieważ ta ma zastosowanie jedynie do pojedynczych błędów. Chcemy dokonać projekcji każdej grupy, która zawiera przypisanego użytkownika i sekwencję przypisanych mu błędów, na pojedynczy element składający się z tego użytkownika i liczby błędów w grupie. Osiągniemy to przy użyciu wyrażenia z listingu 11.19. Listing 11.19. Kontynuacja grupowania przez kolejną projekcję var query = from defect in SampleData.AllDefects where defect.AssignedTo != null group defect by defect.AssignedTo into grouped select new { Assignee=grouped.Key, Count=grouped.Count() }; foreach (var entry in query) { Console.WriteLine("{0}: {1}", entry.Assignee.Name, entry.Count); }

Zmiany w wyrażeniu kwerendowym zostały wytłuszczone. Zmienną zakresu grouped możemy wykorzystać w drugiej części zapytania, ale zmienna defect jest już niedostępna — możesz traktować ją tak, jakby wyszła poza zasięg. Nasza projekcja tworzy typ anonimowy z właściwościami Assignee i Count, używając klucza każdej grupy jako przypisanego użytkownika (Assignee) i zliczając związaną z nią sekwencję błędów. Wynik działania listingu 11.19 jest następujący: Darren Dahlia: 14 Tara Tutu: 5 Tim Trotter: 5 Deborah Denton: 9 Colin Carton: 2

374

ROZDZIAŁ 11

Wyrażenia kwerendowe i LINQ dla Obiektów

Postępując według specyfikacji, wyrażenie kwerendowe z listingu 11.19 zostaje przetłumaczone na następujące: from grouped in (from where group select new { Assignee

defect in SampleData.AllDefects defect.AssignedTo != null defect by defect.AssignedTo) = grouped.Key, Count = grouped.Count() }

Następnie są wykonywane pozostałe translacje, w wyniku czego powstaje następujący kod: SampleData.AllDefects .Where(defect => defect.AssignedTo != null) .GroupBy(defect => defect.AssignedTo) .Select(grouped => new { Assignee = grouped.Key, Count = grouped.Count() })

Alternatywną metodą rozumienia kontynuacji jest myślenie o dwóch oddzielnych wyrażeniach. Nie jest to poprawne w kategoriach faktycznej translacji wykonywanej przez kompilator, ale uważam, że pozwala łatwiej zauważyć to, co się dokładnie dzieje. W tym przypadku wyrażenie kwerendowe (i przypisanie do zmiennej query) może być traktowane jako dwa następujące wyrażenia: var tmp = from defect in SampleData.AllDefects where defect.AssignedTo != null group defect by defect.AssignedTo; var query = from grouped in tmp select new { Assignee = grouped.Key, Count = grouped.Count() };

Oczywiście, jeżeli uznasz, że kod w takiej formie czyta się łatwiej, nic nie powstrzymuje Cię przed rozdzieleniem oryginalnego wyrażenia w Twoim kodzie na taką postać. Tak czy inaczej, ze względu na odroczone wykonanie kod zostanie uruchomiony dopiero wtedy, kiedy podejmiesz próbę przejścia po wynikach zapytania. join … into NIE JEST KONTYNUACJĄ. Łatwo można wpaść w pułapkę

błędnego myślenia, iż w każdym miejscu, w którym widać kontekstowe słowo kluczowe into, znajduje się kontynuacja. Dla złączeń nie jest to prawdą — klauzula join ... into (używana dla złączeń grupowych) nie tworzy kontynuacji. Istotna różnica polega na tym, że w przypadku złączenia grupowego wszystkie wcześniejsze zmienne zakresu (z wyłączeniem tej służącej do nazwania prawej strony złączenia) mogą być nadal używane. Porównaj to do zapytań z tej sekcji, w których każda kontynuacja czyściła cały poprzedni stan. Jedyną zmienną zakresu dostępną później była ta zadeklarowana przez kontynuację. Rozszerzmy ten przykład, aby zobaczyć, jak użyć wielu kontynuacji jednocześnie. Nasze wyniki są w tej chwili nieposortowane — zmieńmy to, aby się przekonać, kto ma najwięcej przypisanych błędów. Moglibyśmy skorzystać z klauzuli let po pierwszej kontynuacji, ale możemy też posłużyć się drugą kontynuacją po naszym bieżącym wyrażeniu — pokazuje to listing 11.20.

Wybór pomiędzy wyrażeniami kwerendowymi a notacją kropkową

375

Listing 11.20. Kontynuacje wyrażenia kwerendowego w klauzulach group i select var query = from defect in SampleData.AllDefects where defect.AssignedTo != null group defect by defect.AssignedTo into grouped select new { Assignee=grouped.Key, Count=grouped.Count() } into result orderby result.Count descending select result; foreach (var entry in query) { Console.WriteLine("{0}: {1}", entry.Assignee.Name, entry.Count); }

Różnice pomiędzy listingami 11.19 i 11.20 zostały wytłuszczone. Nie musieliśmy zmieniać kodu wyświetlającego wyniki, ponieważ nadal mamy ten sam typ sekwencji, z tą różnicą, że zastosowaliśmy do niej sortowanie. Tym razem przetłumaczone wyrażenie kwerendowe wygląda następująco: SampleData.AllDefects .Where(defect => defect.AssignedTo != null) .GroupBy(defect => defect.AssignedTo) .Select(grouped => new { Assignee = grouped.Key, Count = grouped.Count() }) .OrderByDescending(result => result.Count);

Czystym przypadkiem to wyrażenie jest niesamowicie podobne do pierwszego wyrażenia związanego z systemem śledzenia błędów, na jakie natknęliśmy się w sekcji 10.3.4. Nasza ostatnia klauzula select w praktyce nie robi niczego użytecznego, dlatego kompilator ją pomija. Jest ona jednak potrzebna w samym wyrażeniu kwerendowym, ponieważ wszystkie wyrażenia tego typu muszą się kończyć klauzulą select lub group ... by. Nic nie powstrzymuje Cię przed użyciem innej projekcji lub wykonaniem dodatkowych operacji — złączeń, dalszego grupowania itd. — w kontynuacji zapytania. Pamiętaj tylko, aby wraz z rozrastaniem się wyrażenia kwerendowego nie utracić jego czytelności. Skoro jesteśmy przy czytelności, istnieją pewne opcje, które warto rozważyć podczas pisania zapytań LINQ.

11.7. Wybór pomiędzy wyrażeniami kwerendowymi a notacją kropkową Jak widzieliśmy na przestrzeni całego rozdziału, wyrażenia kwerendowe przed właściwą kompilacją są tłumaczone na zwykły kod C#. Nie istnieje żadna oficjalna terminologia opisująca użycie operatorów kwerendowych LINQ w C# (zamiast w formie wyrażeń kwerendowych), ale wielu programistów opisuje tę technikę mianem notacji kropkowej9. 9

Od tej pory będę używał tego terminu, ale jeśli usłyszysz, że ktoś mówi o notacji płynnej (ang. fluent notation), prawdopodobnie ma na myśli to samo.

376

ROZDZIAŁ 11

Wyrażenia kwerendowe i LINQ dla Obiektów

Każde wyrażenie kwerendowe może zostać zapisane w notacji kropkowej, ale stwierdzenie odwrotne jest nieprawdziwe: wiele operatorów LINQ nie posiada swojego odpowiednika w wyrażeniach kwerendowych C#. Powstaje fundamentalne pytanie: w jakiej sytuacji użyć jednej lub drugiej składni?

11.7.1.Operacje wymagające notacji kropkowej Najbardziej oczywista sytuacja zmuszająca do użycia notacji kropkowej ma miejsce, kiedy wywołujesz metody takie jak Reverse lub ToDictionary, które zwyczajnie nie posiadają swojej reprezentacji w składni wyrażeń kwerendowych. Ale nawet kiedy użyjesz operatora kwerendowego obsługiwanego przez wyrażenia kwerendowe, istnieje duże prawdopodobieństwo, że przeciążenie, którego chcesz użyć, będzie niedostępne. Dla przykładu Enumerable.Where nie posiada przeciążenia, w którym indeks do sekwencji nadrzędnej jest przekazywany jako kolejny argument delegata. Aby zatem pobrać co drugi element z sekwencji, mógłbyś użyć: sequence.Where((item, index) => index % 2 == 0)

Podobne przeciążenie istnieje dla metody Select, zatem gdybyś chciał wydobyć oryginalny indeks w sekwencji po jej posortowaniu, mógłbyś użyć czegoś takiego: sequence.Select((Item, Index) => new { Item, Index }) .OrderBy(x => x.Item.Name)

Ten przykład pokazuje kolejną opcję, którą powinieneś rozważyć: jeżeli zamierzasz użyć parametru wyrażenia lambda bezpośrednio w typie anonimowym, możesz pominąć zwyczajową konwencję rozpoczynania nazwy parametru małą literą, a następnie skorzystać z inicjalizatora projekcji, aby uniknąć pisania new {Item = item, Index = index}, co może być rozpraszające. Oczywiście, zamiast tego możesz zignorować konwencję dotyczącą nazw właściwości i wymusić w swoim typie anonimowym obecność właściwości zaczynających się małą literą (na przykład item lub index). Wszystko zależy od Ciebie — warto poeksperymentować. Chociaż spójność ma zazwyczaj znaczenie, tutaj można ją pominąć, ponieważ niezgodność jest ograniczona jedynie do samej metody — nie eksponujesz tych nazw w swoim publicznym interfejsie ani w pozostałej części klasy. Wiele z operatorów kwerendowych obsługuje również porównania niestandardowe — najbardziej oczywistymi przykładami są porządkowanie i łączenie. Sądząc po moich doświadczeniach, jest mało prawdopodobne, abyś często ich potrzebował, ale czasem okazują się nieocenione. Jeżeli na przykład chcesz wykonać zapytanie na nazwisku osoby bez uwzględnienia wielkości liter, możesz użyć komparatora StringComparer. ´OrdinalIgnoreCase (lub komparatora specyficznego dla ustawień językowych i kulturowych) jako ostatecznego argumentu dla wywołania metody Join. Jeśli czujesz, że operator wykonuje niemal dokładnie to, czego potrzebujesz, ale jednak nie do końca, sprawdź w dokumentacji, czy nie ma przypadkiem innych przeciążeń. Kiedy jesteś zmuszony do użycia notacji kropkowej, decyzja jest prosta. Co jednak zrobić w przypadku, kiedy możliwe jest użycie wyrażenia kwerendowego?

Wybór pomiędzy wyrażeniami kwerendowymi a notacją kropkową

377

11.7.2.Wyrażenia kwerendowe, dla których prostszym rozwiązaniem może się okazać notacja kropkowa Niektórzy programiści używają wyrażeń kwerendowych wszędzie, gdzie jest to tylko możliwe. Ja patrzę na to, co robi dane wyrażenie, i decyduję, które podejście będzie bardziej czytelne. Weźmy za przykład poniższe wyrażenie, podobne do jednego z użytych na początku tego rozdziału: var adults = from person in people where person.Age >= 18 select person;

Są to trzy wiersze kodu, chociaż realizowane zadanie sprowadza się zaledwie do filtrowania. W takiej sytuacji użyłbym notacji kropkowej: var adults = people.Where(person => person.Age >= 18);

Taki zapis jest dla mnie bardziej przejrzysty — każda część zapisu wspomina o czymś, czym jesteśmy zainteresowani. Stosowanie notacji kropkowej pozwala osiągnąć większą przejrzystość także w przypadku wyrażeń kwerendowych, w których jesteś zmuszony do (przynajmniej częściowego) zastosowania tej notacji w zapytaniu. Załóżmy na przykład, że zamierzasz użyć metody rozszerzającej ToList(), aby uzyskać listę imion osób dorosłych. (Dla bardziej wyważonego porównania w tym wypadku również wykonuję projekcję). Oto odpowiednie wyrażenie kwerendowe: var adultNames = (from person in people where person.Age >= 18 select person.Name).ToList();

A oto odpowiednik w notacji kropkowej: var adultNames = people.Where(person => person.Age >= 18) .Select(person => person.Name) .ToList();

Potrzeba otoczenia wyrażenia kwerendowego w pierwszym wyrażeniu sprawia, że jest ono dla mnie brzydsze. W dużym stopniu jest to kwestia gustu — celem tej sekcji jest jedynie uświadomienie Ci, że istnieje wybór, do którego masz pełne prawo. Jeżeli zamierzasz intensywnie używać LINQ, powinieneś opanować obie notacje w stopniu zapewniającym komfort pracy. Nie ma nic złego w przełączaniu się pomiędzy jedną notacją a drugą w zależności od zapytania, jakie przyszło Ci wykonać. Tak jak widzieliśmy, wygenerowany kod jest całkowicie kompatybilny. Oczywiście, nie oznacza to wcale, że nie lubię wyrażeń kwerendowych.

11.7.3.Gdzie wyrażenia kwerendowe lśnią? Skoro wiemy już, w jakich sytuacjach notacja kropkowa może się okazać korzystna, powinienem donieść, iż w przypadku wszelkich operacji, w których wyrażenia kwerendowe wymagają użycia identyfikatorów przezroczystych — ze szczególnym wskazaniem na złączenia — notacja kropkowa zaczyna niedomagać pod względem czytelności.

378

ROZDZIAŁ 11

Wyrażenia kwerendowe i LINQ dla Obiektów

Piękno identyfikatorów przezroczystych polega na tym, że są one przezroczyste, a przynajmniej na tyle, że patrząc wyłącznie na wyrażenie kwerendowe, w ogóle ich nie widzisz! Nawet prosta klauzula let wystarczy, aby przechylić szalę na korzyść wyrażeń kwerendowych: wprowadzenie nowego typu anonimowego tylko po to, aby przenieść kontekst w zapytaniu, szybko staje się nieznośne. Wyrażenia kwerendowe wygrywają również wtedy, kiedy wymaganych jest kilka wyrażeń lambda, a nawet kilka wywołań metod. Ponownie dotyczy to złączeń, w których musisz wskazać wyrażenia wybierające klucz dla każdej ze stron złączenia, a także wyrażenia tworzące wynik. Oto na przykład okrojona wersja wcześniejszego zapytania, którego użyłem podczas wprowadzania złączeń wewnętrznych: from defect in SampleData.AllDefects join subscription in SampleData.AllSubscriptions on defect.Project equals subscription.Project select new { defect.Summary, subscription.EmailAddress }

W środowisku IDE rozsądnie byłoby umieścić całą klauzulę join w jednym wierszu, dzięki czemu kod byłby całkiem czytelny. Jednak odpowiednik w notacji kropkowej wygląda dość strasznie: SampleData.AllDefects.Join(SampleData.AllSubscriptions, defect => defect.Project, subscription => subscription.Project, (defect, subscription) => new {defect.Summary, subscription.EmailAddress})

Ostatni argument w środowisku IDE powinien zmieścić się w całości w jednym wierszu, ale mimo to nadal będzie wyglądał brzydko, ponieważ wyrażenie lambda jest pozbawione jakiegokolwiek kontekstu. Nie możesz po jednym spojrzeniu powiedzieć, co oznaczają poszczególne argumenty. Pewną pomocą byłyby tutaj argumenty nazwane z C# 4, ale to jeszcze bardziej zwiększyłoby objętość kodu. Równie nieprzyjemne w notacji kropkowej mogą być złożone wyrażenia porządkujące. Która z poniższych form jest dla Ciebie bardziej czytelna — klauzula orderby: orderby item.Rating descending, item.Price, item.Name

czy wywołania trzech metod: .OrderByDescending(item => item.Rating) .ThenBy(item => item.Price) .ThenBy(item => item.Name)

Aby zmienić kolejność tych sortowań w wyrażeniu kwerendowym, wystarczy je po prostu zamienić miejscami. W notacji kropkowej będziesz musiał od czasu do czasu zamienić OrderBy na ThenBy lub odwrotnie. Powtórzę jeszcze raz, nie staram się narzucać Ci moich własnych preferencji odnośnie do kodu. Chcę jedynie, abyś wiedział, jakie opcje są dostępne, i abyś się zastanowił nad własnymi wyborami. Oczywiście jest to jeden z aspektów pisania czytelnego kodu, ale również zupełnie nowy obszar do rozważenia w C#.

Podsumowanie

379

11.8. Podsumowanie W tym rozdziale przyglądaliśmy się interakcji LINQ i C# 3, skupiając się na tym, w jaki sposób wyrażenia kwerendowe są tłumaczone najpierw na kod pozbawiony takich wyrażeń, który następnie jest kompilowany na ogólnych zasadach. Widzieliśmy, w jaki sposób wszystkie wyrażenia kwerendowe tworzą serie sekwencji przy użyciu pewnego rodzaju transformacji na każdym kroku translacji. W wielu przypadkach sekwencje są wyliczane z odroczonym wykonaniem i pobierają dane dopiero wtedy, kiedy zachodzi taka potrzeba. W porównaniu do innych cech C# 3 wyrażenia kwerendowe wyglądają trochę obco — bardziej przypominają SQL niż C#, do którego jesteśmy przyzwyczajeni. Jednym z powodów, dla których wyglądają dziwnie, jest to, że mają charakter deklaratywny zamiast imperatywnego — wyrażenie mówi o cechach wyniku końcowego, a nie o konkretnych krokach wymaganych do uzyskania tego wyniku. Idzie to w parze z bardziej funkcyjnym sposobem myślenia. Zrozumienie tej koncepcji może chwilę zająć. Nie we wszystkich sytuacjach można ją zastosować, ale tam, gdzie składnia deklaratywna może być użyta, znacznie poprawia czytelność, a także ułatwia testowanie kodu i jego zrównoleglanie. Nie daj się zwieść twierdzeniom, że LINQ powinien być stosowany wyłącznie w odniesieniu do baz danych. Powszechnym zjawiskiem jest używanie tej technologii do manipulacji kolekcjami w pamięci — przekonaliśmy się, że tego typu działania są dobrze wspierane przez wyrażenia kwerendowe i metody rozszerzające klasy Enumerable. W rzeczywistości zobaczyłeś już wszystkie nowe cechy wprowadzone w C# 3! Chociaż nie przyglądaliśmy się jeszcze innym dostawcom LINQ, rozumiemy dokładnie, jakie zadania wykona za nas kompilator, kiedy poprosimy go o zajęcie się XML-em i SQL-em. Kompilator sam w sobie nie widzi różnicy pomiędzy LINQ dla Obiektów, LINQ dla SQL-a a jakimkolwiek innym dostawcą — działa mechanicznie według tych samych reguł. W następnym rozdziale zobaczymy, w jaki sposób reguły te tworzą ostatni element układanki LINQ, kiedy wyrażenia lambda są konwertowane na drzewa wyrażeń, dzięki czemu różne klauzule wyrażeń kwerendowych mogą być wykonywane na różnych platformach… Przyjrzymy się również innym przykładom tego, co potrafi LINQ.

380

ROZDZIAŁ 11

Wyrażenia kwerendowe i LINQ dla Obiektów

LINQ — nie tylko kolekcje

Ten rozdział omawia: ♦ LINQ dla SQL-a, ♦ IQueryable i kwerendowe drzewa wyrażeń, ♦ LINQ dla XML-a, ♦ Równoległe LINQ, ♦ bibliotekę LINQ dla Reactive Extensions, ♦ pisanie własnych operatorów.

382

ROZDZIAŁ 12

LINQ — nie tylko kolekcje

Załóżmy, że odwiedził Cię kosmita i poprosił o opisanie naszej kultury. W jaki sposób ująłbyś jej różnorodność, mając ograniczoną ilość czasu? Zamiast opisywać ją w próżni, mógłbyś wykorzystać ten czas i mu ją pokazać. Wizyta w klubie jazzowym gdzieś w Nowym Orleanie, w operze La Scalla, galeria obrazów w paryskim Luwrze, sztuka Szekspira w Stratford nad rzeką Avon itd. Czy po takiej wycieczce kosmita wiedziałby wszystko o kulturze? Czy byłby w stanie skomponować utwór, napisać książkę, zatańczyć w balecie, wyrzeźbić posąg? Absolutnie nie. Ale, miejmy nadzieję, odszedłby z ogólną wiedzą na temat kultury — jej bogactwa, różnorodności, zdolności rozświetlania ludzkich istnień. Tak będzie również z tym rozdziałem. Widziałeś już wszystkie cechy C# 3, ale jeśli nie zapoznasz się lepiej z LINQ, nie będziesz mógł docenić całości ze względu na brak odpowiedniego kontekstu. W chwili publikacji pierwszego wydania tej książki dostępnych było niewiele technologii związanych z LINQ — teraz jest ich całe zatrzęsienie, zarówno tych z firmy Microsoft, jak i innych dostawców. To akurat mnie nie zaskoczyło, ale zafascynowała mnie rozmaita natura tych technologii. Przyjrzymy się różnorodnym manifestacjom LINQ, pokazując przykład każdej z nich. Postanowiłem skupić się głównie na technologiach Microsoftu, ponieważ są najczęściej wykorzystywane. Nie mówię przez to, że inni dostawcy nie są mile widziani w ekosystemie LINQ. Istnieje szereg projektów — zarówno komercyjnych, jak i open source — dających dostęp do różnorodnych źródeł danych oraz rozbudowujących rozwiązania istniejących dostawców. Tutaj, w przeciwieństwie do pozostałej części książki, przemkniemy jedynie przez każdy temat — celem nie jest poznanie szczegółów, ale zrozumienie ducha LINQ. Jeżeli chcesz zbadać te technologie dokładniej, polecam sięgnięcie do poświęconych im książek lub przestudiowanie odpowiedniej dokumentacji. Oparłem się pokusie napisania na końcu każdej sekcji: „To nie wszystko na temat LINQ dla [xxx]”, ale proszę, żebyś uznał, iż takie zdanie jest na końcu każdej z nich. Poszczególne technologie posiadają wiele możliwości wybiegających poza zapytania o dane, ale ja skupiam się wyłącznie na obszarach związanych bezpośrednio z LINQ. Zacznijmy od dostawcy, który po wprowadzeniu LINQ przykuł największą uwagę. Mowa o LINQ dla SQL-a.

12.1. Odpytywanie bazy danych przez LINQ dla SQL-a Jestem pewien, że do tej pory wiesz już, iż celem LINQ dla SQL-a jest przekształcanie wyrażeń kwerendowych na zapytania SQL, które są następnie wykonywane na bazie danych. Co prawda LINQ dla SQL-a to coś więcej, gdyż możemy tu mówić o pełnoprawnym rozwiązaniu ORM (ang. object-relational mapping), ale ja zamierzam się raczej skoncentrować na części związanej z zapytaniami, niż wnikać w obsługę konkurencyjności i inne szczegóły, z jakimi musi sobie radzić ORM. Pokażę Ci wystarczająco dużo, abyś mógł poeksperymentować samodzielnie — baza danych oraz kod są dostępne na stronie książki (www.helion.pl/ksiazki/cshop2.htm). Baza danych jest w formacie SQL Server 2005, dzięki czemu będziesz mógł z niej skorzystać, nawet jeśli nie posiadasz najnowszej wersji Servera SQL. Oczywiście Microsoft zadbał, aby LINQ dla SQL-a działał również z nowszymi wersjami.

Odpytywanie bazy danych przez LINQ dla SQL-a

383

DLACZEGO LINQ DLA SQL-A ZAMIAST ENTITY FRAMEWORK? Skoro jesteśmy przy „nowszych wersjach”, możesz się zastanawiać, dlaczego wybrałem demonstrację LINQ dla SQL-a zamiast Entity Framework, będącej teraz preferowanym rozwiązaniem firmy Microsoft (obsługującym również LINQ). Odpowiedź jest bardzo prosta. Mimo że Entity Framework jest bez wątpienia pod wieloma względami bardziej funkcjonalny od LINQ dla SQL-a, wymaga zapoznania się z pewnymi dodatkowymi koncepcjami, których wyjaśnienie zajęłoby tutaj zbyt dużo miejsca. Staram się ukazać Ci spójność (czasem z przypadkami jej braku), jaką daje LINQ, a ta jest oferowana w równym stopniu przez LINQ dla SQL-a, jak i przez Entity Framework. Zanim zaczniemy pisać jakiekolwiek zapytania, potrzebujemy bazy danych i modelu do reprezentacji w kodzie.

12.1.1.Zaczynamy od bazy danych i modelu LINQ dla SQL-a wymaga metadanych odnośnie do bazy danych, aby wiedzieć, jakie klasy odpowiadają tabelom bazy itp. Metadane mogą być reprezentowane na wiele sposobów: ja zamierzam użyć narzędzia projektowego LINQ dla SQL-a, wbudowanego w Visual Studio. W pierwszej kolejności możesz zaprojektować encje, a następnie poprosić LINQ o stworzenie bazy lub zaprojektować bazę danych, a potem pozwolić Visual Studio wywnioskować, jak powinny wyglądać encje. Ja wolę drugie podejście, ale oba z nich mają swoje zalety i wady. Tworzenie schematu bazy danych Mapowanie z klas w rozdziale 11. do tabel baz danych jest proste. Każda tabela posiada automatycznie inkrementowaną kolumnę z identyfikatorem o odpowiedniej nazwie: ProjectID, DefectID itd. Referencje pomiędzy tabelami mają te same nazwy, zatem dla przykładu tabela Defect posiada kolumnę z kluczem obcym ProjectID. Jest kilka wyjątków od tych prostych reguł: User jest słowem zastrzeżonym w T-SQL, dlatego klasa User jest mapowana na tabelę DefectUser. Enumeracje (status, ciężar błędu, typ użytkownika) nie posiadają tabel. Ich wartości są mapowane wprost do kolumn z typem tinyint w tabelach Defect i DefectUser. Tabela Defect ma dwa powiązania z tabelą DefectUser: jedno dla użytkownika, który stworzył błąd, i drugie dla osoby aktualnie nad nim pracującej. Są one reprezentowane odpowiednio przez kolumny CreatedByUserId i AssignedToUserId.

384

ROZDZIAŁ 12

LINQ — nie tylko kolekcje

Tworzenie klas encji Kiedy mamy już utworzone tabele, stworzenie klas encji w Visual Studio jest proste. Otwórz eksplorator serwerów (View/Server Explorer)1 i dodaj źródło danych dla bazy SkeetySoftDefects (kliknij prawym przyciskiem węzeł Data Connections i wybierz z menu polecenie Add Connection). Powinieneś zobaczyć cztery tabele: Defect, DefectUser, Project i NotificationSubscription. Następnie możesz dodać do projektu nowy element typu LINQ to SQL classes. Użyta nazwa posłuży do wygenerowania klasy reprezentującej całościowy model bazy danych. Ja użyłem nazwy DefectModel, która doprowadziła do powstania klasy o nazwie Defect ´ModelDataContext. Po utworzeniu tego elementu zostanie otwarte narzędzie projektowe. Możesz zacząć przeciągać tabele z okna eksploratora serwerów do okna narzędzia projektowego. Wszystkie powiązania zostaną utworzone automatycznie. Po umieszczeniu wszystkich tabel w widoku możesz uporządkować diagram i dostosować kilka właściwości encji. Oto lista zmian, jakich dokonałem: Zmieniłem właściwość DefectID na ID, aby pasowała do naszego poprzedniego modelu. Zmieniłem DefectUser na User (zatem, chociaż tabela nadal nosi nazwę DefectUser, my — tak jak poprzednio — wygenerujemy klasę o nazwie User). Zmieniłem typ właściwości Severity, Status i UserType na odpowiadające

im enumeracje (wcześniej kopiując te enumeracje do projektu). Zmieniłem nazwy powiązań właściwości dzieci używanych jako powiązania pomiędzy Defect i DefectUser — narzędzie projektowe wypracowało właściwe nazwy dla pozostałych powiązań, ale w tym przypadku napotkało problem, ponieważ pomiędzy tą samą parą tabel znalazły się dwa powiązania. Nazwałem je AssignedTo/AssignedDefects i CreatedBy/CreatedDefects. Rysunek 12.1 pokazuje diagram po wykonaniu wszystkich powyższych operacji. Jak widzisz, przypomina on w dużym stopniu diagram klas, który widzieliśmy na rysunku 11.3, tyle że bez enumeracji. Jeżeli spojrzysz na kod C# wygenerowany przez narzędzie projektowe (DefectModel. designer.cs), znajdziesz pięć klas częściowych: po jednej dla każdej encji plus wspomniana wcześniej klasa DefectModelDataContext. Fakt, że są one częściowe, jest użyteczny: w tym przypadku dołożyłem własne konstruktory, pasujące do tych, które miałem w naszych oryginalnych klasach kolekcji. Dzięki temu bez większego nakładu pracy mogłem wykorzystać kod generujący przykładowe dane z rozdziału 11. Dla uproszczenia nie umieściłem tego kodu w tym miejscu, ale jeśli chcesz, możesz go z łatwością prześledzić, zaglądając do pliku PopulateDatabase.cs w projekcie. Oczywiście nie musisz uruchamiać go samodzielnie — baza danych przygotowana do pobrania jest już wypełniona danymi.

1

To polecenie menu może się znajdować w różnych miejscach, w zależności od używanej wersji Visual Studio. Na przykład w Visual Studio 2008 Professional Edition powinieneś wybrać View/Other Windows/Server Explorer. Wersje Express Visual Studio nie posiadają eksploratora serwerów, ale mają podobne narzędzie — eksplorator baz danych (dostępne z menu Tools/Other Windows/Database Explorer) — przyp. tłum.

Odpytywanie bazy danych przez LINQ dla SQL-a

385

Rysunek 12.1. Narzędzie projektowe LINQ dla SQL-a prezentujące uporządkowane i zmodyfikowane encje

Skoro mamy już schemat w SQL-u, model danych w C# i przykładowe dane, możemy się zabrać za odpytywanie.

12.1.2.Zapytania wstępne Jestem pewien, że odgadłeś, co się zbliża, ale mam nadzieję, że nie wpłynie to negatywnie na efektowność pokazu. Zamierzamy wykonać wyrażenia kwerendowe na naszym źródle danych, patrząc, jak LINQ dla SQL-a konwertuje w locie nasze zapytania na SQL. Będziemy się trzymać wyrażeń podobnych do tych, które wykonywaliśmy w odniesieniu do przechowywanych w pamięci kolekcji z rozdziału 11. Pierwsze zapytanie — wyszukiwanie błędów przypisanych do Tima Pominę trywialne przykłady z początku rozdziału i przejdę bezpośrednio do zapytania z listingu 11.7, które sprawdza otwarte błędy przypisane do Tima. Dla łatwiejszego porównania zamieszczam poniżej samo zapytanie z listingu 11.7: User tim = SampleData.Users.TesterTim; var query = from defect in SampleData.AllDefects where defect.Status != Status.Closed where defect.AssignedTo == tim select defect.Summary;

386

ROZDZIAŁ 12

LINQ — nie tylko kolekcje

Pełny odpowiednik listingu 11.7 w LINQ dla SQL-a znajduje się poniżej, na listingu 12.1. Listing 12.1. Odpytywanie bazy danych w celu znalezienia otwartych błędów należących do Tima using (var context = new DefectModelDataContext()) Umożliwienie { wyświetlania danych context.Log = Console.Out;

Utworzenie kontekstu do dalszej pracy

w konsoli

Zapytanie o Tima User tim = context.Users .Where(user => user.Name == "Tim Trotter") .Single();

var query = from defect in context.Defects where defect.Status != Status.Closed where defect.AssignedTo == tim select defect.Summary;

Zapytanie o otwarte błędy Tima

foreach (var summary in query) { Console.WriteLine(summary); } }

Listing 12.1 — ze względu na to, że jest zupełnie nowy — wymaga pewnego wytłumaczenia. Zaczynamy od utworzenia nowego kontekstu danych do dalszej pracy ( ). Konteksty danych mają wieloraką funkcjonalność — biorą odpowiedzialność za zarządzanie połączeniem i transakcjami, tłumaczenie zapytań, śledzenie zmian w encjach i obsługę identyczności. Na potrzeby tego rozdziału możemy traktować kontekst danych za nasz punkt styku z bazą danych. Nie będziemy się przyglądać bardziej zaawansowanym cechom, ale skorzystamy z jednej, szczególnej możliwości — wypisywania wykonywanych komand SQL w oknie konsoli ( ). Wszystkie użyte w tej sekcji właściwości związane z modelem (Defects, Users itd.) są typu Table dla odpowiedniego typu encji. Działają one jak źródła danych dla naszych zapytań. W zapytaniu głównym nie możemy zidentyfikować Tima, używając SampleData. ´Users.TesterTim, ponieważ ten obiekt nie zna identyfikatora odpowiedniego wiersza w tabeli DefectUser. Zamiast tego ładujemy encję użytkownika Tim, korzystając z oddzielnego zapytania ( ). Użyłem do tego celu notacji kropkowej, ale równie dobrze mogłoby to być wyrażenie kwerendowe. Metoda Single zwraca pojedynczy wynik z zapytania, rzucając wyjątek, jeśli wynikiem nie jest dokładnie jeden element. W rzeczywistych sytuacjach encja może być produktem innych operacji, takich jak logowanie do systemu — jeśli nie posiadasz pełnej encji, możesz mieć jedynie jej identyfikator, który równie dobrze sprawdzi się w zapytaniu głównym. W tym przypadku moglibyśmy zmienić zapytanie o otwarte defekty tak, aby filtrowało w oparciu o nazwisko przypisanego użytkownika. To nie odpowiadałoby jednak koncepcji oryginalnego zapytania. Jedyna różnica w wyrażeniu kwerendowym ( ) pomiędzy zapytaniem w pamięci i zapytaniem LINQ dla SQL-a to źródło danych — zamiast SampleData.AllDefects używamy context.Defects. Ostatecznie, chociaż praca została wykonana na bazie danych, wyniki są jednakowe (ale nie ma gwarancji odnośnie do ich porządku).

Odpytywanie bazy danych przez LINQ dla SQL-a

387

Ponieważ poprosiliśmy kontekst danych o wyświetlanie wygenerowanego kodu SQL, możemy zobaczyć, co dokładnie dzieje się podczas wykonywania programu. Konsola pokazuje zapytania wykonane na bazie danych razem z wartościami parametrów zapytań2: SELECT [t0].[UserID], [t0].[Name], [t0].[UserType] FROM [dbo].[DefectUser] AS [t0] WHERE [t0].[Name] = @p0 -- @p0: Input NVarChar (Size = 11; Prec = 0; Scale = 0) [Tim Trotter] SELECT [t0].[Summary] FROM [dbo].[Defect] AS [t0] WHERE ([t0].[AssignedToUserID] = @p0) AND ([t0].[Status] <> @p1) -- @p0: Input Int (Size = 0; Prec = 0; Scale = 0) [2] -- @p1: Input Int (Size = 0; Prec = 0; Scale = 0) [4]

Zauważ, że pierwsze zapytanie pobiera wszystkie właściwości użytkownika, ponieważ wypełniamy całą encję, ale drugie zapytanie ogranicza się jedynie do podsumowania, bo tylko tego potrzebujemy. LINQ dla SQL-a przekonwertował również nasze dwie oddzielne klauzule where w drugim zapytaniu na pojedyncze filtrowanie wykonywane na bazie. LINQ dla SQL-a jest zdolny do translacji szerokiego zakresu wyrażeń. Spróbujmy popracować z nieco bardziej złożonym zapytaniem, pochodzącym z rozdziału 11., aby zobaczyć, jaki SQL otrzymamy w odpowiedzi. Generowanie SQL-a dla bardziej złożonego zapytania — klauzula let Nasze następne zapytanie pokazuje, co się stanie, jeśli przy użyciu klauzuli let wprowadzimy pewnego rodzaju zmienną tymczasową. Jak pamiętasz, w rozdziale 11. rozważaliśmy dosyć dziwaczną sytuację — założyliśmy wówczas, że wyliczanie długości łańcucha jest operacją zajmującą dużo czasu. Wyrażenie kwerendowe, z wyjątkiem źródła danych, jest ponownie dokładnie takie samo jak na listingu 11.11. Listing 12.2 pokazuje kod LINQ dla SQL-a. Listing 12.2. Użycie klauzuli let w LINQ dla SQL-a using (var context = new DefectModelDataContext()) { context.Log = Console.Out; var query = from user in context.Users let length = user.Name.Length orderby length select new { Name = user.Name, Length = length }; foreach (var entry in query) { 2

Dodatkowo generowane są pewne szczegółowe informacje dotyczące samego kontekstu danych, które tutaj usunąłem, aby skupić uwagę na SQL-u. Oprócz tego konsola zawiera oczywiście podsumowania wyświetlane przez pętlę foreach.

388

ROZDZIAŁ 12

LINQ — nie tylko kolekcje Console.WriteLine("{0}: {1}", entry.Length, entry.Name); } }

Wygenerowany kod SQL jest zbliżony do sekwencji, jakie widzieliśmy na rysunku 11 5. Najbardziej zagnieżdżona sekwencja (pierwsza na diagramie) to lista użytkowników. Jest ona przekształcana na sekwencję par imię – długość (w zagnieżdżonej klauzuli select), po czym stosowana jest pusta projekcja z sortowaniem po długości: SELECT [t1].[Name], [t1].[value] AS [Length] FROM ( SELECT [t0].[Name], LEN([t0].[Name]) AS [value] FROM [dbo].[DefectUser] AS [t0] ) AS [t1] ORDER BY [t1].[value]

Jest to dobry przykład miejsca, w którym SQL jest bardziej rozwlekły, niż potrzeba. Chociaż w wyrażeniu kwerendowym nie mogliśmy się odwołać do elementów końcowej sekwencji podczas sortowania, możemy zrobić to w SQL-u. Powstałoby zatem zapytanie prostsze, ale działające równie dobrze: SELECT LEN([t0].[Name]) AS [value], [t1].[Name] FROM [dbo].[DefectUser] AS [t0] ORDER BY [value]

Oczywiście liczy się to, co dokładnie wykona optymalizator zapytań na bazie danych — plan wykonania wyświetlony w SQL Server Management Studio Express jest taki sam dla obu zapytań, zatem nie wygląda na to, abyśmy cokolwiek tracili. Ostatni zestaw zapytań LINQ dla SQL-a, jakiemu się przyjrzymy, to złączenia.

12.1.3.Zapytania wymagające złączeń Wykorzystamy zarówno złączenia wewnętrzne, jak i grupowe, używając przykładu łączenia subskrypcji powiadomień z projektami. Przypuszczam, że w tym momencie jesteś już przyzwyczajony do mojej metodologii — wzorzec kodu jest taki sam dla obu zapytań, dlatego od tej pory, o ile nie będzie się działo nic ciekawego, będę pokazywał jedynie wyrażenie kwerendowe i wygenerowany kod SQL. Złączenia jawne — dopasowywanie błędów z subskrypcją powiadomień Naszym pierwszym zapytaniem jest najprostszy rodzaj wewnętrznego równozłączenia przy użyciu klauzuli join LINQ: //Wyrażenie kwerendowe (modyfikacja listingu 11.12) var query = from defect in context.Defects join subscription in context.NotificationSubscriptions on defect.Project equals subscription.Project select new { defect.Summary, subscription.EmailAddress } -- Wygenerowany SQL SELECT [t0].[Summary], [t1].[EmailAddress]

Odpytywanie bazy danych przez LINQ dla SQL-a

389

FROM [dbo].[Defect] AS [t0] INNER JOIN [dbo].[NotificationSubscription] AS [t1] ON [t0].[ProjectID] = [t1].[ProjectID]

Co raczej nie zaskakuje, w kodzie SQL widać złączenie wewnętrzne. Odgadnięcie wygenerowanego zapytania SQL byłoby łatwym zadaniem. A jak sprawa ma się w przypadku złączenia grupowego? Tutaj wszystko nabiera rumieńców: //Wyrażenie kwerendowe (modyfikacja listingu 11.13) var query = from defect in context.Defects join subscription in context.NotificationSubscriptions on defect.Project equals subscription.Project into groupedSubscriptions select new { Defect = defect, Subscriptions = groupedSubscriptions } -- Wygenerowany SQL SELECT [t0].[DefectID] AS [ID], [t0].[Created], [t0].[LastModified], [t0].[Summary], [t0].[Severity], [t0].[Status], [t0].[AssignedToUserID], [t0].[CreatedByUserID], [t0].[ProjectID], [t1].[NotificationSubscriptionID], [t1].[ProjectID] AS [ProjectID2], [t1].[EmailAddress], (SELECT COUNT(*) FROM [dbo].[NotificationSubscription] AS [t2] WHERE [t0].[ProjectID] = [t2].[ProjectID]) AS [value] FROM [dbo].[Defect] AS [t0] LEFT OUTER JOIN [dbo].[NotificationSubscription] AS [t1] ON [t0].[ProjectID] = [t1].[ProjectID] ORDER BY [t0].[DefectID], [t1].[NotificationSubscriptionID]

Widać wyraźną różnicę w ilości wygenerowanego kodu SQL! Są dwie rzeczy godne uwagi. Po pierwsze, abyśmy nadal mogli zobaczyć błąd, nawet gdyby nikt nie subskrybował związanego z nim projektu, zamiast złączenia wewnętrznego zostało użyte lewostronne złączenie zewnętrzne. Jeżeli chcesz osiągnąć lewostronne złączenie zewnętrzne bez grupowania, standardowym sposobem wyrażenia tego jest złączenie grupowe z dodatkową klauzulą from używającą metody rozszerzającej DefaultIfEmpty na sekwencji zagnieżdżonej. Wygląda to dziwnie, ale działa całkiem dobrze. Drugą dziwną rzeczą w poprzednim zapytaniu jest przeliczanie każdej grupy wewnątrz bazy danych. Jest to trik wykonywany przez LINQ dla SQL-a w celu zapewnienia przetwarzania całości po stronie serwera. Natywna implementacja musiałaby przeprowadzić grupowanie w pamięci po pobraniu wszystkich danych. W niektórych przypadkach dostawca mógłby posłużyć się obejściem pozwalającym uniknąć zliczania przez proste wykrywanie zmiany identyfikatora grupującego, ale dla pewnych zapytań takie rozwiązanie stwarza problemy. Być może przyszła implementacja LINQ dla SQLa będzie w stanie zmieniać podejście w zależności od aktualnie przetwarzanego zapytania. Nie musisz jawnie zapisywać złączenia w wyrażeniu kwerendowym, aby zobaczyć je w wygenerowanym SQL-u. Nasze ostatnie zapytania pokażą złączenia niejawne stworzone przy użyciu wyrażeń dostępu do właściwości.

390

ROZDZIAŁ 12

LINQ — nie tylko kolekcje

Złączenia niejawne — prezentacja podsumowań błędów i nazw projektów Weźmy pod uwagę prosty przykład. Załóżmy, że chcemy wyświetlić każdy błąd, pokazując jego podsumowanie i nazwę projektu, którego jest częścią. Wyrażenie kwerendowe to zaledwie zwykła projekcja: //Wyrażenie kwerendowe from defect in context.Defects select new { defect.Summary, ProjectName = defect.Project.Name } -- Wygenerowany SQL SELECT [t0].[Summary], [t1].[Name] AS [ProjectName] FROM [dbo].[Defect] AS [t0] INNER JOIN [dbo].[Project] AS [t1] ON [t1].[ProjectID] = [t0].[ProjectID]

Zauważ, że od błędu do projektu przeszliśmy poprzez właściwość — LINQ dla SQL-a przekonwertował to przejście w złączenie wewnętrzne. Może go tutaj użyć, ponieważ schemat narzuca wymóg istnienia wartości w kolumnie ProjectID tabeli Defect — każdy błąd ma swój projekt. Nie każdy błąd ma jednak przypisaną osobę do pracy nad nim — pole AssignedToUserID jest nullowalne, zatem jeśli w projekcji użyjemy użytkownika przypisanego do pracy, zostanie wygenerowane lewostronne złączenie zewnętrzne: //Wyrażenie kwerendowe var query = from defect in context.Defects select new { defect.Summary, Assignee = defect.AssignedTo.Name } -- Wygenerowany SQL SELECT [t0].[Summary], [t1].[Name] AS [Assignee] FROM [dbo].[Defect] AS [t0] LEFT OUTER JOIN [dbo].[DefectUser] AS [t1] ON [t1].[UserID] = [t0].[AssignedToUserID]

Oczywiście, jeśli przejdziesz przez więcej właściwości, złączenia staną się bardziej skomplikowane. Nie zamierzam tutaj wnikać w szczegóły — najważniejszą rzeczą do zapamiętania jest to, że LINQ dla SQL-a wykonuje sporo pracy związanej z analizą wyrażenia kwerendowego w celu wypracowania potrzebnego zapytania SQL. Oczywiście w celu wykonania tej analizy musi się przyjrzeć wyspecyfikowanemu przez nas wyrażeniu. Odsuńmy się na chwilę od specyfiki LINQ dla SQL-a i pomyślmy w kategoriach ogólnych nad tym, co muszą wykonać tego typu dostawcy LINQ. Będzie to dotyczyło każdego dostawcy, który musi dokonać inspekcji wyrażenia, a nie tylko podstawienia w postaci delegata. W ten sposób nadeszła w końcu pora, aby przekonać się, w jakim celu do C# 3 zostały dodane drzewa wyrażeń.

12.2. Translacje przy użyciu IQueryable i IQueryProvider W tej sekcji zajmiemy się podstawami opisującymi sposób, w jaki LINQ dla SQL-a potrafi przekonwertować nasze wyrażenie kwerendowe na SQL. Jest to punkt startowy do własnej implementacji dostawcy LINQ, jeśli kiedykolwiek przyjdzie Ci na to ochota.

Translacje przy użyciu IQueryable i IQueryProvider

391

(Proszę, abyś nie umniejszał trudności technicznych związanych z takim projektem, ale jeśli lubisz wyzwania, implementacja dostawcy LINQ jest zagadnieniem zdecydowanie interesującym). Jest to najbardziej teoretyczna sekcja w całym rozdziale, ale dobrze jest mieć pewien wgląd w to, jak LINQ decyduje o użyciu przetwarzania w pamięci, bazy danych lub innego silnika wyrażeń. W wyrażeniach kwerendowych, które widzieliśmy w LINQ dla SQL-a, źródłem danych był obiekt Table. Jeśli jednak przyjrzysz się klasie Table, zobaczysz, że nie posiada ona metod Where, Select, Join ani też żadnego innego standardowego operatora kwerendowego. Zamiast tego stosuje taki sam trik, jakim posługuje się LINQ dla Obiektów — tak jak źródło danych w LINQ dla Obiektów zawsze implementuje IEnumerable (możliwie za wywołaniem Cast lub OfType), a następnie używa metod rozszerzających w klasie Enumerable, tak Table implementuje IQueryable, po czym używa metod rozszerzających z klasy Queryable. Zobaczmy, w jaki sposób LINQ buduje drzewo wyrażeń, a następnie pozwala wykonać je dostawcy LINQ w odpowiednim czasie. Zacznijmy od sprawdzenia, co zawiera IQueryable.

12.2.1.Wprowadzenie do IQueryable i związanych z nim interfejsów Sprawdzenie w dokumentacji IQueryable, jakie elementy zawiera bezpośrednio (w przeciwieństwie do odziedziczonych), może rozczarować. Nie ma żadnych. Zamiast tego dziedziczy po IEnumerable i niegenerycznym interfejsie IQueryable, który z kolei dziedziczy po niegenerycznym interfejsie IEnumerable. Można by stąd wnioskować, że nowe elementy są właśnie w IQueryable, czyż nie tak? Prawie. IQueryable posiada zaledwie trzy właściwości: QueryProvider, ElementType i Expression. Właściwość Query ´Provider jest typu IQueryProvider, będącego jeszcze jednym nowym interfejsem, który należy poznać. Zagubiony? Być może pomoże Ci rysunek 12.2. Jest to diagram klas przedstawiający wszystkie użyte bezpośrednio interfejsy. Najprościej traktować IQueryable jako interfejs reprezentujący zapytanie, które w chwili wykonania wyda sekwencję wyników. Szczegóły tego zapytania z punktu widzenia LINQ są przechowywane w drzewie wyrażeń zwracanym poprzez właściwość Expression interfejsu IQueryable. Wykonanie zapytania polega na rozpoczęciu iteracji po IQueryable (inaczej mówiąc, na wywołaniu metody GetEnumerator, a następnie MoveNext na wyniku tego wywołania) lub na wywołaniu metody Execute na IQueryProvider z przekazaniem jej drzewa wyrażeń. Skoro wiemy już, do czego służy IQueryable, zastanówmy się, po co nam IQuery ´Provider? Możemy zrobić coś więcej, niż tylko uruchomić zapytanie — możemy użyć go do zbudowania jeszcze większego zapytania, co jest powodem istnienia w LINQ standardowych operatorów kwerendowych3. Aby zbudować zapytanie, musimy użyć metody CreateQuery na odpowiednim interfejsie IQueryProvider4. 3

Przynajmniej tych, które odraczają wykonanie, takich jak Where i Join. Później zobaczymy, co się dzieje z agregacjami takimi jak Count.

4

Zarówno Execute, jak i CreateQuery posiadają generyczne i niegeneryczne przeciążenia. Wersje niegeneryczne pozwalają na łatwiejsze tworzenie dynamicznych zapytań w kodzie. Wersji generycznych używają wyrażenia kwerendowe czasu kompilacji.

392

ROZDZIAŁ 12

LINQ — nie tylko kolekcje

Rysunek 12.2. Diagram klas pokazujący interfejsy związane z IQueryable

Pomyśl o źródle danych jak o prostym zapytaniu (na przykład SELECT * FROM Some ´Table) — wywołanie Where, Select, OrderBy i podobnych metod daje w wyniku inne zapytanie, bazujące na tym pierwszym. Mając zapytanie w postaci IQueryable, możesz stworzyć nowe zapytanie w następujący sposób: 1. Poproś istniejące drzewo wyrażeń o swoje kwerendowe drzewo wyrażeń (używając właściwości Expression). 2. Zbuduj nowe drzewo wyrażeń, które zawiera oryginalne drzewo i Twoją dodatkową funkcjonalność (na przykład filtr, projekcję, uporządkowanie). 3. Poproś oryginalne wyrażenie kwerendowe o swojego dostawcę (używając właściwości Provider). 4. Wywołaj na dostawcy metodę CreateQuery, przekazując jej nowe drzewo wyrażeń. Jedynym podchwytliwym krokiem w tym zestawieniu jest stworzenie nowego drzewa wyrażeń. Na szczęście w statycznej klasie Queryable znajduje się szereg metod, które wykonają całą tę pracę za nas. Wystarczy teorii — zacznijmy implementować interfejsy, aby zobaczyć to wszystko w działaniu.

Translacje przy użyciu IQueryable i IQueryProvider

393

12.2.2.Prototyp — implementacja interfejsów wykonująca wpisy w dzienniku Nie ekscytuj się zbytnio, w tym rozdziale nie będziemy budować własnego w pełni funkcjonalnego dostawcy. Jeśli jednak zrozumiesz wszystko w tej sekcji, znajdziesz się w o wiele lepszej sytuacji, rozpoczynając budowę, jeśli kiedyś przyjdzie Ci na to ochota i, co jest chyba bardziej istotne, będziesz rozumiał, co dokładnie się dzieje, kiedy wysyłasz zapytania LINQ dla SQL-a. Większość ciężkiej pracy wykonywanej przez dostawcę zapytań ma miejsce w chwili wykonania, kiedy trzeba przeanalizować drzewo wyrażeń i przekonwertować je na formę spełniającą wymogi platformy docelowej. My koncentrujemy się na pracy, która ma miejsce wcześniej — chcemy wiedzieć, w jaki sposób LINQ przygotowuje się do wykonania zapytania. Napiszemy własną implementację IQueryable i IQueryProvider, a następnie spróbujemy wykonać kilka zapytań w odniesieniu do nich. Interesującą rzeczą nie są wyniki — nie będziemy wykonywać żadnej użytecznej pracy przy użyciu naszych zapytań — ale seria wywołań, które mają miejsce do momentu wykonania zapytania. Napiszemy typy FakeQueryProvider i FakeQuery. Implementacja każdego interfejsu zapisuje wykorzystywane w danej chwili wyrażenie, używając do tego celu prostej (niepokazanej tutaj) metody logującej. Przyjrzyjmy się najpierw klasie FakeQuery. Pokazuje ją listing 12.3. Listing 12.3. Prosta implementacja IQueryable rejestrująca wywołania metod class FakeQuery : IQueryable { public Expression Expression { get; private set; } public IQueryProvider Provider { get; private set; } public Type ElementType { get; private set; }

Deklaracja prostych właściwości automatycznych

internal FakeQuery(IQueryProvider provider, Expression expression) { Expression = expression; Provider = provider; ElementType = typeof(T); } internal FakeQuery() : this(new FakeQueryProvider(), null) { Expression = Expression.Constant(this); Użycie istniejącego } wyrażenia jako wyrażenia początkowego

public IEnumerator GetEnumerator() { Logger.Log(this, Expression); return Enumerable.Empty().GetEnumerator(); }

Zwrócenie wyniku w postaci

pustej sekwencji IEnumerator IEnumerable.GetEnumerator() { Logger.Log(this, Expression); return Enumerable.Empty().GetEnumerator(); }

394

ROZDZIAŁ 12

LINQ — nie tylko kolekcje public override string ToString() { return "FakeQuery"; }

Nadpisanie ToString na potrzeby logowania

}

Właściwości interfejsu IQueryable są implementowane w FakeQuery przez właściwości automatyczne ( ) i inicjalizowane przez konstruktor. Są dwa konstruktory: bezparametrowy, używany w naszym programie głównym do stworzenia zwykłego źródła zapytania, oraz drugi, wywoływany przez FakeQueryProvider z bieżącym wyrażeniem kwerendowym. Użycie Expression.Constant(this) jako pierwszego źródła wyrażenia ( ) ukazuje jedynie, że początkowo wyrażenie reprezentuje oryginalny obiekt. (Wyobraź sobie na przykład implementację reprezentującą tabelę — zanim zastosujesz jakiekolwiek operatory kwerendowe, zapytanie zwróci całą tabelę). Podczas logowania wyrażenie stałe używa przeciążenia metody ToString, dlatego też daliśmy krótki stały opis ( ). To sprawia, że końcowe wyrażenie staje się znacznie bardziej przejrzyste niż w przypadku jego braku. Kiedy zostajemy poproszeni o iterację po wynikach zapytania, dla uproszczenia zwracamy zawsze pustą sekwencję ( ). W tym miejscu faktyczna implementacja zajęłaby się analizą wyrażenia lub (co bardziej prawdopodobne) wywołałaby Execute na swoim dostawcy zapytania, a następnie zwróciła otrzymany wynik. Jak widzisz, w FakeQuery niewiele się dzieje. Poniższy listing (12.4) pokazuje, że podobnie jest również w FakeQueryProvider. Listing 12.4. Implementacja IQueryProvider używająca FakeQuery class FakeQueryProvider : IQueryProvider { public IQueryable CreateQuery(Expression expression) { Logger.Log(this, expression); return new FakeQuery(this, expression); } public IQueryable CreateQuery(Expression expression) { Logger.Log(this, expression); Type queryType = typeof(FakeQuery<>).MakeGenericType(expression.Type); object[] constructorArgs = new object[] { this, expression }; return (IQueryable)Activator.CreateInstance(queryType, constructorArgs); } public T Execute(Expression expression) { Logger.Log(this, expression); return default(T); } public object Execute(Expression expression) { Logger.Log(this, expression); return null; } }

Translacje przy użyciu IQueryable i IQueryProvider

395

W przypadku FakeQueryProvider pod względem implementacyjnym jest jeszcze mniej do omówienia, niż było dla FakeQuery. Metoda CreateQuery nie wykonuje żadnego rzeczywistego przetwarzania, lecz działa jako metoda wytwórcza dla zapytania. Jedyny podchwytliwy punkt to to, że niegeneryczna metoda przeciążona musi mimo wszystko dostarczyć odpowiedni argument typu dla FakeQuery w oparciu o właściwość Type danego wyrażenia. Przeciążenie metody Execute rejestruje jedynie wywołanie i zwraca pusty wynik. W tym miejscu w normalnych warunkach zostałaby przeprowadzona szeroka analiza, łącznie z wywołaniem usługi sieciowej, odwołaniem do bazy danych lub innej platformy docelowej. Mimo że nie wykonaliśmy rzeczywistej pracy, kiedy zaczniemy używać FakeQuery jako źródła, w wyrażeniu kwerendowym zaczną dziać się ciekawe rzeczy. Uchyliłem już rąbka tajemnicy na temat tego, jak możemy tworzyć wyrażenia kwerendowe bez jawnego pisania metod obsługujących standardowe operatory kwerendowe — wszystko sprowadza się do metod rozszerzających, tym razem zawartych w klasie Queryable.

12.2.3.Spajanie wszystkiego razem — metody rozszerzające typu Queryable Tak jak Enumerable zawiera metody rozszerzające typ IEnumerable, implementujące standardowe operatory kwerendowe LINQ, tak Queryable zawiera metody rozszerzające typ IQueryable. Pomiędzy implementacjami Enumerable i Queryable istnieją dwie zasadnicze różnice. Przede wszystkim wszystkie metody Enumerable używają delegatów jako swoich parametrów — na przykład metoda Select przyjmuje Func. Takie rozwiązanie sprawdza się w przypadku przekształceń dokonywanych w pamięci, ale dla dostawców LINQ, którzy wykonują zapytania w innych miejscach, potrzebujemy formy — drzew wyrażeń — którą jesteśmy w stanie przeanalizować dokładniej. Dla przykładu odpowiednie przeciążenie Select w Queryable przyjmuje parametr typu Expression>. Kompilatorowi to nie przeszkadza — po przetłumaczeniu zapytania otrzymuje wyrażenie lambda, które przekazuje jako argument samej metodzie, a wyrażenia lambda mogą być tłumaczone zarówno na instancje delegatów, jak i drzewa wyrażeń. Dzięki temu LINQ dla SQL-a jest w stanie działać tak płynnie. Cztery kluczowe elementy zaangażowane w ten proces to nowe cechy C# 3: wyrażenia lambda, tłumaczenie wyrażeń kwerendowych na zwykłe wyrażenia używające wyrażeń lambda, metody rozszerzające i drzewa wyrażeń. Brak któregokolwiek z nich spowodowałby problemy. Jeżeli na przykład wyrażenia kwerendowe byłyby zawsze tłumaczone na instancje delegatów, nie można by było użyć ich z dostawcą takim jak LINQ dla SQL-a, który wymaga drzew wyrażeń. Rysunek 12.3 pokazuje dwie ścieżki możliwe do obrania przez wyrażenia kwerendowe. Różnią się one między sobą jedynie tym, jakie interfejsy implementują źródła danych. Zwróć uwagę, że na wspomnianym rysunku początkowe fazy procesu kompilacji są niezależne od źródła danych. Używane jest to samo wyrażenie kwerendowe, a proces tłumaczenia przebiega dokładnie tak samo. Faktyczne źródło danych nabiera znaczenia dopiero wtedy, kiedy kompilator przygląda się przetłumaczonemu zapytaniu, aby znaleźć odpowiednie metody Select i Where. W tym momencie wyrażenia lambda mogą

396

ROZDZIAŁ 12

LINQ — nie tylko kolekcje

Rysunek 12.3. Zapytanie przebiegające dwoma ścieżkami, w zależności od tego, czy źródło danych implementuje IQueryable, czy tylko IEnumerable

być przekonwertowane na instancje delegatów lub drzewa wyrażeń, dając — potencjalnie — radykalnie odmienne implementacje: typowo w pamięci dla ścieżki po lewej stronie oraz w postaci zapytań SQL wykonywanych na bazie danych dla ścieżki po prawej stronie. Decyzja (rysunek 12.3) o tym, czy użyć Enumerable, czy Queryable, nie jest specjalnie obsługiwana przez kompilator C#. Nie są to dwie jedyne możliwe ścieżki, o czym przekonamy się później, kiedy dojdziemy do rozwiązań Równoległego LINQ i Reaktywnego LINQ. Możesz stworzyć swój własny interfejs i zaimplementować metody rozszerzające zgodne z wzorcem zapytań lub nawet własny typ z odpowiednimi metodami instancji. Druga duża różnica pomiędzy Enumerable i Queryable to wykonywanie przez metody rozszerzające klasy Enumerable faktycznej pracy związanej z odpowiadającymi im operatorami kwerendowymi (lub przynajmniej budowanie iteratorów wykonujących tę pracę). Na przykład w metodzie Enumerable.Where znajduje się kod wykonujący odpowiednie filtrowanie i wydający w sekwencji wynikowej jedynie elementy spełniające kryteria. Dla kontrastu implementacje operatorów kwerendowych w klasie Queryable wykonują niewielką pracę. Tworzą jedynie nowe zapytanie w oparciu o parametry lub wywołują Execute na dostawcy zapytania — tak jak zostało to opisane na końcu sekcji 12.2.1. Innymi słowy, są używane wyłącznie do budowania zapytań i żądania ich wykonania — za operatorami nie kryje się żadna logika. Oznacza to, że nadają się dla każdego dostawcy LINQ, który używa drzew wyrażeń, ale samodzielnie są bezużyteczne. Stanowią one „spoiwo” pomiędzy Twoim własnym kodem i szczegółami dostawcy.

Translacje przy użyciu IQueryable i IQueryProvider

397

Mając już dostępne metody rozszerzające klasy Queryable i nasze gotowe do użycia implementacje interfejsów IQueryable i IQueryProvider, możemy wreszcie zobaczyć, co się stanie, kiedy użyjemy wyrażenia kwerendowego w naszym osobistym dostawcy.

12.2.4.Udawany dostawca w działaniu Listing 12.5 pokazuje proste wyrażenie kwerendowe, które — jak zakładamy — znajduje w naszym udawanym źródle danych wszystkie łańcuchy rozpoczynające się od „abc” i dokonuje projekcji wyników na sekwencję długości pasujących łańcuchów. Iterujemy po wynikach, ale nic z nimi nie robimy, ponieważ wiemy, że będą puste. Nie mamy źródła danych i nie napisaliśmy żadnego kodu wykonującego faktyczne filtrowanie — rejestrujemy jedynie, jakich wywołań dokonuje LINQ w trakcie tworzenia wyrażenia kwerendowego i iterowania po wynikach. Listing 12.5. Proste wyrażenie kwerendowe używające „udawanych” klas zapytań var query = from x in new FakeQuery() where x.StartsWith("abc") select x.Length; foreach (int i in query) { }

Jakich wyników spodziewałbyś się po uruchomieniu listingu 12 5? A w szczególności jakiego wpisu w dzienniku oczekiwałbyś na końcu, w miejscu, gdzie normalnie spodziewałbyś się wykonania jakiejś rzeczywistej pracy z drzewem wyrażeń? Oto wynik, który został dla czytelności odrobinę przeformatowany: FakeQueryProvider.CreateQuery Expression=FakeQuery.Where(x => x.StartsWith("abc")) FakeQueryProvider.CreateQuery Expression=FakeQuery.Where(x => x.StartsWith("abc")) .Select(x => x.Length) FakeQuery.GetEnumerator Expression=FakeQuery.Where(x => x.StartsWith("abc")) .Select(x => x.Length)

Warto tu zwrócić uwagę na dwie rzeczy: GetEnumerator jest wywoływany na końcu, a nie na jakichkolwiek wynikach pośrednich. W chwili wywołania GetEnumerator mamy już całą informację obecną w oryginalnym wyrażeniu kwerendowym. Nie musieliśmy śledzić ręcznie wcześniejszych części wyrażenia na każdym kroku — pojedyncze drzewo wyrażeń przechwytuje wszystkie informacje, jakie się do tej pory pojawiły. Niech Cię nie zwiedzie ten zwięzły wynik — faktyczne drzewo wyrażeń jest głębokie i skomplikowane, a to głównie ze względu na klauzulę where zawierającą dodatkowe wywołanie metody. To drzewo wyrażeń stanowiłoby element podlegający analizie przez LINQ dla SQL-a w celu wypracowania zapytania do uruchomienia. Dostawcy LINQ mogliby budować swoje własne zapytania (w dowolnie wybranej przez siebie formie),

398

ROZDZIAŁ 12

LINQ — nie tylko kolekcje

tak jak wykonywane są wywołania CreateQuery, ale zwykle końcowe drzewo wyrażeń, kiedy jest wywoływana metoda GetEnumerator, jest prostsze, gdyż niezbędna informacja jest już na miejscu. Ostatnim wywołaniem zarejestrowanym przez listing 12.5 było FakeQuery.Get ´Enumerator, co może skłaniać do zadania pytania, po co dodatkowo potrzebujemy jeszcze metody Execute w interfejsie IQueryProvider. Nie wszystkie wyrażenia kwerendowe generują sekwencje — jeżeli użyjesz operatora agregującego, takiego jak Sum, Count lub Average, nie będziesz tak naprawdę tworzył źródła danych, ale obliczał bezpośrednio wynik. W takiej sytuacji jest wywoływana metoda Execute. Przykład takiego wywołania wraz z wynikiem działania programu pokazuje listing 12.6. Listing 12.6. IQueryProvider.Execute var query = from x in new FakeQuery() where x.StartsWith("abc") select x.Length; double mean = query.Average(); //Wynik FakeQueryProvider.CreateQuery Expression=FakeQuery.Where(x => x.StartsWith("abc")) FakeQueryProvider.CreateQuery Expression=FakeQuery.Where(x => x.StartsWith("abc")) .Select(x => x.Length) FakeQueryProvider.Execute Expression=FakeQuery.Where(x => x.StartsWith("abc")) .Select(x => x.Length) .Average()

Klasa FakeQueryProvider może się okazać całkiem użyteczna jako pomoc w zrozumieniu tego, co kompilator C# robi w tle z wyrażeniem kwerendowym. Pokaże ona wszystkie identyfikatory przezroczyste wprowadzone do wyrażenia kwerendowego razem z przetłumaczonymi wywołaniami SelectMany, GroupJoin i podobnymi.

12.2.5.Podsumowanie IQueryable Nie napisaliśmy żadnego znaczącego kodu, jakiego wymagałby rzeczywisty dostawca zapytań w celu wykonania użytecznej pracy. Mam jednak nadzieję, że nasz udawany dostawca pozwolił Ci się przekonać, w jaki sposób informacje z wyrażeń kwerendowych są przekazywane dostawcom. Wszystko bazuje na metodach rozszerzających klasy Queryable przy odpowiedniej implementacji interfejsów IQueryable i IQueryProvider. W tej sekcji zagłębiliśmy się bardziej w szczegóły, niż będzie to miało miejsce w pozostałej części rozdziału, gdyż ma to związek z podstawami, na których bazuje widziany przez nas wcześniej kod LINQ dla SQL-a. Chociaż jest mało prawdopodobne, abyś kiedykolwiek musiał implementować wspomniane interfejsy samodzielnie, kroki algorytmu związane z pobraniem wyrażenia kwerendowego C# i wykonaniem SQL-a na bazie danych są bardzo istotne i znajdują się w sercu głównych cech C# 3. Świadomość, dlaczego C# zyskał te cechy, pozwoli Ci na lepsze zrozumienie języka.

Interfejsy zaprzyjaźnione z LINQ i LINQ dla XML-a

399

Na tym kończymy nasz opis LINQ z użyciem drzew wyrażeń. Pozostała część rozdziału omawia zapytania wewnątrzprocesowe przy użyciu delegatów. Jak się jednak przekonamy, nadal mamy szansę zobaczyć ogromną różnorodność i innowacyjność w rozwiązaniach stosujących LINQ. Naszym pierwszym celem będzie LINQ dla XML-a, który jest „jedynie” interfejsem XML zaprojektowanym do współpracy z LINQ dla Obiektów.

12.3. Interfejsy zaprzyjaźnione z LINQ i LINQ dla XML-a LINQ dla XML-a jest prawdopodobnie najbardziej przyjemnym interfejsem programistycznym XML, jakiego kiedykolwiek używałem. Można go w prosty sposób użyć i zrozumieć, niezależnie do tego, czy chcesz przetworzyć istniejący XML, czy wygenerować nowy dokument, czy też wykonać obie rzeczy jednocześnie. Częściowo jest to zupełnie niezależne od LINQ, ale w dużym stopniu bazuje na dobrej interakcji z pozostałą częścią tej technologii. Podobnie jak w przypadku sekcji 12.1, przedstawię Ci jedynie taką dawkę wstępnych informacji, abyś mógł zrozumieć przykłady, a następnie pokażę, w jaki sposób LINQ dla XML-a łączy swoje własne operatory kwerendowe z tymi znajdującymi się w LINQ dla Obiektów. Pod koniec tej sekcji powinieneś mieć pojęcie na temat tego, jak harmonijnie połączyć swój interfejs programistyczny z resztą środowiska.

12.3.1.Rdzenne typy LINQ dla XML-a LINQ dla XML-a rezyduje w module System.Xml.Linq i również większość typów znajduje się w przestrzeni nazw System.Xml.Linq5. Niemal wszystkie typy w tej przestrzeni nazw mają prefiks w postaci X, zatem odpowiednikiem typu XmlElement z interfejsu DOM (ang. document object model) w LINQ dla XML-a jest typ XElement. Dzięki temu można w łatwy sposób dostrzec miejsca, w których kod używa LINQ dla XML-a, nawet jeśli dany typ nie jest Ci początkowo znany. Rysunek 12.4 prezentuje typy, których będziesz używał najczęściej. Oto krótki opis wszystkich typów z tego rysunku: XName jest używany dla nazw elementów i atrybutów. Instancje są zwykle tworzone przy użyciu niejawnej konwersji z łańcucha (w takim przypadku nie jest używana żadna przestrzeń nazw) lub poprzez przeciążony operator +(XNamespace, string). XNamespace reprezentuje przestrzeń nazw XML — mówiąc prościej, identyfikator w formacie URI. Instancje są zwykle tworzone przez niejawną konwersję z łańcucha.

5

Regularnie zdarza mi się zapomnieć, czy jest to System.Xml.Linq, czy też System.Linq.Xml. Mógłbym powiedzieć, że nie pogubisz się, jeśli będziesz pamiętał, iż chodzi przede wszystkim o interfejs programistyczny XML. Niestety, w moim przypadku to najwyraźniej nie działa. Może będziesz miał więcej szczęścia ode mnie.

400

ROZDZIAŁ 12

LINQ — nie tylko kolekcje

Rysunek 12.4. Diagram klas LINQ dla XML-a, pokazujący najczęściej stosowane typy danych

XObject jest wspólnym przodkiem zarówno XNode, jak i XAttribute.

W przeciwieństwie do API DOM, w LINQ dla XML-a atrybut nie jest węzłem. Stąd na przykład metody zwracające węzły dzieci nie uwzględniają atrybutów. XNode reprezentuje węzeł w drzewie XML. Definiuje on różnorodne metody służące do manipulacji drzewem i odpytywania go. Istnieje szereg klas, takich jak XComment lub XDeclaration, będących potomkami XNode, które nie zostały pokazane na rysunku 12.4. Są one rzadko stosowane — najczęściej są używane węzły dokumentu, elementu i tekstu. XAttribute jest atrybutem z nazwą i wartością. Wewnętrznie wartość jest tekstem, ale istnieją jawne konwersje na wiele innych typów danych, takich jak int czy DateTime. XContainer jest węzłem w drzewie XML, który może posiadać dzieci — mówiąc

prościej, jest to dokument lub element. XText jest węzłem tekstu. Dalszym typem potomnym jest XCData, używany do reprezentacji węzłów tekstowych typu CDATA. (W przybliżeniu są to dosłowne literały łańcuchowe wymagające mniejszej liczby znaków ucieczki). XText jest rzadko instancjonowany bezpośrednio w kodzie użytkownika. Zamiast tego instancja tego typu jest tworzona automatycznie, jeśli w zawartości dokumentu lub elementu zostanie użyty łańcuch.

Interfejsy zaprzyjaźnione z LINQ i LINQ dla XML-a

401

XElement jest elementem. Razem z XAttribute jest to jedna z najczęściej

stosowanych klas w LINQ dla XML-a. W przeciwieństwie do DOM API, instancję klasy XElement możesz utworzyć bez udziału dokumentu będącego jego kontenerem. Jeżeli nie potrzebujesz dokumentu (na przykład w celu wstawienia własnej deklaracji XML), możesz zastąpić go zwykłym elementem. XDocument jest dokumentem. Dostęp do korzenia drzewa daje właściwość Root — jest to odpowiednik XmlDocument.DocumentElement. Jak wspomniałem wcześniej,

często typ ten nie jest wymagany. Model dokumentu zawiera również inne klasy, a ponadto są jeszcze typy przeznaczone dla takich operacji jak ładowanie i zapisywanie opcji, ale te, które opisałem, są najważniejsze. Spośród pokazanych typów jedynymi, do których będziesz się musiał odwoływać w sposób jawny, są XElement i XAttribute. Jeżeli używasz przestrzeni nazw, będziesz musiał skorzystać również z XNamespace, ale pozostałe typy możesz przez większość czasu ignorować. Niesamowite jest, jak wiele możesz zrobić przy użyciu tak małej liczby typów. Skoro jesteśmy już przy rzeczach niesamowitych, nie mogę się powstrzymać przed pokazaniem Ci, jak LINQ dla XML-a obsługuje przestrzenie nazw. Nie będziemy ich używać w innych miejscach, ale jest to dobry przykład obrazujący ułatwienie życia przez zestaw dobrze zaprojektowanych konwersji i operatorów. Jeżeli potrzebujesz jedynie wyspecyfikować nazwę elementu lub atrybutu, bez przestrzeni nazw, możesz użyć zwykłego łańcucha. Nie znajdziesz jednak żadnych konstruktorów dla obu tych typów, które przyjmowałyby parametry typu string — wszystkie przyjmują typ XName. Pomiędzy typem string i XName, a także pomiędzy string i XNamespace istnieje konwersja niejawna. Zsumowanie przestrzeni nazw razem z łańcuchem daje również referencję do typu XName. Naprawdę cienka linia oddziela nadużywanie operatorów od geniuszu w ich zastosowaniu, ale w przypadku LINQ dla XML-a takie podejście faktycznie się sprawdza. Oto fragment kodu tworzący pewne dwa elementy — jeden z przestrzenią nazw i jeden bez: XElement noNamespace = new XElement("no-namespace"); XNamespace ns = "http://csharpindepth.com/sample/namespace"; XElement withNamespace = new XElement(ns + "in-namespace");

Takie podejście sprawia, że kod jest czytelny, nawet kiedy używane są przestrzenie nazw, co po doświadczeniach z innymi interfejsami stanowi spore ułatwienie. Stworzyliśmy jednak zaledwie dwa puste elementy. Jak nadać im treść?

12.3.2.Konstrukcja deklaratywna Stosując interfejs programistyczny DOM, tworzysz element, a następnie dodajesz do niego zawartość. Podobnie możemy zrobić również w LINQ dla XML-a poprzez zastosowanie metody Add odziedziczonej po XContainer — nie jest to jednak idiomatyczny sposób wykonywania operacji w LINQ dla XML-a6. Mimo wszystko warto przyjrzeć

6

W pewnym stopniu jest to przykre, że XElment nie implementuje IEnumerable — pozwoliłoby to na konstruowanie obiektów za pomocą inicjalizatorów kolekcji. Nie ma się jednak czym przejmować — użycie konstruktorów jest równie zmyślne.

402

ROZDZIAŁ 12

LINQ — nie tylko kolekcje

się sygnaturze XContainer.Add, ponieważ wprowadza ona nas w model nadawania wartości obiektom. Być może oczekiwałeś sygnatury Add(XNode) lub Add(XObject), ale w rzeczywistości jest to tylko Add(object). Taki sam wzorzec obowiązuje sygnatury konstruktorów XElement i XDocument. Po nazwie możesz niczego nie określać (tworząc w ten sposób pusty element), wskazać pojedynczy obiekt (tworząc element z pojedynczym węzłem potomnym) lub tablicę obiektów, aby utworzyć wiele węzłów potomnych. W przypadku wielu elementów potomnych jest używany parametr tablicowy (słowo kluczowe param w C#), co oznacza, że kompilator sam utworzy dla Ciebie tablicę — wystarczy jedynie, że zapiszesz listę parametrów. Użycie zwykłego obiektu (referencji do typu object) jako typu reprezentującego treść może się wydawać wariactwem, ale jest niezwykle użyteczne. Kiedy dodajesz treść — przez konstruktor lub metodę Add — sprawdzane są następujące punkty: Ignorowane są puste referencje. Instancje XNode i XAttribute są dodawane względnie prosto. Jeżeli mają już rodziców, zostają sklonowane, w przeciwnym razie nie jest wymagana żadna konwersja. (Przeprowadzane są również inne sprawdzenia poprawności, na przykład aby się przekonać, czy nie masz zduplikowanych atrybutów w pojedynczym elemencie). Łańcuchy, liczby, daty itp. są dodawane poprzez konwersję każdej wartości na węzły typu XText z użyciem standardowego formatowania XML-owego. Jeżeli argument implementuje IEnumerable (i nie jest obsługiwany w inny sposób), wtedy metoda Add przejdzie po każdej wartości kolekcji i doda ją, w miarę

potrzeby stosując rekursję. Cokolwiek, co nie posiada specjalnego trybu obsługi, jest konwertowane na tekst przez zwykłe wywołanie ToString().

Oznacza to, że często nie musisz przygotowywać swojej treści w specjalny sposób przed dodaniem jej do elementu — to LINQ dla XML-a zajmuje się dodaniem odpowiedniego obiektu (lub obiektów) dla Ciebie. Szczegóły są dobrze udokumentowane, zatem nie musisz się martwić, że dzieje się coś niepojętego — prawda jest taka, że to rozwiązanie działa. Konstruowanie elementów zagnieżdżonych prowadzi do powstania kodu, który w sposób naturalny odzwierciedla hierarchiczną strukturę drzewa. Najlepiej będzie to widać na przykładzie. Oto mały fragment kodu LINQ dla XML-a: new XElement("root", new XElement("child", new XElement("grandchild", "text")), new XElement("other-child"));

A oto XML utworzonego elementu — zauważ podobieństwo pomiędzy kodem a wynikiem jego działania: tekst

Interfejsy zaprzyjaźnione z LINQ i LINQ dla XML-a

403

Do tej pory wszystko idzie dobrze, ale najważniejszą dla nas rzeczą jest czwarty punkt na wcześniejszej liście, mówiący o rekursywnym przetwarzaniu sekwencji… ponieważ to pozwala w naturalny sposób zbudować XML z zapytania LINQ. Dla przykładu pewna strona poświęcona książkom posiada kod generujący przekaz RSS na podstawie swojej bazy danych. Wyrażenie konstruujące dokument XML składa się z 28 wierszy — co normalnie uznałbym za paskudztwo — ale okazuje się, że jest wyjątkowo przyjemne w czytaniu7. Wyrażenie to zawiera dwa zapytania LINQ: jedno wypełniające wartość atrybutu i drugie dostarczające sekwencję elementów, z których każdy reprezentuje pewną wiadomość. Czytając kod, bez wątpliwości wiesz, jak będzie wyglądać wynikowy kod XML. Aby skonkretyzować te rozważania, weźmy dwa proste przykłady z systemu śledzenia błędów. Do zademonstrowania przykładowych danych użyję LINQ dla Obiektów, ale równie dobrze moglibyśmy wykorzystać niemal identyczne zapytania działające z innym dostawcą LINQ. Zaczniemy od zbudowania elementu zawierającego wszystkich użytkowników w systemie. W tym przypadku potrzebujemy jedynie projekcji, zatem na listingu 12.7 używamy notacji kropkowej. Listing 12.7. Tworzenie elementów z użytkowników var users = new XElement("users", SampleData.AllUsers.Select(user => new XElement("user", new XAttribute("name", user.Name), new XAttribute("type", user.UserType))) ); Console.WriteLine(users); //Wynik

Jeżeli chcemy stworzyć odrobinę bardziej skomplikowane zapytanie, prawdopodobnie bardziej opłaca się użyć wyrażenia kwerendowego. Listing 12.8 tworzy kolejną listę użytkowników, ale tym razem jedynie programistów w firmie SkeetySoft. Dla urozmaicenia imię każdego programisty nie jest tym razem wartością atrybutu, lecz węzłem tekstowym wewnątrz elementu.

7

Jednym z czynników wpływających na czytelność jest metoda rozszerzająca, którą stworzyłem, aby konwertować typy anonimowe na elementy, używając właściwości dla elementów potomnych. Jeżeli jesteś zainteresowany, kod jest dostępny za darmo jako część mojego projektu MiscUtils (zobacz http://mng.bz/xDMt). Jest on pomocny jedynie wtedy, kiedy struktura XML, jakiej potrzebujesz, pasuje do określonego wzorca, ale w takim przypadku znacznie redukuje nieład spowodowany wywołaniami konstruktorów klasy XElement.

404

ROZDZIAŁ 12

LINQ — nie tylko kolekcje Listing 12.8. Tworzenie elementów z węzłami tekstowymi var developers = new XElement("developers", from user in SampleData.AllUsers where user.UserType == UserType.Developer select new XElement("developer", user.Name) ); Console.WriteLine(developers); //Wynik Deborah Denton Darren Dahlia

Tego typu podejście może zostać zastosowane do wszystkich przykładowych danych, co doprowadzi do następującej struktury dokumentu:

Kod generujący powyższy wynik znajdziesz w całości w pliku XmlSampleData.cs, należącym do projektu, który można pobrać ze strony książki. Demonstruje on alternatywę dla podejścia z jednym dużym wyrażeniem — każdy z elementów pod elementem głównym jest tworzony oddzielnie, a następnie całość jest „sklejana” w następujący sposób: XElement root = new XElement("defect-system", projects, users, defects);

Tego XML-a użyjemy do zademonstrowania następnego punktu związanego z integracją LINQ, czyli zapytań. Zacznijmy od metod kwerendowych dostępnych na pojedynczym węźle.

12.3.3.Zapytania na pojedynczych węzłach Być może oczekujesz mojego oświadczenia, że XElement implementuje IEnumerable i dzięki temu mamy za darmo zapytania LINQ. Nie jest to aż tak proste, ponieważ istnieje wiele różnych elementów, po których może iterować XElement. XElement zawiera szereg metod osiowych używanych jako źródła zapytań. Jeżeli znasz język XPath, powinieneś być bez wątpienia zaznajomiony z ideą osi. Oto metody osiowe używane bezpośrednio do odpytywania pojedynczego węzła, z których każda zwraca odpowiedni typ IEnumerable:

Interfejsy zaprzyjaźnione z LINQ i LINQ dla XML-a

Ancestors

AncestorsAndSelf

Annotations

Attributes

Descendants

DescendantAndSelf

DescendantNodes

DescendantNodesAndSelf

Elements

ElementsAfterSelf

ElemenetsBeforeSelf

Nodes

405

Wszystkie z nich są samokomentujące (w MSDN-ie można znaleźć więcej szczegółów na ich temat). Istnieją użyteczne przeciążenia pozwalające wydobywać jedynie węzły o odpowiedniej nazwie. Na przykład wywołanie Descendants("User") na XElement zwróci wszystkie elementy typu user pod elementem, dla którego dokonaliśmy wywołania. Oprócz wywołań zwracających sekwencje, niektóre metody zwracają pojedyncze wyniki — najważniejsze z nich, zwracające odpowiednio atrybut nazwany i pierwszy element potomny o zadanej nazwie, to Attribute i Element. Dodatkowo istnieją jawne konwersje z XAttribute lub XElement na szereg innych typów, takich jak int, string i DateTime. Mają one znaczenie zarówno dla filtrowania, jak i projekcji wyników. Każda konwersja na wartość nienullowalną ma również swój odpowiednik dla wartości nullowalnej — te (razem z konwersją na łańcuch) zwracają wartość pustą, jeśli zostaną wywołane na pustej referencji. Taka propagacja wartości pustych oznacza, że nie musisz sprawdzać obecności lub nieobecności atrybutów czy elementów wewnątrz zapytania — zamiast tego możesz użyć wyników zapytania. Co to ma wspólnego z LINQ? Fakt, że wielokrotne wyniki wyszukiwania są zwracane w formie IEnumerable, oznacza, iż po znalezieniu pasujących elementów możesz skorzystać ze zwykłych metod LINQ dla Obiektów. Listing 12.9 pokazuje przykład wyszukiwania nazw i typów użytkowników, tym razem zaczynając od przykładowych danych w XML-u. Listing 12.9. Wyświetlanie użytkowników z wnętrza struktury XML XElement root = XmlSampleData.GetElement(); var query = root.Element("users").Elements() .Select(user => new { Name=(string)user.Attribute("name"), UserType=(string)user.Attribute("type") }); foreach (var user in query) { Console.WriteLine ("{0}: {1}", user.Name, user.UserType); }

Po utworzeniu danych na początku przechodzimy do elementu users i pytamy go o jego bezpośrednich potomków. To dwustopniowe pobranie mogłoby zostać skrócone do root.Descendants("user"), ale dobrze jest wiedzieć, że istnieją bardziej sztywne metody nawigacji, aby w razie konieczności móc ich użyć. Takie podejście jest również solidniejsze w obliczu możliwych zmian struktury dokumentu, takich jak dodanie kolejnego (niezwiązanego) elementu user w innej części dokumentu. Pozostała część wyrażenia kwerendowego to jedynie projekcja obiektu klasy XElement na typ anonimowy. Przyznaję, że odrobinę tutaj oszukujemy: trzymaliśmy go jako łańcuch,

406

ROZDZIAŁ 12

LINQ — nie tylko kolekcje

zamiast wywołać Enum.Parse i przekonwertować na odpowiednią wartość typu UserType. Drugie podejście działa równie dobrze, ale jest trochę rozwlekłe, w sytuacji kiedy potrzebujesz jedynie wersji łańcuchowej, a kod staje się trudny do rozsądnego sformatowania w ścisłych granicach strony drukowanej. Nie ma tutaj nic szczególnie wybitnego — w końcu zwracanie wyników zapytania w formie sekwencji to zjawisko całkiem powszechne. Warto zwrócić uwagę na to, jak niepostrzeżenie możemy przejść od operatorów kwerendowych, specyficznych dla danej domeny, do operatorów ogólnego przeznaczenia. To jednak nie koniec historii — LINQ dla XML-a posiada również pewne dodatkowe metody rozszerzające.

12.3.4.Operatory zapytań spłaszczonych Widzieliśmy, że wynikami jednej części zapytania może być sekwencja, a w przypadku LINQ dla XML-a jest to często sekwencja elementów. Co zrobić, jeśli chciałbyś na każdym takim elemencie wykonać zapytanie specyficzne dla XML-a? Aby zaprezentować to na pewnym wymyślonym przykładzie, możemy znaleźć wszystkie projekty w naszych danych, używając root.Element("projects").Elements(). W jaki jednak sposób znajdziemy zagnieżdżone w nich elementy typu subscription? Do każdego elementu musimy zastosować dodatkowe zapytanie, a następnie spłaszczyć wyniki. (Moglibyśmy ponownie użyć root.Descendants("subscription") — wyobraź sobie jednak bardziej złożony model dokumentu, w którym takie wywołanie by nie zadziałało). Może to wyglądać znajomo, i takie właśnie jest. Już sam LINQ dla Obiektów dostarcza operator — SelectMany (reprezentowany w wyrażeniu kwerendowym przez wielokrotne klauzule from) — realizujący to zadanie. Moglibyśmy zatem zapisać nasze zapytanie jako: from project in root.Element("projects").Elements() from subscription in project.Elements("subscription") select subscription;

Ponieważ w projekcie nie ma innych elementów oprócz subskrypcji, moglibyśmy użyć przeciążenia metody Elements, które nie specyfikuje nazwy. Uważam, że w tym przypadku wskazanie nazwy elementu daje większą przejrzystość, ale to kwestia gustu. (Bez wątpienia podobny argument można przytoczyć dla wywołania Element("pro ´jects").Elements("project")). Poniżej znajduje się to samo zapytanie zapisane w notacji kropkowej i z użyciem przeciążenia metody SelectMany, które zwraca spłaszczoną sekwencję bez wykonywania jakichkolwiek dodatkowych operacji: root.Element("projects").Elements() .SelectMany(project => project.Elements("subscription"))

Oba powyższe zapytania są pod wszelkimi względami czytelne, ale nie są idealne. LINQ dla XML-a dostarcza szereg metod rozszerzających (w klasie Xml.Linq.Extensions), które operują na specyficznym typie sekwencji lub są generyczne. Ich celem jest pomoc w poradzeniu sobie z brakiem kowariancji interfejsu generycznego w wersjach poprzedzających C# 4. Istnieje metoda InDocumentOrder, która robi dokładnie to, na co wska-

Interfejsy zaprzyjaźnione z LINQ i LINQ dla XML-a

407

zuje jej nazwa8. Jako metody rozszerzające są również dostępne, wspomniane w sekcji 12.3.4, metody osiowe. Oznacza to, że możemy przekonwertować nasze wyrażenie na prostszą postać: root.Element("projects").Elements().Elements("subscription")

Tego rodzaju konstrukcja ułatwia pisanie w LINQ dla XML-a zapytań w stylu XPath, bez konieczności zapisywania wszystkiego jako łańcuchów. Jeżeli chcesz użyć XPath, taką możliwość oferuje również większość metod rozszerzających, ale ja przekonałem się, że znacznie częściej służyły mi metody z zapytaniami. Pozwalają one na łączenie wyrażeń kwerendowych z operatorami LINQ dla Obiektów. Aby na przykład znaleźć subskrypcje dla projektów o nazwie zawierającej słowo „Media”, mógłbyś użyć: root.Element("projects").Elements() .Where(project => ((string) project.Attribute("name")) .Contains("Media")) .Elements("subscription")

Zanim przejdziemy do Równoległego LINQ, zastanówmy się, jakim sposobem projekt LINQ dla XML-a zasłużył sobie na część „LINQ” w tytule, a także w jaki sposób mógłbyś zastosować te same techniki w swoim własnym interfejsie programistycznym.

12.3.5.Praca w harmonii z LINQ Niektóre z decyzji projektowych w LINQ dla XML-a wydają się dziwne, jeżeli rozważymy je wyłącznie jako część interfejsu programistycznego XML-a, ale mają sens w kontekście LINQ. Projektanci najwyraźniej potrafili wyobrazić sobie, w jaki sposób wymyślone przez nich typy będą używane w zapytaniach LINQ, a także jak mogłyby one współdziałać z innymi źródłami danych. Jeżeli piszesz swój własny interfejs dostępu do danych w jakimkolwiek kontekście, warto wziąć pod uwagę te same zagadnienia. Czy jeżeli ktoś użyje Twoich metod w środku wyrażenia kwerendowego, to otrzyma coś użytecznego? Czy inni użytkownicy będą w stanie skorzystać z niektórych Twoich metod kwerendowych, następnie z metod z LINQ dla Obiektów, a potem znowu z Twoich metod w jednym płynnym wyrażeniu? Widzieliśmy trzy sposoby przyswojenia przez LINQ dla XML-a pozostałych części LINQ: Jest dobry w przetwarzaniu sekwencji przy swoim podejściu do konstruowania.

LINQ jest celowo deklaratywny, co jest wspierane przez LINQ dla XML-a poprzez deklaratywny sposób tworzenia struktur XML. Zwraca sekwencje ze swoich metod kwerendowych. Jest to prawdopodobnie

jedno z najbardziej oczywistych podejść, jakie powinny przyjąć interfejsy programistyczne związane z dostępem do danych. Implementacja zwracania wyników zapytania w formie IEnumerable lub klasy implementującej taki interfejs nie wymaga żadnego zastanowienia.

8

Zwraca sekwencję węzłów, która zawiera wszystkie węzły sekwencji źródłowej, posortowanej w takim samym porządku jak w dokumencie — przyp. tłum.

408

ROZDZIAŁ 12

LINQ — nie tylko kolekcje Rozszerza zestaw zapytań, jakie możesz wykonać na sekwencjach typów

XML-owych. To daje wrażenie zunifikowanego API kwerendowanego, nawet jeśli niektóre jego fragmenty są specyficzne dla XML-a. Wymienione wyżej opcje nie są jedynymi, jakie powinieneś rozważyć, ale stanowią dobry punkt wyjściowy. Być może jesteś w stanie wymyślić inne sposoby pozwalające Twoim własnym bibliotekom dobrze współgrać z LINQ. Ponad wszystko zachęcam Cię do postawienia siebie w pozycji programisty pragnącego użyć Twojego interfejsu wewnątrz kodu, który korzysta z LINQ. Co może chcieć osiągnąć taki programista? Czy LINQ i Twój interfejs mogą zostać łatwo „wymieszane”, czy też są nakierowane na osiągnięcie zupełnie innych celów? Jesteśmy mniej więcej w połowie naszej błyskawicznej wycieczki po różnych podejściach do LINQ. Nasz kolejny krok jest pod pewnymi względami uspokajający, a pod pewnymi przerażający — wracamy do odpytywania prostych sekwencji, ale tym razem równolegle…

12.4. Zastąpienie LINQ dla Obiektów Równoległym LINQ Śledzę Równoległe LINQ od dłuższego czasu. Pierwszy raz natknąłem się na nie, kiedy Joe Duffy przedstawił je na swoim blogu we wrześniu 2006 roku (zobacz http://mng.bz/ vYCO). Pierwsza publiczna beta9 została wypuszczona w listopadzie 2007 roku, w tym czasie ewoluowała również całościowa funkcjonalność. Teraz jest ona elementem składowym szerszego projektu o nazwie Parallel Extensions, będącego częścią C# 4 i mającego na celu udostępnienie elementów składowych wyższego rzędu dla programowania konkurencyjnego w porównaniu do względnie małych elementów, z jakimi musieliśmy pracować do tej pory. Parallel Extensions to coś znacznie większego niż Równoległe LINQ — często znanego pod skrótem PLINQ — ale my będziemy przyglądać się tej bibliotece wyłącznie z punktu widzenia LINQ. Ideą Równoległego LINQ jest możliwość przekształcenia długo wykonującego się zapytania LINQ dla Obiektów na zapytanie szybsze dzięki użyciu wielu wątków wykorzystujących istnienie wielu rdzeni procesora — przy możliwie najmniejszej ingerencji w samo zapytanie. Tak jak w przypadku czegokolwiek, co ma związek z konkurencyjnością, nie jest to proste, ale możesz być zaskoczony tym, co da się osiągnąć. Oczywiście nadal staramy się myśleć w perspektywie szerszej niż pojedyncze technologie LINQ — myślimy o różnych modelach interakcji, a nie tylko o małych szczegółach. Jeśli jesteś zainteresowany programowaniem konkurencyjnym, szczerze polecam zagłębienie się w bibliotekę Parallel Extensions — to jedno z najbardziej obiecujących podejść do zadań równoległych, na jakie natknąłem się ostatnimi czasy. W tej sekcji zamierzam skorzystać z jednego przykładu — generowania obrazu przedstawiającego zbiór Mandelbrota (zobacz http://mng.bz/D6YL). Nim wejdziemy na grząski teren, zacznijmy od próby poprawnego wygenerowania takiego obrazu przy użyciu pojedynczego wątku. 9

Autor mówi tutaj o pierwszym CTP (ang. Community Technology Preview) — przyp. tłum.

Zastąpienie LINQ dla Obiektów Równoległym LINQ

409

12.4.1.Kreślenie zbioru Mandelbrota przez pojedynczy wątek Zanim zaatakuje mnie jakiś matematyk, chcę wskazać, iż używam pojęcia zbiór Mandelbrota w sposób swobodny. Szczegóły nie są istotne — zależy nam jedynie na następujących aspektach: Staramy się stworzyć obraz prostokątny przy różnorodnym zestawie opcji,

takich jak szerokość, wysokość, punkt startowy i głębokość. Dla każdego piksela obrazu zamierzamy wyliczyć wartość typu byte, która będzie indeksem w 256-elementowej palecie. Wyliczenie wartości pojedynczego piksela nie zależy od innych wyników. Ostatni punkt ma krytyczne znaczenie — oznacza, że to zadanie jest zawstydzająco równoległe. Innymi słowy, nie ma w nim nic, co utrudniałoby zrównoleglenie. Nadal potrzebujemy mechanizmu rozkładającego pracę pomiędzy wątki i zbierającego wyniki razem, ale cała reszta powinna być prosta. Za dystrybucję i zbiórkę (przy minimalnej pomocy i uwadze) będzie odpowiedzialny PLINQ. My musimy jedynie wyrazić, co chcemy zrobić. W celu zademonstrowania różnych podejść utworzyłem klasę abstrakcyjną odpowiedzialną za ustawienie wszystkiego, wykonanie zapytania i wyświetlenie wyników razem z metodą obliczającą kolor pojedynczego piksela. Metoda abstrakcyjna jest odpowiedzialna za stworzenie tablicy wartości typu byte, która następnie jest konwertowana na obraz. Jako pierwszy zaczyna się górny wiersz, od lewej do prawej, następnie drugi wiersz itd. Każdy przykład jest po prostu implementacją tej metody. Powinienem zwrócić uwagę, że LINQ nie jest tutaj idealnym rozwiązaniem — sposób wykonywania przeze mnie operacji jest obarczony licznymi niedociągnięciami pod względem wydajnościowym. Nie koncentruj się na tym, tylko zwróć uwagę, że mamy zawstydzająco równoległe zapytanie i chcemy wykonać je przy użyciu wielu wątków. Kolejny listing (12.10) przedstawia wersję jednowątkową, ukazując jej wspaniałość wynikającą z prostoty. Listing 12.10. Jednowątkowe zapytanie generujące zbiór Mandelbrota var query = from row in Enumerable.Range(0, Height) from column in Enumerable.Range(0, Width) select ComputeIndex(row, column); return query.ToArray();

Iterujemy po każdym wierszu i każdej kolumnie, w każdym wierszu obliczając indeks odpowiedniego piksela. Wywołanie ToArray() wylicza sekwencję wynikową, konwertując ją na tablicę. Przepiękny wynik tego działania pokazuje rysunek 12 5. Wygenerowanie tego obrazka na laptopie z dwoma rdzeniami zajęło około 5,5 sekundy. Metoda ComputeIndex wykonuje więcej iteracji, niż faktycznie potrzebujemy, w celu bardziej wyraźnego ukazania różnic czasowych10. Skoro mamy już wyliczenie czasowe oraz wgląd w spodziewane wyniki, spróbujmy zrównoleglić zapytanie. 10

Właściwe wyliczenie czasu jest trudne, szczególnie kiedy w grę wchodzi wiele wątków. Nie próbowałem wykonać ścisłych pomiarów ani czegokolwiek podobnego. Podane czasy oznaczają jedynie „szybszy”, „wolniejszy”. Proszę, abyś podszedł do nich z rezerwą.

410

ROZDZIAŁ 12

LINQ — nie tylko kolekcje Rysunek 12.5. Obraz Mandelbrota wygenerowany przez pojedynczy wątek

12.4.2.Wprowadzenie ParallelEnumerable, ParallelQuery i AsParallel Równoległe LINQ wprowadza kilka nowych typów, chociaż wielu z nich masz szansę nigdy nie zobaczyć na własne oczy. Rezydują one w przestrzeni nazw System.Linq, zatem nie musisz nawet zmieniać dyrektyw using. ParallelEnumerable jest klasą statyczną, podobną do Enumerable. Zawiera głównie metody rozszerzające, z których większość rozszerza ParallelQuery. Ten drugi typ posiada zarówno formę niegeneryczną, jak i generyczną (ParallelQuery i ParallelQuery), ale przez większość czasu będziesz używał formy generycznej, tak jak IEnumerable jest powszechniej stosowany od IEnumerable. Oprócz tego jest jeszcze typ OrderedParallelQuery będący zrównoleglonym odpowiednikiem IOrderedEnumerable. Związki zachodzące pomiędzy tymi typami zostały przedstawione na rysunku 12.6. Jak widzisz, ParallelQuery implementuje IEnumerable, zatem kiedy skonstruujesz już poprawnie zapytanie, możesz iterować po wynikach, tak jak robiłeś to do tej pory. Mając zapytanie równoległe, pierwszeństwo nad metodami z klasy Enumerable mają metody ParallelEnumerable (ponieważ typ ParallelQuery jest bardziej wyspecjalizowany niż IEnumerable — jeżeli potrzebujesz przypomnieć sobie reguły, zajrzyj do sekcji 10.2.3). W ten sposób równoległość jest utrzymywana na przestrzeni całego zapytania. Istnieją równoległe odpowiedniki wszystkich standardowych operatorów kwerendowych LINQ, ale musisz zachować ostrożność, jeżeli stworzyłeś jakąkolwiek własną metodę rozszerzającą. Nadal będziesz mógł ją wywołać, ale spowoduje ona, że od tego momentu zapytanie będzie jednowątkowe. Jak zatem uzyskać zapytanie równoległe? Przez wywołanie AsParallel — metody rozszerzającej w ParallelEnumerable, która rozszerza IEnumerable. Możemy więc zrównoleglić nasze zapytanie Mandelbrota w niesamowicie prosty sposób. Pokazuje to listing 12.11.

Zastąpienie LINQ dla Obiektów Równoległym LINQ

411

Rysunek 12.6. Diagram klas Równoległego LINQ łącznie ze związkami pomiędzy klasycznymi interfejsami LINQ

Listing 12.11. Pierwsza próba wielowątkowego przetworzenia zapytania generującego zbiór Mandelbrota var query = from row in Enumerable.Range(0, Height) .AsParallel() from column in Enumerable.Range(0, Width) select ComputeIndex(row, column); return query.ToArray();

Gotowe? Nie całkiem. To zapytanie działa równolegle, ale wyniki nie do końca wyglądają tak, jakbyśmy się spodziewali. Nie utrzymują one kolejności, w której przetwarzamy wiersze. Zamiast naszego pięknego obrazu Mandelbrota otrzymujemy coś podobnego do rysunku 12.7 — oczywiście za każdym razem wygenerowany obraz jest inny. Ups. Pozytywnym wynikiem jest jednak to, że całość jest tworzona w około 3,2 sekundy, skąd wniosek, że moja maszyna najwyraźniej użyła drugiego rdzenia. Trudno jednak zignorować fakt, iż najważniejsze jest uzyskanie prawidłowego wyniku. Być może będziesz zaskoczony, słysząc, że jest to celowa cecha Równoległego LINQ. Uporządkowanie zapytania równoległego wymaga większej koordynacji pomiędzy wątkami, a głównym celem zrównoleglenia jest poprawienie wydajności, zatem domyślne zachowanie PLINQ to przetwarzanie zapytania w sposób nieuporządkowany. W naszym przypadku jest to pewien niuans.

12.4.3.Podkręcanie zapytań równoległych Na szczęście istnieje rozwiązanie — musisz jedynie zmusić zapytanie, aby było traktowane jako uporządkowane, co umożliwia metoda rozszerzająca AsOrdered. Naprawiony kod, generujący oryginalny obraz, przedstawia listing 12.12. Jest odrobinę wolniejszy od zapytania nieuporządkowanego, ale wciąż zdecydowanie szybszy od wersji jednowątkowej.

412

ROZDZIAŁ 12

LINQ — nie tylko kolekcje Rysunek 12.7. Obraz Mandelbrota wygenerowany przez nieuporządkowane zapytanie, w wyniku czego niektóre sekcje zostały umieszczone w złym miejscu

Listing 12.12. Wielowątkowe zapytanie Mandelbrota utrzymujące porządek var query = from row in Enumerable.Range(0, Height) .AsParallel().AsOrdered() from column in Enumerable.Range(0, Width) select ComputeIndex(row, column); return query.ToArray();

Niuanse sortowania wykraczają poza zakres tej książki, ale polecam lekturę wpisu na blogu pod adresem http://blogs.msdn.com/pfxteam/archive/2008/06/11/8592301.aspx, który wnika głęboko w szczegóły. Do zmiany zachowania zapytania można użyć również szeregu innych metod: AsUnordered — sprawia, że posortowane zapytanie staje się nieposortowane. Jeśli chcesz, aby wyniki były posortowane jedynie w pierwszej części zapytania, metoda ta pozwala na poprawienie wydajności w kolejnych fazach. WithCancellation — określa token anulujący do użycia w zapytaniu. Tokeny

anulujące są stosowane w całej bibliotece Parallel Extensions i mają na celu umożliwienie bezpiecznego anulowania w kontrolowany sposób. WithDegreeOfParallelism — pozwala Ci na wyspecyfikowanie maksymalnej liczby konkurencyjnych zadań użytych do wykonania zapytania. Możesz użyć tej metody, aby ograniczyć liczbę stosowanych wątków i uniknąć „przyblokowania” maszyny lub zwiększyć liczbę wątków dla zapytania, które nie obciąża procesora. WithExecutionMode — może zostać użyta do wymuszenia równoległego wykonania zapytania, nawet jeśli PLINQ uważa, że zostałoby ono wykonane szybciej jako zapytanie jednowątkowe.

Odwrócenie modelu zapytania przy użyciu LINQ dla Rx

413

WithMergeOptions — pozwala na zmiany w sposobie buforowania wyników.

Wyłączenie buforowania daje najkrótszy czas potrzebny do zwrócenia pierwszego wyniku, ale również niższą przepustowość. Pełne buforowanie daje najwyższą przepustowość, ale żadne wyniki nie są zwracane do momentu całkowitego wykonania zapytania. Zachowanie domyślne stanowi kompromis pomiędzy tymi dwoma skrajnościami. Najistotniejszą rzeczą, pomijając sortowanie, jest to, że zrównoleglenie nie powinno wpłynąć na wyniki zapytania. Możesz zaprojektować swoje zapytanie i przetestować je, używając LINQ dla Obiektów, a następnie zrównoleglić je, wyspecyfikować wymagania odnośnie do sortowania i dokonać innych modyfikacji w celu wykonania zgodnie z Twoimi oczekiwaniami. Gdybyś pokazał takie zapytanie komuś, kto zna LINQ, ale nie PLINQ, musiałbyś jedynie wyjaśnić wywołania metod specyficzne dla PLINQ — reszta zapytania powinna być znajoma. Czy kiedykolwiek widziałeś taki prosty sposób osiągnięcia wielozadaniowości? (Również pozostała część biblioteki Parallel Extensions jest nakierowana na osiągnięcie prostoty wszędzie, gdzie jest to możliwe). POBAW SIĘ KODEM. Z kodem do pobrania związane są dwa interesujące spostrzeżenia. Pierwsze: jeśli dokonasz zrównoleglenia na przestrzeni całego zapytania w odniesieniu do pikseli, a nie tylko wierszy, to nieposortowane zapytanie będzie wyglądać jeszcze dziwniej; drugie: istnieje metoda ParallelEnume ´rable.Range, która daje PLINQ odrobinę więcej informacji niż wywołanie Enumerable.Range(...).AsParallel(). Ja użyłem w tej sekcji AsParallel(), gdyż jest to bardziej ogólna metoda zrównoleglenia zapytania — większość zapytań nie zaczyna się od zakresu. Zmiana wewnątrzprocesowego modelu zapytania z jednowątkowego na równoległy jest w zasadzie względnie małym skokiem koncepcyjnym. W następnej sekcji zmienimy zupełnie nasz model.

12.5. Odwrócenie modelu zapytania przy użyciu LINQ dla Rx Wszystkie biblioteki LINQ, jakie widzieliśmy do tej pory, mają jedną wspólną cechę — dane są z nich wyciągane przy użyciu IEnumerable. Na pierwszy rzut oka jest to tak oczywiste, że nie warto nawet o tym mówić. Jak miałoby wyglądać alternatywne rozwiązanie? Co powiesz na wpychanie danych zamiast ich wyciągania? Zamiast dawać kontrolę konsumentowi danych, dostawca sam może usiąść w fotelu kierowcy, pozwalając konsumentowi danych zareagować, kiedy dane są dostępne. Nie przejmuj się zbytnio, jeśli masz problemy ze zrozumiem tego opisu, prawdopodobnie wiesz już, na czym polega fundament tej koncepcji, dzięki zdarzeniom. Jeśli trafia do Ciebie idea subskrypcji zdarzenia, reagowania na jego pojawienie, a następnie wypisania się z subskrypcji, jest to dobry punkt startowy. Reactive Extensions dla .NET to projekt Microsoftu pochodzący z DevLabs (zobacz http://msdn.microsoft.com/en-us/data/gg577609 i http://mng.bz/HCLP). Są wersje dostępne dla .NET 3 5 SP1, .NET 4, Silverlight 3 i 4, a nawet wersja przeznaczona dla JavaScriptu.

414

ROZDZIAŁ 12

LINQ — nie tylko kolekcje

Biblioteka przyjmuje różne nazwy, ale najczęstsze skróty to Rx i LINQ dla Rx — i takich też będę używać dalej. Nie ogranicza się ona jedynie do reaktywności, ale my skupimy się właśnie na tym, a w szczególności na interesującym module o nazwie System. ´Interactive, zawierającym różnorodne dodatkowe metody LINQ dla Obiektów. Operacje wpychające są implementowane w ramach przestrzeni nazw System.Reactive. Nawet w przypadku modelu wpychającego liźniemy zaledwie powierzchnię. Wiem, że dotyczy to wszystkiego, o czym mówiliśmy w tym rozdziale, ale ta sekcja jest pod tym względem szczególna. Nie chodzi jedynie o sporą wiedzę, jaką trzeba nabyć odnośnie do samej biblioteki, ale również o zupełnie nowy sposób myślenia. Sporo filmów na ten temat można obejrzeć na Kanale 9 (zobacz http://mng.bz/QoXE) — niektóre omawiają aspekty matematyczne, podczas gdy inne są bardziej praktyczne. W tej sekcji będę podkreślał koncepcje LINQ, które mogą być zastosowane w modelu wpychającym dla przepływu danych. Wystarczy wprowadzenia. Zapoznajmy się z dwoma interfejsami tworzącymi trzon LINQ dla Rx.

12.5.1.IObservable i IObserver Model danych LINQ dla Rx jest matematyczną dwoistością zwykłego modelu IEnume ´rable11. Kiedy iterujesz po kolekcji w modelu wyciągającym, zaczynasz od powiedzenia: „Daj mi, proszę, iterator” (wywołanie GetEnumerator), a następnie powtarzasz: „Czy jest kolejny element? Jeśli tak, chciałbym go teraz dostać” (przez wywołania Move ´Next i Current). LINQ dla Rx odwraca ten proces. Zamiast pobierać iterator, dostarczasz obserwator. Później zamiast pobierać kolejny element, Twój kod jest informowany, kiedy taki element jest gotowy, a także kiedy nastąpi błąd lub zostanie osiągnięty koniec danych. Poniżej znajdują się deklaracje dwóch interfejsów biorących udział w tym procesie: public interface IObservable { IDisposable Subscribe (IObserver observer); } public { void void void }

interface IObserver OnNext (T value); OnCompleted(); OnException(Exception error);

Mimo że pozostała część LINQ dla Rx stanowi niezależny moduł do ściągnięcia, te interfejsy są częścią .NET 4 (w przestrzeni nazw System). Ściślej rzecz biorąc, w .NET 4 są to typy IObservable i IObserver, wyrażające kowariancję IObservable i kontrawariancję IObserver. Więcej o wariancji generycznej dowiemy się w następnym rozdziale, natomiast tutaj dla ułatwienia przedstawiam oba interfejsy tak, jakby

11

Pragnącym dogłębniej zapoznać się z tą dwoistością i esencją samego LINQ polecam post Barta de Smeta na blogu MinLinq (http://mng.bz/96Wh).

Odwrócenie modelu zapytania przy użyciu LINQ dla Rx

415

nie podlegały wariancji — jedna koncepcja w danej chwili! Rysunek 12.8 przedstawia dwoistość pod względem przepływu danych w obu modelach.

Rysunek 12.8. Diagram sekwencji pokazujący dwoistość IEnumerable i IObservable

Przypuszczam, że nie jestem jedynym, który uważa model wpychający za trudniejszy w zrozumieniu, a to ze względu na jego naturalną zdolność do pracy asynchronicznej. Zauważ jednak, o ile jest on prostszy w porównaniu do modelu wyciągającego z punktu widzenia diagramu przepływu. Jest tak częściowo ze względu na podejście z wieloma metodami w modelu wyciągającym. Sprawa wyglądałaby trochę prościej, gdyby IEnumerable posiadał metodę o sygnaturze bool TryGetNext(out T item). Wcześniej wspomniałem, że LINQ dla Rx jest podobny do mechanizmu zdarzeń, z którym zdążyliśmy się już zaznajomić. Wywołanie Subscribe na typie obserwowanym jest podobne do użycia += dla zdarzenia, do którego chcemy dołożyć metodę obsługi. Referencja IDisposable zwracana przez Subscribe zapamiętuje przekazany do środka obserwator. Jego zwolnienie jest podobne do użycia -= na tej samej metodzie obsługi. W wielu przypadkach nie musisz nawet wypisywać się z obiektu obserwowanego. Możliwość taka istnieje wyłącznie po to, abyś mógł się wypisać gdzieś w środku przetwarzania sekwencji — na zasadzie podobnej do wcześniejszego przerwania pętli foreach. Brak zwolnienia wartości typu IDisposable może Ci się wydawać przekleństwem, ale w LINQ dla Rx takie podejście jest często bezpieczne. W tym rozdziale żaden z przykładów nie będzie używał wartości zwróconej przez Subscribe. To wszystko, jeśli chodzi o IObservable, ale co z samym obserwatorem? Dlaczego ma trzy metody? Rozważ zwykły model wyciągający, w którym dla każdej pary wywołań MoveNext/Current mogą się zdarzyć trzy rzeczy: Możemy być na końcu sekwencji — w takim przypadku MoveNext zwróci false. Możemy być przed końcem sekwencji — w takim przypadku MoveNext zwróci true, a Current nową wartość.

416

ROZDZIAŁ 12

LINQ — nie tylko kolekcje Może wystąpić błąd (np. może nam się nie udać odczytać kolejnego wiersza

z połączenia sieciowego). W takim przypadku zostałby rzucony wyjątek. Interfejs IObserver reprezentuje każdą z tych opcji w formie oddzielnej metody. Typowo obserwator będzie miał wywoływaną w kółko metodę OnNext, a na końcu zostanie wywołana metoda OnCompleted, chyba że wystąpi błąd, co spowoduje wywołanie OnError. Po zakończeniu sekwencji lub napotkaniu błędu dalsze wywołania metod nie będą kontynuowane. Trzeba jednak przyznać, że rzadko będziesz musiał implementować IObserver bezpośrednio. Istnieje wiele metod rozszerzających dla IObservable, włączając w to przeciążenia metody Subscribe. Umożliwiają one zasubskrybowanie obiektu obserwowanego poprzez odpowiednie delegaty: zazwyczaj Ty dostarczasz delegat do wykonania na każdym elemencie i opcjonalnie delegat do wykonania na zakończenie w przypadku błędu lub w obu przypadkach. Mając z głowy to krótkie wprowadzenie teoretyczne, możemy zobaczyć w końcu rzeczywisty kod LINQ dla Rx.

12.5.2.Zaczynamy (ponownie) łagodnie Zademonstruję LINQ dla Rx w taki sam sposób, jak zrobiłem to w przypadku LINQ dla Obiektów — używając przedziału. Zamiast Enumerable.Range będziemy używać metody Observable.Range, która tworzy obserwowany przedział. Za każdym razem, kiedy obserwator subskrybuje przedział, liczby tego przedziału są „emitowane” do tego obserwatora przy użyciu metody OnNext z wywołaniem OnCompleted na końcu. Zaczniemy w najprostszy możliwy sposób, wyświetlając każdą liczbę w miarę ich odbierania oraz komunikat potwierdzający koniec lub błąd. Poniższy listing (12.13) pokazuje, że całość zajmuje faktycznie mniej kodu, niż potrzebowałbyś w modelu wyciągającym. Listing 12.13. Pierwszy kontakt z IObservable var observable = Observable.Range(0, 10); observable.Subscribe(x => Console.WriteLine("Odebrano {0}", x), e => Console.WriteLine("Błąd: {0}", e), () => Console.WriteLine("Koniec"));

Umieściłem w kodzie delegat odpowiedzialny za zgłoszenie błędu, chociaż trudno sobie wyobrazić, jakim sposobem moglibyśmy dostać błąd w tej sytuacji. Wyniki wyglądają tak, jak można się było tego spodziewać: Odebrano 0 Odebrano 1 ... Odebrano 9 Koniec

Obserwowalny obiekt zwracany przez metodę Range jest znany jako zimny obiekt obserwowalny (ang. cold observable). Pozostaje on w uśpieniu do momentu, kiedy obserwator nie dokona jego subskrypcji. Dopiero w tym momencie nastąpi emisja wartości do tego indywidualnego obserwatora. Jeżeli zasubskrybujesz przy użyciu innego obserwatora, otrzymasz kolejną kopię przedziału liczb. To zachowanie nie jest podobne do zwykłego zdarzenia, takiego jak kliknięcie przycisku, kiedy to kilka obserwatorów może sub-

Odwrócenie modelu zapytania przy użyciu LINQ dla Rx

417

skrybować dokładnie tę samą sekwencję wartości, a same wartości mogą być wydawane niezależnie od tego, czy jakieś obserwatory są podpięte, czy też nie. (Było, nie było, możesz kliknąć przycisk, nawet jeśli nie ma do niego podpiętych żadnych metod obsługi zdarzeń). Tego typu sekwencje są określane mianem gorących obiektów obserwowalnych (ang. hot observable). Mimo że w obu przypadkach obowiązuje ten sam zestaw operacji, dobrze jest wiedzieć, z jakiego typu obiektem masz do czynienia. Zakończyliśmy najprostszą z możliwych operacji. Wypróbujmy teraz kilka ze znanych nam operatorów LINQ.

12.5.3.Odpytywanie obiektów obserwowalnych Jestem pewien, że do tej pory podchwyciłeś już wzór postępowania — w klasie statycznej (nazwanej, jak łatwo można przewidzieć, Observable) znajdują się różnorodne metody rozszerzające, które wykonują odpowiednie transformacje. Przyjrzymy się zaledwie kilku z dostępnych operatorów i zastanowimy się przez chwilę nad tym, co nie jest dostępne i dlaczego. Filtrowanie i projekcja Przejdźmy bezpośrednio do wyrażenia kwerendowego, które bierze sekwencję liczb, odfiltrowuje nieparzyste i podnosi do kwadratu wszystkie pozostałe. Na ostatecznym wyniku subskrybujemy Console.WriteLine, dzięki czemu wyprodukowane elementy zostaną wyświetlone na ekranie. Poniższy listing (12.14) przedstawia odpowiedni kod — zwróć uwagę, że wyrażenie kwerendowe równie łatwo mogłoby być zapytaniem LINQ dla Obiektów. Listing 12.14. Filtrowanie i projekcja w LINQ dla Rx var numbers = Observable.Range(0, 10); var query = from number in numbers where number % 2 == 0 select number * number; query.Subscribe(Console.WriteLine);

Dla uproszczenia nie dodałem obsługi zakończenia i błędów, natomiast konwersja grupy metod Console.WriteLine na Action sprawia, że kod jest ładny i krótki. Wynik działania jest taki sam, jaki wyprodukowałby LINQ dla Obiektów: 0, 4, 16 itd. Przejdźmy dalej — do grupowania. Grupowanie W LINQ dla Rx wyrażenie kwerendowe group by produkuje nowe wystąpienie IGrouped ´Observable dla każdej grupy — chociaż to, co następnie zrobisz z takim grupowaniem, nie zawsze jest oczywiste. Na przykład często jest tworzona zagnieżdżona subskrypcja, dzięki czemu po każdym utworzeniu nowej grupy możesz zasubskrybować w niej obserwator. Wyniki wewnątrz każdej grupy są produkowane w miarę otrzymywania ich przez konstrukcję grupującą — w efekcie działanie przypomina wybór z przekierowaniem, jak w przypadku bileterki w teatrze, która sprawdza bilet każdej przybywającej osoby i wysyła ją do odpowiedniej sekcji na sali. Dla kontrastu LINQ

418

ROZDZIAŁ 12

LINQ — nie tylko kolekcje

dla Obiektów zbiera całą grupę razem, zanim zwróci ją jako wynik — oznacza to, że musi przeczytać całą sekwencję do końca, buforując wszystkie wyniki. Przykład takiej zagnieżdżonej subskrypcji pokazuje listing 12.15, który demonstruje przy okazji, w jaki sposób są emitowane grupowe wyniki. Listing 12.15. Grupowanie liczb mod 3 var numbers = Observable.Range(0, 10); var query = from number in numbers group number by number % 3; query.Subscribe(group => group.Subscribe (x => Console.WriteLine("Wartość: {0}; Grupa: {1}", x, group.Key)));

Prawdopodobnie najlepszym sposobem zrozumienia tego kodu jest zapamiętanie, że w LINQ dla Obiektów operowanie na grupach często wymaga zastosowania zagnieżdżonej pętli foreach — w LINQ dla Rx odpowiednikiem jest zagnieżdżona subskrypcja. Kiedy najdą Cię wątpliwości, spróbuj poszukać dwoistości pomiędzy jednym i drugim modelem. W LINQ dla Obiektów przetworzylibyśmy zazwyczaj kolejno każdą następną grupę, podczas gdy porządek przyjęty w LINQ dla Rx oznacza, że wynik listingu 12.15 będzie wyglądał tak: Wartość: Wartość: Wartość: Wartość: Wartość: Wartość: Wartość: Wartość: Wartość: Wartość:

0; 1; 2; 3; 4; 5; 6; 7; 8; 9;

Grupa: Grupa: Grupa: Grupa: Grupa: Grupa: Grupa: Grupa: Grupa: Grupa:

0 1 2 0 1 2 0 1 2 0

Kiedy zastanowisz się nad modelem wpychającym, zrozumiesz, że takie podejście ma sens, a w niektórych przypadkach oznacza również, że operacje, które wymagałyby zbuforowania sporej ilości danych w LINQ dla Obiektów, mogą być zaimplementowane bardziej efektywnie w LINQ dla Rx. W ramach ostatniego przykładu przyjrzyjmy się innemu operatorowi, który używa kilku sekwencji. Spłaszczanie LINQ dla Rx dostarcza kilka przeciążeń metody SelectMany, ale idea działania jest wciąż taka sama jak w przypadku LINQ dla Obiektów — każdy element w oryginalnej sekwencji produkuje nową sekwencję. Wynikiem jest spłaszczona kombinacja wszystkich tych kolekcji. Przykład takiego działania pokazuje listing 12.16 — przypomina on trochę listing 11.16, w którym po raz pierwszy w LINQ dla Obiektów wprowadziliśmy metodę SelectMany. Listing 12.16. Produkcja wielu przedziałów przy użyciu SelectMany var query = from x in Observable.Range(1, 3) from y in Observable.Range(1, x) select new { x, y }; query.Subscribe(Console.WriteLine);

Odwrócenie modelu zapytania przy użyciu LINQ dla Rx

419

Oto wynik działania listingu — powinien być on w miarę przewidywalny: { { { { { {

x x x x x x

= = = = = =

1, 2, 2, 3, 3, 3,

y y y y y y

= = = = = =

1 1 2 1 2 3

} } } } } }

W tym przypadku wyniki są deterministyczne, ale dzieje się tak tylko dlatego, że Observable.Range emituje domyślnie elementy w bieżącym wątku. Całkiem możliwe jest posiadanie wielu sekwencji produkowanych przez wiele wątków. Dla zabawy możesz zmienić drugie wywołanie Observable.Range na przyjmujące jako trzeci argument referencję do Scheduler.ThreadPool. W takiej sytuacji każda wewnętrzna sekwencja wychodzi uporządkowana sama z siebie, ale wszystkie razem mogą być wymieszane między sobą. Wyobraź sobie stadion sportowy z jednym wystrzałem pistoletu oznajmiającym start kilku różnych biegów o szybkim tempie. Nawet jeśli poznasz zwycięzcę każdego biegu, nie będziesz wiedział, który z nich zakończy się jako pierwszy. Najmocniej przepraszam, jeśli powyższa lektura przyprawiła Cię o ból głowy. Jeżeli jest to jakimś pocieszeniem, mogę dodać, że sam doznaję podobnego uczucia, chociaż jednocześnie jestem zafascynowany całym mechanizmem. Co wchodzi, a co wychodzi? Wiemy, że klauzula let działa przez zwykłe wywołanie Select, więc nie będzie z nią problemu, ale nie wszystkie operatory LINQ dla Obiektów są zaimplementowane w LINQ dla Rx. Brakuje między innymi tych, które musiałyby zbuforować cały swój wynik i zwrócić nowy obiekt obserwowalny. Na przykład nie istnieją metody Reverse ani OrderBy. C# radzi sobie z tym doskonale — zwyczajnie nie pozwala Ci użyć klauzuli orderby w wyrażeniu kwerendowym bazującym na obiektach obserwowalnych. Istnieje co prawda metoda Join, ale nie zajmuje się ona bezpośrednio obiektami obserwowalnymi, lecz obsługuje plany złączeń. Jest to część implementacji rachunku złączeń Rx, wykraczająca znacznie poza zakres tej książki. Na podobnej zasadzie nie ma metody GroupJoin, zatem nie jest obsługiwana klauzula join ... into. Więcej na temat różnorodnych standardowych operatorów LINQ, które nie są obsługiwane przez składnię wyrażeń kwerendowych, znajdziesz w dokumentacji System. ´Reactive. Tam też pojawia się szereg dodatkowych metod oferowanych przez bibliotekę. Chociaż możesz być zawiedziony nieobecnością w LINQ dla Rx (głównie ze względu na brak logicznego sensu) znajomej funkcjonalności z LINQ dla Obiektów, pozytywnie zaskoczy Cię bogaty zakres dostępnych metod. Wiele nowych metod jest przenoszonych dla LINQ dla Obiektów w module System.Interactive.

12.5.4.Jaki to wszystko ma sens? Jestem w pełni świadomy, że nie podałem Ci do tej pory jeszcze żadnych przekonywających powodów do stosowania LINQ dla Rx. Zrobiłem to celowo, gdyż nie zamierzam prezentować pełnego, użytecznego przykładu — miałby on poboczne znaczenie, jeśli uwzględnimy cel tego rozdziału, i zająłby zbyt dużo miejsca. Rx pozwala programiście

420

ROZDZIAŁ 12

LINQ — nie tylko kolekcje

myśleć w spójny sposób o wszelkiego rodzaju procesach asynchronicznych — mogą to być dla przykładu zwykłe zdarzenia .NET (postrzegane jako obiekty obserwowalne przy użyciu Observable.FromEvent), asynchroniczne wejście/wyjście czy wywołania usług sieciowych. Daje możliwość zarządzania w efektywny sposób złożonością i konkurencyjnością. Technologia ta jest bez wątpienia trudniejsza do ogarnięcia niż LINQ dla Obiektów, ale jeśli wiesz, że mogłaby Ci się ona przydać, i tak masz już przed sobą ogrom komplikacji. LINQ dla Rx jest względnie młodym projektem. Jego pierwsza prezentacja miała miejsce na DevLabs w listopadzie 2009 roku. Jeżeli zainteresowało Cię to krótkie wprowadzenie, z całą pewnością powinieneś przyjrzeć mu się bliżej. Powodem, dla którego chciałem się zająć Rx w tej książce, pomimo braku możliwości zrobienia tego w sposób oddający sprawiedliwość tej technologii, jest ukazanie, dlaczego LINQ został zaprojektowany tak, a nie inaczej. Chociaż istnieją konwersje pomiędzy IEnumerable i IObservable, nie ma związku dziedziczenia — gdyby język wprowadził jakikolwiek wymóg stosowania modelu wyciągającego dla sekwencji w LINQ, wyrażenia kwerendowe nie byłyby w ogóle obsługiwane w Rx. Miałoby to nawet bardziej katastrofalne skutki niż ograniczenie metod rozszerzających jedynie do IEnumerable. Widzieliśmy również, że nie wszystkie operatory LINQ mają zastosowanie w Rx — właśnie dlatego tak istotne jest, aby język specyfikował translacje zapytań w kategoriach wzorców obsługiwanych w granicach rozsądku dla danego dostawcy. Mam nadzieję, że pomimo dużych różnic pomiędzy modelem wyciągającym i wpychającym wyczułeś jednoczące działanie siły LINQ (tam, gdzie to możliwe). Zapewne z ulgą dowiesz się, że ostatni temat jest o wiele prostszy — wracamy na rodzimy grunt LINQ dla Obiektów, ale tym razem będziemy pisać własne metody rozszerzające.

12.6. Rozszerzanie LINQ dla Obiektów Jedną z pozytywnie zaskakujących cech LINQ jest jego rozszerzalność. Oprócz tworzenia swoich własnych dostawców zapytań i modeli danych możesz również rozszerzać elementy istniejące. Z mojego doświadczenia wynika, że technika ta jest najbardziej użyteczna w przypadku LINQ dla Obiektów. Jeśli potrzebujesz określonego typu zapytania, które nie jest obsługiwane w sposób bezpośredni (lub jego wykonanie przy użyciu standardowych operatorów kwerendowych jest niezgrabne bądź nieefektywne), możesz napisać własne. Oczywiście napisanie metody generycznej ogólnego przeznaczenia może się okazać znacznie większym wyzwaniem niż rozwiązanie Twojego właściwego problemu, ale jeśli znajdziesz się w sytuacji, w której będziesz kilkakrotnie pisał ten sam kod, być może warto się zastanowić nad tym, czy nie lepiej byłoby dokonać refaktoryzacji przez wprowadzenie nowego operatora. Osobiście uwielbiam pisać operatory kwerendowe. Niesie to ze sobą interesujące wyzwania techniczne, ale rzadko zdarza się, aby potrzebna była duża ilość kodu — natomiast wynik potrafi być elegancki. W tej sekcji przyjrzymy się sposobom, które pozwolą Twoim operatorom na efektywne i przewidywalne zachowanie, a następnie przejdziemy do pełnego przykładu wyboru losowego elementu z sekwencji.

Rozszerzanie LINQ dla Obiektów

421

12.6.1.Wytyczne odnośnie do projektu i implementacji Większość z poniższych wskazówek wydaje się oczywista, stanowią one jednak użyteczną listę kontrolną dla osoby pragnącej napisać własny operator. Testy jednostkowe Napisanie dobrego zestawu testów jednostkowych dla operatora jest w miarę łatwą rzeczą, chociaż możesz być zaskoczony rezultatem osiąganym przez wielu programistów dla czegoś, co początkowo miało być prostym kodem. Nie zapominaj o przypadkach szczególnych, takich jak puste sekwencje czy niepoprawne argumenty. Projekt MoreLINQ zawiera pewne metody pomocnicze dla testów jednostkowych, których mógłbyś użyć, pisząc własne testy. Sprawdzanie argumentów Dobre metody sprawdzają swoje argumenty… ale w LINQ jest z tym pewien problem. Jak widzieliśmy, wiele operatorów zwraca kolejną sekwencję, a najlepszym sposobem implementacji takiej funkcjonalności są uproszczenia iteratora. Ty powinieneś jednak dokonać sprawdzenia argumentów, kiedy tylko zostanie wywołana metoda, zamiast czekać do momentu, gdy kod wywołujący zdecyduje się na iterację po wynikach. Jeżeli zamierzasz skorzystać z uproszczenia iteratora, podziel swoją metodę na dwie części: w metodzie publicznej sprawdź poprawność argumentów, a następnie wywołaj metodę prywatną do przeprowadzenia iteracji. Optymalizacja IEnumerable jest słaby pod względem obsługiwanych operacji, ale typ sekwencji, z jakim masz do czynienia w czasie wykonania, może być znacznie bogatszy w funkcjonalność. Dla przykładu operator Count() działa zawsze, ale jego złożoność algorytmiczna to na ogół O(n). Jeśli wywołasz go jednak na implementacji ICollection, będzie mógł użyć bezpośrednio właściwości Count, której złożoność to O(1). W .NET 4 taka optymalizacja została rozszerzona również na ICollection. Podobnie wydobycie specyficznego elementu po indeksie jest w ogólnym przypadku wolne, ale może być znacznie wydajniejsze, jeśli sekwencja implementuje IList. Jeśli Twój operator jest w stanie skorzystać z tych optymalizacji, możesz uzyskać różne czasy działania w zależności od typu czasu wykonania. Aby przetestować wolną ścieżkę w testach jednostkowych, możesz zawsze wywołać Select(x => x) na List, uzyskując w ten sposób sekwencję niebędącą listą. Przypadek, kiedy chcesz mieć kolekcję ICollection nieimplementującą IList, uzyskasz przez LinkedList.

Dokumentacja Ważne jest, aby dokumentować, co Twój kod będzie robił z danymi wejściowymi, a także jaka jest spodziewana wydajność operatora. Ma to szczególne znaczenie, jeśli Twoja metoda musi pracować z kilkoma sekwencjami. Która z nich będzie wyliczona jako pierwsza i do jakiego stopnia? Czy Twój kod strumieniuje dane, buforuje je, czy może

422

ROZDZIAŁ 12

LINQ — nie tylko kolekcje

łączy obie techniki? Czy używa odroczonego wykonania, czy też natychmiastowego? Czy którekolwiek parametry mogą być puste, a jeśli tak, czy mają przez to specjalne znaczenie? Pojedyncza iteracja tam, gdzie to możliwe IEnumerable pozwoli Ci na wielokrotne iterowanie po sobie — potencjalnie na tej

samej kolekcji możesz posiadać wiele aktywnych iteratorów jednocześnie. Stosowanie takiego podejścia nie jest dobrym pomysłem wewnątrz operatora. Tam, gdzie to możliwe, najlepiej przejść po sekwencji wejściowej wyłącznie jeden raz. Dzięki temu Twój kod będzie w stanie pracować nawet z sekwencjami niepowtarzalnymi, takimi jak wiersze czytane ze strumienia sieciowego. Jeśli musisz przeczytać sekwencję wielokrotnie (i nie chcesz buforować jej samodzielnie, tak jak robi to metoda Reverse), powinieneś zwrócić na to szczególną uwagę w dokumentacji. Pamiętaj o zwalnianiu iteratorów W większości przypadków do iteracji po swoim źródle danych możesz użyć wyrażenia foreach. Czasem użyteczne okazuje się potraktowanie pierwszego elementu w sposób

odmienny — wtedy najprostszy kod uzyskuje się dzięki iteratorowi. W takiej sytuacji nie zapomnij otoczyć iteratora blokiem using. Nie jesteśmy przyzwyczajeni do zwalniania iteratorów, ponieważ w normalnych warunkach robi to za nas pętla foreach, co czasami znacznie utrudnia znalezienie błędu. Porównania niestandardowe Wiele operatorów LINQ posiada przeciążenia, które pozwalają wyspecyfikować odpowiedni parametr typu IEqualityComparer lub IComparer. Jeżeli budujesz bibliotekę ogólnego przeznaczenia dla innych programistów (z którymi potencjalnie możesz nie mieć kontaktu), dodanie w niej przeciążeń tego typu może być wskazane. Z drugiej strony, jeśli jesteś jedynym użytkownikiem tej biblioteki lub będzie nim ktoś z Twojego zespołu, możesz zrobić to na zasadzie: „Zaimplementuję, kiedy będzie taka potrzeba”. Sama implementacja nie jest niczym trudnym — jak zwykle prostsze przeciążenie wywołuje przeciążenie bardziej złożone, przekazując mu jako porównanie Equality ´Comparer.Default lub Comparer.Default. Sporo się nagadałem, sprawdźmy teraz, czy ma to pokrycie w czynach.

12.6.2.Proste rozszerzenie — wybieranie losowego elementu Zasada działania naszej metody rozszerzającej jest prosta: mając sekwencję i instancję klasy Random, zwróć losowy element z tej sekwencji. Mógłbyś dołożyć przeciążenie, które nie wymaga instancji klasy Random, ale ja wolę, aby zależność od generatora losowego była jawna. Losowanie z różnych powodów jest zagadnieniem podchwytliwym. Nie będę omawiał tego tematu tutaj, ale w zamian za to umieściłem artykuł na stronie książki (http://mng.bz/h483). Ponadto, ze względu na ograniczone miejsce, listing 12.17 nie zawiera testów jednostkowych ani dokumentacji w formacie XML — są one dostępne w kodzie do pobrania.

Rozszerzanie LINQ dla Obiektów

423

Listing 12.17. Metoda rozszerzająca wybierająca losowy element z sekwencji public static T RandomElement(this IEnumerable source, Random random) { Walidacja argumentów if (source == null) { throw new ArgumentNullException("source"); } if (random == null) { throw new ArgumentNullException("random"); Optymalizacja } dla kolekcji ICollection collection = source as ICollection; if (collection != null) { int count = collection.Count; if (count == 0) { throw new InvalidOperationException("Sekwencja była pusta."); } Dalsza optymalizacja int index = random.Next(count); przez ElementAt return source.ElementAt(index); } using (IEnumerator iterator = source.GetEnumerator()) Obsługa { wolnego if (!iterator.MoveNext()) przypadku { throw new InvalidOperationException("Sekwencja była pusta."); } int countSoFar = 1; T current = iterator.Current; while (iterator.MoveNext()) Od czasu do czasu { zastąpienie countSoFar++; bieżącego elementu if (random.Next(countSoFar) == 0) { current = iterator.Current; } } return current; } }

Listing 12.17 nie używa uproszczenia iteratora, zatem nie pokazuje techniki rozdzielania metody rozszerzającej na walidację argumentów i implementację. Taki przykład znajdziesz w naszej implementacji operatora Where, w sekcji 10.3.3. Nie potrzebujemy również własnych implementacji porównań, ale poza tym zastosowanie ma każdy element z przytoczonej listy kontrolnej. W pierwszej kolejności sprawdzamy poprawność argumentów ( ). W rozdziale 15. poznamy alternatywny sposób wyrażania założeń wstępnych przy użyciu kontraktów kodu, ale teraz trzymam się tradycyjnych wyjątków. Bardziej interesujące rzeczy zaczynają się dziać w okolicy ( ) — obsługujemy przypadek, kiedy sekwencja źródłowa

424

ROZDZIAŁ 12

LINQ — nie tylko kolekcje

implementuje ICollection12. Dzięki temu zdobywamy liczbę elementów małym kosztem, a następnie generujemy pojedynczą liczbę losową, która pozwoli wybrać nam element. Nie implementujemy jawnie przypadku, kiedy sekwencja źródłowa implementuje IList — zamiast tego opieramy się na metodzie ElementAt, która (zgodnie z jej dokumentacją) robi to za nas. Jeżeli mamy do czynienia z sekwencją niebędącą kolekcją (jak ma to miejsce w przypadku wyniku innego operatora kwerendowego), chcemy uniknąć pobierania jej liczebności, a następnie wskazywania elementu — to wymagałoby od nas zbuforowania całej zawartości sekwencji lub przejścia po niej dwukrotnie. Zamiast tego przechodzimy po niej raz, pobierając jawnie iterator ( ), dzięki czemu w łatwy sposób możemy sprawdzić, czy kolekcja jest pusta. Zmyślny fragment kodu13 znajduje się w punkcie ( ) — zastępujemy nasz bieżący element losowy elementem wskazywanym przez iterator z prawdopodobieństwem 1/n, gdzie n jest liczbą elementów, jakie odwiedziliśmy do tej pory. Zatem istnieje prawdopodobieństwo 1/2 zastąpienia pierwszego elementu przez drugi, prawdopodobieństwo 1/3 zastąpienia wyniku po dwóch elementach elementem trzecim itd. W wyniku każdy element w sekwencji ma takie samo prawdopodobieństwo wybrania, a nam udało się przejść po kolekcji tylko jeden raz. Najważniejszą rzeczą nie jest działanie tej konkretnej metody, ale wszelkie potencjalne problemy, o których musieliśmy pomyśleć w czasie jej implementacji. Kiedy wiesz, czego szukać, zaimplementowanie naprawdę solidnej metody, takiej jak powyższa, nie wymaga dużego wysiłku, a poszerza Twój podręczny zestaw narzędzi.

12.7. Podsumowanie Ten rozdział był dokładnym przeciwieństwem pozostałej części książki. Zamiast skupiać się w dużym stopniu na pojedynczej funkcjonalności, omówiliśmy szereg technologii LINQ, ale na płytszym poziomie. Nie oczekuję od Ciebie głębszej znajomości którejkolwiek z przedstawionych tutaj cech, ale mam nadzieję, że lepiej teraz rozumiesz, jak ważną funkcjonalnością jest LINQ. Nie chodzi o XML, zapytania wewnątrz pamięci, SQL, typy obserwowalne czy enumeratory, ale o spójność wyrażeń i możliwość sprawdzania ich poprawności, przynajmniej do pewnego stopnia, przez kompilator C#, bez względu na platformę, na której zostaną ostatecznie wykonane. Powinieneś teraz rozumieć i docenić, dlaczego drzewa wyrażeń są tak ważne, że znajdują się wśród niewielu elementów środowiska (razem z na przykład łańcuchami, IDisposable, IEnumerable i INullable), na temat których kompilator C# posiada bezpośrednią i intymną wiedzę. Są one paszportami zachowania, pozwalającymi przekraczać granice lokalnej maszyny i wyrażać logikę w dowolnie wybranym języku obsługiwanym przez dostawcę LINQ. 12

Kod do pobrania zawiera taki sam test na obecność implementacji ICollection — jest to identyczny blok kodu, tyle że z innym typem i inną nazwą zmiennej.

13

Pozwalam sobie na stwierdzenie, iż jest on zmyślny, gdyż mimo że jest to moja implementacja, sam pomysł nie jest mój.

Podsumowanie

425

Nie chodzi wyłącznie o drzewa wyrażeń — bazowaliśmy również na stosowanym przez kompilator mechanizmie tłumaczenia drzew wyrażeń i sposobach konwertowania wyrażeń lambda na delegaty i drzewa wyrażeń. Równie ważne są metody rozszerzające. Bez nich każdy dostawca musiałby dostarczać własne implementacje odpowiednich metod. Jeśli spojrzysz z perspektywy na wszystkie nowe cechy C#, znajdziesz zaledwie kilka, które nie są w taki czy inny sposób silnie związane z LINQ. To po części powód, dla którego istnieje ten rozdział — chcę pokazać związek pomiędzy wszystkimi tymi cechami. Nie powinienem jednak przesadzać zbytnio z tymi pieśniami pochwalnymi — oprócz wszystkich jasnych stron LINQ widzieliśmy również pewne pułapki. LINQ nie zawsze pozwala nam wyrazić wszystko, co chcemy, w zapytaniu, a także nie ukrywa wszystkich detali źródła danych. Jeśli chodzi o dostawców LINQ przeznaczonych dla baz danych, pewne utrudnienia, które sprawiały programistom wiele problemów w przeszłości, są nadal z nami: możemy zredukować ich siłę, stosując systemy ORM i podobne, ale bez dobrego zrozumienia wykonywanego zapytania można łatwo popaść w poważne kłopoty. Podobnie jest w przypadku planowania funkcjonalnego zapytania równoległego. Musisz wiedzieć, kiedy jest lub nie jest istotne sortowanie, a także pomóc środowisku, dostarczając po drodze dodatkowych informacji pozwalających dostroić zachowanie. Od momentu pojawienia się .NET 3.5 jestem zachwycony gorącym przyjęciem tej wersji przez społeczność programistów. W tym przypadku miałem przywilej przyglądania się temu z perspektywy czasu. Nie mogę jednak powiedzieć, jak programiści przyjmą cechy C# 4, którym przyjrzymy się w ostatniej części książki.

426

ROZDZIAŁ 12

LINQ — nie tylko kolekcje

Część IV C# 4 — dobra współpraca z innymi interfejsami

C

# 4 jest ciekawą bestią. Pracując z nim, nie odnosimy wrażenia, że mamy do czynienia z kilkoma niemal niezwiązanymi ze sobą cechami, jak to było w przypadku C# 2, ani że robimy wszystko w imię LINQ, jak to jest w C# 3. Zamiast tego nowe cechy C# 4 lądują gdzieś mniej więcej pośrodku. Tematem przewodnim jest współpraca z innymi systemami, ale dostarczany jest również zestaw nowych użytecznych cech dla tych, którzy nie pracują w innych środowiskach. Moimi ulubionymi cechami C# 4 są parametry opcjonalne i argumenty nazwane. Są względnie proste, ale w wielu miejscach okazują się bardzo użyteczne, gdyż poprawiają czytelność kodu i ogólnie sprawiają, że życie staje się przyjemniejsze. Czy marnujesz czas, próbując odgadnąć znaczenie poszczególnych argumentów? Nadaj im jakieś nazwy. Jesteś zmęczony pisaniem w kółko przeciążeń tylko po to, aby uniknąć konieczności specyfikowania wszystkich argumentów w wywołaniu? Zmień niektóre parametry na opcjonalne. Jeżeli posługujesz się technologią COM, C# 4 tchnie w Ciebie powiew świeżości. Zacznijmy od cech, o których wspomniałem powyżej. Upraszczają one znacznie pracę z niektórymi interfejsami programistycznymi, w których projektanci danego komponentu założyli, że najprawdopodobniej będziesz korzystał z języka obsługującego parametry opcjonalne i argumenty nazwane. Oprócz tego zostały wprowadzone ulepszenia w dystrybucji oprogramowania, obsługa indekserów nazwanych oraz pomocny skrót pozwalający uniknąć przekazywania wszędzie argumentów przez referencję. Integrację z COM ułatwia również największa nowa cecha — typy dynamiczne. Wszystkim tym tematom, a także łamigłówce wariancji typów generycznych, zastosowanych do interfejsów i delegatów, przyjrzymy się w rozdziale 13. Bądź spokojny, przejdziemy przez wszystko w wolnym tempie i, co najważniejsze, w większości

przypadków nie będziesz musiał znać szczegółów… Nowe cechy sprawią jedynie, że kod będzie działał w miejscach, w których spodziewałeś się tego w C# 3! Rozdział 14. zajmuje się typami dynamicznymi i środowiskiem DLR (ang. Dynamic Language Runtime). Jest to bardzo rozległy temat. Ja skoncentrowałem się na tym, w jaki sposób język C# implementuje typy dynamiczne, ale przyjrzymy się również kilku przykładom współpracy z językami dynamicznymi, takimi jak IronPython, a także przedstawimy przykłady dynamicznej odpowiedzi typu na wywołania metod, dostęp do właściwości itp. Warto wspomnieć, że choć wyrażenia dynamiczne są jedną z głównych cech języka, to nie oznacza to wcale, iż od tej pory będziesz je napotykał w całym Twoim kodzie. Ta cecha nie dorównuje swoją popularnością na przykład LINQ — kiedy jednak zechcesz skorzystać z typów dynamicznych, przekonasz się, że mechanizm ten jest dobrze zaimplementowany w C# 4. Rozdział 15. poprowadzi nas w odrobinę innym kierunku. Kontrakty kodu nie zostały zaimplementowane jako cecha C# 4, ale mimo wszystko zmieniają możliwe podejście do sposobu pisania idiomatycznego kodu w tej wersji języka. Rdzenne typy używane przez kontrakty kodu są częścią .NET 4, ale same w sobie nie niosą żadnej funkcjonalności — stają się użyteczne dopiero dzięki wspierającym je narzędziom. Zastosowanie kontraktów do Twojego kodu — pod względem warunków wstępnych, końcowych, asercji i niezmienników — pozwoli Ci wyrazić elementy funkcjonalności, które wcześniej były jedynie domeną dokumentacji. Jak daleko posuniesz się w kontraktach kodu, zależy wyłącznie od Ciebie. Jest to jednak jedna z najbardziej ekscytujących i przekrojowych technologii w .NET 4.

Małe zmiany dla uproszczenia kodu

Ten rozdział omawia: ♦ parametry opcjonalne, ♦ argumenty nazwane, ♦ usprawnianie parametrów referencyjnych w COM, ♦ osadzanie głównych modułów związanych z obsługą COM, ♦ wywoływanie indekserów nazwanych zadeklarowanych w COM, ♦ wariancję typów generycznych dla interfejsów i delegatów, ♦ zmiany w blokowaniu i zdarzeniach w formie pól.

430

ROZDZIAŁ 13

Małe zmiany dla uproszczenia kodu

Tak jak w poprzednich wersjach języka, C# 4 posiada kilka małych cech niezasługujących na poświęcanie im oddzielnych rozdziałów. Szczerze mówiąc, jest tylko jedna duża cecha w C# 4 — typy dynamiczne. Zajmiemy się nią w następnym rozdziale. Zmiany, którym poświęcimy miejsce w tym rozdziale, sprawiają jedynie, że C# staje się odrobinę przyjemniejszy w pracy, szczególnie jeśli często korzystasz z COM. Te nowe cechy umożliwiają tworzenie bardziej przejrzystego kodu, zmniejszają uciążliwość wywołań COM-owych lub upraszczają dystrybucję oprogramowania. Czy którakolwiek z tych rzeczy ma szansę wzbudzić w tobie większe podekscytowanie? Mało prawdopodobne. Są to jedynie przyjazne cechy języka, z których niektóre mogą znaleźć szerokie zastosowanie. Zacznijmy od przyjrzenia się, w jaki sposób wywołujemy metody.

13.1. Parametry opcjonalne i argumenty nazwane To są cechy C# 4 w stylu Batmana i Robina1 — odrębne, ale zwykle występujące razem. Przez chwilę będę trzymał je oddzielnie, abyśmy mogli przeanalizować kolejno każdą z nich, ale później użyjemy ich razem w nieco bardziej interesujących przykładach. PARAMETRY I ARGUMENTY. Ta sekcja bez wątpienia mówi sporo o parametrach i argumentach. W codziennej konwersacji oba te określenia są często stosowane zamiennie, ale ja zamierzam używać ich zgodnie z ich formalnymi definicjami. Wyłącznie dla przypomnienia: parametr (znany również jako parametr formalny) jest zmienną będącą częścią deklaracji metody lub indeksera. Argument jest wyrażeniem używanym podczas wywołania metody lub indeksera. Rozważ dla przykładu następujący fragment kodu: void Foo(int x, int y) { //Wykonaj jakieś operacje na x i y } ... int a = 10; Foo(a, 20);

Tutaj parametrami są x i y, natomiast argumentami a i 20. Zaczniemy od przyjrzenia się parametrom opcjonalnym.

13.1.1.Parametry opcjonalne Visual Basic dysponuje parametrami opcjonalnymi od wieków, natomiast w CLR są one dostępne od .NET 1.0. Koncepcja jest równie prosta jak jej nazwa: niektóre parametry są opcjonalne, zatem ich wartości nie muszą być specyfikowane w sposób jawny przez kod wywołujący. Każdy parametr, który nie został wyspecyfikowany przez kod wywołujący w formie argumentu, otrzymuje wartość domyślną.

1

Lub, jeśli jesteś bardziej wysublimowany, w stylu Rycerskości wieśniaczej i Pajaców.

Parametry opcjonalne i argumenty nazwane

431

Motywacja Parametry opcjonalne są używane zwykle, kiedy dana operacja wymaga kilku wartości, i zazwyczaj są to za każdym razem te same wartości. Załóżmy, że chcesz przeczytać plik tekstowy. Do tego celu chcesz stworzyć metodę, która pozwoli wywołującemu ją kodowi wyspecyfikować nazwę pliku i kodowanie znaków. Jednak kodowanie to niemal zawsze UTF-8, zatem byłoby miło, gdyby dało się użyć tej wartości automatycznie, jeśli tylko tego potrzebujesz. Z historycznego punktu widzenia idiomatycznym sposobem pozwalającym na takie zachowanie w C# było użycie przeciążania metod. Należało zadeklarować jedną metodę z wszystkimi możliwymi parametrami, a następnie inne, które wywoływałyby tę metodę, przekazując odpowiednie wartości domyślne. Mógłbyś na przykład stworzyć następujące metody: public IList LoadCustomers(string filename, Encoding encoding) { Wykonanie rzeczywistej pracy ... } public IList LoadCustomers(string filename) { Deklaracja metody return LoadCustomers(filename, Encoding.UTF8); z parametrami opcjonalnymi }

Takie podejście sprawdza się doskonale dla pojedynczego parametru, ale przy wielu opcjach zaczyna być podchwytliwe. Każda dodatkowa opcja podwaja liczbę możliwych przeciążeń, a jeśli dwie z nich mają taki sam typ, zaczynają się kłopoty wynikające z deklarowania kilku metod o tej samej sygnaturze. Często ten sam zestaw przeciążeń jest wymagany dla różnych typów parametrów. Na przykład XmlReader.Create() może stworzyć XmlReader z typu Stream, TextReader lub z łańcucha, ale oprócz tego dostarcza możliwość wyspecyfikowania ustawień typu XmlReaderSettings i innych argumentów. Ze względu na taką duplikację istnieje 12 przeciążeń metody Create. Całą sytuację można znacznie uprościć, stosując parametry opcjonalne. Zobaczmy, jak to się robi. Deklarowanie parametrów opcjonalnych i pomijanie ich podczas specyfikowania argumentów Przekształcenie parametru na opcjonalny jest tak proste jak dostarczenie mu wartości domyślnej. Do tego celu jest stosowana konstrukcja przypominająca inicjalizator zmiennej. Rysunek 13.1 przedstawia metodę z trzema parametrami: dwa z nich są opcjonalne, a jeden wymagany. Rysunek 13.1. Deklarowanie parametrów opcjonalnych

432

ROZDZIAŁ 13

Małe zmiany dla uproszczenia kodu

Jedyne, co robi metoda, to wyświetlenie argumentów. To jednak w zupełności wystarczy, aby prześledzić, co się dzieje. Poniższy listing (13.1) przedstawia pełny kod metody i jej trzykrotne wywołanie, za każdym razem z inną liczbą argumentów. Listing 13.1. Deklaracja i wywołanie metody z parametrami opcjonalnymi static void Dump(int x, int y = 20, int z = 30) Deklaracja metody z parametrami { opcjonalnymi Console.WriteLine("x={0} y={1} z={2}", x, y, z); } Wywołanie metody ... ze wszystkimi argumentami Dump(1, 2, 3); Pominięcie jednego argumentu Dump(1, 2); Pominięcie dwóch argumentów Dump(1);

Parametrami opcjonalnymi są te posiadające wartość domyślną ( ). Jeżeli kod wywołujący nie wyspecyfikuje y, jej wartością początkową będzie 20, podobnie z ma wartość domyślną 30. Pierwsze wywołanie ( ) specyfikuje jawnie wszystkie argumenty, pozostałe wywołania ( i ) omijają, odpowiednio, jeden i dwa argumenty, w związku z czym są używane wartości domyślne. Kiedy brakuje jednego argumentu, kompilator zakłada, iż ominięto ostatni parametr, następnie przedostatni itd. Wynik działania wygląda zatem następująco: x=1 y=2 z=3 x=1 y=2 z=30 x=1 y=20 z=30

Mimo że kompilator mógłby użyć pewnej zmyślnej analizy typów parametrów opcjonalnych i argumentów do wypracowania tego, co zostało pominięte, nie robi tego. Zakłada, że specyfikujesz argumenty w takiej samej kolejności, w jakiej występują parametry2. Oznacza to, że poniższy kod jest niepoprawny: static void TwoOptionalParameters(int x = 10, string y = "domyślny") { Console.WriteLine("x={0} y={1}", x, y); } ... Błąd! TwoOptionalParameters("drugi parametr");

Jest to próba wywołania metody TwoOptionalParameters z użyciem łańcucha jako pierwszego argumentu. Nie istnieje przeciążenie przyjmujące jako pierwszy parametr wartość konwertowalną z łańcucha, stąd kompilator zgłasza błąd. Jest to dobre zachowanie — rozwiązywanie przeciążeń jest wystarczająco podchwytliwym zadaniem (szczególnie kiedy w grę wchodzi wnioskowanie typów generycznych) bez analizowania wszystkich możliwych permutacji w celu znalezienia czegoś, co być może chcesz wywołać. Jeśli chcesz pominąć wartość jednego z parametrów opcjonalnych, ale wskazać kolejny, musisz użyć argumentów nazwanych.

2

Oczywiście, o ile nie używasz argumentów nazwanych, które poznamy wkrótce.

Parametry opcjonalne i argumenty nazwane

433

Ograniczenia parametrów opcjonalnych Istnieje kilka reguł opisujących parametry opcjonalne. Wszystkie parametry opcjonalne występują za parametrami obowiązkowymi. Wyjątek od tej reguły stanowią tablice parametrów (deklarowane przy użyciu modyfikatora params), które nadal muszą się pojawiać na końcu listy parametrów, ale mogą występować po parametrach opcjonalnych. Tablica parametrów nie może zostać wyspecyfikowana jako parametr opcjonalny — jeśli kod wywołujący nie wyspecyfikuje dla niej żadnych wartości, zostanie użyta pusta tablica. Parametry opcjonalne nie mogą również posiadać modyfikatorów ref i out. Parametr opcjonalny może mieć dowolny typ, ale istnieją pewne ograniczenia odnośnie do wartości domyślnych. Zawsze dozwolone jest użycie stałych: numerycznych, łańcuchowych, null, stałych (const) elementów typu, pól enumeracji oraz operatora default(T). Dodatkowo dla typów wartościowych możesz wywoływać konstruktory bezparametrowe, chociaż jest to równoznaczne z użyciem operatora default(...). Musi istnieć niejawna konwersja z wyspecyfikowanej wartości na typ parametru, ale nie może to być konwersja zdefiniowana przez użytkownika. Przykłady poprawnych list parametrów przedstawia tabela 13.1. Tabela 13.1. Poprawne listy parametrów metody, używające parametrów opcjonalnych Deklaracja

Uwagi

Foo(int x, int y = 10)

Literał numeryczny użyty jako wartość domyślna

Foo(decimal x = 10)

Niejawna wbudowana konwersja z int na decimal

Foo(string name = "default")

Literał łańcuchowy użyty jako wartość domyślna

Foo(DateTime dt = new DateTime())

Wartość zerowa typu DateTime

Foo(DateTime dt = default(DateTime))

Alternatywna składnia dla wartości zerowej

Foo(T value = default(T))

Operator wartości domyślnej współpracuje z parametrami typu

Foo(int? x = null)

Konwersja nullowalna

Foo(int x, int y = 10, params int[] z)

Tablica parametrów po parametrach opcjonalnych

Dla kontrastu tabela 13.2 pokazuje przykłady niepoprawnych list parametrów z wyjaśnieniem, dlaczego są niedozwolone. Tabela 13.2. Niepoprawne listy parametrów metody, używające parametrów opcjonalnych Deklaracja (niepoprawna)

Uwagi

Foo(int x = 0, int y)

Parametr wymagany (inny niż tablica parametrów) nie może wystąpić po parametrze opcjonalnym

Foo(DateTime dt = DateTime.Now)

Wartości domyślne muszą być stałymi

Foo(XName name = "default")

Konwersja z łańcucha na XName jest konwersją zdefiniowaną przez użytkownika

Foo(params string[] names = null)

Tablice parametrów nie mogą być opcjonalne

Foo(ref string name = "default")

Parametry ref/out nie mogą być opcjonalne

434

ROZDZIAŁ 13

Małe zmiany dla uproszczenia kodu

Wymóg stałości wartości domyślnej ma swoje dwa mankamenty. Jeden z nich znamy już z odrobinę innej sytuacji, o czym przekonamy się teraz. Parametry opcjonalne i wersjonowanie Restrykcje dotyczące wartości domyślnych dla parametrów opcjonalnych mogą przypominać Ci ograniczenia na polach const lub wartościach atrybutów. Ich zachowanie jest podobne. W obu przypadkach, kiedy kompilator odwołując się do wartości, kopiuje ją bezpośrednio na wyjście, wygenerowany kod IL zachowuje się dokładnie tak, jakby Twój oryginalny kod źródłowy zawierał wartość domyślną. Oznacza to, że jeśli kiedykolwiek zmienisz wartość domyślną bez rekompilacji wszystkich miejsc odwołujących się do niej, stary kod wywołujący będzie nadal używał starej wartości domyślnej. Dla skonkretyzowania wyobraź sobie następujące kroki: 1. Stwórz bibliotekę (Library.dll) z następującą klasą w środku: public class LibraryDemo { public static void PrintValue(int value = 10) { System.Console.WriteLine(value); } }

2. Stwórz aplikację konsolową (Application.exe), która odwołuje się do powyższej biblioteki: public class Program { static void Main() { LibraryDemo.PrintValue(); } }

3. Uruchom aplikację; można z łatwością przewidzieć, że zostanie wyświetlona dziesiątka. 4. Zmień deklarację PrintValue, a następnie skompiluj ponownie wyłącznie bibliotekę: public static void PrintValue(int value = 20)

5. Uruchom aplikację ponownie — nadal będzie wyświetlać 10. Taka wartość została wkompilowana bezpośrednio w plik wykonywalny. 6. Skompiluj ponownie aplikację i uruchom ją — tym razem wyświetli 20. Ponieważ cały kod wygląda dobrze, ten problem z wersjonowaniem może spowodować trudne do wyśledzenia błędy. Zasadniczo jesteś ograniczony do używania faktycznych stałych, które nie powinny nigdy ulec zmianie jako wartości domyślne dla parametrów opcjonalnych3. Z takiego podejścia płynie jedna korzyść: kod wywołujący 3

Lub zaakceptować fakt, że po każdej zmianie takiej wartości musisz przekompilować wszystko. W wielu przypadkach jest to koszt, na który można się zgodzić.

Parametry opcjonalne i argumenty nazwane

435

otrzymuje gwarancję, że wartość, którą poznał na etapie kompilacji, jest tą, która będzie użyta. Takie rozwiązanie może dać programistom poczucie większego komfortu niż wartość wyliczana dynamicznie lub zależna od wersji biblioteki użytej w czasie wykonania. Oczywiście oznacza to również, że nie możesz użyć żadnych wartości, które nie mogą być wyrażone w formie stałych — dla przykładu nie możesz utworzyć metody z wartością domyślną „bieżącej daty”. Uelastycznienie wartości domyślnych przez nullowalność Na szczęście istnieje obejście tego problemu. To, co powinieneś zrobić, to wprowadzić wartość magiczną, reprezentującą wartość domyślną, a następnie zastąpić tę wartość magiczną rzeczywistą wartością domyślną wewnątrz samej metody. Nie jest dla mnie zaskoczeniem, jeśli niepokoi Cię stwierdzenie wartość magiczna — zaznaczam jednak, że jako wartości magicznej zamierzamy użyć null — odpowiednika braku zwykłej wartości. Jeżeli typ parametru będzie typem wartościowym, przekształcimy go na odpowiedni nullowalny typ wartościowy i w tym momencie będziemy mogli wyspecyfikować null jako wartość domyślną. W ramach przykładu przyjrzyjmy się sytuacji podobnej do tej, z jaką zetknęliśmy się we wprowadzeniu do całego zagadnienia — mowa o umożliwieniu dostarczenia metodzie przez kod wywołujący odpowiedniego kodowania, ale z wartością domyślną UTF-8. Nie możemy wyspecyfikować domyślnego kodowania jako Encoding.UTF8, ponieważ nie jest to wartość stała, ale możemy potraktować pustą wartość parametru jako stwierdzenie „użyj wartości domyślnej”. Aby zademonstrować, w jaki sposób możemy obsłużyć typy wartości, każemy metodzie dopisywać znacznik czasowy do pliku tekstowego z wiadomością. Domyślnie będziemy stosować kodowanie UTF-8 i znacznik czasowy odpowiadający aktualnej dacie. Kompletny kod metody oraz kilka przykładów jej użycia przedstawia listing 13.2. Listing 13.2. Użycie nullowych wartości domyślnych do obsłużenia sytuacji, kiedy nie można zastosować stałych static void AppendTimestamp(string filename, string message, Encoding encoding = null, Dwa parametry DateTime? timestamp = null) opcjonalne { Encoding realEncoding = encoding ?? Encoding.UTF8; Dla wygody użycie DateTime realTimestamp = timestamp ?? DateTime.Now; nullowego operatora koalescencyjnego using (TextWriter writer = new StreamWriter (filename, true, realEncoding)) { writer.WriteLine("{0:s}: {1}", realTimestamp, message); } } ... AppendTimestamp("utf8.txt", "Pierwsza wiadomość"); AppendTimestamp("ascii.txt", "ASCII", Encoding.ASCII); AppendTimestamp("utf8.txt", "Wiadomość z przyszłości", null, new DateTime(2030, 1, 1));

Jawne użycie null

436

ROZDZIAŁ 13

Małe zmiany dla uproszczenia kodu

Listing 13.2 pokazuje kilka przyjemnych cech powyższego podejścia. Zaczęliśmy od rozwiązania problemu wersjonowania. Domyślnymi wartościami parametrów opcjonalnych są wartości puste (null) ( ),ale wartościami faktycznymi są „kodowanie UTF-8” i „bieżące data i czas”. Żadna z nich nie mogłaby być wyrażona w formie stałej, a jeśli kiedykolwiek przyszłoby nam do głowy zmienić rzeczywistą wartość domyślną — na przykład użyć bieżącego czasu UTC zamiast czasu lokalnego — moglibyśmy to zrobić bez konieczności ponownej kompilacji całego kodu, który wywołuje AppendTimestamp. Oczywiście zmiana faktycznej wartości domyślnej wpływa na zachowanie metody — musisz podjąć takie same środki ostrożności jak przy każdej innej zmianie w kodzie. W tym momencie Ty, jako autor biblioteki, stajesz się odpowiedzialny za wersjonowanie — w praktyce oznacza to, że bierzesz odpowiedzialność za prawidłowe działanie klientów, chociaż jest to odrobinę bardziej znany teren, gdyż wiesz, że wszystkie klienty będą doświadczać tego samego bez związku z rekompilacją. Wprowadziliśmy ponadto dodatkowy stopień elastyczności. Dzięki parametrom opcjonalnym możemy nie tylko skrócić wywołania, ale również — ze względu na to, że posiadamy specyficzną wartość „użyj domyślnej” — jeśli tylko przyjdzie nam na to ochota, możemy dokonać jawnego wywołania metody, pozwalającego jej na wybór odpowiedniej wartości. Chwilowo jest to jedyny sposób, jaki znamy, pozwalający na jawne wskazanie znacznika czasu bez jednoczesnego wskazywania kodowania ( ), ale tylko do momentu, kiedy przyjrzymy się argumentom nazwanym. Obsługa wartości parametrów opcjonalnych jest prosta dzięki nullowemu operatorowi koalescencyjnemu ( ). Ze względu na ograniczenia strony drukowanej użyłem wyodrębnionych zmiennych, ale w rzeczywistym kodzie równie dobrze można by użyć tych samych wyrażeń bezpośrednio w wywołaniach konstruktora StreamWriter i metody WriteLine. Podejście to ma dwa minusy. Pierwszy: jeśli kod wywołujący przypadkowo przekaże null ze względu na błąd w kodzie, otrzyma wartość domyślną zamiast wyjątku. Nie stanowi to zbytniego problemu w sytuacjach, kiedy używasz nullowalnego typu wartościowego, a kod wywołujący stosuje jawnie null lub argument nienullowalny, ale dla typów referencyjnych może być to wyzwanie. Drugi: mechanizm wymaga rezygnacji ze stosowania null jako wartości „rzeczywistej”4. Istnieją sytuacje, w których chcesz, aby null znaczyło null. W takiej sytuacji, jeśli nie chcesz używać jej jako wartości domyślnej, musisz znaleźć inną stałą lub zgodzić się na obowiązkowość parametru. Problem w tym, że nie istnieje inna oczywista stała wartość, która w jasny sposób będzie zawsze wskazywać odpowiednią wartość domyślną. Poleciłbym takie podejście do parametrów opcjonalnych, gdyż ułatwia zachowanie spójności i usuwa niektóre z powszechnych trudności. Będziemy musieli przyjrzeć się, w jaki sposób parametry opcjonalne wpływają na rozwiązywanie przeciążeń, ale lepiej zaczekać z tym do momentu, kiedy poznamy sposób działania argumentów nazwanych. Skoro o nich mowa…

4

Niemal widać potrzebę istnienia drugiej (podobnej do null) wartości znaczącej: „Proszę użyć domyślnej wartości dla tego parametru”, która mogłaby być dostarczana automatycznie dla brakujących argumentów lub jawnie w liście argumentów. Jestem pewien, że spowodowałoby to ogrom problemów, ale stanowi dobry eksperyment myślowy.

Parametry opcjonalne i argumenty nazwane

437

13.1.2.Argumenty nazwane Podstawowa idea argumentów nazwanych polega na możliwości określenia nazwy parametru podczas specyfikowania przeznaczonej dla niego wartości argumentu. Kompilator upewnia się, że istnieje parametr o wskazanej nazwie, i używa wartości właśnie dla niego. Już sam ten mechanizm pozwala na podniesienie czytelności w pewnych sytuacjach. W praktyce argumenty nazwane są najbardziej użyteczne, kiedy mogą się pojawić również parametry opcjonalne. Zaczniemy jednak od sytuacji najprostszej. INDEKSERY, PARAMETRY OPCJONALNE I ARGUMENTY NAZWANE. Parametrów opcjonalnych oraz argumentów nazwanych możesz używać zarówno z metodami, jak i indekserami. Jest to jednak użyteczne jedynie dla indekserów o więcej niż jednym parametrze (tak czy inaczej, nie możesz się odwołać do indeksera bez wyspecyfikowania przynajmniej jednego argumentu). Biorąc pod uwagę to ograniczenie, zakładam, że nie będziesz często używał tej cechy w połączeniu z indekserami, i w związku z tym nie demonstruję jej w książce. Dodam jedynie, że zachowanie jest zgodne z tym, czego możesz oczekiwać. Jestem pewien, że widziałeś już kiedyś kod, który wygląda mniej więcej tak: MessageBox.Show("Proszę, nie klikaj ponownie tego przycisku", //tekst "Ała!"); //tytuł

Wybrałem w miarę prosty przykład. Przy wielu argumentach może być znacznie gorzej, zwłaszcza jeśli wiele z nich jest tego samego typu. Niemniej jest on nadal realistyczny: nawet przy dwóch argumentach musiałbym zgadywać znaczenie każdego z nich w oparciu o tekst zawarty w kodzie, chyba że znalazłyby się tam komentarze, takie jak dodałem powyżej. Jest jednak pewien problem: komentarze mogą kłamać na temat kodu, który przyszło im opisywać. Nie ma żadnego mechanizmu nadzorującego ich poprawność. Argumenty nazwane proszą pod tym względem o pomoc kompilator. Składnia Wszystko, co musimy zrobić z poprzednim przykładem, to poprzedzić każdy argument nazwą odpowiadającego mu parametru i dwukropkiem na końcu: MessageBox.Show(text: "Proszę, nie klikaj ponownie tego przycisku", caption: "Ała!");

Nie mamy wpływu na nazwę, która wydaje się najbardziej znacząca — osobiście wolę tytuł (title) zamiast podpisu (caption) — ale przynajmniej będziemy wiedzieć, jeśli zapisaliśmy coś niepoprawnie. Oczywiście najczęstszym przypadkiem pomieszania argumentów jest ich zupełne odwrócenie. Bez argumentów nazwanych byłby to problem, wylądowalibyśmy z tekstami odwróconymi w okienku dialogowym. Przy argumentach nazwanych kolejność staje się nieistotna. Poprzedni kod możemy przepisać w następujący sposób: MessageBox.Show(caption: "Ała!", text: "Proszę, nie klikaj ponownie tego przycisku");

Nadal otrzymalibyśmy właściwy tekst we właściwym miejscu, ponieważ kompilator wypracowałby to, co mieliśmy na myśli, poprzez nazwy argumentów. W ramach kolejnego

438

ROZDZIAŁ 13

Małe zmiany dla uproszczenia kodu

przykładu przyjrzyj się wywołaniu konstruktora StreamWriter, użytego przez nas na listingu 13.2. Drugi argument ma wartość true. Co on oznacza? Czy chodzi o wymuszenie wypuszczenia całego strumienia po każdej operacji zapisu? Dołączenie znacznika bajtowego? Dopisywanie do istniejącego pliku zamiast tworzenia nowego? Oto odpowiednik tego wywołania używający argumentów nazwanych: new StreamWriter(path: filename, append: true, encoding: realEncoding)

W obu tych przykładach widzieliśmy, w jaki sposób argumenty nazwane nadają wartościom znaczenie semantyczne. Jest to zdecydowany krok naprzód w niekończącej się walce o to, aby uczynić nasz kod bardziej zrozumiałym zarówno dla ludzi, jak i dla komputerów. Oczywiście nie sugeruję, że argumenty nazwane powinny być stosowane, kiedy znaczenie argumentów jest oczywiste. Tak jak w przypadku wszystkich cech, powinna być ona stosowana rozważnie i w sposób przemyślany. ARGUMENTY NAZWANE Z out I ref. Jeśli chcesz wyspecyfikować nazwę argumentu dla parametru ref lub out, umieść modyfikator ref lub out za nazwą, a przed samym argumentem. Biorąc za przykład int.TryParse, mógłbyś zapisać wywołanie następująco: int number; bool success = int.TryParse("10", result: out number);

W celu poznania dalszych aspektów składni posłużymy się poniższym listingiem (13.3), zawierającym metodę z trzema parametrami typu całkowitego, podobną do tej, której użyliśmy na początku sekcji poświęconej parametrom opcjonalnym. Listing 13.3. Proste przykłady użycia argumentów nazwanych static void Dump(int x, int y, int z) { Console.WriteLine("x={0} y={1} z={2}", x, y, z); } ... Dump(1, Dump(x: Dump(z: Dump(1, Dump(1,

2, 1, 3, y: z:

3); y: 2, y: 2, 2, z: 3, y:

Zwykłe wywołanie metody

z: 3); x: 1); 3); 2);

Zwykła deklaracja metody

Wyspecyfikowanie nazw wszystkich argumentów

Wyspecyfikowanie nazw niektórych argumentów

Każde wywołanie na listingu 13.3 produkuje taki sam wynik: x=1 y=2 z=3. Dokonaliśmy wywołania tej samej metody na pięć różnych sposobów. Warto zwrócić uwagę, że deklaracja metody nie zawiera żadnych trików ( ): argumenty nazwane mogą być stosowane dla każdej metody posiadającej parametry. Na początku wywołujemy metodę normalnie, bez stosowania jakichkolwiek nowych cech ( ). Jest to pewnego rodzaju próbka kontrolna, pozwalająca udowodnić, że pozostałe wywołania są jej rzeczywistymi odpowiednikami. Następnie wykonujemy dwa wywołania, używając wyłącznie argumentów nazwanych ( ). Drugie z tych wywołań odwraca kolejność argumentów, ale wynik jest nadal taki sam, ponieważ argumenty są dopasowane do parametrów po

Parametry opcjonalne i argumenty nazwane

439

nazwach, a nie według pozycji. W końcu pojawiają się dwa wywołania używające mieszanki argumentów nazwanych i argumentów pozycyjnych ( ). Argument pozycyjny to taki, który nie posiada nazwy — zatem każdy argument w poprawnym kodzie C# 3 jest z punktu widzenia C# 4 argumentem pozycyjnym. Rysunek 13.2 pokazuje sposób działania ostatniego wiersza kodu. Rysunek 13.2. Argumenty pozycyjne i nazwane w tym samym wywołaniu funkcji

Wszystkie argumenty nazwane muszą się pojawić po argumentach pozycyjnych — nie ma możliwości przełączania się pomiędzy jednym i drugim stylem. Argumenty pozycyjne odnoszą się zawsze do odpowiadających im parametrów w deklaracji metody — nie możesz pominąć argumentu pozycyjnego przez wskazanie go później za pomocą argumentu nazwanego. Oznacza to, że oba poniższe wywołania byłyby niepoprawne: Dump(z: 3, 1, y: 2) — argumenty pozycyjne muszą się pojawić przed argumentami nazwanymi. Dump(2, x: 1, z: 3) — x został już wyspecyfikowany przez pierwszy argument pozycyjny, zatem nie możemy wyspecyfikować go ponownie, stosując argument nazwany. Chociaż w tym szczególnym przypadku wywołania metod były tożsame, taka sytuacja nie zawsze ma miejsce. Przyjrzyjmy się, dlaczego zmiana kolejności argumentów może doprowadzić do zmiany zachowania. Kolejność ewaluacji argumentów W C# jesteśmy przyzwyczajeni do ewaluacji argumentów w kolejności, w jakiej zostały one wyspecyfikowane — co do C# 4 było również zgodne z porządkiem deklaracji parametrów. W C# 4 jedynie pierwsza część tego stwierdzenia jest nadal prawdziwa: argumenty są nadal ewaluowane w kolejności, w jakiej zostały zapisane, nawet jeśli nie jest to ten sam porządek, w jakim zostały one zadeklarowane jako parametry. Ma to znaczenie, jeśli wyliczanie argumentów niesie ze sobą efekty uboczne. Zazwyczaj opłaca się unikać wystąpienia efektów ubocznych w argumentach, chociaż są przypadki, kiedy ich obecność pozwala na stworzenie bardziej przejrzystego kodu. Bardziej realistyczną zasadą jest unikanie efektów ubocznych, kiedy mogą mieć one wzajemny wpływ na siebie. Na potrzeby demonstracji kolejności wykonania złamiemy obie powyższe zasady. Proszę jednak, abyś nie traktował tego postępowania jako rekomendacji w podobnych sytuacjach. Na początek stworzymy zupełnie niegroźny przykład w postaci metody, która wypisuje, a następnie zwraca swoje dane wejściowe — pewnego rodzaju „logujące echo”.

440

ROZDZIAŁ 13

Małe zmiany dla uproszczenia kodu

Wartości, które zostaną zwrócone przez trzy kolejne wywołania, użyjemy do wywołania metody Dump (która nie jest pokazana w kodzie i nie uległa zmianie od poprzedniego wystąpienia w książce). Dwa wywołania metody Dump, które dają odrobinę inne wyniki, pokazuje listing 13.4. Listing 13.4. Logowanie ewaluacji argumentów static int Log(int value) { Console.WriteLine("Log: {0}", value); return value; } ... Dump(x: Log(1), y: Log(2), z: Log(3)); Dump(z: Log(3), x: Log(1), y: Log(2));

Wynik działania listingu 13.4 ukazuje, co się dzieje: Log: 1 Log: 2 Log: 3 x=1 y=2 z=3 Log: 3 Log: 1 Log: 2 x=1 y=2 z=3

W obu przypadkach parametrami x, y i z metody Dump są 1, 2 i 3 — w takiej kolejności. Widzimy, że w takim porządku zostały one wyświetlone przez pierwsze wywołanie (będące odpowiednikiem zwykłego użycia argumentów pozycyjnych). Drugie wywołanie wyliczyło w pierwszej kolejności wartość parametru z. Możemy jeszcze bardziej uwydatnić to zjawisko przez efekty uboczne, które w wyniku ewaluacji argumentów zmieniają wartości końcowe. Do tego celu zastosujemy ponownie metodę Dump (listing 13 5). Listing 13.5. Nadużywanie kolejności ewaluacji argumentów int i = 0; Dump(x: ++i, y: ++i, z: ++i); i = 0; Dump(z: ++i, x: ++i, y: ++i);

Wynik działania listingu 13.5 można w najlepszym wypadku przyrównać do analizy śladów krwi na miejscu morderstwa po tym, kiedy to ktoś zajmujący się utrzymaniem kodu podobnego do wskazanego powyżej dopadł jego autora z nożem w ręku. Tak, z technicznego punktu widzenia ostatni wiersz listingu 13.5 wyświetla x=2 y=3 z=1, ale z pewnością wiesz, do czego zmierzam. Po prostu powiedz „nie” takiemu kodowi. Zmieniaj kolejność argumentów w celu poprawienia czytelności: można wyobrazić sobie na przykład, że wywołanie MessageBox.Show z tytułem pojawiającym się nad tekstem wiadomości lepiej odzwierciedla wygląd tego dialogu na ekranie. Jeśli jednak chcesz oprzeć się na konkretnym porządku wyliczania argumentów, wprowadź dodatkowe zmienne lokalne, aby wykonać odpowiednie wyrażenia oddzielnie. Kompilatorowi nie

Parametry opcjonalne i argumenty nazwane

441

zrobi to większej różnicy — będzie przestrzegał reguł zawartych w specyfikacji — natomiast zredukuje to ryzyko „niegroźnej refaktoryzacji”, wprowadzającej subtelny błąd do kodu. Aby powrócić do jaśniejszych sfer, połączmy obie cechy (parametry opcjonalne oraz argumenty nazwane) i zobaczmy, o ile bardziej zwięzły kod uda się nam uzyskać.

13.1.3.Złożenie dwóch cech w całość Obie cechy działają w tandemie bez dodatkowego wysiłku z Twojej strony. Często zdarza się sytuacja, w której grupa parametrów występuje z oczywistymi wartościami domyślnymi, ale jednocześnie pojawia się trudność w określeniu, które z nich kod wywołujący chce wyspecyfikować w sposób jawny. Przykład niemal dowolnej możliwej kombinacji parametru wymaganego, dwóch parametrów opcjonalnych, argumentu pozycyjnego i brakującego parametru opcjonalnego pokazuje rysunek 13.3. Rysunek 13.3. Wymieszanie argumentów nazwanych z parametrami opcjonalnymi

Wracając do naszego wcześniejszego przykładu, na listingu 13.2 chcieliśmy dołączyć konkretny znacznik czasowy do pliku, stosując domyślne kodowanie UTF-8. Wtedy dla kodowania użyliśmy argumentu null, ale teraz możemy zapisać ten sam kod prościej. Pokazuje to listing 13.6. Listing 13.6. Połączenie argumentów nazwanych i opcjonalnych static void AppendTimestamp(string filename, string message, Encoding encoding = null, DateTime? timestamp = null) { Taka sama implementacja jak poprzednio

} ... AppendTimestamp("utf8.txt", "Wiadomość z przyszłości", timestamp: new DateTime(2030, 1, 1));

Kodowanie zostało pominięte Nazwany argument znacznika czasowego

W tej w miarę prostej sytuacji zysk nie jest duży, ale tam, gdzie chcemy pominąć trzy lub cztery argumenty i wyspecyfikować ostatni, jest to prawdziwe błogosławieństwo. Widzieliśmy, w jaki sposób parametry opcjonalne redukują potrzebę tworzenia sporej listy przeciążeń, ale jest jeszcze jeden wzorzec, przy okazji którego warto o nich wspomnieć — chodzi o niezmienność.

442

ROZDZIAŁ 13

Małe zmiany dla uproszczenia kodu

Niezmienność i inicjalizacja obiektów Jedną z rzeczy, która odrobinę mnie rozczarowuje w C# 4, jest to, że nie zrobiono w nim nic, aby w sposób jawny ułatwić niezmienność. Typy niezmienne są podstawową częścią programowania funkcyjnego, a C# stopniowo wprowadza coraz więcej elementów wspierających ten model programowania… z wyjątkiem niezmienności. Inicjalizatory obiektów i kolekcji ułatwiają pracę z typami zmiennymi, ale typy niezmienne zostały porzucone. (Do tej kategorii zaliczają się również właściwości implementowane automatycznie). Na szczęście, chociaż nie zostały one zaprojektowane specjalnie do wspierania niezmienności, argumenty nazwane i parametry opcjonalne pozwalają Ci na napisanie inicjalizatorów obiektów, podobnie jak kod, który zwyczajnie wywołuje konstruktor lub inną funkcję wytwórczą. Dla przykładu załóżmy, że tworzymy klasę Message, która wymaga adresu od, adresu do, ciała wiadomości oraz opcjonalnego tematu i załączników. (Dla zachowania jak największej prostoty przykładów będziemy się trzymać pojedynczych odbiorców). Moglibyśmy stworzyć typ zmienny z odpowiednimi polami zapisywalnymi, a następnie zacząć konstruować instancję w następujący sposób: Message message = new Message { From = "[email protected]", To = "[email protected]", Body = "Mam nadzieję, że spodoba Wam się druga edycja", Subject = "Krótka wiadomość" };

Z takim podejściem wiążą się dwa problemy. Po pierwsze, nie wymusza podania obowiązkowych danych. Moglibyśmy wymusić ich obowiązkowość przy wywołaniu konstruktora, ale wtedy (przed C# 4) nie byłoby wiadomo, jakie znaczenie mają poszczególne argumenty: Message message = new Message( "[email protected]", "[email protected]", "Mam nadzieję, że spodoba Wam się druga edycja") { Subject = "Krótka wiadomość"; };

Drugim problemem jest to, że wzorzec inicjalizacyjny nie działa w połączeniu z typami niezmiennymi. Kompilator musi wywołać setter właściwości po zainicjalizowaniu obiektu. Stosując parametry opcjonalne i argumenty nazwane, możemy wypracować coś, co cechuje się przyjaznością pierwszej formy (specyfikowanie wyłącznie tego, co Cię interesuje, z jednoczesnym dostarczeniem nazw), bez tracenia walidacji obowiązkowych elementów wiadomości i zysku wynikającego z niezmienności. Poniższy listing (13.7) pokazuje możliwą sygnaturę konstruktora i sam krok konstrukcyjny dla takiej samej wiadomości jak powyżej. Listing 13.7. Konstruowanie niezmiennej wiadomości przy użyciu C# 4 public Message(string from, string to, string body, string subject = null, byte[] attachment = null)

Parametry opcjonalne i argumenty nazwane

443

{ Miejsce na zwykły kod inicjalizacyjny

} ... Message message = new Message( from: "[email protected]", to: "[email protected]", body: " Mam nadzieję, że spodoba Wam się druga edycja", subject: "Krótka wiadomość" );

Takie rozwiązanie bardzo mi się podoba pod względem czytelności i ogólnej przejrzystości. Nie musisz wybierać z całej masy konstruktorów przeciążonych, wystarczy jeden z niektórymi parametrami opcjonalnymi. Ta sama składnia, w przeciwieństwie do inicjalizatorów obiektów, będzie również działać w połączeniu ze statycznymi metodami wytwórczymi. Jedyny minus to faktyczne bazowanie na założeniu, iż Twój kod będzie „konsumowany” przez język obsługujący parametry opcjonalne i argumenty nazwane. W przeciwnym razie osoby wywołujące będą zmuszone do pisania brzydkiego kodu, specyfikującego wartości wszystkich parametrów opcjonalnych. Oczywiście niezmienność to coś więcej niż tylko dostarczenie wartości do kodu inicjalizującego, ale nie umniejsza to faktu, iż jest to mile widziany krok w dobrym kierunku. Zanim przejdziemy do COM, jest jeszcze kilka uwag odnośnie do cech przedstawionych powyżej. Rozwiązywanie przeciążeń Argumenty nazwane i parametry opcjonalne bez wątpienia wpływają na sposób rozwiązywania przeciążeń przez kompilator. Jeżeli istnieje wiele sygnatur metod o tej samej nazwie, która z nich powinna zostać wybrana? Parametry opcjonalne mogą zwiększyć liczbę metod możliwych do zastosowania (jeżeli niektóre metody mają więcej parametrów niż liczba wyspecyfikowanych argumentów), podczas gdy argumenty nazwane mogą zmniejszyć tę liczbę (przez wykluczenie metod, które nie posiadają odpowiednich nazw parametrów). Na ogół zmiany są intuicyjne: aby się przekonać, czy dana metoda może być zastosowana, kompilator próbuje zbudować listę argumentów, jaką przekazałby do środka, w porządku argumentów pozycyjnych, a następnie dopasowując argumenty nazwane do pozostałych parametrów. Jeśli parametr wymagany nie został wyspecyfikowany lub jeśli argument nazwany nie pasuje do żadnego z pozostałych parametrów, metoda nie jest możliwa do zaaplikowania. Więcej szczegółów na ten temat podaje specyfikacja w sekcji 7.5.3, ale są dwie sytuacje, na które chciałbym zwrócić szczególną uwagę. Po pierwsze, jeśli istnieją dwie metody możliwe do zastosowania i w jednej z nich wyspecyfikowano jawnie wszystkie argumenty, podczas gdy druga używa parametru opcjonalnego wypełnionego wartością domyślną, wygra metoda, która nie korzysta z żadnych wartości domyślnych. Ta reguła nie sprowadza się do zwykłego porównania liczby użytych wartości domyślnych — jest to jednoznaczny podział w oparciu o odpowiedź na pytanie, czy metoda używa wartości domyślnych, czy też nie. Dla przykładu rozważ następujący kod: static void Foo(int x = 10) { } static void Foo(int x = 10, int y = 20) { }

444

ROZDZIAŁ 13

Małe zmiany dla uproszczenia kodu ... Foo(); Foo(1); Foo(y: 2); Foo(1, 2);

Błąd: wywołanie niejednoznaczne Wywołuje pierwsze przeciążenie Wywołuje drugie przeciążenie Wywołuje drugie przeciążenie

W pierwszym wywołaniu ( ) obie metody mogą zostać użyte ze względu na swoje parametry opcjonalne. Kompilator nie jest jednak w stanie stwierdzić, którą z nich miałeś na myśli, i dlatego zgłasza błąd. W drugim wywołaniu ( ) nadal mogą być zastosowane obie metody, ale używana jest pierwsza z nich, ponieważ jej wywołanie nie wymaga obecności jakiejkolwiek wartości domyślnej, podczas gdy drugie przeciążenie użyłoby wartości domyślnej dla parametru y. Dla wywołań trzeciego i czwartego zastosowanie ma jedynie drugie przeciążenie. Trzecie wywołanie ( ) nazywa argument y, a czwarte ( ) ma dwa argumenty, co oznacza, że w obu przypadkach nie może zostać zastosowane pierwsze przeciążenie. PRZECIĄŻENIA I DZIEDZICZENIE NIE ZAWSZE ZE SOBĄ WSPÓŁGRAJĄ. Całe powyższe rozważania bazują na założeniu, że kompilator znalazł wiele przeciążeń, spośród których powinien wybrać jedno. Jeżeli niektóre metody są zadeklarowane w klasie bazowej, ale istnieją metody możliwe do zaaplikowania w klasie potomnej, wygrają te drugie. Takie zachowanie jest stosowane od początku i czasem może doprowadzić do zaskakujących wyników (zobacz http://mng.bz/aEmE)… jednak teraz obecność parametrów opcjonalnych oznacza, że zastosowanie może mieć większa liczba metod, niż mógłbyś oczekiwać. Moja rada to unikanie przeciążania metod klasy bazowej w klasie potomnej, chyba że kryje się za tym ogromna korzyść. Po drugie, czasami argumenty nazwane mogą stanowić alternatywę dla rzutowania mającego pomóc kompilatorowi w rozwiązaniu przeciążeń. W pewnych sytuacjach wywołanie może być niejednoznaczne, ponieważ argumenty mogą zostać przekonwertowane na typy parametrów w dwóch różnych metodach, ale żadna z nich pod żadnym względem nie jest lepsza. Dla przykładu rozważ następujące sygnatury metod i znajdujące się niżej wywołanie: void Method(int x, object y) { ... } void Method(object a, int b) { ... } ... Method(10, 10); Wywołanie niejednoznaczne

Obie metody mogą zostać użyte, ale żadna z nich nie jest lepsza od drugiej. Istnieją dwie możliwości rozwiązania tego problemu, przy założeniu, iż nie jesteś w stanie usunąć niejednoznaczności przez zmianę ich nazw. (Jest to preferowane przeze mnie podejście. Przekształć nazwę każdej metody na bardziej informacyjną i specyficzną, a podniesiesz tym samym ogólną czytelność kodu). Możesz zrzutować jeden z argumentów w sposób jawny lub rozwiązać niejednoznaczność przez użycie argumentów nazwanych: void Method(int x, object y) { ... } void Method(object a, int b) { ... } ... Method(10, (object) 10); Rzutowanie w celu rozwiązania niejednoznaczności Method(x: 10, y: 10); Nazwanie argumentów w celu rozwiązania niejednoznaczności

Parametry opcjonalne i argumenty nazwane

445

Oczywiście takie rozwiązanie zadziała jedynie wtedy, kiedy w różnych metodach występują różne nazwy parametrów, ale mimo wszystko jest to poręczny trik, o którym warto wiedzieć. Czasami bardziej czytelny kod zostanie osiągnięty przez rzutowanie, a czasem przez nazwę. Może to być dodatkowa broń w walce o przejrzysty kod. Tak jak argumenty nazwane w ogólności, to podejście ma swoje wady — trzeba zwracać na nie uwagę podczas zmian w metodzie. Słabo widoczny problem zmiany nazw W przeszłości, jeśli używałeś wyłącznie C#, nazwy parametrów nie odgrywały istotnej roli. Inne języki mogły zwracać na to uwagę, ale w C# jedyną sytuacją, w której nazwy parametrów miały znaczenie, była praca z IntelliSense lub przyglądanie się źródłom samej metody. Teraz, nawet jeśli jesteś ograniczony jedynie do C#, nazwy parametrów stają się faktycznie częścią interfejsu programistycznego. Zmieniając je później, możesz popsuć kod — jeśli zdecydujesz się na zmianę, coś, co korzystało z argumentu nazwanego przy odwołaniu do jednego z Twoich parametrów, przestanie się kompilować. Być może nie będzie to poważny problem, jeśli Twój kod konsumuje jedynie sam siebie, ale jeśli tworzysz publiczne API, miej świadomość, że zmiana nazwy parametru to rzecz bardzo istotna. Ściślej rzecz biorąc, taka zmiana zawsze była istotna, ale jeśli wszystko, co wywoływało dany kod, było napisane w C#, mogliśmy to ignorować. Zmiana nazwy parametru jest zła, ale zamiana nazw parametrów miejscami jest jeszcze gorsza. W ten sposób kod wywołujący będzie się nadal kompilował, ale z zupełnie innym znaczeniem. Szczególnie paskudną wersją tego problemu jest nadpisanie metody ze zmianą miejsc nazw parametrów w wersji nadpisanej. Bazując na statycznym typie wyrażenia użytego jako cel wywołania metody, kompilator będzie zawsze patrzył na jej najgłębiej nadpisaną wersję, jaką zna. Nie chcesz raczej dojść do sytuacji, w której wywołanie tej implementacji metody z taką samą listą argumentów spowoduje inne zachowanie, w zależności od statycznego typu zmiennej. Podsumowanie Argumenty nazwane i parametry opcjonalne są prawdopodobnie jednymi z dwóch najprościej brzmiących cech C# 4, a mimo to są dosyć skomplikowane, co mieliśmy okazję zobaczyć. Podstawowe koncepcje są proste do wyrażenia oraz zrozumienia — i właściwie tylko to powinno zaprzątać Ci głowę. Możesz skorzystać z parametrów opcjonalnych do zredukowania liczby potrzebnych przeciążeń, natomiast argumenty nazwane sprawiają, że kod jest o wiele bardziej czytelny, kiedy zostało użytych kilka łatwych do pomylenia ze sobą argumentów. Najbardziej podchwytliwym krokiem jest decyzja, których wartości domyślnych użyć, biorąc pod uwagę potencjalne problemy wynikające z wersjonowania. Teraz również o wiele bardziej niż kiedyś znaczenia nabierają nazwy parametrów. Musisz zachować szczególną ostrożność podczas nadpisywania istniejących metod, aby uniknąć wyrządzenia krzywdy innym osobom wywołującym Twój kod. Skoro rozważamy krzywdę przejdźmy do nowych cech związanych z COM. Z tą krzywdą to oczywiście żart… w przeważającej większości.

446

ROZDZIAŁ 13

Małe zmiany dla uproszczenia kodu

13.2. Usprawnienia we współpracy z COM Skwapliwie przyznam, iż daleko mi do bycia ekspertem w dziedzinie COM. Kiedy próbowałem z niego korzystać przed pojawieniem się .NET, zawsze kończyło się to kłopotami, które bez wątpienia były częściowo spowodowane moim brakiem wiedzy, a częściowo kiepskim projektem lub implementacją komponentów, z którymi przyszło mi pracować. Wciąż postrzegam COM jako swego rodzaju czarną magię. Mówiono mi, że w tej technologii jest sporo do polubienia, ale niestety nie próbowałem poznać jej tajników, a wydaje się, że jest ich całkiem sporo. TA SEKCJA JEST SPECYFICZNA DLA MICROSOFTU. Zmiany dotyczące lepszej współpracy z COM nie będą miały większego sensu dla wszystkich kompilatorów C#, a sam kompilator może nadal być określany mianem zgodnego ze specyfikacją bez implementowania tych cech. .NET sprawił, że COM stał się bardziej przystępny, ale dotychczas znacznie więcej korzyści przynosiło używanie go z Visual Basica, a nie z C#. Boisko do gry zostało wyrównane przez C# 4, o czym przekonamy się w tym podrozdziale. W bieżącym rozdziale będę bazował na przykładzie Worda, a w kolejnym na Excelu, ale nowe cechy nie niosą ze sobą niczego specyficznego odnośnie do Office’a — Twoje wrażenia związane z pracą z COM powinny być przyjemniejsze w C# 4, niezależnie od tego, co robisz.

13.2.1.Horror automatyzacji Worda przed C# 4 Nasz przykład będzie prosty — jego celem będzie uruchomienie Worda, stworzenie dokumentu z jednym akapitem tekstu, zapisanie go i wyjście. Brzmi prosto, nieprawdaż? Gdyby tylko tak było. Listing 13.8 pokazuje kod potrzebny przed C# 4. Listing 13.8. Tworzenie i zapisywanie dokumentu w C# 3 object missing = Type.Missing; var app = new Application { Visible = true }; app.Documents.Add(ref missing, ref missing, ref missing, ref missing); Document doc = app.ActiveDocument; Paragraph para = doc.Paragraphs.Add(ref missing); para.Range.Text = "Jak to dobrze, że mamy C# 4";

Uruchomienie Worda

Utworzenie dokumentu

object filename = "demo.doc"; object format = WdSaveFormat.wdFormatDocument97; Utworzenie doc.SaveAs(ref filename, ref format, komórki ref missing, ref missing, ref missing, widoku tabeli ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing); doc.Close(ref missing, ref missing, ref missing); Wyjście app.Application.Quit(ref missing, ref missing, ref missing); z Worda

Usprawnienia we współpracy z COM

447

Każdy krok w tym fragmencie kodu wygląda prosto: na początku tworzymy instancję typu COM-owego ( ) i włączamy jego widoczność poprzez wyrażenie inicjalizujące obiekt, a następnie tworzymy i wypełniamy nowy dokument ( ). Mechanizm służący do wstawiania tekstu do dokumentu nie jest tak prosty, jak moglibyśmy się tego spodziewać, ale warto pamiętać, że dokument Worda może mieć całkiem złożoną strukturę (może być gorzej). Kilka wywołań w tym miejscu posiada opcjonalne parametry referencyjne. Nie jesteśmy nimi zainteresowani, dlatego przekazujemy przez referencję zmienną lokalną o wartości Type.Missing. Jeżeli kiedykolwiek zdarzyło Ci się pracować z COM, ten wzorzec jest Ci zapewne znany. Następnie pojawia się bardzo paskudny fragment — zapisywanie dokumentu ( ). Tak, metoda SaveAs ma naprawdę 16 parametrów, z których używamy jedynie dwóch. Te dwa muszą być przekazane przez referencję, co oznacza, że musimy stworzyć dla nich zmienne lokalne. Jest to zupełny koszmar pod względem czytelności, ale nie martw się, niedługo to poprawimy. W końcu zamykamy dokument i samą aplikację ( ). Pomijając fakt, iż oba wywołania mają trzy parametry opcjonalne, nie widać tu nic interesującego. Zacznijmy od skorzystania z cech, które spotkaliśmy w tym rozdziale — już sama ich obecność powoduje znaczne zredukowanie tego przykładu.

13.2.2.Zemsta parametrów opcjonalnych i argumentów nazwanych Wszystko po kolei. Pozbądźmy się wszystkich tych argumentów odpowiadających parametrom opcjonalnym, którymi nie jesteśmy zainteresowani. Oznacza to również, że nie potrzebujemy zmiennej missing. Wciąż mamy przed sobą 2 parametry spośród 16, jakie przyjmuje metoda SaveAs. W tej chwili wiadomo, który jest który, dzięki nazwom zmiennych lokalnych, ale co, jeśli pomylimy się w kolejności ich użycia? Wszystkie parametry są typu słabego, więc czeka nas zgadywanka. Możemy w prosty sposób sprawić, że wywołanie będzie przejrzyste, przez nadanie nazw argumentom. Tak czy inaczej, musielibyśmy użyć nazwy, jeśli chcielibyśmy wyspecyfikować jakikolwiek z parametrów pojawiający się później, aby pominąć wszystkie pozostałe. Kolejny listing (13.9) pokazuje powstały kod — już widać, że jest on bardziej przejrzysty. Listing 13.9. Automatyzowanie Worda przy użyciu zwykłych cech C# 4 var app = new Application { Visible = true }; app.Documents.Add(); Document doc = app.ActiveDocument; Paragraph para = doc.Paragraphs.Add(); para.Range.Text = "Jak to dobrze, że mamy C# 4"; object filename = "demo.doc"; object format = WdSaveFormat.wdFormatDocument97; doc.SaveAs(FileName: ref filename, FileFormat: ref format); doc.Close(); app.Application.Quit();

448

ROZDZIAŁ 13

Małe zmiany dla uproszczenia kodu

Kod wygląda teraz o wiele lepiej, chociaż nadal szpeci go konieczność tworzenia zmiennych lokalnych na potrzeby argumentów SaveAs, które specyfikujemy. Ponadto, jeśli czytałeś uważnie, możesz być odrobinę zaniepokojony parametrami opcjonalnymi, które usunęliśmy. Były to parametry ref, ale opcjonalne — kombinacja, której C# nie obsługuje w normalnych warunkach. Co więc się dzieje?

13.2.3.Kiedy parametr ref nie jest parametrem ref? Zazwyczaj C# przyjmuje dosyć restrykcyjną postawę wobec parametrów ref. Musisz oznaczyć tym modyfikatorem zarówno argument, jak i sam parametr, pokazując w ten sposób, że rozumiesz, co się dzieje (wartość Twojej zmiennej może zostać zmieniona przez wywoływaną metodę). To wszystko jest w pełni zrozumiałe w zwykłym kodzie, ale interfejs programistyczny COM w celu poprawienia wydajności często używa parametrów ref niemal do wszystkiego. Na ogół zmienne przekazywane przez takie parametry nie podlegają modyfikacji. W C# przekazywanie parametrów przez referencję jest troszeczkę uciążliwe. Oprócz konieczności dodania modyfikatora ref musisz również posiadać zmienną. Nie możesz przekazać wartości przez referencję. W C# 4 kompilator znacznie ułatwia to zadanie, gdyż pozwala Ci przekazać argument do metody COM przez wartość, nawet jeśli jest ona przeznaczona dla parametru ref. Rozważ następujące wywołanie, w którym argument może się okazać zmienną typu string, ale sam parametr jest zadeklarowany jako ref object: obiektCOM.JakasMetoda(argument);

Kompilator wstrzykuje kod będący odpowiednikiem: object tmp = argument; obiektCOM.JakasMetoda(ref tmp);

Zauważ, że wszelkie zmiany wykonane przez metodę JakasMetoda są porzucane, zatem wywołanie faktycznie zachowuje się tak, jakbyś przekazywał argument przez wartość. Taki sam proces jest stosowany dla opcjonalnych parametrów ref — każdy wymusza zmienną lokalną inicjalizowaną wartością Type.Missing, która jest przekazywana przez referencję do metody COM-owej. Jeśli zdekompilujesz kod C#, zobaczysz, że wygenerowany kod IL jest usiany tymi dodatkowymi zmiennymi. Możemy teraz zastosować końcowe poprawki do naszego przykładu z Wordem — pokazuje je listing 13.10. Listing 13.10. Przekazywanie argumentów przez wartość w metodach COM-owych var app = new Application { Visible = true }; app.Documents.Add(); Document doc = app.ActiveDocument; Paragraph para = doc.Paragraphs.Add(); Argumenty przekazywane para.Range.Text = "Jak to dobrze, że mamy C# 4"; przez wartość doc.SaveAs(FileName: "test.doc", FileFormat: WdSaveFormat.wdFormatDocument97); doc.Close(); app.Application.Quit();

Usprawnienia we współpracy z COM

449

Jak widzisz, rezultat końcowy jest znacznie bardziej przejrzysty w porównaniu do tego, od którego zaczęliśmy. W przypadku takiego interfejsu programistycznego, jaki oferuje Word, nadal musisz przegryźć się przez oszałamiający zestaw metod, właściwości i zdarzeń w typach zasadniczych, takich jak Application i Document, ale przynajmniej Twój kod będzie o wiele łatwiejszy w lekturze. Zanim przejdziemy do poprawek związanych z dystrybucją aplikacji, jest jeszcze jeden, ostatni już aspekt wsparcia COM, któremu musimy się przyjrzeć pod względem zmian w kodzie źródłowym.

13.2.4.Wywoływanie indekserów nazwanych Kilka elementów C# 4 jest związanych z dodaniem funkcjonalności dla cech, które od dawna istnieją w Visual Basicu — ta jest kolejną z nich. CLR, COM i Visual Basic pozwalają na istnienie niedomyślnych właściwości z parametrami, w nomenklaturze C#: indekserów nazwanych. Do wersji czwartej C# nie tylko zabraniał deklarowania własnych indekserów nazwanych, ale również nie udostępniał żadnej metody dostępu do nich przy użyciu składni właściwości. Jedynym indekserem, jakiego mogłeś użyć z poziomu C#, był ten zadeklarowany jako właściwość domyślna danego typu. Nie stanowiło to większego problemu dla komponentów .NET napisanych w Visual Basicu, gdyż — uogólniając — stosowanie indekserów nazwanych jest odradzane. Jednak komponenty COM-owe, takie jak Office, używają ich dosyć intensywnie. C# 4 pozwala Ci na wywoływanie ich w bardziej naturalny sposób, chociaż nadal nie możesz deklarować ich dla swoich własnych typów C#. PONOWNIE KONFLIKT TERMINOLOGICZNY. W całej sekcji używam określenia indekser do opisania czegoś, co w terminologii VB jest znane pod nazwą właściwości sparametryzowanej. Niezależnie od użytej nazwy, w języku IL indekser jest zadeklarowany jako właściwość i posiada parametry. Zwykły indekser (w sensie języka C#) jest zdefiniowany jako element domyślny (lub właściwość domyślna) typu — na przykład domyślnym elementem typu StringBuilder jest właściwość Chars (posiadająca parametr typu Int32). Kiedy mówię o indekserach nazwanych, mam na myśli te, które nie są domyślnymi dla typu, i dlatego musisz się do nich odnosić poprzez nazwę. Jako przykładu użyjemy ponownie Worda, pokazując tym razem różne znaczenia dla słów. Typ _Application w Wordzie definiuje indekser o nazwie SynonymInfo o następującej deklaracji: SynonymInfo SynonymInfo[string Word, ref object LanguageId = Type.Missing]

Nie jest to poprawna składnia C#, ponieważ nie możesz zadeklarować indeksera nazwanego, ale mam przynajmniej nadzieję, że jej znaczenie jest jasne. Nazwą indeksera jest SynonymInfo. Zwraca on referencję do obiektu SystemInfo i posiada dwa parametry, z których jeden jest opcjonalny. (Fakt, iż nazwa indeksera i nazwa typu zwracanego są w tym przypadku identyczne, jest zwykłym zbiegiem okoliczności). SynonymInfo może zostać

450

ROZDZIAŁ 13

Małe zmiany dla uproszczenia kodu

użyty do odnalezienia znaczenia słowa i synonimów dla każdego z tych znaczeń. Następujący listing (13.11) przedstawia trzy różne sposoby użycia powyższego indeksera w celu wyświetlenia liczby znaczeń dla trzech różnych słów. Listing 13.11. Wyświetlanie liczby synonimów przy użyciu indeksera nazwanego static void ShowInfo(SynonymInfo info) { Console.WriteLine("{0} – liczba znaczeń: {1}", info.Word, info.MeaningCount); } ... Application app = new Application { Visible = false }; object missing = Type.Missing; ShowInfo(app.get_SynonymInfo("bolesny", ref missing));

Użycie poprzedniej składni C#

ShowInfo(app.SynonymInfo["miły", WdLanguageID.wdEnglishUS]);

Wyspecyfikowanie obu argumentów

ShowInfo(app.SynonymInfo[Word: "cechy"]); app.Application.Quit();

Użycie parametru opcjonalnego

Nawet bez indekserów nazwanych cechy, które widzieliśmy wcześniej, pomogłyby w złagodzeniu bólu związanego z wierszem kodu w punkcie ( ). Moglibyśmy na przykład wywołać app.get_SynonymInfo("bolesny") i skorzystać z parametrów opcjonalnych. Patrząc na ( ) i ( ), widzisz, że składnia indeksera wygląda mniej dziwacznie niż wywołanie get_. Można się spierać, że tak czy inaczej powinno to być wywołanie metody lub powinna istnieć bezparametrowa właściwość SynonymInfo zwracająca kolekcję z odpowiednim indekserem domyślnym. Jest to jeden z głównych argumentów podawanych przez projektantów C# przemawiających za nieimplementowaniem pełnego wsparcia dla indekserów nazwanych, łącznie z deklarowaniem ich w C#. Problem polega jednak na tym, że to już jest indekser w Wordzie, zatem dobrze byłoby móc skorzystać z tej możliwości5. Kod w wierszu ( ) korzysta z cechy niejawnego parametru ref, o którym mówiliśmy w sekcji 13.2.3, natomiast wiersz ( ) pomija parametr opcjonalny i dla zabawy nazywa pozostały argument. W przypadku indekserów i parametrów opcjonalnych istnieje jedna mała niezręczność — jeśli wszystkie parametry są opcjonalne i nie chcesz specyfikować żadnego z argumentów, musisz pominąć również nawiasy kwadratowe. Zatem zamiast pisać foo.Indexer[], napisałbyś jedynie foo.Indexer. Dotyczy to zarówno pobierania wartości z indeksera, jak i przypisywania mu jej. Do tej pory wszystko idzie płynnie, ale pisanie kodu to zaledwie część walki. Zazwyczaj musisz również opublikować swoją aplikację na innych maszynach. Tutaj z pomocą ponownie przychodzi C# 4.

5

Być może bardziej interesujące byłoby wyświetlenie faktycznych znaczeń, ale to prowadzi do problemów związanych ze współpracą z COM, które nie są przedmiotem tej książki. Więcej szczegółów na ten temat znajdziesz na stronie książki.

Usprawnienia we współpracy z COM

451

13.2.5.Łączenie głównych bibliotek COM-owych Kiedy budujesz kod w oparciu o typ COM-owy, używasz modułu wygenerowanego dla biblioteki komponentu. Zazwyczaj korzystasz z modułu PIA (ang. primary interop assembly), będącego kanonicznym modułem współdzielonym dla biblioteki COM, podpisanym przez publikującego. Dla swoich bibliotek COM-owych możesz wygenerować takie moduły, używając narzędzia importującego bibliotekę typów (Type Library Importer — tlbimp). Moduły PIA ułatwiają życie poprzez dostarczanie jedynej słusznej metody dostępu do typów COM-owych, ale stanowią niedogodność pod innymi względami. Potrafią być całkiem spore, a do tego muszą być obecne w całości, nawet jeśli korzystasz jedynie z małego podzbioru funkcjonalności. Ponadto na maszynie, na której chcesz opublikować swój projekt, musisz posiadać taką samą wersję PIA, jakiej użyłeś podczas kompilacji. To może być trudne w sytuacji, kiedy ze względów licencyjnych nie możesz dystrybuować samego modułu PIA i musisz bazować na przekonaniu, iż dobra wersja jest już zainstalowana. Jeżeli istnieje kilka dostępnych wersji i wszystkie one dostarczają funkcjonalność, której potrzebujesz, możesz być zmuszony do dystrybuowania różnych wersji Twojego kodu w celu zapewnienia prawidłowego działania referencji. C# 4 pozwala na zgoła odmienne podejście. Zamiast odwoływać się do PIA tak jak do każdego innego modułu, możesz go połączyć (ang. link). W Visual Studio 2010 opcja taka jest dostępna pod postacią właściwości referencji do modułu — pokazuje ją rysunek 13.4. Rysunek 13.4. Łączenie PIA w Visual Studio 2010

Miłośnicy wiersza poleceń mogą zastąpić przełącznik /r (lub /reference) przełącznikiem /l (lub /link), doprowadzając do połączenia zamiast referencji: csc /l:Sciezka\Do\PIA.dll MojKod.cs

Kiedy połączysz PIA, kompilator osadzi bezpośrednio w Twoim module jedynie te elementy, które są mu niezbędne. Będą to tylko potrzebne typy i elementy wewnątrz tych typów. Przykładowo dla kodu, który napisaliśmy w tym rozdziale, kompilator tworzy następujące typy:

452

ROZDZIAŁ 13

Małe zmiany dla uproszczenia kodu namespace Microsoft.Office.Interop.Word { [ComImport, TypeIdentifier, CompilerGenerated, Guid("...")] public interface _Application [ComImport, TypeIdentifier, CompilerGenerated, Guid("...")] public interface _Document [ComImport, CompilerGenerated, TypeIdentifier, Guid("...")] public interface Application : _Application [ComImport, Guid("..."), TypeIdentifier, CompilerGenerated] public interface Document : _Document [ComImport, TypeIdentifier, CompilerGenerated, Guid("...")] public interface Documents : IEnumerable [TypeIdentifier("...", "WdSaveFormat"), CompilerGenerated] public enum WdSaveFormat }

A jeśli spojrzysz na interfejs _Application, wygląda on mniej więcej tak: [ComImport, TypeIdentifier, CompilerGenerated, Guid("...")] public interface _Application { void _VtblGap 1_4(); Documents Documents { [...] get; } void _VtblGap2_1(); Document ActiveDocument { [...] get; } }

Ze względu na ograniczone miejsce, pominąłem GUID-y i atrybuty właściwości. Pamiętaj, że zawsze możesz użyć Reflectora, aby przyjrzeć się z bliska typom osadzonym w module. Są to jedynie enumeracje i interfejsy — nie ma implementacji. Zwykły moduł PIA posiada koklasę (CoClass) reprezentującą faktyczną implementację (ale jej zadanie sprowadza się oczywiście do przekierowania wszystkiego do rzeczywistego typu COM-owego). Kiedy kompilator musi utworzyć instancję typu COM-owego poprzez złączony PIA, tworzy jego instancję, używając GUID-a związanego z tym typem. Dla przykładu przy włączonym łączeniu PIA wiersz kodu w naszym przykładzie, który tworzy instancję obiektu Application, jest tłumaczony na następujący kod6: Application application = (Application) Activator.CreateInstance( Type.GetTypeFromCLSID (new Guid("...")));

Rysunek 13 5 pokazuje, jak powyższy kod zachowuje się podczas wykonania. Łączenie biblioteki typów niesie ze sobą różnorodne korzyści: Publikacja jest prostsza: oryginalny moduł PIA nie jest wymagany, zatem nie

musisz bazować na przekonaniu, iż odpowiednia wersja jest dostępna u klienta, ani wysyłać PIA samodzielnie.

6

Ściśle rzecz biorąc, na kod zbliżony do tego. Inicjalizator obiektu sprawia, że kod jest odrobinę bardziej skomplikowany, ponieważ kompilator korzysta z dodatkowej zmiennej tymczasowej.

Wariancja typów generycznych dla interfejsów i delegatów

453

Rysunek 13.5. Porównanie łączenia i odwołania przez referencję

Wersjonowanie jest prostsze: jak długo korzystasz wyłącznie z elementów

tej wersji biblioteki COM-owej, która jest faktycznie zainstalowana, nie ma znaczenia, czy skompilowałeś swój kod w odniesieniu do wcześniejszej, czy późniejszej wersji tej biblioteki. Typy wariantowe są traktowane jako typy dynamiczne, co prowadzi

do zredukowania liczby potrzebnych rzutowań. Nie przejmuj się chwilowo ostatnim punktem — żeby wyciągnąć z niego jakiś sens, muszę najpierw wyjaśnić Ci typy dynamiczne. Wszystkiego dowiesz się w kolejnym rozdziale. Jak widzisz, Microsoft zabrał się na poważnie za współpracę z COM w C# 4, dzięki czemu cały proces programowania stał się mniej uciążliwy. Oczywiście stopień dokuczliwości może być różny w zależności od biblioteki COM, z jaką przyszło Ci pracować, dlatego nowe cechy przyniosą niektórym więcej korzyści niż innym. Nasza kolejna cecha jest całkowicie niezależna od COM, argumentów nazwanych i parametrów opcjonalnych, ale — tak jak poprzednie — ma na celu ułatwienie odrobinę procesu programowania.

13.3. Wariancja typów generycznych dla interfejsów i delegatów Być może pamiętasz, że w rozdziale 3. wspomniałem o istnieniu pewnego stopnia obsługi wariancji typów generycznych przez CLR, który nie został jeszcze udostępniony z poziomu C#. Uległo to zmianie w C# 4. Język zyskał składnię wymaganą do deklarowania wariancji generycznej, a kompilator jest teraz świadomy możliwych konwersji dla interfejsów i delegatów. Nie jest to cecha, która wpłynie fundamentalnie na Twoje dotychczasowe życie programisty. Jest to raczej likwidacja trudności, które zdarzało Ci się czasem napotkać.

454

ROZDZIAŁ 13

Małe zmiany dla uproszczenia kodu

Tak naprawdę nie usuwa ona nawet wszystkich trudności, a to głównie ze względu na chęć zachowania bezpieczeństwa typu generyków. Mimo wszystko jest to nadal cecha, którą warto mieć. Na wypadek gdybyś potrzebował przypomnienia, zaczniemy od krótkiego podsumowania dwóch podstawowych postaci wariancji.

13.3.1.Typy wariancji: kowariancja i kontrawariancja Sednem wariancji jest możliwość użycia — w sposób bezpieczny pod względem typu — obiektu jednego typu w taki sposób, jakby był on innego typu. Jesteśmy przyzwyczajeni do wariancji pod postacią zwykłego dziedziczenia. Jeśli na przykład metoda posiada typ zwracany Stream, wewnątrz implementacji możesz zwrócić MemoryStream. Wariancja generyczna opiera się na tej samej koncepcji, ale zastosowanej do typów generycznych, przez co cały proces staje się odrobinę bardziej skomplikowany. Wariancja jest stosowana do parametrów typu w interfejsach i delegatach. Na tym fragmencie powinieneś się skoncentrować. W ostatecznym rozrachunku nie ma znaczenia, czy pamiętasz terminologię, której zamierzam użyć w tej sekcji. Będzie ona przydatna podczas czytania rozdziału, ale mało prawdopodobne jest, abyś potrzebował jej w trakcie zwykłej rozmowy. O wiele bardziej istotne są same koncepcje. Są dwa typy wariancji: kowariancja i kontrawariancja. Stanowią one w istocie tę samą ideę, ale użytą w kontekście wartości poruszających się w różnych kierunkach. Zaczniemy od kowariancji, która jest prostsza w zrozumieniu. Kowariancja — wartości wychodzące z API Kowariancja to wszystko, co ma związek z wartościami zwracanymi przez operację z powrotem do kodu wywołującego. Wyobraźmy sobie bardzo prosty interfejs generyczny reprezentujący wzorzec fabryki. Posiada on pojedynczą metodę — CreateInstance, która zwraca instancję odpowiedniego typu. Oto cały kod: interface IFactory { T CreateInstance(); }

T pojawia się tylko raz w interfejsie (pomijając jego nazwę). Jest używany wyłącznie

jako wartość zwracana — stanowi dane wyjściowe metody. Sensowne wydaje się zatem, aby traktować fabrykę specyficznego typu jako fabrykę typu bardziej ogólnego. Odwołując się do przykładu z rzeczywistości, możesz myśleć o fabryce pizzy jako fabryce żywności. Kontrawariancja — wartości wchodzące do API Kontrawariancja działa w odwrotnym kierunku. Dotyczy wszystkiego, co jest przekazywane do wnętrza API przez kod wywołujący. API nie produkuje wartości, lecz je konsumuje. Wyobraźmy sobie inny prosty interfejs — taki, który potrafi w ładny sposób wyświetlić określony typ dokumentu w oknie konsoli. Interfejs ponownie posiada wyłącznie jedną metodę o nazwie Print:

Wariancja typów generycznych dla interfejsów i delegatów

455

interface IPrettyPrinter { void Print(T document); }

Tym razem T pojawia się jako parametr na pozycji wejściowej interfejsu. Gdyby spojrzeć na to ponownie z bardziej praktycznego punktu widzenia, jeśli mielibyśmy implementację IPrettyPrinter, powinniśmy być w stanie użyć jej jako IPrettyPrinter ´. Inwariancja — wartości poruszające się w obu kierunkach Jeśli kowariancja ma miejsce, kiedy wartości wydostają się wyłącznie z API, a kontrawariancja, kiedy wartości dostają się wyłącznie do API, co się dzieje, gdy wartość podróżuje w obu kierunkach? W skrócie: nic. Taki typ należałoby określić jako inwariancyjny. Oto interfejs reprezentujący typ, który umożliwia serializację i deserializację określonego typu danych: interface IStorage { byte[] Serialize(T value); T Deserialize(byte[] data); }

Tym razem, jeśli mamy instancję interfejsu IStorage dla określonego typu T, nie możemy traktować go jako implementacji interfejsu mniej lub bardziej specyficznego typu. Próbując użyć takiej instancji w sposób kowariancyjny (na przykład stosując IStorage jako IStorage), moglibyśmy wywołać Serialize z obiektem, którego ta metoda nie potrafi obsłużyć. Podobnie gdybyśmy chcieli użyć implementacji kontrawariancyjnie, w wyniku deserializacji pewnych danych moglibyśmy otrzymać typ, którego się nie spodziewamy. Jeśli jest to pomocne, możesz traktować inwariancję jak parametr z modyfikatorem ref. Chcąc przekazać zmienną przez referencję, jej typ musi dokładnie pasować do typu samego parametru, ponieważ wartość przemieszcza się do metody, a następnie z niej powraca.

13.3.2.Użycie wariancji w interfejsach C# 4 pozwala Ci na wyspecyfikowanie w deklaracji interfejsu lub delegata generycznego faktu, iż parametr typu może być użyty kowariancyjnie, poprzez wstawienie modyfikatora out, lub kontrawariancyjnie, poprzez wstawienie modyfikatora in. Po zadeklarowaniu typu odpowiednie konwersje typów stają się dostępne w sposób niejawny. Działanie jest identyczne w przypadku interfejsów i delegatów, ale dla przejrzystości pokażę je oddzielnie. Zacznijmy od interfejsów, gdyż są nam lepiej znane, bowiem użyliśmy ich już do opisania wariancji. KONWERSJE WARIANCYJNE SĄ KONWERSJAMI REFERENCYJNYMI. Dowolna konwersja używająca wariancji lub kowariancji jest konwersją referencyjną, co oznacza, że po konwersji jest zwracana ta sama referencja. Konwersja

456

ROZDZIAŁ 13

Małe zmiany dla uproszczenia kodu

nie tworzy nowego obiektu, a jedynie powoduje traktowanie istniejącej referencji tak, jakby pasowała ona do typu docelowego. Jest to takie samo zachowanie jak w przypadku rzutowania pomiędzy typami referencyjnymi w hierarchii — jeśli zrzutujesz Stream na MemoryStream (lub użyjesz niejawnej konwersji w drugim kierunku), nadal będzie istnieć tylko jeden obiekt. Natura tych konwersji wprowadza pewne ograniczenia, o czym przekonamy się później, ale podstawowe znaczenie jest takie, iż są to konwersje wydajne, pozwalające lepiej zrozumieć zachowanie pod względem tożsamości obiektu. Tym razem do zademonstrowania wspomnianych powyżej koncepcji użyjemy znanych nam interfejsów w połączeniu z prostymi, zdefiniowanymi przez nas typami służącymi jako argumenty typu. Wyrażanie wariancji modyfikatorami in i out Są dwa interfejsy, które szczególnie dobrze nadają się do zademonstrowania wariancji: IEnumerable jest kowariancyjny pod względem T, natomiast IComparer jest kontrawariancyjny pod względem T. Oto ich nowe deklaracje typów w C# 4: public interface IEnumerable public interface IComparer

Wystarczy pamiętać, że jeśli parametr typu jest używany wyłącznie na wyjściu, możesz użyć out, zaś gdy jest używany tylko na wejściu, możesz użyć in. Kompilator nie ma pojęcia, czy wiesz, która forma jest określana mianem kowariancji, a która kontrawariancji! Na nasze nieszczęście środowisko nie zawiera zbyt wiele hierarchii dziedziczenia, które pomogłyby nam przejrzyście zademonstrować wariancję, dlatego też posłużę się standardowym przykładem programowania zorientowanego obiektowo — kształtami. Kod do pobrania zawiera w miarę oczywiste definicje IShape, Circle i Square. Interfejs udostępnia właściwości związane z bryłą brzegową kształtu i jej powierzchnią. W kolejnych przykładach będę używał często dwóch list. Poniżej przedstawiam kod, który je konstruuje: List circles = new List { new Circle(new Point(0, 0), 15), new Circle(new Point(10, 5), 20), }; List squares = new List { new Square(new Point(5, 10), 5), new Square(new Point(-10, 0), 2) };

Jedyną istotną rzeczą są typy zmiennych — zostały zadeklarowane jako List i List, a nie List. Takie podejście może się okazać użyteczne, gdy będziemy chcieli odwołać się do listy okręgów w innym miejscu. Będziemy mogli na przykład skorzystać z elementów kolekcji bez konieczności rzutowania. Wartości użyte

Wariancja typów generycznych dla interfejsów i delegatów

457

w kodzie konstrukcyjnym są całkowicie bez znaczenia! W dalszej części rozdziału odnoszę się do obu kolekcji poprzez nazwy circles i squares, nie duplikując już samego kodu inicjalizującego7. Użycie kowariancji interfejsów Aby zademonstrować kowariancję, spróbujemy zbudować listę kształtów z listy okręgów i listy kwadratów. Listing 13.12 prezentuje różne podejścia do tego zadania, z których żadne nie działałoby w C# 3. Listing 13.12. Budowanie listy ogólnych kształtów z okręgów i kwadratów List shapesByAdding = new List(); shapesByAdding.AddRange(circles); shapesByAdding.AddRange(squares); List concat = circles.Concat(squares) .ToList();

Bezpośrednie zsumowanie list Złączenie za pomocą LINQ

Listing 13.12 pokazuje kowariancję w czterech miejscach, z których każde konwertuje sekwencję okręgów lub kwadratów na sekwencję ogólnych kształtów. Zaczynamy od utworzenia nowej listy List i wywołania AddRange, aby dodać do niej listy okręgów i kwadratów ( ). (Jedną z list moglibyśmy również przekazać bezpośrednio do konstruktora, a następnie wywołać AddRange tylko jeden raz). Parametrem List.AddRange jest IEnumerable, zatem w tym przypadku traktujemy każdą listę jako IEnumerable ´ — coś, co wcześniej nie było możliwe. Metoda AddRange mogłaby zostać napisana jako generyczna ze swoim własnym parametrem typu, ale nie została — takie podejście utrudniłoby lub wręcz uniemożliwiło pewne optymalizacje. Innym sposobem stworzenia listy, która zawiera dane z dwóch istniejących sekwencji, jest użycie LINQ ( ). Nie możemy bezpośrednio wywołać circles.Concat(squares), ponieważ wprowadziłoby to w zakłopotanie mechanizm interfejsu typów, ale pożądany efekt uzyskamy, specyfikując jawnie argument typu. Zarówno okręgi (circles), jak i kwadraty (squares) dzięki kowariancji mogą być niejawnie przekonwertowane na IEnumerable. Ta konwersja nie zmienia faktycznie wartości, a jedynie to, w jaki sposób kompilator ją traktuje. Co ważne, nie budujemy oddzielnej kopii. Kowariancja jest szczególnie istotna w LINQ dla Obiektów, ponieważ spora część jej interfejsu programistycznego jest wyrażona w formie IEnumerable. Kontrawariancja jest mniej istotna, ponieważ mniejsza liczba zaangażowanych typów jest kontrawariancyjna. W C# 3 można by z całą pewnością podejść inaczej do tego samego problemu. Dla oryginalnych kształtów zbudowalibyśmy instancje IList zamiast List i List. Moglibyśmy użyć operatora LINQ Cast, aby przekonwertować listy specyficzne na bardziej ogólne. Moglibyśmy napisać swoją własną klasę listy z generyczną metodą AddRange. Jednak żadne z tych podejść nie byłoby tak wygodne i funkcjonalne jak przedstawione tutaj rozwiązania. 7

W pełnej wersji kodu źródłowego obie listy są dostępne poprzez właściwości statycznej klasy Shapes. W wersji z fragmentami kod jest dołączony wszędzie tam, gdzie jest to potrzebne. Jeśli chcesz, możesz go samodzielnie przerobić.

458

ROZDZIAŁ 13

Małe zmiany dla uproszczenia kodu

Użycie kontrawariancji interfejsów Tych samych typów kształtów użyjemy do zademonstrowania kontrawariancji. Skorzystamy wyłącznie z listy okręgów oraz komparatora, który jest w stanie porównać dwa dowolne kształty w oparciu o ich powierzchnię. Nie moglibyśmy zrobić tego przed C# 4, ponieważ komparator IComparer nie mógłby być użyty jako IComparer, natomiast teraz jest to możliwe dzięki kontrawariancji, co pokazuje listing 13.13. Listing 13.13. Sortowanie okręgów przy użyciu komparatora ogólnego użytku i kontrawariancji class AreaComparer : IComparer Porównuje kształty { po powierzchni public int Compare(IShape x, IShape y) { return x.Area.CompareTo(y.Area); } } ... Sortowanie z użyciem IComparer areaComparer = new AreaComparer(); kontrawariancji circles.Sort(areaComparer);

Nie ma tutaj nic skomplikowanego. Nasza klasa AreaComparer ( ) odpowiada najprostszej możliwej implementacji IComparer. Nie potrzebuje na przykład żadnego stanu. Zazwyczaj w metodzie Compare pojawiłby się kod odpowiedzialny za sprawdzanie wartości pustych, ale nie jest on konieczny do zademonstrowania wariancji. Kiedy mamy już IComparer, używamy go do sortowania listy okręgów ( ). Argumentem circles.Sort musi być IComparer, ale kontrawariancja pozwala nam na niejawną konwersję naszego komparatora. To takie proste. NIESPODZIANKA, NIESPODZIANKA. Gdyby ktoś pokazał Ci ten kod tak, jakby był on napisany dla C# 3, mógłbyś oglądać go z przeświadczeniem, że będzie działał. Wydaje się oczywiste, że powinien działać — jest to powszechne odczucie. Inwariancja w C# 2 i 3 okazuje się często nieoczekiwaną niespodzianką. Nowe możliwości C# 4 w tym obszarze nie wprowadzają odkrywczych koncepcji, o których nie pomyślałbyś nigdy wcześniej, a jedynie pozwalają Ci na większą elastyczność. Oba przykłady bazowały na prostych interfejsach z pojedynczą metodą, ale te same zasady obowiązują również w przypadku bardziej złożonych interfejsów programistycznych. Oczywiście, im bardziej złożony interfejs, tym większe prawdopodobieństwo, że parametr typu będzie użyty zarówno na wejściu, jak i wyjściu, co w konsekwencji sprawi, iż ten interfejs będzie inwariancyjny. Do podchwytliwych przykładów wrócimy później, ale najpierw przyjrzyjmy się delegatom.

13.3.3.Zastosowanie wariancji w delegatach Teraz, kiedy widzieliśmy, jak użyć wariancji w połączeniu z interfejsami, zastosowanie tej samej wiedzy do delegatów jest proste. Ponownie skorzystamy ze znanych nam typów: delegate T Func() delegate void Action(T obj)

Wariancja typów generycznych dla interfejsów i delegatów

459

Są to w praktyce odpowiedniki interfejsów IFactory i IPrettyPrinter, od których zaczęliśmy nasze rozważania. Używając wyrażeń lambda, możemy z łatwością zademonstrować oba powyższe delegaty, a nawet połączyć je w wywołanie łańcuchowe. Poniższy listing (13.14) pokazuje przykład korzystający z naszych typów kształtów. Listing 13.14. Użycie wariancji w połączeniu z delegatami Func i Action Func squareFactory = () => new Square(new Point(5, 5), 10); Konwersja Func Func shapeFactory = squareFactory;

przy użyciu kontrawariancji

Action shapePrinter = shape => Console.WriteLine(shape.Area); Action squarePrinter = shapePrinter; Konwersja Action squarePrinter(squareFactory()); shapePrinter(shapeFactory());

przy użyciu kontrawariancji Sprawdzenie poprawności

Mam nadzieję, że w tym momencie kod nie wymaga szczegółowego tłumaczenia. Nasza fabryka kwadratów produkuje zawsze kwadrat na tej samej pozycji, mający bok równy 10. Kowariancja pozwala nam bez dodatkowych trudności na traktowanie fabryki kwadratów zawsze jako ogólnej fabryki kształtów ( ). Następnie tworzymy akcję ogólnego przeznaczenia, która wyświetla powierzchnię dowolnego kształtu, jaki zostanie jej przekazany. Tym razem używamy konwersji kotrawariancyjnej, aby potraktować akcję jako taką, która może być zastosowana do dowolnego kwadratu ( ). W końcu „karmimy” akcję dotyczącą kwadratów wynikiem wywołania fabryki kwadratów, a akcję dotyczącą kształtów — wynikiem wywołania fabryki kształtów. Obie, zgodnie z naszymi oczekiwaniami, wyświetlają 100. Użyliśmy tutaj delegatów zaledwie z pojedynczym parametrem typu. Co się stanie, kiedy interfejs lub delegat będzie miał więcej parametrów typu? Co z argumentami typu, które same w sobie są delegatami generycznymi? Wszystko może stać się całkiem skomplikowane.

13.3.4.Złożone sytuacje Zanim zacznę wprowadzać zamęt w Twojej głowie, powinienem udzielić Ci małej pociechy. Mimo że będziemy robić dziwne i jednocześnie wspaniałe rzeczy, kompilator ustrzeże Cię od błędów. Jeżeli użyjesz kilku parametrów typu w nieszablonowy sposób, nadal możesz się spodziewać trudnych do zrozumienia błędów. Kiedy jednak kod się skompiluje, wszystko powinno być w porządku. Sytuacje złożone mogą mieć miejsce zarówno w przypadku wariancji interfejsów, jak i delegatów, chociaż praca z wersją delegatową daje zazwyczaj bardziej zwięzłe wyniki. Zacznijmy od względnie prostego przykładu. Symultaniczna kowariancja i kontrawariancja z użyciem Converter Typ delegatowy Converter jest dostępny mniej więcej od wersji .NET 2.0. W rzeczywistości jest to Func, ale przedstawiony w sposób jasno wyrażający cel. W .NET 4 typ ten przyjmuje postać Converter,

460

ROZDZIAŁ 13

Małe zmiany dla uproszczenia kodu

wskazując rodzaj wariancji każdego z parametrów typu. Poniższy listing (13.15) pokazuje kilka kombinacji wariancji przy użyciu prostego konwertera. Listing 13.15. Demonstracja wariancji i kontrawariancji w pojedynczym typie Converter
string> string> object> object>

converter = x => x.ToString(); Konwersja contravariance = converter; obiektów covariance = converter; na łańcuchy Konwersja przycisków na obiekty both = converter;

Listing 13.15 pokazuje różne konwersje wariancyjne dostępne poprzez typ delegatowy Converter. Delegat przyjmuje dowolny obiekt i przekształca go na łańcuch. W pierwszej kolejności implementujemy delegat, używając prostego wyrażenia lambda, które wywołuje metodę ToString ( ). Jak to zwykle bywa, faktycznie nigdy nie wywołujemy tego delegata, zatem równie dobrze moglibyśmy użyć pustej referencji, ale myślę, że łatwiej jest analizować wariancję, jeżeli możesz powiązać ją z konkretną akcją, jaka miałaby miejsce, gdybyś rzeczywiście dokonał tego wywołania. Następne dwa wiersze są względnie proste, pod warunkiem że skoncentrujesz się w danej chwili wyłącznie na jednym parametrze typu. TInput jest używany tylko na pozycji wejściowej, zatem użycie go kontrawariancyjnie ma sens, gdy potraktujemy Converter jako Converter. Innymi słowy, jeżeli możesz przekazać do konwertera dowolną referencję obiektu, z całą pewnością możesz przekazać również referencję do Button. Podobnie parametr TOutput jest używany wyłącznie na pozycji wyjściowej (typ zwracany), zatem sensowne jest użycie go w sposób kowariancyjny. Jeżeli konwerter zwraca zawsze referencję do łańcucha, możesz użyć go bezpiecznie, kiedy potrzebna jest Ci zaledwie gwarancja, iż zwracana będzie referencja do obiektu. Ostatni wiersz ( ) jest jedynie logicznym rozszerzeniem tej koncepcji. Używa zarówno kontrawariancji, jak i wariancji w tej samej konwersji, stając się tym samym konwerterem, który akceptuje jedynie przyciski i deklaruje, że będzie zwracał tylko referencje do obiektów. Zauważ, że nie możesz powrócić z tej sytuacji z powrotem do oryginalnej konwersji bez użycia rzutowania — na każdym kroku ograniczaliśmy gwarancje i nie możemy teraz zacieśnić ich z powrotem w sposób niejawny. Utrudnijmy jeszcze trochę całą sytuację i zobaczmy, do jakiego stopnia skomplikowania jesteśmy w stanie dojść, jeżeli naprawdę się postaramy. Szaleństwo metod wyższego rzędu Naprawdę zakręcone rzeczy zaczynają się dziać, kiedy do całego zamieszania wprowadzisz typy wariantowe. Nie zamierzam wnikać tutaj głęboko w szczegóły, chcę jedynie, abyś zdał sobie sprawę z potencjalnej złożoności. Przyjrzyjmy się deklaracji czterech delegatów: delegate delegate delegate delegate

Func FuncFunc

Skeet J. - C# od podszewki. Wydanie II

ABC Linux. Wydanie II

II C J Roberts NZapach Ciemnosci

Albahari J. - C# 5.0. Leksykon kieszonkowy. Wydanie III

Android w akcji Wydanie II

Grzywacz J. - Faktoring Wydanie 2

Ullman C. - Ajax. Od podstaw

Topolski J., Od Achillesa-1

100 sposobow na sieci bezprzewodowe Wydanie II

Jonathan-Gennick-sql-leksykon-kieszonkowy-wydanie-II

Reese G. - MySQL. Leksykon kieszonkowy. Wydanie II

Agarwal M. - Metasploit. Receptury pentestera. Wydanie II

K Krysiak Sieci komputerowe Kompendium Wydanie II

Lam W. - Rysunek i malarstwo Wydanie II

Stutz M. - Linux. Najlepsze przepisy. Wydanie II

abc-sam-naprawiam-komputer-wydanie-II

Jonathan Gennick sql leksykon kieszonkowy wydanie II

Oflag II C Woldenberg

Walls C. - Spring w akcji Wydanie III

Walls C. - Spring w akcji. Wydanie IV

Sobieska J. - Polski folklor muzyczny Wydanie 3

Kredziarz C J Tudor

C J Tudor Kredziarz

Kredziarz C J Tudor

Kredziarz - C. J. Tudor

Symfonia C++ _ J. Grebosz

Kredziarz C J Tudor

Gilmore W. - PHP i MySQL. Od podstaw. Wydanie IV

Gilmore W PHP i MySQL Od podstaw Wydanie IV

Gilmore W PHP i MySQL Od podstaw Wydanie IV

G S J 03 C J

Skeet J. - C# od podszewki. Wydanie II

ABC Linux. Wydanie II

II C J Roberts NZapach Ciemnosci

Albahari J. - C# 5.0. Leksykon kieszonkowy. Wydanie III

Android w akcji Wydanie II

Grzywacz J. - Faktoring Wydanie 2

Ullman C. - Ajax. Od podstaw

Topolski J., Od Achillesa-1

100 sposobow na sieci bezprzewodowe Wydanie II

Jonathan-Gennick-sql-leksykon-kieszonkowy-wydanie-II

Reese G. - MySQL. Leksykon kieszonkowy. Wydanie II

Agarwal M. - Metasploit. Receptury pentestera. Wydanie II

K Krysiak Sieci komputerowe Kompendium Wydanie II

Lam W. - Rysunek i malarstwo Wydanie II

Stutz M. - Linux. Najlepsze przepisy. Wydanie II

abc-sam-naprawiam-komputer-wydanie-II

Jonathan Gennick sql leksykon kieszonkowy wydanie II

Oflag II C Woldenberg

Walls C. - Spring w akcji Wydanie III

Walls C. - Spring w akcji. Wydanie IV

Sobieska J. - Polski folklor muzyczny Wydanie 3

Kredziarz C J Tudor

C J Tudor Kredziarz

Kredziarz C J Tudor

Kredziarz - C. J. Tudor

Symfonia C++ _ J. Grebosz

Kredziarz C J Tudor

Gilmore W. - PHP i MySQL. Od podstaw. Wydanie IV

Gilmore W PHP i MySQL Od podstaw Wydanie IV

Gilmore W PHP i MySQL Od podstaw Wydanie IV

G S J 03 C J

Recommend Documents