Ile parametrów jest za dużo? [Zamknięte]

228

Procedury mogą mieć parametry, to nie jest żadna wiadomość. Możesz zdefiniować tyle parametrów, ile potrzebujesz, ale zbyt wiele z nich utrudni zrozumienie i utrzymanie rutyny.

Oczywiście można zastosować zmienną strukturalną jako obejście: umieszczając wszystkie te zmienne w jednej strukturze i przekazując je do procedury. W rzeczywistości stosowanie struktur w celu uproszczenia list parametrów jest jedną z technik opisanych przez Steve'a McConnella w Code Complete . Ale jak mówi:

Ostrożni programiści unikają łączenia danych bardziej niż jest to logicznie konieczne.

Więc jeśli twoja procedura ma zbyt wiele parametrów lub używasz struktury do ukrywania dużej listy parametrów, prawdopodobnie robisz coś złego. Oznacza to, że nie utrzymujesz luźnego połączenia.

Moje pytanie brzmi: kiedy mogę uznać listę parametrów za zbyt dużą? Myślę, że ponad 5 parametrów to za dużo. Co myślisz?

Auron
źródło
1
Odwołując się tutaj do tego pytania, które jest praktycznym przykładem tego, ile parametrów jest zbyt wielu ...
Gideon
5
W JavaScript 65537 parametrów jest zbyt wiele: jsfiddle.net/vhmgLkdm
Aadit M Shah
wystarczy spojrzeć na Apache komponentów jest to prawie niemożliwe, aby zbudować coś dynamiki z niego
Andrew Scott Evans

Odpowiedzi:

162

Kiedy coś uważa się za tak nieprzyzwoite, że może być regulowane pomimo gwarancji 1. poprawki do wolności słowa? Według Justice Potter Stewart: „Wiem, kiedy to widzę”. To samo dotyczy tutaj.

Nienawidzę takich twardych i szybkich reguł, ponieważ odpowiedź zmienia się nie tylko w zależności od wielkości i zakresu twojego projektu, ale myślę, że zmienia się nawet do poziomu modułu. W zależności od tego, co robi twoja metoda lub co ma reprezentować klasa, całkiem możliwe, że 2 argumenty to za dużo i jest to objaw zbyt dużego sprzężenia.

Sugerowałbym, że zadając to pytanie i kwalifikując je tak samo jak Ty, naprawdę to wszystko wiesz. Najlepszym rozwiązaniem nie jest poleganie na twardej i szybkiej liczbie, ale zamiast tego przeglądaj projekty i recenzje kodu wśród swoich rówieśników, aby zidentyfikować obszary, w których masz niską spójność i ścisłe połączenie.

Nigdy nie bój się pokazywać swoim kolegom swojej pracy. Jeśli się boisz, to prawdopodobnie większy znak, że coś jest nie tak z twoim kodem i że już o tym wiesz .

Nick
źródło
Dobrą zasadą jest liczba rejestrów procesora, ponieważ kompilator będzie zmuszony przydzielić je do stosu.
Michaelangel007
1
@ Michaelangel007 odnośnie odpowiedzi, którą komentujesz, nie powinieneś tego mówić, ponieważ mówi, że nie ma żadnej reguły. Ponadto liczba parametrów jest kwestią czytelności, a nie wydajności.
clemp6r
1
@ clemp6r Niepoprawnie - jest to jedno i drugie . Kompilatorzy mają do czynienia z „rejestracją wycieków” przez cały czas. Tylko odpowiedź autorytatywna jest do wglądu zespół co kompilator generuje. Liczba rejestrów nie zmienia się magicznie na tej samej platformie. en.wikipedia.org/wiki/Register_allocation
Michaelangel007
124

Funkcja może mieć zbyt wiele parametrów tylko wtedy, gdy niektóre parametry są nadmiarowe. Jeśli wszystkie parametry są używane, funkcja musi mieć poprawną liczbę parametrów. Weź tę często używaną funkcję:

HWND CreateWindowEx
(
  DWORD dwExStyle,
  LPCTSTR lpClassName,
  LPCTSTR lpWindowName,
  DWORD dwStyle,
  int x,
  int y,
  int nWidth,
  int nHeight,
  HWND hWndParent,
  HMENU hMenu,
  HINSTANCE hInstance,
  LPVOID lpParam
);

