Discussion :

[ALWEBER]

...
la POO c'est de la la programmation orientée objet, si tu utilises des objets c'est de la POO
...

Non Paul. Il y a la POO d'un côté et Object Pascal de l'autre. Il est possible de faire une programmation de Type POO avec Delphi. Pour ne prendre que quelques éléments, la signification des termes polymorphisme, encapsulation et héritage recouvrent des réalités différentes en POO et en Object Pascal. Reprendre à ce sujet les premières versions des manuels Delphi à ce sujet (ou dernières versions de Turbo Pascal)
Voici un lien vers le manuel POO Delphi 5
https://drive.google.com/file/d/1JXQ...ew?usp=sharing

[ShaiLeTroll]

Non Paul. Il y a la POO d'un côté et Object Pascal de l'autre. Il est possible de faire une programmation de Type POO avec Delphi...

Paul a parlé d'objet et non d'Object Pascal dans sa phrase : "la POO c'est de la la programmation orientée objet, si tu utilises des objets c'est de la POO"
Je ne vois pas le rapport de ta remarque négative et pas plus ce qui te sert d'appui sur la documentation jointe.

Après il y a de la bonne POO et de la mauvaise POO
Faire des objets au pif, sans architecture, sans réflexion, tu obtiens un code pire que si il avait été procédural.
On a inventé les Design Patterns pour faire de la belle POO.


Sinon, personnellement pour les objets ORM, j'évite le TObjectList<TClient>, cela devient vite très lourd, je le fais mais rarement.
Je me suis fait une couche d'objet business qui fonctionne via un DataSet et le l'objet comme ce TClient n'est juste qu'un curseur sur le DataSet pour un accès plus lisible, des accesseurs protégés, une validation globale ...
Ainsi le même objet TClient peut-être instancié comme objet unique ou comme objet collection

[ALWEBER]

Bonjour ShaiLeTroll

Il n'y a rien de négatif dans mon affirmation et ja la maintiens.
J'apprécie la qualité du travail de Paul et ses compétences

Tu verras dans le manuel que j'ai mis en accès qu'il n'est fait nullement référence à la POO. Ce manuel date de la fin des années 90. Le paradigme de la POO est beaucoup plus ancien puisqu'il date je crois des années 70 et de Smalltalk et doit sa célébrité à UML et Java. Il s'est greffé progressivement à Delphi ce qui permet aujourd'hui de l'utiliser avec le langage Object Pascal. Si tu le souhaites je répondrai point à point via mon blog sur ce sujet

[ShaiLeTroll]

il n'est fait nullement référence à la POO

Ah oui ?

Le Pascal Objet est un langage compilé de haut niveau à types stricts qui gère la
conception structurée et orientée objet. Ces qualités sont la lisibilité du code, une
compilation rapide et l’utilisation d’unités multiples permettant une
programmation modulaire.

Tiens, le même un plus tard récent en anglais


Il évoque la OOD (Oriented-Object Design) qui justement est la base d'un bonne OOP
Pas de conception, pas de bonne programmation

Après, non, je me dispenserais de ton blog, c'est un débat de terminologie qui ne sert pas à grand chose.

[ALWEBER]

Voir le lien Wikipédia
https://fr.wikipedia.org/wiki/Progra...t%C3%A9e_objet
Tu verras que l'on ne parle pas d'Object Pascal dans ce wiki
Par contre on y trouve une référence à COM/DCOM et CORBA implémenté en Delphi

[ShaiLeTroll]

Mon but est :
Select * from TClients

Chez nous la table fait 10 000 000 millions d'enregistrement et l'on a un CRM qui gère du déboulonnement
Une très mauvais approche en terme de performance


Réponse au HS de ALWEBER : https://en.wikipedia.org/wiki/List_o...ming_languages
Source libre au contenu variable selon les pays et les contributeurs

[anapurna]

Bonjour

le polymorphisme dans ton cas pourrais très bien
ce faire sur cette base

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
 
TPersonne = Class()
....
end;
 
TClient          =  Class(TPersonne)
....
end;
TFournisseur =  Class(TPersonne)
....
end;
...
TModulePersonnes = TModule ;
  ...
  Procedure AddPersonne(Personne : TPersonne);virtual;
...
end;
 
TModuleClient = TModulePersonnes 
....
end;
 
TModuleFournisseur = TModulePersonnes 
....
end;
 
....
 
Procedure ModulePersonnes.AddPersonne(Personne : TPersonne);
begin
  // ici j'ajoute la personne ou son decendant dans un datasource ou dans une liste c'est comme on veux
end;

l'avantage étant de ne changer que l’ancêtre pour que les enfants puissent en profiter

[ALWEBER]

Pour répondre au message initial. En utilisant un SGDB type SQL Server ou MYSQL les composants d'accès comme Firedac sont beaucoup plus riches en terme de possibilités. Quand j'utilise la POO c'est plutôt pour fabriquer des outils comme par exemple un générateur de formes 3D, ou améliorer une fonction existante comme la gestion dynamique du multiliguisme dans une application

[ShaiLeTroll]

les composants d'accès comme Firedac sont beaucoup plus riches en terme de possibilités.

C'est parce qu'il manque en Delphi un équivalent de LinQ, MyBatis ...
je pense au defunts BOLD, InstantObjects ... ça c'était des ORM (une chier de POO dedans avec du Pattern Strategy, Observer, Bridge ...)

On peut appliquer la POO à un niveau business mais il est vrai que c'est plutôt d'abord qu'on se construit son Framework ou Library
ALWEBER évoque une POO à un niveau de programmation technique, niveau Framework mais pas un au niveau métier.

Il est très fréquent chez un développeur expérimenté de ne pas perdre son temps avec une couche métier lourde classe en se reposant sur le TDataSet et quelques assistants.
La POO étant réservée à du code intéressant (oui le métier c'est chiant)

Je ne crois pas que l'on aide jojo86 à comprendre grand chose dans sa problématique
Je pense que jojo86 tente une "figure de style"
Il pense code avant de penser architecture, c'est ce que l'on fait tous quand on débute,
on expérimente puis on comprend ensuite que tout va plus loin que l'on ne le croyait.


Après, utilisez la POO pour la couche business, c'est bien pour se former, s'améliorer pour un jour faire justement des choses plus techniques.
Surtout que pour un salon de coiffure, la volumétrie sera tellement faible que le code pourra être lourdissime que cela ne proposera pas de problème.

Sinon, depuis le début, jojo86 n'a jamais montré qu'il avait besoin d'une application du polymorphisme
C'est juste une manipulation de Collection d'objet des plus lambda
Il faut d'abord effectivement maitrisé parfaitement les TDBGrid et le TDataSet
Puis l'idée d'un Helper sur le TDataSet générique + RTTI pour lié à une classe permettant d'assurer la cohérence de données est une première approche à creuser
Ensuite, une fois tout ça maitrisé, passer au développement de sa propre couche ORM qui encapsule le TDataSet si l'on souhaite que l'application contiennent les règles métiers
C'est dans la couche ORM où arrive les concepts d'encapsulation, d'héritage, de polymorphisme car cela doit gérer des cas variés pour supporter les différentes natures et interactions des objets métiers.

En Delphi, faut être honnête, on voit finalement beaucoup plus de règle métier géré par les SGBGR à coups de CONSTRAINTS, TRIGGER, PACKAGE ... et une application qui ne sert que d'affichage
Suffit de voir les offres d'emplois où la compétence SQL / PL SQL / T-SQL est plus importante que la compétence DELPHI