Czy wystarczy, aby metody można było odróżnić tylko nazwą argumentu (a nie typem)?

Czy wystarczy, aby metody można było rozróżnić tylko według nazwy argumentu (a nie typu), czy lepiej nazwać ją bardziej jednoznacznie?

Na przykład T Find<T>(int id)vs T FindById<T>(int id).

Czy jest jakiś dobry powód, aby nazwać go bardziej jawnie (tj. Dodając ById), zamiast utrzymywać tylko nazwę argumentu?

Jednym z powodów, o których mogę myśleć, jest to, że podpisy metod są takie same, ale mają inne znaczenie.

FindByFirstName(string name) i FindByLastName(string name)

Pewnie, że istnieje dobry powód, aby nazwać to bardziej jednoznacznie.

To nie jest przede wszystkim metoda definicja , która powinna być oczywista, ale metoda wykorzystanie . I choć findById(string id)i find(string id)to zarówno oczywiste, istnieje ogromna różnica pomiędzy findById("BOB")a find("BOB"). W pierwszym przypadku wiesz, że literał losowy jest w rzeczywistości Id. W tym drugim przypadku nie jesteś pewien - może to być imię lub coś zupełnie innego.

Zalety FindById () .

1. Future pokryć : Jeśli początek Find(int), a później trzeba dodać inne metody ( FindByName(string), FindByLegacyId(int), FindByCustomerId(int), FindByOrderId(int), etc), ludzie tacy jak ja spędzają wieki szukając FindById(int). Naprawdę nie jest to problem, jeśli możesz i zmienisz Find(int)go, FindById(int)gdy stanie się to konieczne - w przyszłości sprawdzimy, czy jest to konieczne .

2. Łatwiejszy do odczytania . Findjest całkowicie w porządku, jeśli wygląda na to połączenie record = Find(customerId);Jeszcze FindByIdjest nieco łatwiejszy do odczytania, jeśli tak jest record = FindById(AFunction());.

3. Spójność . Możesz konsekwentnie stosować wzór FindByX(int)/ FindByY(int)wszędzie, ale Find(int X)/ Find(int Y)nie jest możliwe, ponieważ powodują konflikty.

Zalety Find ()

• POCAŁUNEK. Findjest prosty i jednoznaczny, a obok operator[]tego jest jedną z 2 najbardziej oczekiwanych nazw funkcji w tym kontekście. (Niektóre popularne alternatywy bycia get, lookuplub fetch, w zależności od kontekstu).
• Zasadniczo, jeśli masz nazwę funkcji, która jest pojedynczym dobrze znanym słowem, które dokładnie opisuje jej działanie, użyj jej. Nawet jeśli istnieje dłuższa nazwa składająca się z wielu słów, która jest nieco lepsza w opisywaniu działania funkcji. Przykład: Długość vs NumberOfElements . Istnieje kompromis, a gdzie wytyczyć granicę, jest przedmiotem ciągłej debaty.
• Na ogół dobrze jest unikać redundancji. Jeśli spojrzymy na to FindById(int id), możemy łatwo usunąć redundancję, zmieniając ją na Find(int id), ale istnieje kompromis - tracimy trochę przejrzystości.

Alternatywnie możesz uzyskać zalety obu , używając silnie napisanych identyfikatorów:

CustomerRecord Find(Id<Customer> id) 
// Or, depending on local coding standards
CustomerRecord Find(CustomerId id) 

Implementacja Id<>: Mocne wpisywanie wartości identyfikatora w C #

Komentarze tutaj, a także w powyższym linku, wzbudziły wiele obaw związanych z Id<Customer>tym, co chciałbym rozwiązać:

• Obawa 1: To nadużycie generyczne. CustomerIdi OrderIDsą różnymi typami ( customerId1 = customerId2;=> dobra, customerId1 = orderId1;=> zła), ale ich implementacja jest prawie identyczna, więc możemy zaimplementować je za pomocą kopiowania wklej lub metaprogramowania. Podczas gdy dyskusja na temat ujawniania lub ukrywania generyków ma wartość, o tyle metaprogramowanie jest tym, do czego służą.
• Obawa 2: Nie zatrzymuje prostych błędów. / Jest to rozwiązanie problemu . Głównym problemem, który został usunięty przy użyciu silnie wpisanych identyfikatorów ID, jest niewłaściwa kolejność argumentów w wywołaniu DoSomething(int customerId, int orderId, int productId). Silnie wpisane identyfikatory zapobiegają również innym problemom, w tym zapytaniu o OP.
• Obawa 3: Naprawdę po prostu zaciemnia kod. Trudno powiedzieć, czy identyfikator jest zatrzymany int aVariable. Łatwo jest stwierdzić, że identyfikator jest przechowywany Id<Customer> aVariable, a nawet możemy stwierdzić, że jest to identyfikator klienta.
• Obawa 4: Te identyfikatory nie są silnymi typami, są tylko opakowaniami. Stringto tylko opakowanie byte[]. Zawijanie lub enkapsulacja nie stoi w sprzeczności z silnym pisaniem na klawiaturze.
• Obawa 5: To już koniec. Oto minimalna wersja, chociaż polecam dodanie, operator==a operator!=także, jeśli nie chcesz polegać wyłącznie na Equals:

.

public struct Id<T>: {
    private readonly int _value ;
    public Id(int value) { _value = value; }
    public static explicit operator int(Id<T> id) { return id._value; }
}

Innym sposobem myślenia na ten temat jest użycie bezpieczeństwa typu języka.

Możesz zaimplementować metodę taką jak:

Find(FirstName name);

Gdzie FirstName jest prostym obiektem, który otacza ciąg zawierający imię i oznacza, że ​​nie może być pomyłki co do tego, co robi metoda, ani argumentów, z którymi jest wywoływana.

Głosuję za wyraźną deklaracją, taką jak FindByID .... Oprogramowanie powinno być tworzone na potrzeby zmian. Powinien być otwarty i zamknięty (SOLID). Tak więc klasa jest otwarta na dodanie podobnej metody find, np. FindByName .. itd.

Ale FindByID jest zamknięty, a jego implementacja jest testowana jednostkowo.

Nie będę sugerować metod z predykatami, są one dobre na poziomie ogólnym. Co zrobić, jeśli na podstawie pola (ByID) masz pełną inną metodologię.

Dziwi mnie, że nikt nie sugerował użycia predykatu, takiego jak:

User Find(Predicate<User> predicate)

Dzięki takiemu podejściu nie tylko zmniejszasz powierzchnię swojego API, ale także dajesz większą kontrolę użytkownikowi, który go używa.

Jeśli to nie wystarczy, zawsze możesz rozszerzyć go na swoje potrzeby.