To 12 parametrów (9, jeśli pakiet x, y, wih jest prostokątem), a także parametry wyprowadzone z nazwy klasy. Jak byś to zmniejszył? Czy chcesz jeszcze bardziej zmniejszyć liczbę?

Nie przejmuj się liczbą parametrów, po prostu upewnij się, że jest logiczna i dobrze udokumentowana, a Intellisense * ci pomoże.

* Inni asystenci kodowania są dostępni!

Skizz
źródło
37
Głosuję za tym. Jestem zaskoczony wszystkimi pozostałymi odpowiedziami, które mówią „3” i „4”! Prawidłowa odpowiedź to: niezbędne minimum, które czasami może być całkiem sporo.
Tony Andrews,
16
Gdyby ta funkcja została zaprojektowana dzisiaj, prawdopodobnie wyglądałaby nieco inaczej. x, y, nWidth i nHeight mogą być zawarte w obiekcie Rectangle. style i xStyle można łączyć w zbiór wyliczeń lub ciągów znaków. Teraz masz tylko 8 parametrów.
finnw
16
@finnw Jeśli ta funkcja została zaprojektowana dzisiaj? Już został przeprojektowany. Formularz f = nowy formularz (); ma 0 parametrów.
Nick
36
To jest C i winapi. Nie mogę wymyślić gorszego przykładu.
L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳
17
Nie? Nie. To jest styl proceduralny. Windows to obiekty, więc jest to teraz przestarzałe. Dzisiaj rozwiązałoby się to za pomocą klas zagregowanych, a nie wielu parametrów. Intuicyjna zasada dobrego projektu polega na tym , że jeśli nie można opisać funkcji (w tym parametrów) w jednym prostym zdaniu, jest ona źle zaprojektowana . Wierzę, że tak jest.
Jan Turoň
106

W Clean Code Robert C. Martin poświęcił temu tematowi cztery strony. Oto sedno:

Idealna liczba argumentów dla funkcji wynosi zero (niladic). Dalej jest jeden (monadyczny), a następnie dwa (dyadyczny). Tam, gdzie to możliwe, należy unikać trzech argumentów (triadycznych). Więcej niż trzy (poliady) wymagają bardzo specjalnego uzasadnienia - i tak czy inaczej nie powinny być używane.

Patrick McElhaney
źródło
2
Wątpię, aby zawierało to „to”, ponieważ jest to kontekst wykonania. W programowaniu funkcjonalnym kontekst jest globalny, a poza tym kontekstem jest obiekt, na którym stosuje się metodę. Ponadto, jeśli umieścisz „to” na liście parametrów, wówczas niemożliwe byłoby posiadanie 0 parametrów (idealne).
Tom
1
Nie, nie obejmuje „tego”.
Patrick McElhaney
20
Ponadto Martin powinien porozmawiać ze standardowym komitetem C ++. Połowa <algorytmu> zajmuje więcej niż 3 parametry, ponieważ tylko jeden zakres iteratora ma już 2. Jest to po prostu natura programowania z iteratorami (tj. Programowanie ogólne z kolekcjami STL).
Steve Jessop
3
@ SteveJessop: błąd <algorytmu> polega na tym, że zawsze działa on na plasterku. Gdyby algorytm i kolekcja miały zostać przeprojektowane, sprawiłbym, że algorytmy zawsze zajmowałyby całą kolekcję, a ty miałbyś sposób na wycięcie widoku kolekcji, aby umożliwić algorytmom działanie na częściach; alternatywnie zdefiniowałbym również skrótowe zastąpienie, aby ułatwić pracę nad wspólnym przypadkiem.
Lie Ryan
3
@LieRyan: natomiast gdybym przeprojektowywał <algorithm>, działałbym na obiekcie zasięgu. Kolekcje byłyby zakresami, ale nie wszystkie zakresy byłyby kolekcjami. I rzeczywiście, boost już to zrobił. W każdym razie, chodzi mi o to, że masowo powszechnie używane biblioteki ignoruje tę radę, więc najgorsze co jest gwarantowane , aby się z tobą, jeśli nie za to, że wiele swoich milionów użytkowników będzie majstrować przy niewielkich uproszczeń do interfejsu ;-)
Steve Jessop,
79

