Reguły dotyczące konkretności typów parametrów metody, typów zwracanych i typów właściwości

Jakiś czas temu przeczytałem rodzaj „ogólnej zasady” na temat konkretności typów parametrów metody, typów zwracanych i typów właściwości, ale po prostu tego nie pamiętam.

Mówiło coś o tym, aby typy zwracane były jak najbardziej konkretne, a typy parametrów jak najbardziej abstrakcyjne ... lub odwrotnie.

Nie wiem, czy tak naprawdę była to dobra czy zła rada, więc jeśli masz własne przemyślenia, proszę o komentarz.

Twoje zdrowie.

Nie wymagaj więcej, obiecaj nie mniej.

Wyrażenie pochodzi od pomysłów „Design by Contract”, zapoczątkowanych przez Bertranda Meyera.

http://wiki3.cosc.canterbury.ac.nz/index.php/Design_by_contract

Zobacz także „zasadę podstawienia Liskowa”

/programming/56860/what-is-the-liskov-substitution-principle

Posiadanie abstrakcyjnych danych wejściowych i konkretnych wyników czyni twoją funkcję bardziej ogólną. Oznacza to, że można go używać na więcej sposobów. Z drugiej strony nakłada to silniejsze ograniczenia na twoją metodę, ograniczając jej przyszłe implementacje. Jest to więc kompromis między różnymi celami.

Być może słyszałeś ekstrapolację prawa Postela : „Bądź konserwatywny w tym, co wysyłasz, liberalny w tym, co akceptujesz”.

Głównie chodzi o maksymalizację możliwości ponownego wykorzystania kodu. Łatwo jest wymyślić przypadki, aby pokazać, dlaczego to pomaga. Rozważ Java Iterable<T>jako przykład. Jeśli jedyną rzeczą, którą robi twoja metoda, jest iteracja przez wszystkie Ts, posiadanie Iterable<T>jako typu parametru pozwala na użycie tej metody z ponad 60 wbudowanymi klasami, nie wspominając o żadnych niestandardowych klasach implementujących interfejs. Jeśli ograniczysz go do, powiedzmy, Vector<T>kodu, który wywołuje twoją metodę, będzie musiał zostać przekonwertowany na Vector<T>pierwszy.

Z drugiej strony, wracającIterable<T> z metody ogranicza ilość kodu, który może wykorzystać swoją wartość powrotną do tych, które biorą Iterable<T>parametr. Jeśli wrócisz typ bardzo konkretny, jak Vector<T>, wówczas wartość powrotu może być przekazywana w dowolnej metody, która trwa Serializable, Cloneable, Iterable<T>, Collection<T>, List<T>, RandomAccess, Vector<T>, AbstractList<T>, lub AbstractCollection<T>, i to będzie działać zgodnie z oczekiwaniami.