Discussion :

[seb92400]

Hello...

Voilà, je me lance, je suis nul !!!!! Ca, c'est dit...

Sérieusement, voilà un bout de document qui me pose de graves problèmes :

La programmation objet vaut largement celle de Visual Basic.

On peut programmer aussi clairement et aussi mal qu’on le souhaite, avec n’importe quel langage. Profitons en donc pour conseiller à tous les programmeurs Access et VBA d’utiliser
 un minimum de code dans les formulaires et états (l’interface utilisateur). Typiquement, un événement contient une ligne d’appel à une propriété ou méthode d’un objet métier, récupère éventuellement quelques valeurs en retour, et du code de contrôle d’erreur.
 effectuer tous calculs dans des modules de classe indépendants des formulaires, les objets métier. Ces objets permettront de se débarrasser des innombrables variables globales, mais surtout donneront une structure très claire et facile à maintenir à l’ensemble de l’application. Et pourront être copiés dans Visual Basic, si besoin est !
 regrouper en une classe ou objet d’accès aux données tous les accès à la base. Cette question est simple mais délicate, car il faut éviter tout conflit entre l’accès aux données directement par un formulaire, dans l’interface, et les accès depuis le code VBA.

Voilà quelque mots écrits par un personnage que je ne connais que virtuellement mais que j'apprécie beaucoup... Seulement, je suis vraiment nul, car ça fait un bout de temps que je potasse, que je lis des tutoriels, etc... Et je n'arrive toujours pas à comprendre pourquoi, comment, où, quand, etc... il faut faire de la programmation objet !!!!

Voilà, donc j'ai deux questions :
1. Est-ce que quelqu'un pourrait en quelques mots m'expliquer ce concept de programmation objet et l'avantage par rapport à des fonctions écrites dans des modules simples plutôt que des modules de classe (car si j'ai bien compris, la programmation objet, ce sont des modules de classe)
2. C'est quoi les objets et les règles métier ???

Merci d'avance si vous pouvez éclairer ma lampe de bureau... PS, j'ai lu les tutoriels, donc pas la peine, je connais les liens, et bien que j'ai compris à peu près la façon de faire, je n'en vois pas trop l'interet, ni comment intégrer ce concept dans mes bases de données...

Merci...

[seb92400]

Re...

J'ai trouvé ce genre d'infos (parmi beaucoup d'autres cours dispo sur la POO)... ICI

Ca n'empêche que j'ai du mal à en saisir le principe... Je comprends parfaitement comment on programme, comment on appelle, etc...

Mais ce que je ne comprends pas, c'est "pourquoi" ???

Pourquoi faire des classes alors qu'une fonction peut suffire ? Quel est l'interêt ??



Les exemples que je trouve : L'objet est un article - les attributs sont la référence, la désignation, le prix unitaire et la quantité - les méthodes sont le calcul du prix ttc, la sortie de l'article et l'entrée de l'article.

Ok, je vois... Mais j'ai déjà une table qui repertorie mes articles et leurs attributs et des fonctions écrites dans des modules que j'appelle quand j'en ai besoin...

Je trouve aussi clair de placer des fonctions dans un module et de les appeler quand j'en ai besoin que de créer des modules de classe avec les mêmes fonctions et d'instancier des objets pour avoir le même résultat et ensuite détruire mon objet.... Ou alors, je n'ai rien de rien compris à tout ce que j'ai lu...

Donc bref : En un mot, je ne cherche pas à ce qu'on m'explique comment on fait de la POO, mais pourquoi... Et je crois que tant que je n'aurais pas compris ça, je vais avoir du mal à me lancer dedans... Pourtant, tout le monde s'accorde à dire que c'est bien, la POO !!!

Bon, allez, je vais me mettre encore quelques

[jnore]

Ca fait plaisir de voir que je ne suis pas le seul ....
A vrai dire je suis comme toi. J
'ai commencé sous access et actuellement je suis en PHP pour gérer mes bases.
La notion d'objet, on la voit toujours...mais un peu de loin. A se demander si c'est vraiment utile!
A ecouter les experts, il semblerait que oui.
Notamment lorsqu'il y a une équipe projet, il est facile de confier une partie du code à telle ou telle équipe.
Au final, sans concertation (ou presque), il est possible de compiler un ensemble de code qui font une application. Le but ultime, je crois est d'organiser le code, de le hiérarchiser donc le maintenir simplement.

Pour ma part, je n'en ai pas l'utilité (cela ne veut pas dire qu'il n'y en a pas).
Je programme seul et je suis le seul à maintenir mes codes...donc pas de souci

Je pense qu'à environ 80% des visiteurs de ce site, il doit en être de même.(j'espère que je n'y vais pas un peu fort !!!)

Il devrait y avoir un sondage à ce sujet !!! pour en avoir une idée.

En totale compréhension avec toi , Jnore

[seb92400]

Hi,

Notamment lorsqu'il y a une équipe projet, il est facile de confier une partie du code à telle ou telle équipe.
Au final, sans concertation (ou presque), il est possible de compiler un ensemble de code qui font une application. Le but ultime, je crois est d'organiser le code, de le hiérarchiser donc le maintenir simplement.

En fait... Je le fait déjà ça, j'ai des modules (mais des modules standards) que j'utilise dans toutes mes applis : Un module pour connecter la base dorsale, un autre pour l'utilisation de MsgBox Avancées, un autre pour mes variables générales (d'ailleurs là, ça rejoint l'article de Papy Turbo qui n'aime pas ces variables et les remplacent par une classe (voir mon premier messaqge)), un autre pour la gestion de la résolution, un autre pour........

