Quel tutoriel pour débuter ?

Antoine Leca a écrit :

En news:48ba96bf$0$961$ba4acef3@news.orange.fr, Wykaaa va escriure:

Donc, pour résumer, l'approche objet s'appuie sur 4 concepts majeurs
de base :
- le concept d'abstraction (se matérialise par la notion de classe
dans un langage de programmation objet)

- le concept d'encapsulation qui permet à un objet (une classe donc)
de ne montrer à l'extérieur que ce qui est nécessaire à son
utilisation.
Ce concept est matérialisé dans les LOO (langages orientés objet) par
les directives de contrôle d'accès (private, protected, public)

- le concept de modularité (au sens objet) qui s'ppuie sur 2
principes :
- La forte cohésion : un objet ne traite que d'une seule
abstraction et il la traite entièrement
- Le faible couplage : minimisation des dépendances entre classes
et encapsulation
ATTENTION : cette notion de modularité est piégeuse car dans les
langages on a aussi la notion de package (regroupement de plusieurs
classes). Le faible couplage est souvent mis en oeuvre, dans les
grosses applications, au niveau des packages et non au niveau des
classes car la granularité est trop fine.

- Enfin le concept de hiérarchie. Il est mis en oeuvre, dans les LOO,
à travers l'héritage mais aussi à travers la composition/agrégation
d'objets.

Si on revient à C, le concept d'encapsulation est me semble-t-il traité par
la séparation .h/.c et des règles de gestion, et le concept de modularité
par d'autres règles de gestion, mais le langage n'est aucunement un
obstacle.

C'est la modularité qui est traitée par la séparation .h/.c. Ensuite,
tout dépend de ce que tu mets dans le .h. Pour respecter le concept
d'encapsulation, le .h présentera uniquement un pointeur sur la
structure (représentant l'abstraction et ceci afin qu'on ne puisse pas
accéder directement aux champs de données de la structure. C'est un
moyen de les rendre "privés") et un moyen d'accès aux pointeurs sur
fonctions qui représentent les "méthodes" de l'abstraction (Il faut que
le programmeur puisse les appeler. C'est un moyen de rendre les
fonctions "publiques").
La structure elle-même, dans cette construction, n'est pas présentée
dans le .h (Philippe Drix montre un exemple complet dans son livre
"Langage C - norme ANSI- vers une approche orientée objet")

Le concept d'héritage est (toujours « me semble-t-il ») spécifiquement mis
en ouvre par les règles relatives aux pointeurs de structure et d'union.

Pour l'héritage, on peut faire comme tu dis ou mettre en place tout un
mécanisme à base de macros du préprocesseur (ce qui était fait pour
X-Window/Motif).
Le plus difficile est de simuler le polymorphisme car il faut tout faire
"à la main" (se le programmer...).

Le concept d'abstraction tel que décrit ci-dessus n'a aucun sens pour moi.
Se reférerait-il à l'utilisation de pointeurs ?