Niektóre kody, z którymi pracowałem w przeszłości, używały zmiennych globalnych tylko po to, aby uniknąć przekazywania zbyt wielu parametrów.

Proszę nie rób tego!

(Zazwyczaj.)

Jeffrey L. Whitledge
źródło
Trochę kodu, nad którym pracowałem nad używanymi członkami klasy, aby osiągnąć to samo. W tym czasie byłem programistą C i zapytałem, dlaczego jest tak wiele zmiennych globalnych, dlaczego wejścia / wyjścia nie mogą być wyraźnie parametrami?
user3528438,
38

Jeśli zaczniesz odliczać w myślach parametry w podpisie i dopasować je do połączenia, czas na refaktoryzację!

Rob Walker
źródło
To bardzo dobra odpowiedź. Jeśli parametry są zorganizowane logicznie (x, y, w, h), łatwo jest zapamiętać je wszystkie w odpowiedniej kolejności. Trudno jest zapamiętać, gdzie umieścić wskaźnik PLIK w putc (który ma tylko dwa parametry), zwłaszcza, że ​​fprintf jest przeciwny.
user877329
Najładniejsza odpowiedź. Bardzo dobrze powiedziane
Anwar
31

Dziękuję bardzo za wszystkie odpowiedzi:

  • To było trochę zaskakujące, aby znaleźć ludzi, którzy również myślą (tak jak ja), że 5 parametrów jest dobrym ograniczeniem dla rozsądku kodu.

  • Ogólnie rzecz biorąc, ludzie zgadzają się, że granica między 3 a 4 jest dobrą regułą. Jest to uzasadnione, ponieważ ludzie zwykle mają zły czas licząc więcej niż 4 rzeczy.

  • Jak wskazuje Milan , średnio ludzie mogą mieć w głowie mniej więcej 7 rzeczy na raz. Myślę jednak, że nie możesz zapomnieć, że projektując / utrzymując / studiując rutynę, musisz pamiętać o więcej niż tylko parametrach.

  • Niektórzy uważają, że procedura powinna zawierać tyle argumentów, ile potrzeba. Zgadzam się, ale tylko w kilku konkretnych przypadkach (wywołania interfejsów API systemu operacyjnego, procedury, w których ważna jest optymalizacja itp.). Sugeruję, aby ukryć złożoność tych procedur, dodając warstwę abstrakcji tuż nad tymi wywołaniami, gdy tylko jest to możliwe.

  • Nick ma na ten temat ciekawe przemyślenia . Jeśli nie chcesz czytać jego komentarzy, podsumowuję dla ciebie: w skrócie, to zależy :

    Nienawidzę takich twardych i szybkich reguł, ponieważ odpowiedź zmienia się nie tylko w zależności od wielkości i zakresu twojego projektu, ale myślę, że zmienia się nawet do poziomu modułu. W zależności od tego, co robi twoja metoda lub co ma reprezentować klasa, całkiem możliwe, że 2 argumenty to za dużo i jest to objaw zbyt dużego sprzężenia.

    Morał nie polega na tym, że nie obawiasz się pokazywać kodu swoim rówieśnikom, dyskutować z nimi i próbować „zidentyfikować obszary, w których masz niską spójność i ścisłe powiązanie” .

  • Wreszcie myślę, że wnoise bardzo zgadza się z Nickiem i kończy swój satyryczny wkład tą poetycką wizją sztuki programowania (patrz komentarze poniżej):

    Programowanie to nie inżynieria. Organizacja kodu jest sztuką, ponieważ zależy od czynników ludzkich, które w zbyt dużym stopniu zależą od kontekstu dla jakiejkolwiek twardej reguły.

Auron
źródło
16

