J'ai remarqué que les méthodes statiques semblent plus populaires en F # que c #. Dans C #, vous ajouteriez toujours un élément à une collection en appelant une méthode d'instance: mais dans F # il y a généralement une méthode statique équivalente: Et j'ai vu cette dernière forme assez souvent dans des échantillons. Les deux semblent-ils complètement identiques sémantiquement et fonctionnellement, mais provenant d'un fond de C # en utilisant la méthode d'instance se sent plus naturelle. Quel est le meilleur style dans F # et pourquoi?
4 Réponses :
en F # comme langue fonctionnelle plus indigène pour séparer les variables qui sont immuables et fonctionnent des opérations. Cela fonctionne comme des méthodes statiques en C #, mais il y a un avantage des fonctions avant les méthodes C #. C'est une application partielle. Vous pouvez transmettre pour fonctionner certains paramètres (pas tous) et cette fonction avec une partie des paramètres sera une nouvelle fonction qui nécessite d'autres paramètres.
En plus des raisons mentionnées dans cette réponse liée à la déduction du type, dans le style fonctionnel est plus naturelle d'envoyer une fonction de paramètre.
Si c'est une méthode d'instance, vous devrez écrire quelque chose comme ceci: mais s'il est défini comme une méthode statique, vous pouvez écrire: P> myHigherOrderFunction MyType.myFunctionAsMethod
Excellentes cas d'utilisation sur le style FP. Et dans la programmation de style OO, les fonctions d'instance sont plus courtes.
La plupart des types Standard F # sont immuables. Lorsque vous travaillez avec des objets immuables, des méthodes statiques représentent mieux ce qui se passe, par exemple: ressemble à mySet code> est muté pour inclure elem code >, lorsqu'un ensemble F # retournerait un nouveau mySet code>. Heureusement, F # omet de compiler pour vous assurer de ne pas faire cette erreur, cela conduit toujours à un code déroutant. En revanche: p> mySet |> Set.Add elm
tandis que les méthodes statiques en F # sont très courantes, je trouve que les méthodes d'instance ont beaucoup de sens pour le développement des composants.
la raison? Le système de module F # manque de foncteurs. Dans d'autres saveurs de ml tels que SML ou OCAML, vous développez des composants comme des modules simples. Si vous décidez plus tard de paramétrer le module, vous pouvez la promouvoir à un foncteur sans réécrire trop de votre code source. En F #, vous ne pouvez pas.
Pour créer un "module" paramétré dans F #, vous devez recourir à une classe et transformer vos méthodes par exemple, transmettre des paramètres lors de la construction d'instances. Malheureusement, passer d'un module à une classe implique un peu de changements de code source mécanique mais gênant. Par conséquent, un programmeur de composants acharné peut choisir de fonctionner avec des classes et des méthodes d'instance par défaut, comme en C #. Cela rappelle un style "foncier-seulement" parfois employé dans SML.
Connexes: Stackoverflow.com/q/7698133/162396
Il y a tellement de raisons, enracinées dans une programmation fonctionnelle dans son ensemble, et certaines personnes à F #, il est difficile de savoir où commencer à la justifier. Une fois que vous vous êtes familiarisé avec une programmation fonctionnelle, cela deviendra évident.
Cela se rapporte simplement aux 2 styles, OO et FP. Puisque F # est Multi Paradigm, je suppose qu'il est logique d'avoir les deux.