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.
Odpowiedzi:
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.