Dzień dobry,
mam takie pytanie. Ile metoda powinna posiadać maksymalnie parametrów aby wyglądała przyzwoicie ? Muszę wygenerować pewien obraz i teraz metoda posiada ich aż 6 (width, height, accurancy, start, end, sourceImage). Każdy z nich jest ważny. Czy rozbijać to na metody z mniejszą liczbą parametrów czy może tak być ?
Pozdrawiam
Jeśli potrzebujesz, zrób tyle. Ważne, by miało to sens i żeby metoda nie zajmowała się kilkoma operacjami jednocześnie w myśl zasady jednej odpowiedzialności. Jeżeli pojawi się w niej kilka różnych zadań, wtedy to rozbij na pośrednie. Ilością parametrów się nie przejmuj, na pewno nie sześcioma.
Metoda powinna wykonywać tylko jedną dedykowaną jej czynność oraz posiadać możliwie jak najmniej parametrów.
accurancy :D
Czemu nie zrobisz z tych parametrów jakiegoś DTO? Przecież te parametry są wyraźnie powiązane, więc logicznym jest zrobić ładną klasę immutable która będzie przechowywać te twoje ImageParameters czy co to tam masz.
Origin_ napisał(a):
Ile metoda powinna posiadać maksymalnie parametrów aby wyglądała przyzwoicie ? Muszę wygenerować pewien obraz i teraz metoda posiada ich aż 6 (width, height, accurancy, start, end, sourceImage). Każdy z nich jest ważny. Czy rozbijać to na metody z mniejszą liczbą parametrów czy może tak być ?
Jeśli możesz rozbić metodę, bo robi wiele rzeczy na raz, to ją rozbij - niezależnie od tego, ile parametrów przyjmuje. A parametry pogrupuj sensownie i opakuj w jakieś klasy.
pavon147 napisał(a):
Jeśli potrzebujesz, zrób tyle. Ważne, by miało to sens i żeby metoda nie zajmowała się kilkoma operacjami jednocześnie w myśl zasady jednej odpowiedzialności. Jeżeli pojawi się w niej kilka różnych zadań, wtedy to rozbij na pośrednie. Ilością parametrów się nie przejmuj, na pewno nie sześcioma.
A jeśli potrzebuje 50, to ma zrobić 50?!
Nie wrzucaj tego w tablice - a jak chcesz wiedzieć czemu to patrz na komentarze tego posta
A jeśli potrzebuje 50, to ma zrobić 50?!
Przecież napisałem o sześciu parametrach:
Ilością parametrów się nie przejmuj, na pewno nie sześcioma
Nie wiadomo na jaką skalę to rozwiązanie ma zaistnieć. Może nie warto w ogóle kombinować, a do jakiejś pierdoły (if any) niech ma te 6 parametrów w funkcji.
Na studiach mieliśmy taki wykład o nazwie "Perfekcyjna pani kodu", była w nim mowa o tym by metody(funkcje) miały jak najmniej parametrów(optymalnie 1-3) jeżeli twoja metoda ma ich więcej należy zmienić podejście. Rozbić na kilka metod czy klas. W javie można żonglować obiektami co ułatwia sprawę ;P
Na wykładzie była też mowa by nie używać komentarzy, nazwy klas, metod, zmiennych powinny być jasne :P
6 parametrów? Toż to samobójstwo prawie. 1-2 optimum, jak się naprawdę mocno uprze i ma porządne argumenty to maksimum 3!
Zbyt wiele argumentów wskazuje na jedną z dwóch możliwości:
Ale cytując R.C. Martina:
The ideal number of arguments for a function is zero.
xfin napisał(a):
Ale cytując R.C. Martina:
The ideal number of arguments for a function is zero.
I ma operować na stanach globalnych? :D
Też się ostatnio dużo rozwijam w tym temacie ale z lektur i wiedzy nabytej i przykładów.
Obraz potraktować jako Obiekt, opisać go klasą. W której będziesz miał odpowiednie metody z mniejszą ilością argumentów max.2 no chyba że zaczniesz pisać jakieś 3 wymiarowe obiekty albo jest to bezwzglednie konieczne.
Nie wiem dokładnie na czym polega program bo było by łatwiej. Przy podchodzeniu do jakiegoś projektu po 1 powinno się pisać obiektowo, po 2 za nim zabierzesz się za programowanie obiektowe jest etap projektowania obiektowego w który właśnie warto ustalić takie rzeczy i można nawet opisać tam metody.
width, height
accurancy
start, end
sourceImage
xfin napisał(a):
6 parametrów? Toż to samobójstwo prawie. 1-2 optimum, jak się naprawdę mocno uprze i ma porządne argumenty to maksimum 3!
- autor nie stosuj zasady "pojedynczej odpowiedzialności",
- argumenty są ze sobą bardzo powiązane (ale wtedy to lepiej napisać jakąś klasę),
(oczywiście jest też trzecia możliwość - ktoś uczy się programowania, ale skoro ładnie tutaj pyta to odpowiadam jak należy).
A ja się tutaj nie zgodzę. Jak przeglądam kod jednego projektu to większość metod się mieści w tych granicach owszem, ale są wyjątki by design. Na przykład mam interfejs który definiuję metodę Initialize i ta metoda przyjmuje 6 parametrów właśnie. Wszystkie parametry są potrzebne, a co metoda robi to zależy od poszczególnych implementacji. Czasem robi bardzo dużo wywołując inne metody danej klasy. Można by też tutaj dyskutować o zasadzie pojedynczej odpowiedzialności. Czy są z tym problemy? Nie. Żadne. Funkcjonuje to od 3 lat co najmniej i wielokrotnie były dodawane kolejne implementacje (łącznie około 30). Wywołanie natomiast cały czas jest jedno w całym projekcie.
Podsumowując - nie ma tutaj maksimum - wszystko zależy od okoliczności. Od każdej reguły znajdzie się wyjątek o ile programista ma wystarczająco dużo doświadczenia, aby kierować się zdrowym rozsądkiem.
Zadziwia mnie jak łatwo przychodzi, nam programistom, rzucanie osądów na temat dobrych praktyk programowania - zupełnie jakby człowiek już wszystko w życiu widział. Owszem są mądre książki pisane przez mądrych doświadczonych ludzi, ale one zawierają reguły właśnie - pomijają wyjątki.
To zależy co to za parametry. Posłużę się przykładami w C, bo akurat dwa skrajne przychodzą mi do głowy:
C# void gluLookAt(GLdouble eyeX, GLdouble eyeY, GLdouble eyeZ,
GLdouble centerX, GLdouble centerY, GLdouble centerZ,
GLdouble upX, GLdouble upY, GLdouble upZ);
Tu jest parametrów dziewięć, ale tak jakby były trzy: eye, center, up. Więcej pamiętać nie trzeba, kolejność x,y,z jest oczywista.
Mogłyby być trzy struktury, ale nie są, a mimo to wywołanie funkcji jest dość jasne, zwłaszcza jeśli sami sobie te struktury stworzymy:
gluLookAt(eye.x, eye.y, eye.z, center.x, center.y, center.z, 0, 1, 0);
HWND wnd = CreateWindow(MAKEINTATOM(atom), L"Ala ma kota", WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, 400, 300, NULL, NULL, hInstance, NULL);
Masakra.
HWND wnd = CreateWindow(
MAKEINTATOM(atom),
L"Ala ma kota",
WS_OVERLAPPEDWINDOW,
CW_USEDEFAULT, CW_USEDEFAULT,
400, 300,
(HWND)NULL,
(HMENU)NULL,
(HINSTANCE)hInstance,
(LPVOID)NULL
);
Już lepiej. Większość przykładów w necie ma dopisane nazwy parametrów w komentarzach.
Czy są z tym problemy? Nie. Żadne. Funkcjonuje to od 3 lat co najmniej i wielokrotnie były dodawane kolejne implementacje
To że coś działa wcale nie znaczy że jest napisane sensownie i poprawnie ;) A jak się okaże że któraś kolejna implementacja wymaga dodatkowego parametru? Albo kilku dodatkowych parametrów? To dodajecie w tej bazowej a reszta ma X nulli w tym wywołaniu? ;)
Shalom napisał(a):
- Równie dobrze mogłaby przyjmować jeden argument "InitializeParameters" i kod nagle byłby bardziej czytelny ;)
Bym się może zgodził, ale i z tymi 6 też jest ok. Wywołań metody więcej nie będzie i tworzenie specjalnego obiektu w tym przypadku byłoby nadmiarowe.
- To że coś działa wcale nie znaczy że jest napisane sensownie i poprawnie ;) A jak się okaże że któraś kolejna implementacja wymaga dodatkowego parametru? Albo kilku dodatkowych parametrów? To dodajecie w tej bazowej a reszta ma X nulli w tym wywołaniu? ;)
Żadna z nowych implementacji nie będzie wymagała dodatkowych parametrów :P. Tutaj jestem tego w 100% pewien. :)
Nie chodzi mi o to, że się nie zgadzam z tym. Zgadzam się jak najbardziej. Chodzi mi o to, że w niektórych przypadkach pisanie wszystkiego sztywno zgodnie z wszystkimi dobrymi praktykami prowadzi do zbędnego nadmiarowego kodu. Te zasady trzeba znać i rozumieć, ale też wiedzieć kiedy można je trochę nagiąć.
xfin napisał(a):
6 parametrów? Toż to samobójstwo prawie.
Bez przesady. 6 to nie 60. :)
Sarrus napisał(a):
Podsumowując - nie ma tutaj maksimum - wszystko zależy od okoliczności. Od każdej reguły znajdzie się wyjątek o ile programista ma wystarczająco dużo doświadczenia, aby kierować się zdrowym rozsądkiem.
Zgodnie z doświadczeniem i zdrowym rozsądkiem należy dążyć do tego, żeby metoda miała jeden argument wejściowy. W przyszłości łatwiej będzie dodać nowe pole w istniejącej klasie niż przerabiać 6 parametrów na klasę. To drugie wymaga znacznie więcej zmian w projekcie, a już nie daj Boże, jeśli mamy jakieś testy.
Sarrus napisał(a):
Chodzi mi o to, że w niektórych przypadkach pisanie wszystkiego sztywno zgodnie z wszystkimi dobrymi praktykami prowadzi do zbędnego nadmiarowego kodu. Te zasady trzeba znać i rozumieć, ale też wiedzieć kiedy można je trochę nagiąć.
Nie wierzę w istnienie projektów, w którym nadmiarowy kod jest powodowany przez dobre praktyki. Owszem, stosowanie wzorców i pisanie wszystkiego "ładnie" powoduje pewien narzut, ale niestosowanie wzorców, używanie kopiuj-wklej i podejście "a po co tak, przecież działa", powoduje powstawianie dużo więcej zbędnego kodu.
Taka tam ciekawostka, że niektórym 255 parametrów (limit w pythonie) nie starcza -> https://twiki.cern.ch/twiki/bin/view/CMSPublic/SWGuidePythonTips#Running_on_more_than_255_files ;)
Ostatnio mi się podoba mi się pomysł z opakowywaniem parametrów w złączenie named parameter idiom/packed parameter idiom z optionalami. Trochę więcej pisania (sądzę, że dałoby radę napisać coś generycznego i ładniejszego niż boost::parameter ; p) ale za to do funkcji przekazujemy tylko to co potrzebujemy w danej chwili, a funkcja przyjmuje jeden argument.
Oczywiście nie piszę tak w pracy ; >
Shalomstartczyendktóre cholera wie czym są. Jasne że jak autor chce latać z tymi zmiennymi a dopiero na czas samego wywołania zrobicnew ImagesParameters(...)to nie ma to sensu, ale ja zakładam że ktoś tu myśli...