En C, une abstraction sera représentée par une structure qui contient
les attributs de l'abstraction (les champs de données) et les pointeurs
sur les fonctions qui permettent de manipuler ces champs de données
(l'équivalent des méthodes dans une classe "à la C++")

Par exemple, il doit être plus difficile d'utiliser Fortran que C, justement
pour cette raison ?

C'est évidemment bien plus difficile de faire de l'objet en Fortran
classique car il n'y a pas de pointeur...

Si j'ai bien compris, on peut faire ce genre d'approche orientée objets avec
le langage C plus quelques règles (communément observées) sur ce qui
s'appelle traditionellement en C la compilation séparée, c'est-à-dire le
découpage en module ?

Absolument. c'est ce que j'ai essayé de décrire ci-dessus

Ce qui me surprend le plus à relire cet article, c'est que je n'ai même pas
mentionné les pointeurs de fonction... Comme à ma connaissance c'est un
ingrédient nécessaire à une API pour pouvoir y implanter des langages «
orientés objet », j'ai comme l'idée qu'il y a des choses qui ne sont pas
correctes ci-dessus. Donc, où est l'erreur ?

Les pointeurs sur fonction sont essentiel pour "simuler" une approche
objet en C, comme je l'ai montré ci-dessus.

Wykaaa

J'ai retrouve la ref papier que je cherchais, c'est

http://lucacardelli.name/TheoryOfObjects.html

dont tu peux avoir au moins la table des matieres sur le web.

La partie sigma-calcul et la suite sont une bonne theorisation de
l'oriente-objet, entierement basee sur la notion d'objet et de methodes,
avec un eventuel typage, et l'introduction de concepts divers et varies
`au-dessus' des concepts primitifs, dont ne fait pas partie la notion
d'heritage... La partie I 4, avec les choix de prototype-based, et
tout ce qui s'ensuit, correspond plus ou moins a mon discours.

Pas mal de tout ceci de memoire: c'est un bouquin que j'ai lu il y a
deja quelques annees, et que je n'ai evidemment plus sous la main!

candide a écrit :

Bref pour toi apprendre est un combat, une lutte. Pour moi, apprendre
c'est comme quand je vais au cinéma ou quand on me raconte une histoire
ou que je fais un voyage.

Tiens, c'est pas ça l'idée du "literate programming" ?

Marc Espie a écrit :

J'ai retrouve la ref papier que je cherchais, c'est

http://lucacardelli.name/TheoryOfObjects.html

dont tu peux avoir au moins la table des matieres sur le web.

La partie sigma-calcul et la suite sont une bonne theorisation de
l'oriente-objet, entierement basee sur la notion d'objet et de methodes,
avec un eventuel typage, et l'introduction de concepts divers et varies
`au-dessus' des concepts primitifs, dont ne fait pas partie la notion
d'heritage... La partie I 4, avec les choix de prototype-based, et
tout ce qui s'ensuit, correspond plus ou moins a mon discours.

Pas mal de tout ceci de memoire: c'est un bouquin que j'ai lu il y a
deja quelques annees, et que je n'ai evidemment plus sous la main!

Effectivement, voilà une très bonne référence que j'avais "oubliée".
J'ai le papier :
On Understanding Types, Data Abstraction, and Polymorphism de Cardelli
et Wegner mais il date de 85 :-(
Je considère cependant ce papier comme la meilleure référence sur les
sujets qu'ils y abordent.

Francois a écrit :

Tiens, en tapant "Conception et programmation orientée objet" sur
google, je tombe sur ce cours : http://rainet.enic.fr/unit/A43/index.htm
Ça a l'air vachement bien. :-)

Je trouve ce lien très intéressant et l'auteur fait un bel effort de
vulgarisation, dommage que tout soit dans des frames.

Alors, dans sa séquence 1, l'auteur attribue le développement des
langages OO à la "crise du logiciel" (qui proviendrait de sa
complexification croissante) et justement dans la 4ème page du menu
"crise du logiciel", il cite des projets d'ampleurs croissantes (j'ai
pas compris ses unités hommes/ mois) :

Compilateur (C, Pascal...) -> 120 HM
Compilateur ADA -> 1800 HM
Logiciel Navette -> 12000 HM
Système d'exploitation -> 60000 HM

Bon, justement, un des logiciels les plus complexes est un OS. Or, des
OS comme Linux ou Windows pour x86 sont en général écrit majoritairement
en C avec de l'assembleur dans de petites proportions.

Donc, ma question est : pourquoi ne réécrit-on from scratch pas les OS
dans un langage objet genre C++ ? Trop de travail ? pas utile ?

Autre question dans le même registre : comment se fait-il que les
implémentations de langage objets comme Python et Ruby soient écrits en
C et non pas en C++ ? Pour Python 3000, il semblerait qu'il avait été
envisagé de tout réécrire, cf.

http://python.org/dev/peps/pep-3000/

Et les jvm, elles sont écrites en C ou en C++ ? Un compilateur C++ est
écrit en quoi ? Sinon, il me semble que le compilateur DMD est écrit en C.

In article <48bbed5f$0$15612$426a74cc@news.free.fr>,
candide <candide@free.invalid> wrote:

langages OO à la "crise du logiciel" (qui proviendrait de sa
complexification croissante) et justement dans la 4ème page du menu
"crise du logiciel", il cite des projets d'ampleurs croissantes (j'ai
pas compris ses unités hommes/ mois) :