Bref... A priori, je devrais m'orienter vers les modules de classe, mais je n'y arrive pas... Les tutos la dessus sont très bien faits... D'ailleurs, afin de cultiver mon ignorance, j'ai relu, hier soir, une ultime fois ceux qui concernent la POO et les classes... Ils sont très bien faits, ils sont très compréhensibles, mais...

Si quelqu'un avait un exemple concret et imparable (genre je me prends une grande giffle (virtuelle, hein !!)), je suis preneur... Quelque chose qui me fasse le déclic quoi...

Voilà le 'tit sondage : J'ai mis "jamais", mais je ne demande qu'à changer d'avis....

[cafeine]

Hello,

loin d'être un expert, pour moi la programmation objet devient vraiment utile lors d'un travail collaboratif ou qui est susceptible d'être repris par un tiers.
Ce n'est pas le cas lors d'un développement individuel ou occasionnel pour répondre à un besoin ponctuel.

[boubounne]

Je programme en objet depuis 3 ans deja, et franchement, c'est un developpement qui vous change la vie :
1) pas besoin de remodeler tout ton code en cas de probleme, si il faut rajouter une fonction, tu la rajoute dans ta classe.
2) un objet est facile a creer et tu peut en creer autant que tu veut (ou que ta ram te le permet..) exemple, lors d'un de mes projet, j'ai du creer 500 objet, ca ne ma pris que 3 lignes de code...
3) ca permet de regrouper les fonctions des différents objets dans des "classes meres", resultat, chaque classe "fille" de la classe mere pourra faire les memes choses, et plus encore.
4) la maniere de programmer est totalement différente, peut modifier la connexion a la base de données, l'ihm, ou rajouter des classes sans avoir a modifier le reste du code... (ex : un programme tourne sous access, on veut changer pour oracle -> dans la classe de connexion, on change une ligne et tout le programme se connecte a oracle...)

c'est une petite partie des avantages de l'objet, et j'en oubli encore plein la dedans..
Bien sur au niveau SGBD, ca ne sert pas a grand chose de faire de l'objet, mais, du point de vue programmation, l'objet montre un aspect super appreciable.

Mais tout depend egalement de la taille du programme.

[jnore]

Je ne programme rien en POO, j'ai du mal, à mon niveau à générer du code.
J'ai donc voté 'Jamais'

Par contre je suis utilisateur de classes en PHP (phpToPdf) ,...(Ok ici on est au vba!!!), et bien là il faut reconnaitre que la POO a son intérêt,... quelques instructions et le pdf est généré.