Ta odpowiedź zakłada język OO. Jeśli nie używasz jednego - pomiń tę odpowiedź (innymi słowy, nie jest to odpowiedź zależna od języka.

Jeśli przekazujesz więcej niż 3 parametry (szczególnie wewnętrzne typy / obiekty), to nie jest tak, że to „Zbyt wiele”, ale możesz stracić szansę na utworzenie nowego obiektu.

Poszukaj grup parametrów, które są przekazywane do więcej niż jednej metody - nawet grupa przekazana do dwóch metod prawie gwarantuje, że powinieneś mieć tam nowy obiekt.

Następnie przekształcasz funkcjonalność w nowy obiekt i nie uwierzyłbyś, jak bardzo pomaga to zarówno Twojemu kodowi, jak i zrozumieniu programowania OO.

Bill K
źródło
Podaj nazwę języka, który nie używa procedur ani parametrów. Nie mogę wymyślić jednego, nawet montaż można uznać za mający procedury (etykiety).
Auron,
Asembler x86 zdecydowanie ma procedury (call / return). Inne mogą wymagać kombinacji cmp / jmp.
Brian Knoblauch,
Niestety „ret”, a nie „return”. Wzdycha To był już długi dzień.
Brian Knoblauch
Przepraszam za niejednoznaczne sformułowanie Aurona, myślę, że to naprawiłem. To była moja odpowiedź specyficzna dla języka, a nie pytanie.
Bill K,
1
Nie wszystkie języki pozwalają na przekazywanie struktur. Ponadto przekazanie struktury oznacza, że ​​metoda odbiorcza musi mieć kod do obsługi struktury, a zatem może potrzebować więcej parametrów. Ponadto w języku innym niż firma na ogół potrzebujesz dodatkowego parametru - wszystkie języki OO mają „ukryty” parametr „tego”, który w przeciwnym razie powinien zostać przekazany (lub, w bardziej przerażającym języku / projekcie, może być globalny dostępne)
Bill K
13

Wygląda na to, że istnieją inne względy niż zwykła liczba, oto kilka, które przychodzą na myśl:

  1. logiczna relacja do głównego celu funkcji a ustawienia jednorazowe

  2. Jeśli są to tylko flagi środowiska, tworzenie pakietów może być bardzo przydatne

John Mulder
źródło
12

Jeden z dobrze znanych epigramów programistycznych Alana Perlisa (opisany w ACM SIGPLAN Notices 17 (9), wrzesień 1982)) stwierdza, że ​​„Jeśli masz procedurę z 10 parametrami, pewnie coś przegapiłeś”.

Peter S. Housel
źródło
11

Według Steve'a McConnella w Code Complete powinieneś

Ogranicz liczbę parametrów procedury do około siedmiu

Paul Reiners
źródło
3
/: Liczba wskazująca, że ​​faktoid jest złożony: xkcd.com/899
user877329
9

Dla mnie, gdy lista przecina jeden wiersz w moim IDE, to jest o jeden parametr za dużo. Chcę zobaczyć wszystkie parametry w jednej linii bez przerywania kontaktu wzrokowego. Ale to tylko moje osobiste preferencje.

Uczenie się
źródło
Jest to dobre, dopóki z kilkoma programistami nie spróbujesz foo (int a, float b, string c, double d). Chyba najlepiej postarać się unikać współpracy z nimi. : D
Rontologist,
4
Gdyby ktoś inny nadał klasom absurdalnie długie nazwy, nie pozwoliłbym, aby wpłynęło to na sposób, w jaki definiuję lub nazywam moje procedury.
finnw
9
Czy mogę przedstawić Państwu „zwrot karetki”?
3
Gdy lista przecina jedną linię w twoim IDE, twój monitor jest zbyt mały, aby używać go z tym kodem i powinieneś wyraźnie kupić monitor o wyższej rozdzielczości poziomej. Przerwanie linii lub zmniejszenie ilości parametrów to tylko obejścia, które nie rozwiązują głównego problemu, który polega na tym, że monitor jest za mały dla tej bazy kodu!
Kaiserludi
9

Generalnie zgadzam się z 5, jednak jeśli jest sytuacja, w której potrzebuję więcej i jest to najwyraźniejszy sposób rozwiązania problemu, wtedy użyłbym więcej.

Inisheer
źródło
8