Deja, vu que tu ecris hommes / mois, tu dois etre fache avec la physique.

C'est evidemment homme * mois qu'il faut lire, et c'est une unite de
mesure de travail violemment decriee en informatique (confere le tres
fameux _le mythe du mois-homme_), puisqu'elle revient a supposer qu'il
suffit de mettre deux fois plus de programmeurs sur un projet pour le
terminer en deux fois moins de temps...

Marc Espie a écrit :

Deja, vu que tu ecris hommes / mois, tu dois etre fache avec la physique.

J'ai répété un peu bêtement ce que l'auteur écrit lui-même, je cite :

"Coût (en Homme/Mois)"

C'est evidemment homme * mois qu'il faut lire, et c'est une unite de
mesure de travail

Ok, je ne connaissais pas, c'est plus clair ainsi.

candide <candide@free.invalid> writes:

Francois a écrit :
> Tiens, en tapant "Conception et programmation orientée objet" sur google,
> je tombe sur ce cours : http://rainet.enic.fr/unit/A43/index.htm
> Ça a l'air vachement bien. :-)

Je trouve ce lien très intéressant et l'auteur fait un bel effort de
vulgarisation, dommage que tout soit dans des frames.

Alors, dans sa séquence 1, l'auteur attribue le développement des langages
OO à la "crise du logiciel" (qui proviendrait de sa complexification
croissante) et justement dans la 4ème page du menu "crise du logiciel", il
cite des projets d'ampleurs croissantes (j'ai pas compris ses unités
hommes/ mois) :

Pas hommes/mois, mais homme*mois; mesure de la quantite de travail
engloutie par un projet, avec comme idee soujacente chez pas mal de
personnes employant ce genre de mesure que mettre plus de monde aide a
accelerer le projet; ca marche peut-etre pour certains chantiers (et
encore, essaye de paralleliser la pose du toit avec la fabriquation de la
chappe), rarement en informatique. Cfr le bouquin de Brooks.

Compilateur (C, Pascal...) -> 120 HM
Compilateur ADA -> 1800 HM
Logiciel Navette -> 12000 HM
Système d'exploitation -> 60000 HM

On ne va pas demander d'ou viennent ces chiffres...

Bon, justement, un des logiciels les plus complexes est un OS.

Pas sur... il y a des aspects dans le developpement d'un OS qui sont plus
facilement parallelisable qu'ailleurs (le developpement des drivers par
exemple).

Or, des OS comme Linux ou Windows pour x86 sont en général écrit
majoritairement en C avec de l'assembleur dans de petites proportions.

Donc, ma question est : pourquoi ne réécrit-on from scratch pas les OS dans
un langage objet genre C++ ? Trop de travail ? pas utile ?

Pourquoi reecrire de scratch? c'est le fantasme de tout qui commence sur un
projet important: le code est merdique, il faut tout reecrire de scratch.
Quand on le fait, on commence a remarquer que tout n'est pas aussi simple
et au mieux on se retrouve avec autant de m... mais placee differemment
sans progres visibles de l'exterieur, au pire on aura englouti de l'argent
et du temps dans un projet abandonne. Meme s'il y a des choses qui sont a
reecrire, il vaut mieux le faire incrementalement que tout reecrire.

Autre fantasme, le choix des langages est parfaitement rationnel et
purement technique... je parie que les criteres non-rationnels ou
non-technique (quand ils ne sont pas a la fois non-rationnels et
non-techniques) dominent. Naturellement, on peut les rationnaliser
techniquement apres coup, mais rationnaliser une autre decision serait tout
aussi facile.

Autre question dans le même registre : comment se fait-il que les
implémentations de langage objets comme Python et Ruby soient écrits en C
et non pas en C++ ?

cfr ci-dessus.