Perso, ce qui manque à ma compréhension des classes, c'est QUAND faut-il commencer à penser POO?

J'avoue (peut-être paceque je suis nul), que j'ai essayé de me mettre au java, bouquin en main. Je l'ai refermé et remis au placard...
Pourquoi? c'est un language qui est pratiquement du pur POO. Certaines notions m'échappent encore d'où mon abandon.

Mais j'y retournerai, si le temps m'en est donné.

[boubounne]

Je suis d'accord que attaquer la POO comme ca (meme avec tuto), c'est chaud, pour savoir quand programmer en POO, c'est une bonne question, ce n'est pas trop de savoir quand, mais ce que va faire ton application surtout. SI par exemple tu as une base de donnée contenant 20 tables, et des formulaires a faire dessus, la POO sera un allier de taille, si ton programme a besoin d'evolutions rapides sans faire forcement de nouvelle version, la POO est encore super utiles. Maintenant, c'est juste une maniere de programmer, rien ne t'empeche de faire en normal ce que tu pourrait faire en POO.

D'un autre coté, la POO diminue ton temps de programmation, si tu a compris les grandes lignes.

Il faut d'abort connaitre le fonctionnement de la POO (un peu comme le Merise) pour comprendre ce qu'elle va t'apporter. Les principales notions étant :
1) l'heritage (super pratique)
2) la surcharge
3) le polymorphisme
4) la notion de methode et d'attributs

une fois ca compris, attaquer l'UML devient plus facile, mais la encore, tout UML n'est pas necessaire pour commencer, mais surtout le diagramme de classe, et le diagramme de sequence (quoi que je ne l'utilise que rarement...)

Apres, le langage n'est pas important, C#, JAVA, PHP object, oracleObjet...

apres, ce qu'il faut, c'est reussir a avoir la vision de tes classes, tout comme en merise tu voit a quoi va ressembler tes methodes.

[random]

Dans l'environnement access le besoin de programmation orientée objet n'est pas évident.

Et pourtant nous programmons tous objet sans en prendre conscience, en fait
l'essentiel des programmes acces utilise des instanciations d'objets fournis avec acess.

Le programme le plus fréquent est du type

set mabase=currentdb() 'création d'un objet base dao
set monrecord=mabase.openrecordset("machin") 'méthode appliquée à un objet+instance de mon recordset
etc...
C'est la richesse de ces collections qui rend souvent inutile la poo
Par contre la souplesse et la sécurité apportée par cette méthode ne nous échappe pas

quand je songe à un objet dao.field avec son polymorphisme, ses propriétés à la facilité et à la sécurité qu'il offre à la manipulation, je me dis que faire la même chose (même en travaillant seul) en procédural ce serait plus difficile.

par contre quand on ajoute à access des composants métiers un peu ingénieux, en songeant à une réutilisation excel par exemple, la poo peut rendre de grands services.

ceci dit on peut toujours faire la même chose en procédural...

Maintenant pour répondre à boubounne

S’il faut rajouter une fonction tu la rajoutes dans un module
Une variable est facile à créer et il existe des types définis par l’utilisateur , un array est facile à manipuler, et 500 objets cela me parait bien beaucoup même au prix de 3 lignes de code
Un module peut appeler le contenu d’un autre module, c’est aussi de l’hérédité
On peut programmer une connexion avec une fonction vba
Pour moi la poo n’a pas changé ma vie, mais si tu es à l’aise avec cette approche des problèmes et si elle te convient il faut continuer.

Dernier point si j’observe les questions de programmation évoquées dans le forum access, et les solutions qui leur sont apportées, l’usage de l’objet m’apparaît rarissime, et les exemples de code de la faq lorsqu’ils utilisent les notions d’objet pourraient parfaitement s’en passer, je
Soupconne d’ailleurs certains rédacteurs d’avoir utilisé l’objet plus à des fins (auto ?)didactiques que par réflexe.

[seb92400]

Il faut d'abort connaitre le fonctionnement de la POO (un peu comme le Merise) pour comprendre ce qu'elle va t'apporter. Les principales notions étant :
1) l'heritage (super pratique)
2) la surcharge
3) le polymorphisme
4) la notion de methode et d'attributs