Siedem rzeczy w pamięci krótkoterminowej?

  1. Nazwa funkcji
  2. Zwraca wartość funkcji
  3. Cel funkcji
  4. Parametr 1
  5. Parametr 2
  6. Parametr 3
  7. Parametr 4
Mike Clark
źródło
Dobrze. Jest to ogólna zasada. Kiedy kodujesz ciało funkcji, nie przejmujesz się jej nazwą, a zwracana wartość i jej przeznaczenie są ściśle powiązane.
Auron,
7
8. kolejność parametrów
Eva
7

W Najgorszych 5 fragmentach kodu zaznacz drugi „Czy to konstruktor”. Ma ponad 37 ⋅ 4 ≈ 150 parametrów:

Tutaj programista napisał ten konstruktor [...] Niektórzy z was mogą myśleć, że tak, to duży konstruktor, ale użył narzędzi do automatycznego generowania kodu zaćmienia [.] NOO, w tym konstruktorze był mały błąd, który odkryłem, co sprawiło, że wyciągnij wniosek, że ten konstruktor został napisany ręcznie. (nawiasem mówiąc, jest to tylko górna część konstruktora, nie jest kompletna).

konstruktor z ponad 150 parametrami

medopal
źródło
To takie smutne ... Niewiedza o „rekordach”, „strukturach” lub „obiektach wartości”, które łączą kilka wartości razem i nadają im wspólną nazwę, dzięki czemu można hierarchicznie reprezentować wiele z nich w czytelny sposób, jest jak spacerowanie z butami bez sznurowadeł od lat, bo nikt nigdy ci nie powiedział, że możesz to zrobić 🙈
yeoman
6

Jeden więcej niż to konieczne. Nie chcę być glibem, ale jest kilka funkcji, które niekoniecznie wymagają sporo opcji. Na przykład:

void *
mmap(void *addr, size_t len, int prot, int flags, int fildes, off_t offset);

Jest 6 argumentów i każdy z nich jest niezbędny. Co więcej, nie ma wspólnego łącza między nimi, aby uzasadnić ich połączenie. Może mógłbyś zdefiniować „struct mmapargs”, ale byłoby to gorsze.

Kirk Strauser
źródło
Cóż, proti flagsmożna by go zrolować, gdyby projektant uznał, że 5 jest w pewnym sensie magiczną liczbą, która jest znacznie lepsza niż 6. Trochę jak sposób, który openłączy tryb odczytu / zapisu ze wszystkimi innymi flagami. A może i ty mógł pozbyć offsetpoprzez określenie, że odwzorowane rozpoczyna rozdział na obecnym szukać pozycji filedes. Nie wiem, czy są jakieś sytuacje, w których możesz mmapstworzyć region, do którego nie jesteś zdolny lseek, ale jeśli nie, to nie jest to absolutnie konieczne.
Steve Jessop,
... więc myślę, że mmapto dobra ilustracja tego, że niektórzy projektanci i użytkownicy wolą długą długą listę parametrów, podczas gdy inni wolą przejść kilka kroków, przygotowując mniejszą liczbę parametrów przed wykonaniem połączenia.
Steve Jessop,
1
@ Steve: Wcześniejsze ustawienie pozycji szukania za pomocą osobnego połączenia wprowadziłoby nieuzasadniony warunek wyścigu. W przypadku niektórych interfejsów API (OpenGL) istnieje tak wiele parametrów, które wpływają na wywołanie, że naprawdę musisz użyć stanu, ale normalnie każde połączenie powinno być samodzielne tak bardzo, jak to możliwe. Działanie na odległość jest ścieżką do ciemnej strony.
Ben Voigt,
5

Według najlepszych praktyk Perla , 3 jest w porządku, 4 to za dużo. To tylko wskazówka, ale w naszym sklepie staramy się tego trzymać.

Adam Bellaire
źródło
5

Sam wyznaczam limit funkcji publicznych przy 5 parametrach.

IMHO, długie listy parametrów są akceptowane tylko w prywatnych / lokalnych funkcjach pomocniczych, które mają być wywoływane tylko z kilku określonych miejsc w kodzie. W takich przypadkach może być konieczne przekazanie wielu informacji o stanie, ale czytelność nie jest tak dużym problemem, ponieważ tylko Ty (lub ktoś, kto będzie utrzymywał twój kod i powinien zrozumieć podstawy Twojego modułu), musisz się tym przejmować wywołanie tej funkcji.

