Discussion :

[popo]

Bonjour à tous, pour continuer la discussion sur le sujet
J'ai regardé Wikipédia sur le thème "Programmation Orientée Objet" pas de trace de Delphi ni de Pascal Objet
De même pas de POO dans les manuels Delphi 5 ou Delphi 2005.
Si vous trouvez des traces sur le moment de l'apparition de la thématique POO dans Delphi, je suis preneur.

Je crois avoir déjà eu une discussion avec les même protagonistes sur le sujet en 2015 ...

Et pourtant Delphi (ou plutôt Turbo Pascal à l'époque) est orienté POO depuis 1989 !
https://fr.wikipedia.org/wiki/Pascal_(langage)

Il y a même encore le manuel sur le site d'embarcadero
https://edn.embarcadero.com/article/..._OOP_Guide.pdf

Je connais ces manuels puisque je pratique turbo pascal depuis ses origines (1983).

Tes deux messages repris ci-dessus sont plutôt contradictoires...

Je travaillais à l'époque sur un PC Dual boot : MS-DOS/CPM 86. Quand on parle de POO on pense Smalltalk et descendants. Je cite un chapitre de ce manuel :
A note to you who have done object-oriented programming in other languages:
Put aside your previous impressions of OOP and learn Turbo Pascal 5.5’s object-oriented features on their own terms. OOP is not one single way;
it is a continuum of ideas. In its object philosophy, Turbo Pascal 5.5 is more like C++ than Smalltalk. Smalltalk is an interpreter, while from the beginning,
Turbo Pascal has been a pure native code compiler. Native code compilers do things differently (and far more quickly) than interpreters. Turbo
Pascal was designed to be a production development tool, not a research tool

Ensuite j'ai suivi (avec succès) les cours du CNAM pour comprendre le paradigme de la POO tel qu'il est enseigné pour UML. Les termes sont similaires (Héritage, Encapsulation,Polymorphisme,...) mais les réalités que recouvrent ces termes sont différentes .

Si tu le souhaites on peut reprendre pas à pas tous ces termes

Non merci.
J'ignore ce qui se cachait derrière ces termes à l'époque où Smalltalk a été créé.
Mais je connais ce que ces termes désignait à l'époque de Delphi 7 et ce qu'ils désignent encore aujourd'hui.
D'ailleurs la formation proposée par le CNAM est toujours présentée avec des diagrammes en UML.
http://deptinfo.cnam.fr/~graffion/UES/GLG101/POO.pdf
Alors reprendre les termes d'une POO selon Smalltalk ne m'intéresse pas.

Edit :
Libre à toi de suivre les paradigmes de Smalltalk.
Mais personnellement lorsqu'il s'agit de Delphi, je préfère y appliquer le paradigme de la POO tel qu'il est enseigné pour UML.

[ALWEBER]

Tes deux messages repris ci-dessus sont plutôt contradictoires...

Libre à toi de suivre les paradigmes de Smalltalk.
Mais personnellement lorsqu'il s'agit de Delphi, je préfère y appliquer le paradigme de la POO tel qu'il est enseigné pour UML.

Bonjour il est dit dans UML que les objets communiquent par message. Comment cela se passe t'il en Delphi VCL ?

[popo]

Tes deux messages repris ci-dessus sont plutôt contradictoires...

Libre à toi de suivre les paradigmes de Smalltalk.
Mais personnellement lorsqu'il s'agit de Delphi, je préfère y appliquer le paradigme de la POO tel qu'il est enseigné pour UML.

Bonjour il est dit dans UML que les objets communiquent par message. Comment cela se passe t'il en Delphi VCL ?

Je te faisais simplement remarquer que
- d'un coté tu dis ne pas trouver de notions de POO dans les documentations officielles de Delphi
- de l'autre lorsqu'on te donne les références, tu dis les connaître depuis longtemps.
Ces deux affirmations sont contradictoires.

Quand à la POO selon Smalltalk, encore une fois j'ignore ce qui s'y cache.
Mais la manière dont tu cites mon message pour ensuite poser ta question sur la VCL laisse à penser que tu souhaite me voir réagir sur le sujet.

Ma réaction va certainement te décevoir mais je ne vois pas où tu veux en venir.
Lorsque je regarde les sources de la VCL, j'y retrouve les paradigme de POO que j'ai toujours connus et que j'ai toujours modélisé en UML.
Et puisque tu affirmes toi même que les mots employés pour Smalltalk et pour UML sont les mêmes mais qu'ils n'ont pas la même signification, j'ignore comment faire le lien entre Smalltalk et la VCL.

[ShaiLeTroll]

Bonjour il est dit dans UML que les objets communiquent par message. Comment cela se passe t'il en Delphi VCL ?

La terminologie UML est franchement à chier, un message c'est juste une méthode du receveur
J'ai eu un stage de plusieurs jours en UML sur Delphi, je n'ai pas trouvé pas plus applicable qu'à l'école où j'étais une bille en Merise et UML.

En 20 ans, je n'ai jamais vu un seul diagramme de classe !
Quand je faisais un MOT ou un MLD\MPD dans mes projets, pas une seule personne pigeait, du coup j'ai arrêté et fait comme tout le monde : A l'arrache selon la météo !



Et mon dernier projet, pas loin de ma démission, j'ai tout fait dans les règles, en face des nuls qui ne comprenait rien, normal c'était des consultants SAP
Là juste l'interaction entre les programmes SAP (+ Dépendance) en bleu, le nouveau projet en violet et la phase de transition avec l'ERP Legacy en vert


Franchement faut pas être un génie pour comprendre des schémas aussi simple !
Moi, je peux le dire, on m'a dit que c'est complexe

[ALWEBER]

Parlons de ces langages : Smalltalk, Objective C, Pascal Objet
- Smalltalk est un langage de programmation orienté objet, réflexif et dynamiquement typé
(réflexif : capacité d'un programme à examiner, et éventuellement à modifier, ses propres structures internes de haut niveau lors de son exécution).

Fin1970, début 1980 passage de la programmation structurée à la programmation orientée objet vise à résoudre la problématique de la complexité croissante des programmes.
- Objective C se présente comme une surcouche du C pour permettre la création et la manipulation d'objets, en reprenant certains concepts du langage Smalltalk-80.
- Pascal objet tel qu'implémenté dans Turbo Pascal prédécesseur de Delphi reprend donc les techniques et évolutions d' Objective C, Smalltalk, C++
- POO - Aujourd'hui, la programmation par objets est vue davantage comme un paradigme, le paradigme objet, que comme une simple technique de programmation. C'est pourquoi, lorsque l'on parle de nos jours de programmation par objets, on désigne avant tout la partie codage d'un modèle à objets obtenu par Analyse Orientée Object (AOO).

La POO permet donc entre autres de penser objet et d'implémenter le code en faisant communiquer entre elles ou eux plusieurs OS, plusieurs Machines, plusieurs Langages.

Au sein de Delphi : Com/DCom, Corba, Midas, Datasnap vont dans ce sens

[popo]

Parlons de ces langages : Smalltalk, Objective C, Pascal Objet
- Smalltalk est un langage de programmation orienté objet, réflexif et dynamiquement typé
(réflexif : capacité d'un programme à examiner, et éventuellement à modifier, ses propres structures internes de haut niveau lors de son exécution).

Fin1970, début 1980 passage de la programmation structurée à la programmation orientée objet vise à résoudre la problématique de la complexité croissante des programmes.
- Objective C se présente comme une surcouche du C pour permettre la création et la manipulation d'objets, en reprenant certains concepts du langage Smalltalk-80.
- Pascal objet tel qu'implémenté dans Turbo Pascal prédécesseur de Delphi reprend donc les techniques et évolutions d' Objective C, Smalltalk, C++
- POO - Aujourd'hui, la programmation par objets est vue davantage comme un paradigme, le paradigme objet, que comme une simple technique de programmation. C'est pourquoi, lorsque l'on parle de nos jours de programmation par objets, on désigne avant tout la partie codage d'un modèle à objets obtenu par Analyse Orientée Object (AOO).

La POO permet donc entre autres de penser objet et d'implémenter le code en faisant communiquer entre elles ou eux plusieurs OS, plusieurs Machines, plusieurs Langages.

Au sein de Delphi : Com/DCom, Corba, Midas, Datasnap vont dans ce sens

Puisque l'objet pratiqué en Smalltack n'est pas celui de Delphi (car selon tes propres dires, Delphi a subi des évolutions), pourquoi venir en parler dans un sujet concernant Delphi ?

[popo]

En 20 ans, je n'ai jamais vu un seul diagramme de classe !
Quand je faisais un MOT ou un MLD\MPD dans mes projets, pas une seule personne pigeait, du coup j'ai arrêté et fait comme tout le monde : A l'arrache selon la météo !

C'est vrai que ça ne m'arrive pas souvent non plus.
En règle générale, un petit schéma tracé vite fait avec des bulles et des flèches suffit.
Et pour expliquer ce qu'est un singleton (parce qu'il faut bien revenir sur le sujet), c'est carrément inutile.

[ALWEBER]

Puisque l'objet pratiqué en Smalltack n'est pas celui de Delphi (car selon tes propres dires, Delphi a subi des évolutions), pourquoi venir en parler dans un sujet concernant Delphi ?

Parce que Turbo Pascal dans sa version Objet est inspiré indirectement de SmallTlak 80.
Pour revenir à la notion s'apparentant à un singleton le TDirectory ou le TTask dans Delphi XE+ me conviennent bien. Il y a de l'encapsulation et une structure de type record évite les problèmes d'héritage et conserve la notion d'unicité

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
  TDirectory = record
  public
.../...
  public
    class procedure Copy(const SourceDirName, DestDirName: string); static;
...

[popo]

Parce que Turbo Pascal dans sa version Objet est inspiré indirectement de SmallTlak 80.
Pour revenir à la notion s'apparentant à un singleton le TDirectory ou le TTask dans Delphi XE+ me conviennent bien. Il y a de l'encapsulation et une structure de type record évite les problèmes d'héritage et conserve la notion d'unicité.

Un record évite, et c'est logique, les problèmes d'héritages.

Mais parler d'unicité alors qu'un record est par défaut un type par valeur est selon moi une aberration.
Du coup, comme je suis plus habitué à Delphi 7, je suis allé vérifié ce qu'il en est dans un delphi récent et il s'avère que c'est toujours le cas à moins de veiller à en n'avoir qu'une seule instance (donc difficilement contrôlable sur un gros projets avec de nombreuses personnes) ou de passer par New et Dispose (ce qui n'est pas naturel pour un record)
Extrait de la documentation : http://docwiki.embarcadero.com/RADSt...Types_(Delphi)

Though records can now share much of the functionality of classes, there are some important differences between classes and records.

Records do not support inheritance.
Records can contain variant parts; classes cannot.
Records are value types, so they are copied on assignment, passed by value, and allocated on the stack unless they are declared globally or explicitly allocated using the New and Dispose function. Classes are reference types, so they are not copied on assignment, they are passed by reference, and they are allocated on the heap.
Records allow operator overloading on the Win32 platform; classes, however, do not allow operator overloading.
Records are constructed automatically, using a default no-argument constructor, but classes must be explicitly constructed. Because records have a default no-argument constructor, any user-defined record constructor must have one or more parameters.
Record types cannot have destructors.
Virtual methods (those specified with the virtual, dynamic, and message keywords) cannot be used in record types.
Unlike classes, record types on the Win32 platform cannot implement interfaces.