Il est bien là le souci... C'est qu'à force de lire des documents portant sur ce sujet, notamment en Java et C++, je vais finir par connaître par coeur ce que sont ces définitions... et pourtant, je ne vois pas l'intérêt de passer à la POO avec Access... Et ça m'inquiète, car j'aimerais vraiment, même si je ne m'en sers jamais, me dire "ah oui, tiens, la poo m'aiderait à faire ça plus simplement..." (-ou une autre réflexion dans ce style).

SI par exemple tu as une base de donnée contenant 20 tables, et des formulaires a faire dessus, la POO sera un allier de taille, si ton programme a besoin d'evolutions rapides sans faire forcement de nouvelle version, la POO est encore super utiles.

Ca, je ne comprends pas..... Je peux très bien apporter de nouvelles fonctions à mes modules ou faire évoluer mon appli sans faire de grandes modifs à celle-ci....

Pour prendre un exemple concret (simplifié) : Je conçois une application avec trois tables (clients, commandes, paiements), quelques formulaires la dessus... Je créé des modules (normaux) pour valider certaines données (numéro de commande incrémenté non auto, mise en majuscule des noms, placement du curseur au début des champs formatés, etc...) et j'appelle les procédures ou fonctions des modules de formulaires...
J'ai d'autres modules : Connexion à la base de données dorsale, gestion des erreurs, etc...
Bref... Ca fonctionne très bien, si j'ai une erreur de connexion, je sais que l'erreur vient forcément du module "modConnexion", si le nom ne se met pas en majuscule, je sais que ça vient soit de l'appel de la fonction, soit du module "modMiseEnForme", si le curseur ne se place pas au début du champ, je sais que l'erreur vient du module "modSelection", etc...........

Maintenant, mon client me demande d'ajouter un champ qui affiche le prénom suivi du nom dans le même champ. Pas de souci, j'ajoute une fonction fctNomComplet dans un module existant qui traites des actions sur le client, et j'appelle cette fonction dans mon formulaire client...

Donc : Pour cet exemple tout simple et pourtant complet, que vont m'apporter les modules de classe et la POO ? Je sais, je suis un peu "relou" avec mes questions, mais j'ai vraiment du mal.... j'aimerais vraiment, vraiment, vraiment... comprendre !!!

[francishop]

Bonsoir,

Je sais, je suis un peu "relou" avec mes questions...

Au contraire! C'est formidable d'aller au fond du sujet. Bravo!

Cordialement.

[seb92400]

Au contraire! C'est formidable d'aller au fond du sujet. Bravo!

Voilà le genre de petites phrases que j'aime bien... qui passent et qui font beaucoup, beaucoup de bien !!!

Merci à Toi !

[boubounne]

Je n'ai pas dit que au niveau SGQB, l'objet est tres utile... :

Bien sur au niveau SGBD, ca ne sert pas a grand chose de faire de l'objet, mais, du point de vue programmation, l'objet montre un aspect super appreciable.

Apres, comme l'a dit random,

Et pourtant nous programmons tous objet sans en prendre conscience, en fait
l'essentiel des programmes acces utilise des instanciations d'objets fournis avec acess.

Le programme le plus fréquent est du type

set mabase=currentdb() 'création d'un objet base dao
set monrecord=mabase.openrecordset("machin") 'méthode appliquée à un objet+instance de mon recordset
etc...
C'est la richesse de ces collections qui rend souvent inutile la poo

Seulement, j'allie souvent mes programmes (JAVA ou .net) avec une base de données conséquante, et grace a l'objet (et nottement au mapping), ma programmation devient plus claire et plus rapide (desolé si je me suis mal exprimé...)

