Miguel Moquillon wrote:
Bruno Desthuilliers wrote:
Un objet, dans un programme, représente un concept du monde de
l'entreprise ou une idée ou une chose du monde concret.
Ah bon ? Une boite de dialogue, une connection à une base de donnée ou
un handler de fichier sont des concepts du monde de l'entreprise ou des
idées ou choses du monde concret ? On ne doit pas vivre dans le même
monde !-)
Si si on vit bien dans le même monde. La preuve on peut communiquer
ensemble.
!-)
Évidemment, je ne saurais être exhaustif et donc on peut rajouter
aussi des concepts informatiques.
Bref, un objet représente un élément du programme, que cet élément
provienne du problème ou de la solution...
Bon, on est bien avancé avec ça !-)
Ce n'est pas une fonction si
c'est à quoi tu penses.
Python 2.4.1 (#1, Jul 23 2005, 00:37:37)
[GCC 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)] on
linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> def func(arg):
... print arg
...
>>> func
<function func at 0x40423374>
>>> func.__class__
<type 'function'>
>>> func.func_code
<code object func at 0x4041b1a0, file "<stdin>", line 1>
>>> isinstance(func, object)
True
>>> newfunc = func.__new__(func.__class__, func.func_code, func.__dict__)
>>> newfunc
<function func at 0x404233ac>
>>> newfunc is func
False
>>>
Il semblerait pourtant bien que dans certains langages, un fonction soit
un objet... et réciproquement d'ailleurs:
>>> class MyFunctionType(object):
... def __call__(self, arg):
... print arg
...
>>> func2 = MyFunctionType() # create a new instance of type
>>> func2(42)
42
>>>
Que les fonctions puissent être implémentées sous forme d'objet dans un
langage est une chose, qu'un objet soit une fonction en est une autre.
Je n'ai pas dit qu'un objet *était* une fonction, juste qu'un objet
*pouvait être* une function (et réciproquement). Et crois moi, c'est
*très* loin d'être un gadget.
De même, les fonctors (objets qui agissent comme une fonction) sont une
chose, les fonctions par elles-même une autre.
J'avoue avoir du mal à saisir la différence conceptuelle profonde. Le
pattern functor - comme une grande majorité des design patterns du GOF -
n'est jamais qu'une solution de contournement née des limitations de
certains langages plus ou moins OO.
Il faut arrêter de percevoir la PO qu'au travers de la petite lorgnette de
tel ou tel langage de programmation.
Tout à fait d'accord. C'est bien pour ça que je cite l'exemple
(relativement marginal - hélas AMHA) d'un langage où les fonctions sont
des objets...
Le problème, c'est l'OO "officiel" est exactement ce que tu dénonces :
une réduction du concept aux fonctionnalités supportés par quelques
langages soit-disant OO mais pour la plupart bien plus proche du
procédural que du modèle d'origine proposé par Smalltalk.
Avec C++ ça a abouti suffisamment à
des travers pour que l'on commence à arrêter les conneries.
Par contre, il peut être dédié à une tâche précise pour laquelle il offre
différents services ou opérations : un gestionnaire de connexions par
exemple. Mais là aussi, tu dois le penser comme une entité, comme un
sujet, et non comme un verbe.
En analyse, oui. En conception, c'est déjà plus tangeant. [...]
Non, non et non. Arrêtons de tout voir par et uniquement par les langages
qui ne sont que des outils limités de l'approche objet.
Jusqu'à preuve du contraire, il s'agit bien au final d'implémenter une
solution, ce qui nécessite un langage de programmation. La conception
n'est *pas* indépendante des technos choisies (malgré ce que certains
marchands de vent voudraient faire croire). Se limiter, lors de la
conception, au sous-ensemble commun aux technos "main stream", c'est
AMHA s'amputer le cerveau.
Tout ça pour s'excuser de faire du mixte de procédurale et de l'objet parce
qu'on a du mal à faire de la programmation par objets correcte.
Je ne vois pas où est le problème à utiliser des fonctions là où c'est
la solution appropriée. En faire des méthodes statique d'une classe
bidon qui n'existe que parce les concepteurs du langage ont décidé que
tout devait être mis dans une classe ne change rien au problème.
Par ailleurs, je me permets d'attirer ton attention sur le fait que
fonction n'implique pas procédural. Le fait d'avoir des fonctions
représentées par des objets permet une approche fonctionelle qui est
parfois la plus appropriée (et que d'autres langages émulent par
l'emploi de 'functors'). Pour ce que ça vaut, Smalltalk (qui reste,
qu'on le veuille ou non, *la* référence en matière d'OO) utilise
lui-même une approche inspirée de la programmation fonctionnelle (les
"blocks" de Smalltalk ne sont pas grand chose d'autre que des fermetures).
Et après,
on va entendre des soit disant experts (qui ne sont experts que par leur
prétention de l'être) que l'objet c'est limité, c'est machin, c'est truc.
Mais *c'est* limité !-) En tous cas dans la version "officielle" (UML,
Java et autres couenneries déficientes du bulbe). Ce n'est certainement
pas un hasard si de plus en plus de langages essentiellement objets
tournent le dos à cette approche réductrice et intègrent de plus en plus
d'éléments provenant des langages fonctionnels.
Note : désolé ... j'ai piqué une colère.
Pas de mal, ça m'arrive aussi - comme tu a pu le constater en lisant
cette diatribe.
(et pas seulement du
point de vue conceptuel - pour l'ordinateur, il s'agit toujours d'une
suite de bits stockés à une adresse mémoire, et l'interprétation qu'il
va en faire dépend essentiellement de ce qu'on lui demande (c'est
d'ailleurs à l'origine de pas mal de faille de sécurité...)).
L'approche objet est une abstraction bien au-dessus de considérations de
bits (pas de vilain jeux de mots stp :) )
Je parlais de la distinction artifielle entre données et traitements.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
