Jeśli zmienisz nazwę metody, nie będzie ona już przeciążona. Samo przeciążenie niekoniecznie powoduje, że kod jest mniej czytelny, jednak może utrudnić wykonanie implementacji, jeśli składnia nie jest jasna.
Wiele języków używa przeciążania metod jako sposobu prezentacji interfejsu dla funkcjonalności, w której parametry mogą być opcjonalne i sugerowane są domyślne parametry opcjonalne. Jest to szczególnie prawdziwe w przypadku języków, które nie obsługują domyślnej składni parametrów w deklaracji metody.
Robiąc to:
void MyMethod(int param1, int param2 = 10)
{
...
}
ratuje cię przed zrobieniem tego:
void MyMethod(int param1)
{
MyMethod(param1, Param2Default);
}
void MyMethod(int param1, int param2)
{
....
}
Co jest bardziej czytelne, to naprawdę sprowadza się do ciebie. Osobiście wolę drugą opcję, szczególnie gdy lista parametrów staje się trochę długa, ale przypuszczam, że to nie ma znaczenia, o ile jesteś konsekwentny w całym interfejsie API.
Trudność z przeciążeniem pojawia się, gdy chcesz, aby funkcje, które wykonują zasadniczo to samo, i gdzie chcesz, aby listy parametrów były takie same, ale typy zwracane były różne. Większość języków nie wie, jak rozróżnić dwie metody o tej samej nazwie, ale z różnymi typami zwrotów. W tym momencie musisz pomyśleć o użyciu ogólnych, zmianie interfejsu parametrów lub zmianie nazwy jednej z metod, aby wskazać różnicę w typie zwrotu. Tutaj czytelność może stać się dużym problemem, jeśli nie zdecydujesz się na prosty i przejrzysty schemat nazewnictwa, aby poradzić sobie z takimi sytuacjami.
Nazywanie przeciążonych metod GetSomething()i GetSomethingEx()nie będzie dużo mówić o różnicach między metodami, szczególnie jeśli to typy zwracane są jedynymi różnicami między nimi. Z drugiej strony, GetSomethingAsInt()i GetSomethingAsString()powiem ci trochę więcej o tym, co robią metody, i chociaż nie jest to przeciążenie, wskazuj, że obie metody robią podobne rzeczy, ale zwracają różne typy wartości. Wiem, że istnieją inne sposoby nazywania metod, jednak w celu zilustrowania tego, te prymitywne przykłady powinny zrobić.
W przykładzie OP zmiana nazwy nie jest absolutnie niezbędna, ponieważ parametry metody są różne, ale to sprawia, że określenie nazwy metody jest nieco bardziej precyzyjne. Ostatecznie sprowadza się to do rodzaju interfejsu, który chcesz przedstawić użytkownikom. Decyzja, czy nie przeciążać, nie powinna być podejmowana wyłącznie na podstawie własnego postrzegania czytelności. Przeciążenie metod może na przykład uprościć interfejs API i zmniejszyć liczbę metod, które deweloper może potrzebować pamiętać, z drugiej strony może zaciemnić interfejs w stopniu, który następnie wymaga od programisty przeczytania dokumentacji metody, aby zrozumieć, która forma metody do użycia, podczas gdy posiadanie wielu podobnie, ale opisowo nazwanych metod może sprawić, że bardziej oczywiste będzie po prostu czytanie nazwy metody co do jej celu.