Ensuite, le fait de faire des modules que tu appel pour ta connection ou pour mettre en gras, etc... cela ressemble deja pas mal a de l'objet, sauf qu'en objet, on met ca dans des classes. Mais ce n'est pas a ce niveau la que l'objet est le plus efficace, mais bien sur ce qui est heritage, collection, polymorphisme, etc...Apres si tu souhaite faire une base de données en objet, deja je te previent, ce n'est pas un jeu d'enfant, de plus, pour le moment, cela n'a pas de réel utilité, et ce a cause du mapping qui permet de passer du langage sql vers de l'objet..

Et ça m'inquiète, car j'aimerais vraiment, même si je ne m'en sers jamais, me dire "ah oui, tiens, la poo m'aiderait à faire ça plus simplement..." (-ou une autre réflexion dans ce style).

Dans access, je n'en voit pas l'utilité non plus, mais si tu programme à coté (.net ou java), la tu verra l'utilité de l'objet.

500 objets cela me parait bien beaucoup même au prix de 3 lignes de code

Une fois les objets instanciés, il n'en faut gere plus pour recuperer le données de tes tables, mais je voyais ça avec du mapping desolé de pas l'avoir indiqué...

[seb92400]

Hello,

(desolé si je me suis mal exprimé...)

Pas la peine de s'excuser, j'ai juste ouvert une discussion libre (pas de pour, pas de contre) simplement parce qu'un jour j'ai lu quelque chose comme ça : Il faut utiliser les Classes dans Access car blablabla...

Hors, je ne vois pas trop l'utilité de ces classes (qu'on associe à la poo) lorsqu'on programme une base de données...

Effectivement, le fait de faire des modules séparés est déjà à la base un genre de poo... et à priori, les tranformer en modules de classes serait mieux...

Bref, je vais continuer de potasser... et juste pour que je comprenne si je retombre sur ce mot, le mapping, c'est quoi ?

[boubounne]

Le mapping....comment dire

Tu prend une base de donnée (genre oracle), ou tu a des tables de partout..
tu souhaite faire un programme en java par exemple.. tu créé tes classes, mais c'est chiants de devoir faire un truc du genre :

créer la requete
faire ta connexion
recueperer les données
parcourir tes données
creer un objet
remplir ton objet avec les données

et recommencer n fois pour creer un simple tableau

le mapping, c'est un fichier XML (un fichier par classe), qui va communiquer avec ta base de données (donc en relationnel), et passer tes donner dans tes classes ( en objet)

resultat, plus de requetes bien lourdes et gourmandes en ressources, tu créer un fichier XML tout bete et simple a modifier, tu l'associe a une classe, tu lance la procedure qui va bien (abracadabra....) et hop 50 objets créés rapidement en 3 lignes de code....dans ton tableau...

de plus il permet de faire de la persistance de données, et si tu modifie tes objets, il modifie tout seul ta base de données

pour plus d'information, va voir Hibernate (c'est pour java) ou Nhibernate (pour .net) sur le net, ce sera peut etre plus clair que moi.

[seb92400]

Déjà là, ça me parait un peu plus clair... Merci à toi...

Et dire que j'ai envie d'apprendre Java....... Allez, encore un peu :

[boubounne]

Maintenant pour te repondre sur l'histoire de faire des modules de classes, oui ca peut etre utile, maintenant, il faut voir l'utilité que tu en a. Les notions d'objets, je le pense du moin, ne sont pas ultra super utiles en BDD.

Il est vrai que c'est plus une habitude de programmation, j'ai programmé d'abord sous JAVA, puis VB.net, C#, ASP, ... et depuis, tout ce que je fait est objet.

Mettre ton code dans un module de classe te permettra de voir ta base un peu autrement,

je m'explique :

tu créer un module de classe (dison ClassePersonne) dont les attributs sont ceux de ta table (TablePersonne). tu remplit cet objet avec les données de ta table (Nom, Age Adresse, metier....) , dans ce cas tu vas pouvoir definir des actions a cet objet :

Ajouter Adresse
Changer nom
Changer metier
ajouter metier( dans le cas ou il peut en avoir plusieurs...)

