2

Been grokking F# coming from a C# background.

In C# there is a clear difference in deciding when to use interfaces and when to use abstract classes. In F# I see the two blurring almost into one. I understand under the hood that the same is being done in F# as c# as far as the CLR is concerned, but what is the "best practise" when programming in F# to use?

Should I avoid class inheritance altogether?

WeNeedAnswers
  • 4,620
  • 2
  • 32
  • 47
  • Related: http://stackoverflow.com/questions/1932247/abstract-classes-and-interfaces-best-practices-in-java – S.Lott Jun 24 '10 at 10:23
  • possible duplicate of [Interface vs Abstract Class (general OO)](http://stackoverflow.com/questions/761194/interface-vs-abstract-class-general-oo) – S.Lott Jun 24 '10 at 10:23
  • 3
    not duplicate, different paradigm, different language. – WeNeedAnswers Jun 24 '10 at 10:27

2 Answers2

5

I think that interfaces tend to be used much more frequently than abstract classes (compared to object-oriented languages like C#).

In many cases, you don't need any of the two, because you can just write higher-order function (that takes a function as an argument, instead of taking an interface as an argument). However, sometimes you may have two functions that are always used together - in that case, you can group two functions into an interface:

// Instead of using higher-order function
val foo : (int -> string) -> (string -> int) -> ...

// ..we can define an interface
type TwoWayConversion = 
  abstract ToString : int -> string
  abstract FromString : string -> int

val foo : TwoWayConversion -> ...

I think that this is quite useful F# programming pattern that uses interfaces in a perfectly functional style.

On the other hand, I would use abstract classes only when writing object-oriented code that is supposed to be used from C# (e.g. C# code implementing your F# abstract class) - because that's a natural extensibility point from the C# point of view. However, I think that idiomatic F# code uses different extensibility points than C# (e.g. taking function/interface as an argument), so you don't really need abstract classes.

Tomas Petricek
  • 240,744
  • 19
  • 378
  • 553
  • interesting, therefore you feel that abstract classes hold no relevance in f# and that interfaces are the way to go if you really have to do inheritance. – WeNeedAnswers Jun 24 '10 at 15:23
  • 2
    By the way, after thinking about the way I have been coding in the last couple of years in C#, I have tended to veer away from class inheritance completely and used composition instead, using interfaces and generics heavily with some help using delegates. Maybe objects are dead and modelling behaviour is the new model? – WeNeedAnswers Jun 25 '10 at 09:05
3

Well, if you're debating between abstract classes and interfaces, I think your reasons for one or the other would be the same as in C#. Maybe you should consider using functions, functional data types and modules as units of abstraction though. If you need to write an F# library to be used in C#, then you'll probably want to use interfaces etc for your exported types.

Mau
  • 14,234
  • 2
  • 31
  • 52
  • Yes I understand the differences between the two. The implementation of interfaces within f# look to be more relevant. Abstract classes have always seemed a little alien to me even in c#. Yes I like the functional way, just need to know "the done thing" in f#. I think that you have correctly pointed out that maybe I should ditch my OO thinking when in f#. – WeNeedAnswers Jun 24 '10 at 15:21