Et les jvm, elles sont écrites en C ou en C++ ?

Ca m'etonnerait qu'il n'y en ait pas ecrites dans les 2 langages. Je
serais meme pas surpris s'il y en avait ecrites dans un autre langage
encore.

Un compilateur C++ est écrit en quoi ?

Meme reponse.

Sinon, il me semble que le compilateur DMD est écrit en C.

Et? voir des pistes ci-dessus. Et ne pas oublier l'histoire... c'est un
compilateur C qui a acquis d'autres front-end. Le back-end a
vraisemblablement beaucoup moins evolue. Et pour faire le compilateur d'un
nouveau langage, on n'en a pas deja un. Mais ca n'explique pas tout,
comment faire est assez bien connu (chercher bootstrap par exemple; pour un
cas de cette approche voir le compilateur Ada de GCC dont le front-end est
ecrit en Ada mais qui partage le back-end avec les autres compilateurs
faisant partie de GCC... je suis sur que Marc pourra te donner tous les
desavantages de cette approche).

A+

--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Marc Espie a écrit :

In article <48bbed5f$0$15612$426a74cc@news.free.fr>,
candide <candide@free.invalid> wrote:

langages OO à la "crise du logiciel" (qui proviendrait de sa
complexification croissante) et justement dans la 4ème page du menu
"crise du logiciel", il cite des projets d'ampleurs croissantes (j'ai
pas compris ses unités hommes/ mois) :

Deja, vu que tu ecris hommes / mois, tu dois etre fache avec la physique.

C'est evidemment homme * mois qu'il faut lire, et c'est une unite de
mesure de travail violemment decriee en informatique (confere le tres
fameux _le mythe du mois-homme_), puisqu'elle revient a supposer qu'il
suffit de mettre deux fois plus de programmeurs sur un projet pour le
terminer en deux fois moins de temps...

Oh là. Tu y vas fort quand même.
Si on prend le modèle COCOMO d'estimation des HM en fonction du nombre
de lignes de code estimées et des différents facteurs de coût, on voit
que les formules ne sont pas linéaires, justement parce que, par
exemple, 6 * 20 HM ne sont pas équivalents à 12 * 10 HM ce que montre,
justement, Frederick Brooks dans son livre "The mythical Man-Month".

Cette unité de mesure n'est pas décriée mais elle doit être manipulée
avec précaution, ce que l'on sait depuis les années 60 (Brooks étant le
père de l'OS/360 d'IBM et yant écrit ce livre à la suite des avatars de
ce projet (doublement des délais, deux fois plus de bogues que prévu, etc.).
D'ailleurs une des lois dite de Brooks, énoncée dans son bouquin, dit ceci :
Ajouter du personnel à un projet en retard ne fait qu'augmenter le retard.

In article <48bbfa8b$0$927$ba4acef3@news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:

Oh là. Tu y vas fort quand même.
Si on prend le modèle COCOMO d'estimation des HM en fonction du nombre
de lignes de code estimées et des différents facteurs de coût, on voit
que les formules ne sont pas linéaires, justement parce que, par
exemple, 6 * 20 HM ne sont pas équivalents à 12 * 10 HM ce que montre,
justement, Frederick Brooks dans son livre "The mythical Man-Month".

Comme tu peux t'en douter, je suis contre la mecanisation a outrance
du travail en informatique, une forme de taylorisme de plus.

Il y a deux sortes de projets en informatique:
- les trucs triviaux, que tu vas filer a un pisseur de code java/C#/vbasic,
et qui va quand meme arriver a te le planter parce qu'il ne sait pas lire.
- les trucs interessants, qui sont presque infaisables.

Le premier cas se mecanise et se deshumanise tres bien. Appliquer des
techniques de management un peu cretines au 2e cas ne fonctionne pas trop...

Evidemment, le premier cas correspond a environ 90% du chiffre d'affaires
actuel de l'informatique... je ne sais pas trop s'il faut s'en rejouir ou
en pleurer, mais perso, je prefere faire des trucs qui appartiennent a la
2e categorie.