Extension method design guidelines: should a like method name be the same for the sub and super class?
I just finished reading the section on extension members in Framework Design Guidelines 2nd Ed., by Krzysztof Cwalina and Brad Abrams, and didn't find an example for this. My question concerns a super and sub class in an F# library, but I expect the answer is relevant to all .NET languages.
F# has two types, the super type Expr
and the sub type Expr<'a>
where the latter is just a wrapper for a typed version of the former. These are the types used for quotation expressions.
If I wanted to define extension methods on these types for evaluating them, which would be a better design:
- Do as the F# PowerPack does a开发者_C百科nd defined methods with different names
EvalUntyped() : Expr -> obj
onExpr
andEval() : Expr<'a> -> 'a
onExpr<'a>
. - Do something closer to what you would do if you owned the types and use the same name (where the method on the super type can be thought of as virtual, and the method on the sub type can be thought of as overriding the super virtual method). i.e.
Eval() : Expr -> obj
onExpr
andEval() : Expr<'a> -> 'a
onExpr<'a>
.
The second option seems more correct to me, but I'd like to follow whatever design guidelines there may be: is there any authoritative precedence for this (supposing they got it "wrong" in the PowerPack)?
There may not be a definitive answer to this. However, unless you truly believe the F# PowerPack did get the design "wrong", I'd follow their style for two reasons:
- To keep the style consistent with what other developers already work with in F# and official extensions.
- To more explicitly show the difference in the return types of the two methods since it does matter.
Your analogy in your reply to Tomas is a good one, but I'd assume any other developers using this code may not pay as much attention to the design as you have. Best to keep consistent with official style and be explicit in your intentions.
精彩评论