Extension methods – nowe metody w starych typach
Extension methods
Extension methods – to sposób na dodanie nowych metod, rozszerzenie interfejsów, czy klas bez fizycznej ich zmiany. Metoda ta umożliwia rozszerzenie klasy lub interfejsu bez potrzeby dziedziczenia, przez co rozszerzać możemy także klasy, po których nie możemy dziedziczyć (sealed). Extension method może działać jedynie na publicznym api i nie ma dostępu do prywatnych wartości.
Rozszerzenia tego typu są tak naprawdę jedynie “lukrem składniowym” dostarczanym przez język. Extension method nie łączy się tak naprawdę z typem, który rozszerza, jest to statyczna metoda, która to przyjmuje określone parametry. I jako statycznej metody można jej użyć w momencie kiedy z dwóch różnych bibliotek mamy takie samo rozszerzenie. Przy tej samej nazwie i pracy na tym samym typie, nie sposób byłoby rozróżnić, którego rozszerzenia użyć. Wtedy to wykorzystujemy zapis jak dla normalnej metody statycznej.
Definicja własnego rozszerzenia
Definiując własne rozszerzenie postępujemy jak przy definiowaniu własnej klasy statycznej wraz ze statyczną metodą. Jedyną różnicą jest to, iż pierwszy parametr w metodzie oznaczamy słowem kluczowym “this”, dzięki czemu kompilator wie na jakim typie dane rozszerzenie ma funkcjonować. Dla przykładu rozszerzenie string-a, które sprawdza czy wszystkie znaki są liczbami.
|
1 2 3 4 5 6 7 |
public static class StringExtension { public static bool IsDigitOnly(this string input) { return input.All(c => char.IsDigit(c)); } } |
Uwagi i wskazówki
Z racji na to, iż temat jest stosunkowo prosty chciałbym tylko zwrócić uwagę na kilka aspektów związanych z użyciem extension methods. Rozszerzenia możemy zrobić na dowolnym typie danych nawet na object, co spowoduje, iż możemy go użyć na dowolnym obiekcie. W mojej opinii nie jest to najrozsądniejszy typ do rozszerzania w ten sposób. Błędnie wykorzystany taki extension może naprawdę sporo namieszać. Wykorzystujmy rozszerzenia na jak najbardziej specyficznych typach. Pozwoli nam to uniknąć głupich i zupełnie nie potrzebnych problemów. Gdyż, co nam po sprawdzeniu czy stan obiektu jest poprawny, kiedy zmienna, którą testujemy wcale takiego stanu nie posiada*.
Należy również pamiętać, iż rozszerzenie nie zostanie wykorzystane, jeśli obiekt, na którym jest wykorzystane posiada już metodę o takim samym prototypie.
*pomysł z rozszerzeniem klasy object nie był mój. Widziałem taki wspaniały kwiatek w kodzie, gdzie rozszerzenie próbowało wyciągnąć stan obiektu poprzez refleksję i zwrócić go. Przy dosyć dziwnej nazwie metody w pewnym momencie ktoś użył tego extensiona na niewłaściwej klasie powodując spektakularny crash aplikacji.