Techniki minimalizowania liczby argumentów funkcji

W czystym kodzie napisano, że „idealna liczba argumentów dla funkcji wynosi zero”. Powody, dla których zostały wyjaśnione i mają sens. Poszukuję technik refaktoryzacji metod z 4 lub więcej argumentami, aby rozwiązać ten problem.

Jednym ze sposobów jest wyodrębnienie argumentów do nowej klasy, ale z pewnością doprowadziłoby to do eksplozji klas? Czy te klasy prawdopodobnie kończą się nazwami, które naruszają niektóre reguły nazewnictwa (kończące się na „Dane” lub „Informacje” itp.)?

Inną techniką jest przekształcenie zmiennych używanych przez wiele funkcji w zmienne prywatne, aby uniknąć ich przekazania, ale rozszerza to zakres zmiennej, być może tak, że jest ona otwarta na funkcje, które w rzeczywistości jej nie potrzebują.

Po prostu szukam sposobów na zminimalizowanie argumentów funkcji, po zaakceptowaniu powodów, dla których warto to zrobić.

Najważniejszą rzeczą do zapamiętania jest to, że są to wytyczne, a nie zasady.

Są przypadki, w których metoda musi po prostu wziąć argument. Pomyśl +na przykład o metodzie liczb. Lub addmetoda kolekcji.

W rzeczywistości można nawet argumentować, że to, co oznacza dodanie dwóch liczb, zależy od kontekstu, np. W ℤ 3 + 3 == 6, ale w ℤ _{| 5} 3 + 3 == 2 , więc tak naprawdę operator dodawania powinien być metodą na obiekcie kontekstu, który przyjmuje dwa argumenty zamiast metoda na liczbach, która przyjmuje jeden argument.

Podobnie metoda porównywania dwóch obiektów musi być albo metodą jednego obiektu przyjmującego drugi jako argument, albo metodą kontekstu przyjmującą dwa obiekty jako argumenty, więc po prostu nie ma sensu mieć metody porównawczej z mniej niż jeden argument.

To powiedziawszy, istnieje kilka rzeczy, które można zrobić, aby zmniejszyć liczbę argumentów dla metody:

• Zmniejsz samą metodę : może, jeśli metoda wymaga tak wielu argumentów, robi zbyt wiele?
• Brakująca abstrakcja : jeśli argumenty są ściśle ze sobą powiązane, może należą do siebie i brakuje Ci abstrakcji? (Przykład kanonicznej książki tekstowej: zamiast dwóch współrzędnych podaj Pointobiekt lub zamiast nazwy użytkownika i adresu e-mail podaj IdCardobiekt.)
• Stan obiektu : jeśli argument jest potrzebny na wiele sposobów, być może powinien on być częścią stanu obiektu. Jeśli jest to potrzebne tylko przez niektóre metody, ale nie przez inne, być może obiekt robi za dużo i powinien być naprawdę dwoma obiektami.

Jednym ze sposobów jest wyodrębnienie argumentów do nowej klasy, ale z pewnością doprowadziłoby to do eksplozji klas?

Jeśli twój model domeny ma wiele różnych rodzajów rzeczy, wtedy twój kod skończy z wieloma różnymi rodzajami obiektów. Nie ma w tym nic złego.

Czy te klasy prawdopodobnie kończą się nazwami, które naruszają niektóre reguły nazewnictwa (kończące się na „Dane” lub „Informacje” itp.)?

Jeśli nie możesz znaleźć właściwej nazwy, być może zgrupowałeś za dużo argumentów lub za mało. Więc albo masz tylko fragment klasy, albo masz więcej niż jedną klasę.

Inną techniką jest przekształcenie zmiennych używanych przez wiele funkcji w zmienne prywatne, aby uniknąć ich przekazania, ale rozszerza to zakres zmiennej, być może tak, że jest ona otwarta na funkcje, które w rzeczywistości jej nie potrzebują.

Jeśli masz grupę metod, z których wszystkie działają na tych samych argumentach, i inną grupę metod, które nie, być może należą one do różnych klas.

Zauważ, jak często używałem słowa „może”? Dlatego są to wytyczne, a nie zasady. Może Twoja metoda z 4 parametrami jest w porządku!

Zauważ, że zero argumentów nie oznacza skutków ubocznych, ponieważ twój obiekt jest niejawnym argumentem. Zobacz , na przykład, ile metod zerowej arity ma niezmienna lista Scali .

Jedną przydatną technikę nazywam techniką „ogniskowania obiektywu”. Po ustawieniu ostrości obiektywu aparatu łatwiej jest zobaczyć prawdziwy punkt ostrości, jeśli przesuniesz go za daleko, a następnie cofniesz do właściwego punktu. To samo dotyczy refaktoryzacji oprogramowania.

Zwłaszcza jeśli używasz rozproszonej kontroli wersji, zmiany oprogramowania są łatwe do eksperymentowania, sprawdź, czy podoba ci się ich wygląd, i wycofaj się, jeśli nie, ale z jakiegoś powodu ludzie często niechętnie to robią.

W kontekście twojego obecnego pytania oznacza to napisanie wersji zerowej lub jednej argumentacji, z kilkoma funkcjami najpierw rozdzielnymi, wtedy stosunkowo łatwo jest zobaczyć, które funkcje wymagają połączenia w celu zapewnienia czytelności.

Zauważ, że autor jest również wielkim zwolennikiem rozwoju opartego na testach, który na początku produkuje funkcje o niskiej wydajności, ponieważ zaczynasz od trywialnych przypadków testowych.

Podejście, które po prostu (i naiwnie - a nawet powinienem powiedzieć ślepo ) ma na celu ograniczenie liczby argumentów do funkcji, jest prawdopodobnie błędne. Nie ma absolutnie nic złego w funkcjach z dużą liczbą argumentów. Jeśli są one wymagane przez logikę, no cóż, są one wymagane ... Długa lista parametrów wcale mnie nie martwi - pod warunkiem, że jest odpowiednio sformatowana i skomentowana dla czytelności.

W przypadku, gdy wszystkie lub podzbiór argumentów należą do jednego unikalnego logicznego bytu i są zwykle przekazywane w grupach w całym programie, może być sensowne pogrupowanie ich w jakiś kontener - zazwyczaj obiekt strukturalny lub inny. Typowymi przykładami mogą być typy danych wiadomości lub zdarzeń .

Możesz łatwo przesadzić z tym podejściem - gdy okaże się, że pakowanie i rozpakowywanie rzeczy do iz takich pojemników transportowych generuje więcej kosztów ogólnych niż poprawia czytelność, prawdopodobnie posunąłeś się za daleko.

OTOH, duże listy parametrów mogą być znakiem, że twój program może nie mieć odpowiedniej struktury - być może funkcja, która wymaga tak dużej liczby parametrów, po prostu próbuje zrobić zbyt wiele i powinna zostać podzielona na kilka mniejszych funkcji. Wolę zacząć od martwienia się o # parametrów.

Nie ma magicznego sposobu: musisz opanować domenę problemów, aby odkryć odpowiednią architekturę. To jedyny sposób na refaktoryzację: opanowanie domeny problemu. Więcej niż cztery parametry to tylko pewność, że twoja obecna architektura jest wadliwa i zła.

Jedynymi wyjątkami są kompilatory (metaprogramy) i symulacje, w których teoretycznie limit wynosi 8, ale prawdopodobnie tylko 5.