Version imprimable
Bonjour à tous,
J'ai lu récemment un article concernant la programmation orienté objet en F# :
http://weblogs.asp.net/podwysocki/ar...g-classes.aspx
Et je trouve la POO en F# vraiment intéressante. Cependant quelques questions me taraude. Le fait d'avoir, dans la majorité des cas, des objets immuables ne va-t-il pas impacter les performances?
Citation:
Envoyé par Max.Adorable
pas forcemment... tout dépend de ce que tu vas faire avec :aie:
Je développe principalement des applications CRUD et sites web. Les classes représentent surtout des entités persistantes (en base de données la plupart du temps).
Je garde une approche par module pour les services en remplacement aux multiples classes aux méthodes statiques (bien que les modules F# soit compilé comme tel).
Max.
Si tu as besoin de modifier des variables, rien ne t'empêche de le faire.
Tu peux aussi faire du fonctionnel pur, sans utiliser d'objet.
Tu peux faire un peu comme tu veux, il est toujours possible d'avoir de bonnes performances (évidemment, si tu as un objet très lourd et que tu passes ron temps à le dupliquer, ça risuqe d'être lent).
Pour une réponse plus précise, il faudra une question plus précise. :)
Il n'y a pas longtemps j'ai réécris en F# un système de cache que j'avais écris en VB.Net pour le boulot et j'ai été agréablement surpris pas le temps passé, la quantité de code et les performances de cette nouvelle version.
Aus vu de ce résultat, je me suis donc mis à réfléchir sur la réécriture d'une application de type CRUD. Le problème est que j'ai toujours appris à penser objet et donc l'approche fonctionnel non-objet bloque un peu.
Comment représenter des entités (tables en base de données) en fonctionnel et les relations entre ces entités. Dans ce genre de cas l'objet me semble le plus approprié (maintenant le fonctionnel est tout nouveau pour moi).
Est-il possible de faire de l'orienté objet fonctionnel? Si oui comment ?
Merci d'avance.
Max.
La mixité de l'objet et du fonctionnel ne se fait pas en déclarant des classes qui seraient à tout prix immuables.
La mixité se fait en préservant l'existant sur certaines parties de l'application (typiquement ce sont les parties qui impliquent d'autres composants dotnet) tout en repensant certaines autres parties de façon purement fonctionnelle, sans objets ou avec peu d'objets (typiquement les parties plus riches en spécifications et plus pauvres en interactivité).
La transition peut se faire de façon incrémentale, en donnant la priorité aux parties où le bénéfice est le plus évident tout en touchant peu ou pas les parties où tu as des doutes sur l'approche à adopter.
À mon avis, sur dotnet, il faut voir le fonctionnel plutôt comme une option qui éventuellement est une bonne idée de conception ou de refactoring.
Il faut garder à l'esprit que dotnet est par nature une plateforme à objets et donc le fonctionnel n'est pas une fin en soi mais un moyen d'améliorer la qualité en abaissant la complexité sémantique des applications.
:D oui ça je m'en doutaisCitation:
Envoyé par SpiceGuid
Merci pour les précisions.
Max.
Bonjour,
Pourquoi le fonctionnel et l'objet seraient incompatibles ?
A priori je ne vois pas pourquoi on ne peut pas mélanger ces deux concepts.
Citation:
Envoyé par Quentin_
il faudrait des objets immutables... si on veut rester avec du fonctionnel pur ;)
la POO implique souvent la notion d'état interne modifié, de manière invisible au développeur (boite noire), et fonctionnel fait parfois mauvais ménage avec effets de bords ;)
On pourrait imaginer un langage comme ça non ? :
L'opérateur d'assignation `:=` ne modifie pas directement la variable, il en créé une autre du même nom (pas d'effets de bord donc).Code:
2
3
4
5
6
7
8
9
10
11
La seule différence, ça serait qu'au lieu de faire v.edit(), on ferait let v = v.edit(), qui recréerait un nouvel objet.
On pourrait par la suite autoriser cette syntaxe :
v.edit("ok")
Qui serait équivalente à :
let v = v.edit("ok"), c'est à dire sans effets de bords.
Qu'est-ce que vous en pensez ?
Oui, on peut mélanger objet et fonctionnel.
Au niveau de F#, les entiers sont des objets, tout comme les types somme, etc. L'objet string possède plein de méthodes, mais il reste entièrement pur (contrairement à Caml !). Cela ne pose aucun problème, bien au contraire.
Quant on commence à faire une modélisation objet, comme on en voit souvent en Java, C++, etc., on a souvent tendance à vouloir des valeurs mutables. Recopier tout l'objet n'est pas toujours une solution souhaitable. Cela dit, même s'il faut se méfier des effets de bord, avoir du code pur n'est pas forcément un objectif.
La fonction suivante n'est pas très dangereuse :
Code:
2
3