Witam,
mam troszkę nietypowy problem. Otóż mój kolega, podczas pisania nadużywa parametrów out.
Najczęściej jego metody wyglądaj dla przykładu tak:
bool GetUsers(out List<User> users, out string message)
Jest to taki człowiek, który musi usłyszeć parę argumentów, zanim zmieni zdanie. Mi już niestety się skończyły :( Proszę, podajcie mi powody, dla których Waszym zdaniem takie rozwiązanie jest złe.</cpp>
a dlaczego wg Ciebie jest złe?? Bo o ile przy message bez out to po prostu nie zadziała to przy users może być a może go nie być. Dodatkowo patrząc na taką metodę wiesz dokładnie co należy podać a co dostajesz
Chodzi o to że twój kolega do każdego parametru w każdej funkcji dodaje out?
Nie. Chodzi mi o to, że dla przykładu pobranie użytkowników z bazy danych, powinno moim zdaniem wyglądać tak:
IEnumerable<User> GetUsers();
I w przypadku jakichkolwiek komplikacji, metoda powinna rzucać exception, który następnie będzie łapany w warstwie prezentacji i na jego podstawie zostanie wyświetlona informacja o błędzie.
Natomiast jego metody są napisane w sposób jaki przedstawiłem w 1 poście. Gdzie jeżeli wszystko wykona się pomyślnie, zwracana jest wartość true, jeżeli nie, zwracana wartość false i w parametrze message, jakaś informacja dotycząca błędu. Nie wyrzuca żadnego wyjątku, wszystko jest "załatwiane" wewnątrz metody.
</cpp>na pewno styl twojego kolegi jest niestandardowy, jednak czy zaraz bledny, hmmm...
przypomina mi troche zabawe z posixem, czy genralnie unix/linux gdzie sprawdzalo sie zawsze czy fukncja zwrocila 0/1 bo inaczej pan odcinal punkty na laborkach :D
uzycie out czasem sie przydaje, zeby zwrocic kilka wartosci i nie musiec tworzyc sztucznej klasy za pomoca ktorej sie to zrobi
inna sprawa ze w podanym przykladzie logicznie byloby ze GetUsers zwroci liste uzytkownikow jesli wszystko poszlo ok, a null lub pusta liste jesli wystapily jakies problemy
zakladam ze message jest do zwracania bledow, pytanie czy nie moznaby rzucic jakiegos biznesowego wyjatku, ale to juz zalezy od architektury aplicakacji, za duzo exceptionow tez zle ;]
z drugiej strony jesli metoda nalezy juz do jakiejs wyzszej warstwy abstrakcji, to moze jednak warto miec jakis zunifikowany model zwracania przez nia danych i zrobienie specjalnej klasy bazowej, ktora zwracaja wszystkie metody tej warstwy nie jest zlym pomyslem
kolejna sprawa, jesli jedna funkcja za pomoca out zwraca zbyt duzo elementow, to znaczy ze byc moze nie jest dobrze zaprojketowana, bo idea jest aby enkapsulowac dane/zachowanie i tworzyc obiekty/metody wyspecjalizowane, ktore dobrze wykonuja jedna rzecz, wiec w przypadku metody, ktora duzo danych zwraca przez out, moze wartoby ja rozczlonkowac na kilka mniejszych
rozumiem ze aby zawsze zwracac bool, ajakies informacje w message, musi miesz try-catch w kazdej metodzie
osobliwe. dlaczego?
bo w ten sposob lapiac wszystkie wyjatki inne warstwy przestaja miec o nich szczegolowe informacje, chyba ze jako message zwraca exception.ToString() a nie tylko Message exceptiona, to byloby glupie
ale wracajac do lapania wszystkich wyjatkow, jesli takze zapisuje je do np. trace (czy ma jakis inny model logowania), to jeszcze pol biedy, ale jesli nie, to jest to dobry argument za tym aby zmienil podejscie, bo jesli cos przestaje dzialac, to w tej sytuacji przestajesz wiedziec czemu, bo dostaniesz z metody false i jakis komunikat, np. ze jakis obiekt jest null, ale jaki? to juz zagadka
Misiak69 napisał(a)
Nie. Chodzi mi o to, że dla przykładu pobranie użytkowników z bazy danych, powinno moim zdaniem wyglądać tak:
IEnumerable<User> GetUsers();
I w przypadku jakichkolwiek komplikacji, metoda powinna rzucać exception, który następnie będzie łapany w warstwie prezentacji i na jego podstawie zostanie wyświetlona informacja o błędzie.
Natomiast jego metody są napisane w sposób jaki przedstawiłem w 1 poście. Gdzie jeżeli wszystko wykona się pomyślnie, zwracana jest wartość true, jeżeli nie, zwracana wartość false i w parametrze message, jakaś informacja dotycząca błędu. Nie wyrzuca żadnego wyjątku, wszystko jest "załatwiane" wewnątrz metody.
no ale to się ma nijak do tego co napisałeś w pierwszym poście! Generalnie z tym co teraz napisałeś w pełni się zgadzam - po co sobie utrudniać życie. Był błąd to exception i tyle. Ma to tę niezaprzeczalną zaletę, że dla większości języków są mechanizmy, które potrafią automatycznie logować wszystkie exceptiony np. do pliku. A to jest pomocne przy "debugowaniu na odległość".
Jakie argumenty przeciw - przede wszystkim jeśli tworzycie w zespole to musi się podporządkować ze stylem kodowania większości. Poza tym musisz mieć dodatkowe zmienne, które przekazujesz do metody.
Przecież to nie ma związku z programowaniem obiektowym. :|
Somekind, nie rozumiem o co Ci chodzi :)
Pewnie kolega do każdego błędu daje out string, zamiast po prostu samodzielnie wyrzucić wyjątek .. głupota
Nie. Chodzi mi o to, że dla przykładu pobranie użytkowników z bazy danych, powinno moim zdaniem wyglądać tak:
IEnumerable<User> GetUsers();
Czy oby na pewno? .. Trzymać otwarte połączenie z bazą, podczas gdy ktoś kto wywołał tą metodą operuje na LINQu i robi różne rzeczy pomiędzy kolejnymi yield'ami ;-)
A niech przyjdzie przerobić takie klasy z metodami pełnych out-ów na inny język, gdzie tego nie ma ;P
No to wstawi sie wskaznik wielkie mi co. Zreszta, czy przy pisaniu kodu nalezy zwaracac uwage zeby bylo to latwo przerobic na inny jezyk? Chyba nie
zależy, u mnie przykładowo czesto przerabia się java/c# i koledzy też często jęczą na te outy.
nie uważasz że "nadużywanie" outów to troche lenistwo lub błąd w projektowaniu?
Znalazłem wypowiedzi innych osób na ten temat :) Na StackOverflow oraz na MSDN.
Ogólnie rzecz biorąc, ja osobiście nie spotkałem się wcześniej z podejściem jakie prezentuje mój kolega i może po prostu z tego wynika moje zdziwienie :).
Misiak69 napisał(a)
Somekind, nie rozumiem o co Ci chodzi :)
Pisze tak, jakby pisał w (proceduralnym a nie obiektowym) C - tam to pewno dobre rozwiązanie. Nie korzysta z wbudowanego mechanizmu wyjątków (toć przecież pokolenia programistów marzyły o czymś takim, w końcu jest to jedna z zalet nowoczesnych języków). Na dodatek pisze w znanej tylko sobie konwencji, co jest bez sensu w pracy grupowej.
To nie jest programowanie obiektowe.
Zapytaj czemu jeszcze tego bool'a nie wyciąga przez out.
Generalnie powinno się unikać stosowania 'out' wszędzie tam gdzie to możliwe.
http://msdn.microsoft.com/en-us/library/ms182131(VS.80).aspx
http://stackoverflow.com/questions/413218/best-practice-of-using-the-out-keyword-in-c
only use out when really needed in interop type scenarios. In all other cases, simply do not use out.
Cos takiego to było dobre w C. Nie ma mechanizmu wyjątków, więc jakoś trzeba było zasygnalizować występienie błędu. Nadużywanie tego w C# nie uważam za dobrą praktykę.
W ogóle najlepiej, jakby w całym programie była jedna metoda o takiej sygnaturze:
void DoEverythingAndReturnBool(out bool operationSuccess, params object[] somethingOrSomethingElse)
Która w środku sprawdzi sobie w switchu parametry i zrobi co ma zrobić.
Generalnie nawyk z c i (w konsekwencji) c++. Sam ostatnio poprawialem kod w celu zgodnosci z FxCopem po kims, kto przyszedl z c++. Znam tez kilka osob pracujacych w branzy pare lat, dla ktorych wyjatki sa upierdliwe i konczy sie pozniej na catch(Exception){} Tylko lapy poucinac...