Jak poradzić sobie z przeciążeniami metod, gdy argumenty są tego samego typu, ale pobierają inną informację

Odpowiedz Nowy wątek
2019-07-08 17:14
0

Witam,

chciałem się dowiedzieć jak najlepiej rozwiązać taki dylemat.

Mamy taką przykładową metodę:


public MyItem GetSomething(int uniqueID, int page = 1, int pageSize = 10) {
// Zrób coś
return myItem;
}
public MyItem GetSomething(int commonID, int page = 1, int pageSize = 10) {
// Zrób coś podobnego
return myItem;
}

Zastosowanie przeciążenia w tym wypadku z takimi samymi typami argumentów nie jest możliwe, ale zastosowanie dwóch metod o różnych nazwach z kolei jest nieestetyczne, bo metoda zwraca coś z API, którego struktura ma jedną metodę, a ta może pobrać oba argumenty.

W tym wypadku dokładnie odzwierciedlająca strukturę API metoda miałaby taki wygląd:

public MyItem GetSomething(in uniqueID, int commonID, int page = 1, int pageSize = 10) {
// Zrób coś podobnego
return myItem;
}

Niby spoko, ale wymusza to na użytkowniku podanie obu parametrów, gdzie priorytet ma commonID i to na jego podstawie wyświetli się wynik. O ile API nie potrzebuje obu, o tyle metoda w C# już w tym wypadku tak.

Kolejna opcja jaka przyszła mi do głowy:

public MyItem GetSomething(int? uniqueID, int? commonID = null, int page = 1, int pageSize = 10) {
// Zrób coś podobnego
return myItem;
}

W powyższym wypadku null zostanie pominięty, a konieczne jest podanie jednego z argumentów. Tutaj jednak z kolei możliwe jest podanie obu null, więc techniczne też może to wprowadzać błąd i co gorsza trzeba w środku to gdzieś sprawdzić.

Czy jest jakiś magiczny myk, który pozwoliłby estetyczne wymusić na użytkowniku podanie poprawnego parametru uniqueID lub commonID, koniecznie jednego z nich, ale nie pozwalał na obie wartości null? Technicznie podanie obu poprawnych wartości też z punktu widzenia konstrukcji metody API jest dopuszczalne. Jak w takiej sytuacji postępować?

edytowany 2x, ostatnio: Wojciech Dudek, 2019-07-08 17:26

Pozostało 580 znaków

2019-07-09 11:53
1

W zależności od Twoich potrzeb, może też przydać się wzorzec STRATEGIA.

Pozostało 580 znaków

2019-07-09 14:10
1

Ja chciałbym zobaczyć Twój restowy uri i co tam ma się rzeczywiście pobierać. Może problem jest na innym poziomie niż implementacja tutaj.Np jeśli chcesz mieć
GET /posts/{commonid}
GET /posts/{uniqueId}
to faktycznie kiepsko, ale pytanie czemu tego potrzebujesz? W rescie pracujesz na zasobach i jeśli masz ten specyficzny przypadek, że dany zasób ma kilka id, to najlepiej to wyjawić explicit dla klienta z czego korzysta i mieć nie tylko osobne metody ale uri np
GET /posts/title={myTitle}
GET /posts/{uniqueId}

Inaczej, możesz mieć sytuacje, ze klient nie wie z czego korzysta i może to doprowadzić to do jakiś nie ciekawych błędów. (np prosisz o zasob z common ID =1, a dostajesz z Unique ID = 1). Nie bez powodu nie da się tego łatwo zaimplementować. ANi kompilator ani runtime nie powinien próbowa zgadywać co klient danego API chce zrobić.


Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0