Il semble que le code F # réponde souvent à des types. Certainement
match opt with
| Some val -> Something(val)
| None -> Different()
semble courant.
Mais du point de vue de la POO, cela ressemble énormément à un flux de contrôle basé sur une vérification de type d'exécution, qui serait généralement mal vu. Pour l'expliquer, dans OOP, vous préféreriez probablement utiliser la surcharge:
type T =
abstract member Route : unit -> unit
type Foo() =
interface T with
member this.Route() = printfn "Go left"
type Bar() =
interface T with
member this.Route() = printfn "Go right"
C'est certainement plus de code. OTOH, il me semble que OOP-y a des avantages structurels:
- l'extension à une nouvelle forme de
T
est facile; - Je n'ai pas à m'inquiéter de trouver une duplication du flux de contrôle de choix d'itinéraire; et
- le choix de l'itinéraire est immuable en ce sens qu'une fois que j'ai un
Foo
en main, je n'ai plus à me soucier deBar.Route()
la mise en œuvre
Y a-t-il des avantages à faire correspondre des modèles à des types que je ne vois pas? Est-il considéré comme idiomatique ou s'agit-il d'une capacité qui n'est pas couramment utilisée?
But from an OOP perspective, that looks an awful lot like control-flow based on a runtime type check, which would typically be frowned on.
- semble trop dogmatique. Parfois, vous voulez séparer vos opérations de votre hiérarchie: peut-être 1) vous ne pouvez pas ajouter une opération à une hiérarchie b / c vous ne possédez pas la hiérarchie; 2) les classes dont vous voulez avoir l'op ne correspondent pas à votre hiérarchie; 3) vous pouvez ajouter l'op à votre hiérarchie, mais ne voulez pas b / c vous ne voulez pas encombrer l'API de votre hiérarchie avec un tas de conneries que la plupart des clients n'utilisent pas.