Miguel Moquillon <miguel@home.fr> writes:

Pascal Bourguignon wrote:

Il y a un antagonisme fondamental entre la programmation par objet et
la programmation fonctionnelle.

Dans la programmation fonctionnelle, quand on n'a que des fonctions
pures, il n'y a pas d'état.

C'est un peu réducteur, voir faux. En fait, en programmation fonctionnelle,
les entités logiciels manipulées sont des fonctions qui s'appuient
toutefois sur les types de base. Un langage fonctionnel est dit pur
lorsqu'il n'y a pas d'effet de bords dans la manipulation des données,
c'est tout. Un donnée, exprimée sous forme de fonction ou de types de base,
a au moins 1 état, seulement le passage d'un état à l'autre conduit à une
autre donnée ou fonction. Pour vraiment apprécier ce qu'est un langage
fonctionnel pur, voir Haskell qui plus est est libre.

Oui, je sais que ma définition est un peu dure. Elle exclue les choses
comme les nombres des objets.  Comme on ne peut pas modifier un
nombre, c'est qu'il n'a pas d'état, seulement une identité.  Si on
accepte cette définition, Smalltalk y va un peu trop fort.


J'admet qu'en pratique, en programmation objet, on peut considérer des
objets sans état, où seul l'identité de l'objet est utile.  Mais
souvent ce sont ces cas limitites (par exemple, les singletons), qui
sont critiqué à partir des langages moins fondamentalistement OO.

Alors que la programmation par objet n'est concernée justement que par
l'état des objets.  Quand il n'y a pas d'état on est bien embêté en
POO, c'est là qu'on fait intervenir des classes et méthodes de classes
artificielles.

D'abord, je ne suis pas tout à fait d'accord sur cette assertion : dans un
premier temps, on se concentre sur le type de l'objet, donc sur la syntaxe
et la sémantique des messages, indépendamment de la structure interne de
l'objet qui décrit finalement son état ou plus exactement sa machine à
état. Dans un deuxième temps, on se concentre effectivement sur l'état de
l'objet. Du moins, c'est l'approche que je préconise dans le développement
objet.

Ensuite, dans la réalité, j'ai plus l'impression que l'on fait intervenir
des classes artificielles pour écrire ce qui a été mal (voir pas de tout)
exprimé ou modélisé. Car d'après mon expérience, lorsqu'il ne semble pas
avoir d'état, c'est qu'il y a déjà quelque part un problème ; en effet, une
entité a toujours au moins un état, que ce dernier soit ou non explicité
par son codeur.

Oui, ensuite en pratique, il faut voir selon les circonstances quelle
méthodologie d'analyse on emploie; ça dépend de l'environnement et du
type de développement.  Les questions techniques de programmation sont
subalterne, et c'est simplement plus agréable quand le langage de
programmation impose le moins de contraintes possible.


--
__Pascal Bourguignon__                     http://www.informatimago.com/

NEW GRAND UNIFIED THEORY DISCLAIMER: The manufacturer may
technically be entitled to claim that this product is
ten-dimensional. However, the consumer is reminded that this
confers no legal rights above and beyond those applicable to
three-dimensional objects, since the seven new dimensions are
"rolled up" into such a small "area" that they cannot be
detected.