Zine.net online

Witaj na Zine.net online Zaloguj się | Rejestracja | Pomoc
w Szukaj

arkadiusz.wasniewski

Refaktoryzacja metod zwrotnych

Najnowsza refaktoryzacja kodu jednego z moich projektów polegała na usunięciu wszystkich własnych definicji delegatów będących metodami zwrotnymi. Zamiast tego użyłem standardowych metod z przestrzeni nazw System:

dla metod zwrotnych, które nie zwracają wartości oraz:

dla metod zwrotnych zwracających wartość.

Dzięki temu zniknęło kilka klas. A sam kod wbrew pozorom stał się bardziej przejrzysty przez to, iż nie trzeba zastanawiać się jak wygląda metoda WorkflowTerminateCallback jeśli teraz w kodzie występuje wywołanie metody Action. Wbrew pozorom, ponieważ nazwa metody WorkflowTerminateCallback jest bardziej wymowna od metody Action i niepokoiło mnie, czy przypadkiem źródła nie staną się mniej przejrzyste. Kod żyje jednak w pewnym kontekście i po wprowadzeniu zmian okazało się, iż moje obawy były bezzasadne.

Opublikowane 20 lipca 2008 00:57 przez arkadiusz.wasniewski

Komentarze:

 

rod said:

Bardzo dobry pomysł. Sam kiedyś robiłem własne delegaty a ostatnio zaprzestałem tego procederu na rzecz wymienionych przez Ciebie systemowych delegatów.

Pomimo ze Action i Funct wyczerpują swobodnie pulę to nadmienię że są jeszcze takie jak

bool Predicate <T> = bool Func<T, bool>

TOutput Converter<TInput,TOutput> = TOutput Func<TInput, TOutput, TOutput>

int Comparison<T> = int Func<T, int>

Stosuje je po to aby bez dokumentacji zwrócić uwagę drugiemu programiście z zespołu do czego ona jest np. Predicate  zazwyczaj ma byc rodzajem filtra, podobnie jak w  metodach Find obiektu List.

lipca 20, 2008 11:33
 

jakubin said:

Też ostatnio zacząłem stosować głównie "wbudowane" delegaty zamiast własnych. Wbrew pozorom napisanie jednej linijki z definicją delegatu zajmuje chwilkę czasu, zwłaszcza, jak do napisania jest ich sporo.

Na razie widzę tylko jeden problem - nie związany z brakiem nazwy metody. Delegat:

Func<bool,int,int,string>

absolutnie nic nie mówi, o tym, do czego służą poszczególne parametry. Własny delegat ma tu taką przewagę, że parametry są nazwane.

lipca 20, 2008 11:56
 

arkadiusz.wasniewski said:

@rod - jak ktoś ma zaimplementowany wzorzec Specification to Predicate<T> staje się metodą tego wzorca ;-)

@jakubin - jeśli chodzi o nazwane parametry to zgadzam się. Ale przyznaję, iż jak dotąd nie wychodzę poza metody zwrotne z jednym parametrem. Jak mam więcej to zazwyczaj tworzę już klasę zbierającą parametry

lipca 21, 2008 10:47
 

Wojciech Gebczyk said:

Przy okazji wychodzi inny problem z .NET Frameworkiem. A mianowiecie brak wbudowanych gotowcow dla typowych operacji wykonywanych wewnatrz bibliotek/app a nie wystawianych jako API, ktore musi byc czyste i zrozumiale. Te sytuacje to:

- delegaty - o czym pisaliscie wyzej

- typowane pojemniki na wartosci (cos jak anonymous, ale widoczne internalowo)

- "ulepszpne" asserty (najlepiej z API podobnym do ktoregoz z frameworkowo unit testowych) z gotowymi metodami dla null, kolekcji, string, etc

Za kazdym razem jak pisze jakis projekt gdzie jest wiecej niz 30 klas, to konczy sie kopiowaniem z innego projektu paru plikow z potrzebnymi typami.

lipca 21, 2008 11:54
 

arkadiusz.wasniewski said:

Jeśli chodzi o Assert to faktycznie funkcjonalność uboga jest. NUnit powinni zaimportować.

A mógłbyś  rozwinąć temat typowanych pojemników?

lipca 21, 2008 12:32
 

Wojciech Gebczyk said:

:-) Nic szczegolnego - chyba sie zle wyrazilem. Poprostu czasami potrzebne sa takie typy-pojemniki aby przechowac na przyklad nazwe, id i jakis obiekt razem (listy, dictionary, etc) gdzies wewnatrz implenetnacji klasy nie widoczne na zwenatrz.

Poprostu mam wytworzone takie proste klasy typu "Entry<T1, T2>", "Entry<T1, T2, T3>", "Entry<T1, T2, T3, T4>", etc postaci:

public sealed class Entry<T1,T2> {

   public readonly T1 Value1;

   public readonly T2 Value2;

   public Entry() {}

   public Entry(T1 value1, T2 value2) {

       Value1 = value1;

       Value2 = value2;

   }

... etc

Dla mnie czesto uzyteczne ale oczywiscie nie jako API "zewnetrzne". Czasami ewoluuja do typow z odpowiednia nazwa.

lipca 21, 2008 13:57
 

arkadiusz.wasniewski said:

Anonymous Types - częściowo pewnie niektóre problemy rozwiąże.

lipca 21, 2008 14:21
 

Wojciech Gebczyk said:

nide do konca jako ze typ sam z siebie nie jest widziany poza cialem metody (?)

ale cos  wtym rodzaju :-)

lipca 21, 2008 15:48
 

Ww.CodeSculptor said:

Od chwili pojawienia się DSL Tools dla Visual Studio, dostępne były szablony tekstowe T4. Pisał o nich

lipca 21, 2008 22:42
 

Bysza said:

Jedyna niemiła rzecz to wsparcie dla nowych deklaracji delegatów dopiero w wersji .net 3.5.

W 2.0 jest tylko jeden, czyli Nazwa<T>.

Ale wystarczy je sobie szybciutko zadeklarować i są ;)

lipca 22, 2008 12:10
Komentarze anonimowe wyłączone
W oparciu o Community Server (Personal Edition), Telligent Systems