Wytyczne projektowania metod rozszerzenia: czy podobna nazwa metody powinna być taka sama dla sub i super klasy?

Question

Właśnie skończyłem czytać sekcję o członkach rozszerzeń w II Edycji ramowych, autorstwa Krzysztofa Cwaliny i Brada Abramsa, ale nie znalazłem na to przykładu. Moje pytanie dotyczy super i podkategorii w bibliotece F #, ale spodziewam się, że odpowiedź jest odpowiednia dla wszystkich języków .NET.

F # ma dwa typy, super typ Expr i podtyp typu Expr<'a>, gdzie drugi to tylko opakowanie dla typowej wersji tego pierwszego. Są to typy używane w wyrażeniach cudzysłowu.

Gdybym chciał określić metody rozszerzenie na temat tych typów dla ich oceny, która byłaby lepsza konstrukcja:

1. zrobić jak F # PowerPack robi i zdefiniowane sposoby z różnymi nazwami EvalUntyped() : Expr -> obj na Expr i Eval() : Expr<'a> -> 'a na Expr<'a> .
2. Zrób coś bliższego temu, co zrobiłbyś, gdybyś posiadał typy i używał tej samej nazwy (gdzie metoda na super typie może być uważana za wirtualną, a metoda na podtypie może być uważana za nadrzędną super wirtualna metoda). tj. Eval() : Expr -> obj na Expr i Eval() : Expr<'a> -> 'a na Expr<'a>.

Druga opcja wydaje mi się bardziej poprawna, ale chciałbym postępować zgodnie z wszelkimi wytycznymi dotyczącymi projektowania: czy istnieje jakikolwiek autorytatywny precedens dla tego (przypuśćmy, że jest to "złe" w PowerPack)?

Answer 1

Może nie być jednoznacznej odpowiedzi na to. Jednakże, chyba że naprawdę wierzą, że F # PowerPack udało nam się projekt „źle”, będę śledzić swój styl z dwóch powodów:

1. Aby zachować styl zgodny z tym, co inni deweloperzy już pracować w F # i oficjalnych rozszerzeń .
2. Aby wyraźniej pokazać różnicę w typach zwracanych dwóch metod, ponieważ ma to znaczenie.

Twoja analogia w Twojej odpowiedzi na Tomas jest dobra, ale zakładam, że inni deweloperzy używający tego kodu mogą nie zwrócić tak dużej uwagi na projekt, jaki masz. Najlepiej zachować zgodność z oficjalnym stylem i jasno wyrażać swoje intencje.