Wyrko
źródło
I właśnie dlatego wiele osób w tym momencie tworzyłoby wszystko, co nie jest faktycznym argumentem, ale stanem jest, tylko stan obiektu w postaci pól (zmiennych składowych). Ten obiekt byłby reprezentowany jako klasa. Zostanie utworzona instancja raz lub dla każdego użycia. Czasami taki obiekt będzie miał tylko jeden pakiet metody prywatnej lub publicznej, który następnie deleguje pracę do metod prywatnych z kilkoma argumentami. Możliwych jest niewiele argumentów, ponieważ konfiguracja i stan mają teraz właściwe miejsce :)
yeoman
5

Powiązane pytanie, które należy rozważyć, to jak spójność rutyny. Duża liczba parametrów może być zapachem, który mówi ci, że sama procedura próbuje zrobić zbyt wiele, a zatem jej spójność jest podejrzana. Zgadzam się, że twarda i szybka liczba parametrów jest prawdopodobnie niemożliwa, ale zgaduję, że rutyna wysokiej kohezji oznaczałaby małą liczbę parametrów.

Onorio Catenacci
źródło
4

Zatrzymuję się na trzech parametrach jako ogólna zasada. Teraz już czas, aby zamiast tego przekazać tablicę parametrów lub obiekt konfiguracyjny, co pozwala również na dodawanie przyszłych parametrów bez zmiany interfejsu API.

Eran Galperin
źródło
Jeśli interfejs API ulegnie zmianie, interfejs API powinien się zmienić, a nie tylko mieć ukrytą zmianę, w której nadal może wystąpić niekompatybilność, ale być mniej oczywistym.
wnoise
jeśli jednak potrzebujesz jeszcze jednego parametru do skonfigurowania przypadku krawędzi, nie powinien on propagować się do niepowiązanych komponentów przy użyciu interfejsu API
Eran Galperin,
4

Ograniczenie długości na liście parametrów to tylko jedno ograniczenie. A ograniczenie oznacza stosowaną przemoc. Brzmi zabawnie, ale możesz być bez przemocy, nawet podczas programowania. Niech kod dyktuje reguły. Oczywiste jest, że jeśli masz wiele parametrów, treść metody funkcja / klasa będzie wystarczająco duża, aby z nich skorzystać. Fragmenty dużego kodu zwykle można ponownie przetworzyć i podzielić na mniejsze fragmenty. Otrzymujesz więc rozwiązanie zapobiegające posiadaniu wielu parametrów jako darmowego bonusu, ponieważ są one podzielone na mniejsze, zrekonstruowane fragmenty kodu.

Anonimowy
źródło
4

Z perspektywy wydajności chciałbym zwrócić uwagę na to, że w zależności od tego, jak przekazujesz parametry do metody, przekazywanie wielu parametrów według wartości spowolni program, ponieważ każdy parametr musi zostać skopiowany, a następnie umieszczony na stosie.

Zastosowanie jednej klasy do objęcia wszystkich parametrów działałoby lepiej, ponieważ pojedynczy parametr przekazywany przez referencję byłby elegancki, czystszy i szybszy!

Dominic Zukiewicz
źródło
Daję tej odpowiedzi +1, ponieważ jest to jedyna, która omawia wszystko oprócz czystości kodu lub arbitralnych limitów, które są zarówno subiektywne. Niektórzy ludzie mogą nie myśleć o tym, co robisz ze stosem, gdy jesteś w pętli i wypychasz dziesiątki argumentów na stosie i poza nim. Jeśli jest w pętli, powinieneś rozważyć użycie liczby argumentów przekazanych przez REJESTRY w ABI, dla którego kompilujesz. Na przykład w MS x64 ABI maksymalna liczba argumentów przekazywanych przez rejestry wynosi 4. ABI „System V” (używany w systemach operacyjnych innych niż Windows) korzysta z większej liczby rejestrów, więc użycie 4 argumentów jest dość przenośne
Lakey
3