et la tu ne travail plus avec ta table, mais avec les objets, puis tu enregistre le tout une fois que tu as fini. Bien sur tu peut faire les memes choses a grand renfort de vba, ou de requete select, update... Mais faire des modules et leurs donner une tache précise (comme la connection) revient en quelque sorte a faire de l'objet...

Apres lequel est le mieux, franchement, aucune idée, personnelement j'utilise l'objet, apres les modules "classiques" permette de faire la meme chose, c'est juste une question de logique et d'habitude

[micniv]

Intéressante cette discussion.
Pour ma part je n'utilise des classes d'objet que lorsque c'est indispensable :
Illustration par l'exemple : j'ai eu à créer un système d'alarmes (de rappels téléphoniques) avec reprise à chaud (c'est à dire que si la base se ferme pour une raison quelconque, volontaire ou pas, les alarmes actives sont relancées).
On a 2 options pour programmer cela :

• sans les classes, tu dois te fixer un nombre maximal d'alarmes actives par frontal, par exemple 10 : cela signifie que tu dois créer et gérer les 10 formulaires (par ex Alarm1, Alarma2 ...) qui seront lancés pour les alarmes.

• avec une classe alarme, tu lances une nouvelle instance de l'objet pour chaque nouvelle alarme : un seul code à entretenir et pas de limitation du nombre d'instances !

Donc utiliser les classes chaque fois qu'on doit utiliser plusieurs fois et simultanément le même formulaire .

[seb92400]

et la tu ne travail plus avec ta table, mais avec les objets, puis tu enregistre le tout une fois que tu as fini. Bien sur tu peut faire les memes choses a grand renfort de vba, ou de requete select, update... Mais faire des modules et leurs donner une tache précise (comme la connection) revient en quelque sorte a faire de l'objet...

Elle est donc la la solution ... Depuis le début je me disais que je faisais la même chose avec mon code et mes tables... et je ne comprennais donc pas pourquoi mettre en place une solution avec modules de classe... (du moins pur l'exmple que tu me donnes)... J'avais bien compris effectivement les notions liées aux objets mais pas le pourquoi...

Donc utiliser les classes chaque fois qu'on doit utiliser plusieurs fois et simultanément le même formulaire

Je commence à bien saisir le fonctionnement là...

Encore une 'tite question tant qu'on y est, je reviens à la discussion du départ :

 effectuer tous calculs dans des modules de classe indépendants des formulaires, les objets métier. Ces objets permettront de se débarrasser des innombrables variables globales, mais surtout donneront une structure très claire et facile à maintenir à l’ensemble de l’application. Et pourront être copiés dans Visual Basic, si besoin est !

Pourquoi ne pas utiliser de variables globales, et surtout comment on s'en débarrase ?

Par exemple, j'ai un formulaire qui prend les coordonnées de la société utilisatrice et son nom. Plutôt que de créer une variable globale qui va s'appeler varNomSociete, je devrais plutôt créer une classe SocieteUtilisatrice que j'instancie à l'ouverture de la base, qui récupère les données écrites dans la table tblSociete, et lorsque j'aurai besoin de ces donées, dans un formulaire, je créé un objet objSociete et si je veux le nom dans un champ, j'utilise Me.monChamp = Societe.Nom (plutôt que d'utiliser Me.MonChamp = varNomSociete)

Dans ce cas, j'ai l'impression de devoir écrire beaucoup de code pour pas grand chose... Ou est l'avantage de supprimer les varaibles globales ?

Merci pas avance...

[boubounne]

comme la dit micniv :

sans les classes, tu dois te fixer un nombre maximal d'alarmes actives par frontal, par exemple 10 : cela signifie que tu dois créer et gérer les 10 formulaires (par ex Alarm1, Alarma2 ...) qui seront lancés pour les alarmes.

avec une classe alarme, tu lances une nouvelle instance de l'objet pour chaque nouvelle alarme : un seul code à entretenir et pas de limitation du nombre d'instances !

dans ce cas tu a besoin soit de 10 variables globale (une par nom pour ta societe), soit de une seule classe objet, c'est au choix....