Według mnie mogą zdarzyć się przypadki, w których przekroczysz 4 lub jakiś ustalony numer. Rzeczy, na które trzeba uważać

  1. Twoja metoda robi zbyt wiele i musisz ją zrefaktować.
  2. Możesz rozważyć użycie kolekcji lub jakiejś struktury danych.
  3. Zastanów się nad projektem klasy, być może niektóre rzeczy nie muszą być przekazywane.

Z punktu widzenia łatwości użycia lub łatwości czytania kodu, myślę, że kiedy trzeba trochę „zawinąć słowo” swój podpis metody, powinno to sprawić, że przestaniesz i pomyślisz, chyba że czujesz się bezradny, a wszelkie wysiłki zmierzające do zmniejszenia podpisu prowadzą do brak wyników. Niektóre bardzo dobre biblioteki w przeszłości i obecnie używają ponad 4-5 wózków dziecięcych.

Perpetualcoder
źródło
3

Moją ogólną zasadą jest to, że muszę być w stanie zapamiętać parametry wystarczająco długo, aby spojrzeć na połączenie i powiedzieć, co robi. Więc jeśli nie mogę spojrzeć na metodę, a następnie przejść do wywołania metody i zapamiętać, który parametr robi to, co jest za dużo.

Dla mnie to równa się około 5, ale nie jestem taki bystry. Twój przebieg może się różnić.

Możesz utworzyć obiekt z właściwościami do przechowywania parametrów i przekazania go, jeśli przekroczysz ustawiony limit. Zobacz książkę refaktoryzacji Martina Fowlera i rozdział dotyczący uproszczenia wywołań metod.

Mike Two
źródło
1

Zależy to w dużej mierze od środowiska, w którym pracujesz. Weźmy na przykład javascript. W javascript najlepszym sposobem na przekazanie parametrów jest użycie obiektów z parami klucz / wartość, co w praktyce oznacza, że ​​masz tylko jeden parametr. W innych systemach słaby punkt będzie miał trzy lub cztery.

Ostatecznie wszystko sprowadza się do osobistego gustu.

Joeri Sebrechts
źródło
1

Zgadzam się z 3 jest w porządku, 4 to zbyt wiele jako wskazówka. Przy więcej niż 3 parametrach nieuchronnie wykonujesz więcej niż jedno zadanie. Więcej niż jedno zadanie należy podzielić na osobne metody.

Jednak gdybym spojrzał na najnowszy projekt, nad którym pracowałem, byłyby wyjątki i większość przypadków trudno byłoby sprowadzić do 3 parametrów.

kae
źródło
1

Jeśli mam 7-10 parametrów w jednej procedurze, patrzę na łączenie ich w nową klasę, ale nie, jeśli klasa ta byłaby niczym innym jak zbiorem pól z modułami pobierającymi i ustawiającymi - nowa klasa musi robić coś innego niż tasowanie wartości w i na zewnątrz. W przeciwnym razie wolę pogodzić się z długą listą parametrów.

finnw
źródło
1
Spakuję go z klasą tylko danych, jeśli jest używana w więcej niż jednym miejscu, ale nawet wtedy zwykle tworzę oba konstruktory.
Leahn Novash
1

Jest to znany fakt, że średnio ludzie mogą przechowywać 7 +/- 2 rzeczy na raz. Lubię używać tej zasady z parametrami. Zakładając, że wszyscy programiści są ponadprzeciętnymi inteligentnymi ludźmi, powiedziałbym, że wszystko 10+ to za dużo.

BTW, jeśli parametry są w jakikolwiek sposób podobne, umieściłbym je w wektorze lub liście zamiast w struct lub klasie.

Milan Babuškov
źródło
1

Oparłbym swoją odpowiedź na częstotliwości wywoływania tej funkcji.

Jeśli jest to funkcja inicjująca, która jest wywoływana tylko raz, niech bierze 10 parmsów lub więcej, kogo to obchodzi.

Jeśli nazywa się to kilka razy na klatkę, to zwykle tworzę strukturę i po prostu przekazuję do niej wskaźnik, ponieważ zwykle jest to szybsze (zakładając, że za każdym razem nie przebudowujesz struktury).

KPexEA
źródło