Discussion :

[zais_ethael]

VB a introduit un concept novateur qui est le typage intrinsèque ce qui permet de faire abstraction du polymorphisme .

Si j'ai bien compris, c'est du dynamiquement typé sauf que ça ne s'applique pas aux données de base du langage (string, int,...)?
Autre question: c'est possible de faire de l'héritage (non pas que ce soit indispensable pour une approche POO mais ça a son utilité)?

[philben]

re-bonjour zais_ethael,

si les 3 principes de base de la programmation objet sont :

• Encapsulation;
• Polymorphisme;
• Héritage;

seul le premier est supporté.

En résumé :

• Encapsulation

Données de l'instance : Private ou Public
Attributs communs entre instances : NON
Types de propriétés : Get, Let (avec même nom si on veut)
Types de méthodes : Function, Sub (Public / Private / Friend / Static).

• Polymorphisme

Surcharge interdite mais possibilité de passer par des Variants.

Certaines liaisons tardives sont réalisables

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
 
...
   Dim o1 As POO
   Dim o2 As POO2
   Dim ooo As Object
 
   Set o1 = New POO
   Set o2 = New POO2
 
   o1.Nom = "OO1"
   o2.Nom = "OO2"
 
   Set ooo = IIf(Timer() Mod 2 = 0, o1, o2)
   Debug.Print ooo.Nom
...

• Héritage

Non

• Divers

1. On peut déclencher un évènement pour l'utilisateur
2. On peut bien sûr instancier une classe dans une autre
3. Méthode Static sans attribut commun

C'est du rustique !

Résumé à corriger ou à compléter !

cordialement,

Philippe

[Shakram]

Joli résumé philben.

Je n'utilise pas la POO dans Access du fait qu'il ne supporte justement pas tous les principes décrits.

[rawsrc]

je me suis penché sur la poo pour vba, il y a 5 ans et je dois avouer que je l'utilise absolument partout. Excel Word, Access.

Bien que les principes pures de la poo ne soient pas implémentés dans le vba, on peut quand même y trouver des adaptations qui ne soient pas lourdes à coder.

Personnellement, l'intérêt de la poo réside dans le travail préparatoire au développement. Tu visualises plus concrètement ce que tu codes ou devra coder. Plus le projet est gros et plus la représentation objet est utile. Il est de loin préférable de manipuler des objets qui sont autodescriptifs que d'être toujours obliger d'aller fouiller son code pour savoir quel nom de fonction ou de variable globale il faut appeler.

Et puis les modules de classes autorisent la création et le déclenchement d'évènements personnalisés donc pour une application MDI, c'est le bonheur.

Enfin, gérer les formulaires pour ce qu'ils sont (càd des instances de classe) permet d'avoir une main mise totale sur leur manipulation. Au final, il est tout à fait possible de bâtir les formulaires autour des classes métiers et ce en les gardant entièrement indépendants (=> vitesse, légèreté)

Ouala

[seb92400]

Hi,

Très heureux que ce sujet soit toujours fréquenté...

Comme je suis totalement autodidacte en programmation, j'ai du zapper quelques définitions, et notament : J'entends souvent parler d'objets métiers, de classes métiers... C'est quoi, des "métiers" ??

Personnellement, l'intérêt de la poo réside dans le travail préparatoire au développement. Tu visualises plus concrètement ce que tu codes ou devra coder. Plus le projet est gros et plus la représentation objet est utile.

C'est ça que je n'ai pas encore compris...

Et puis les modules de classes autorisent la création et le déclenchement d'évènements personnalisés donc pour une application MDI, c'est le bonheur.

Pour les déclenchements, oui, ok, ça, j'ai compris... mais dans le cadre d'une MDI, quel est l'avantage ? On peut très bien autoriser ou pas l'ouverture d'une fenêtre avec un simple test booléen... (je ne critique pas, hein je ne demande qu'à apprendre...)

Il est de loin préférable de manipuler des objets qui sont autodescriptifs que d'être toujours obliger d'aller fouiller son code pour savoir quel nom de fonction ou de variable globale il faut appeler.

Bah... Si j'ai une fonction qui permet de transformer une chaine en nom propre, ou bien de remplacer les "," ou ";" ou autre d'un e-mail, elles sont dans un module, bien étiquetées, portant le nom mduChaine... Quant à mes variables globales, elles sont également déclarées dans un autre module... Peut-être que je ne vois pas trop l'avantage car mon code est bien organisé...

Enfin, gérer les formulaires pour ce qu'ils sont (càd des instances de classe) permet d'avoir une main mise totale sur leur manipulation. Au final, il est tout à fait possible de bâtir les formulaires autour des classes métiers et ce en les gardant entièrement indépendants (=> vitesse, légèreté)

Oui, c'est à dire, se servir d'une classe pour crééer un genre de "table temporaire" qui va stocker et valider les infos du formulaire avant qu'elles ne soient enregistrées ?

Merci... Bon week-end à toutes et tous...

[rawsrc]

J'entends souvent parler d'objets métiers, de classes métiers... C'est quoi, des "métiers" ??

Les classes métiers correspondent à l'ensemble des classes ayant un rapport direct avec la problématique centrale du programme. Par exemple, récemment j'ai codé une bdd suivant les carnets de vaccination, mes classes métiers étaient : clsPatient, clsVaccin, clsVisite...
Le métier regroupe tout ce qui ne peut être reprit dans une autre application sous peine de la copier. Dans mon exemple, la gestion des formulaires et l'accès aux données... sont quasiment génériques et peuvent être réutilisés presque tels quels dans d'autres applications, ces classes ne sont pas qualifiées de "métier".

Le travail préparatoire et la modélisation de la problématique (obligatoire) avant tout développement doit être en prise directe avec la réalité du problème à résoudre. Chaque partie (client / développeur) a sa propre problématique, mais au moment de l'expression du besoin, il est obligatoire de bien se comprendre. Le client va parler un langage correspondant au métier que le programme devra gérer et le développeur aura la tâche (souvent ardue) de modéliser cette attente. C'est au développeur de se mettre au niveau du client et de son métier, de l'aider à exprimer le plus exhaustivement sa problématique.
Dans mon exemple de bdd, j'ai cerné le métier et il a été bien plus facile pour le client d'expliquer sa problématique avec des mots tels que Patient, Vaccin, Visite et Vaccination que je ne sais quel autre jargon informatique.
Une fois ce travail accompli, j'ai réutilisé tout ce vocabulaire métier en isolant mes classes métiers.
Au moment de la recette, quand un problème survient, il t'est possible d'aller voir ton client et lui dire tout de suite : il y a un os dans le suivi de la vaccination car le problème est survenu dans la classe clsVaccination.
(parfois, c'est un peu plus compliqué que ça, héhéhé...)

Quand tu manipules un objet (une instance de classe), ce dernier est autodescriptif. C'est-à-dire qu'il te montre ce qu'il t'est possible de faire avec. Il t'est possible de lire ou de définir des attributs, d'exécuter des routines ou des fonctions, de tirer un évènement. Bref tu manipules ton objet métier sans te préoccuper comment tout ceci est géré en arrière plan (encapsulation).
Par exemple pour créer un nouveau patient cela donne :

Code :

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

1
2
3
4
5
6
7
Dim vPatient As New clsPatient
With vPatient
<div style="margin-left:40px">
.setNom = "Haddock"
.setPrenom = "Capitaine"
.setMetier = "Marin d'eau douce"
If .Creer Then MsgBox "Création de : " & .getNom & ", " & .getPrenom & " réussie."</div>End With

Comme tu peux le constater, tu ne fais appel à rien "d'informatique" dans cette approche. Tout est beaucoup plus parlant. Je ne dis pas qu'à petite échelle, la bonne vieille approche procédurale peut se justifier mais dès que tu commences à manipuler des programmes complexes avec 30 ou 40 classes voire plus, cette méthodologie est beaucoup plus efficace.

Enfin, pour la gestion des formulaires, il t'est tout à fait possible de précharger tes objets avec l'enregistrement désiré et de le passer au formulaire qui le lira pour renseigner les différentes zones de saisies.
Une fois la saisie terminée, le click sur le bouton OK renseignera les attributs de l'objet et procédera à son enregistrement après sa validation (.Enregistrer). Plus aucun code lourd derrière les formulaire, juste de la manipulation d'objet. Et comme tu peux avoir autant d'objets que tu le souhaites, tu peux avoir autant de formulaires ouverts que ta ram te le permet. Un formulaire ouvert est une instance particulière de la classe Form. Et si tu as besoin de prévenir tous ces formulaires d'un évènement particulier (par exemple : rupture de l'accès aux données), tu peux tous les mettre à l'écoute de cet évènement et il y réagiront tous dès que l'évènement sera déclenché. Code minimaliste avec effet garanti.

La poo en vba est certes limitée mais permet de de coder même de la complexité assez proprement.

[Papy Turbo]

Quel beau débat j'ai raté au mois d'août !

D'aord, bravo Noawsen d'avoir
1- posé la question aussi clairement,
2- de t'être cramponé comme ça. Il n'y a aucune raison d'avaler des déclarations toutes faites, si tu n'y vois aucun intérêt !

Je ne vais pas reprendre les multiples clarifications très justes ci-dessous, Philben a très bien résumé les limitations de la POO sous VBA, (qui font parfois , mais bon. C'est vrai qu'on arrive souvent à tricher en faisant un faux héritage avec de l'agrégation, ou pire... mais ce n'est pas (encore) le sujet de ce thread.)

Par contre, j'insisterai sur un aspect propre à Access et qui fait que la POO pert beaucoup de son intérêt sous Access, par rapport aux autres langages : le binding marche dans Access ! Dans les aplications "classiques", sous VB, .Net ou autres, on a tendance à bien distinguer les 3 couches de base :
- l'accès à la base de données,
- les objets métier,
- l'interface utilisateur (formulaires...)

Dans ce cas, on a tout intérêt à
- lire un enregistrement dans la couche BDD,
- remplir les propriétés des objets métier (en mémoire),
- remplir les contrôles du formulaire à partir de ces objets.
Ensuite, après saisie, au moment de l'enregistrement (je simplifie), on repasse les valeurs des contrôles aux objets métier qui contiennent toute l'intelligence (validation...) et qui vont passer les résultats à la couche BDD, pour enregistrement.
C'est indispensable sous VB, où le binding (liaison entre contrôle et champ de la BDD) ne marche quasiment jamais ! ou tellement mal
Sous Access, ce serait une hérésie d'écrire autant de code pour rien, puisque le binding est complètement intégré et marche parfaitement.

Restent :
- la portabilité, uniquement si tu as plusieurs applications qui utilisent les mêmes 'objets' on 'fonctionalités'.
Bien sûr, tu peux copier tes modules d'une application à l'autre. En utilisant les modules de classe, tu transportes + que du code. L'exposé de Xysyo (#46) me paraît assez clair pour cela.
Même si, Xysyo, je me permets, pour rigoler, de te demander pourquoi une propriété ".getNom" (en lecture seule ?) et une autre ".setNom" (en écriture seule ?) Ça me paraît pour le moins zarbi, et j'aurais préféré un bon :

Code :

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

1
2
3
4
5
6
7
8
Dim vPatient As New clsPatient
 
    With vPatient
        .Nom = "Haddock"
        .Prenom = "Capitaine"
        .Metier = "Marin d'eau douce"
    If .Creer Then MsgBox "Création de : " & .Nom & ", " & .Prenom & " réussie."
    End With

Manière de penser :

c'est surtout une manière de penser, une manière plus humaine et naturelle.

Je préfère 1000 fois le code ci-dessus à celui là :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
Dim NomPatient As String
Dim PrénomPatient As String
Dim MetierPatient As String
 
        NomPatient = "Haddock"
        PrénomPatient = "Capitaine"
        MetierPatient = "Marin d'eau douce"
        If CreerPatient() Then 
             MsgBox "Création de : " & NomPatient  & ", " & NomPatient  & " réussie."
        End If
    End With

D'une part, le Nom, le Prénom "appartiennent" bien au patient, mais aussi une liste (collection) de maladies ou ...
D'autre part, le seul fait d'utiliser intellisense et la liste déroulante des propriétés et méthodes est une aide très très valable à elle toute seule
Et encore, il s'agit d'un exemple simple.
Quant on en arrive à

Code :

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

Debug.? ThisApp.System.Version.Major

Je ne serais même pas capable, 3 mois après, de me souvenir comment s'appelle la variable ou la fonction qui me renvoit ça ??

Tu peux voir (liens dans ma signature) l'objet ThisApp que nous sommes en train de stocker dans une librairie : imagine toutes les propriétés et les méthodes qui manquent à Access.application, et que tu peux stocker dans cette 'application+' (à commencer par la méthode CheckTablesConnexion(), mais il y en aura plein d'autres...)

Structure :
Tu connais bien Merise et la structure des tables + champs + relations qui, si elles sont bien faites, représentent la réalité du travail de ton client.
La base est parfaite pour stocker les valeurs, mais il y manque l'intelligence : le code "métier", voulu par ton client.
Tu la mets dans tes modules : penses aux classes comme un hybride qui relie les 2.
Mettre les noms en majuscules, les prénoms en 1ère cap, etc., par exemple.
Qu'est-ce que tu penses du code ci-dessous, dans la classe clClient :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
Public Property Let Nom (NouveauNom As String)
    mNom = Ucase(NouveauNom)
End Property
Public Property Get Nom () As String
    Nom = mNom
End Property
 
Public Property Let Prénom (NouveauPrénom As String)
    mPrénom = FirstCaps(NouveauPrénom)
End Property
Public Property Get Prénom () As String
     Prénom = mPrénom
 End Property

- Une fois pour toutes, les noms seront toujours en majuscules, les prénoms seront en 1ère cap... Tu n'oublieras plus jamais de les mettre dans la bonne casse.
- ton "module" (ici de classe) englobe à la fois les données et leur code (métier) associé : plus logique, et plus facile à maintenir.
- ton client veut un nom complet ? tu ajoutes juste une

Code :

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

1
2
3
4
'Pas de Let : lecture seule
Public Property Get NomComplet() As Sting
    NomComplet = mPrénom & " " & mNom
End Property

Et hop, l'objet Client dispose d'un Client.NomComplet, disponible partout dans ta (tes ?) applications.
Imagine une variable à la place. Qu'est-ce qui te garantit que tu ne vas pas, un jour de grosse fatigue, modifier cette variable là, au lieu du 'vrai' nom et/ou prénom. Une variable ne peut pas être en lecture seule.

À l'inverse, une fonction telle que, ci-dessus, FirstCaps(), n'a pour moi surtout pas sa place dans un module de classe !
Elle doit être traitée comme une extension du langage VBA auquel elle manque donc, idéalement : dans un module standard, dans une bibliothèque, que tu réutiliseras dans toutes tes applis.

Maintenant, juste pour le fun, comment tu crées une variable booléenne initialisée à Vrai ?
- réponse évidente : dans un module de classe, à l'évènement Initialize :
Exemple, dans une classe Client :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
Dim mSolvable As Boolean
 
Private Sub Class_Initialize()
    mSolvable = True
End Sub
Public Property Get Solvable() As Boolean
    Solvable = mSolvable
End Property
Public Property Let Solvable(NouveauSolvable As Boolean)
    mSolvable = NouveauSolvable
End Property

Lorsque tu crées ton client, il est, par défaut, solvable.

Code :

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

1
2
Dim Jules as New Client
    Debug.Print Jules.Solvable

Exemple assez bidon, mais je te laisse extrapoler sur les valeurs par défaut que tu peux donner à toute propriété d'un objet...

En gros, j'insisterai sur les points déjà indiqués par d'autres : ça ne vaut la peine que
- sur des applications complexes, où tu dois utiliser des variables globales pour passer des infos d'un formulaire à l'autre (c'est là que tu vires tes globales pour un bon et bel objet bien structuré),
- lorsque le nombre de variables globales devient important (je dirais + de 2 ) : c'est tellement plus clair de les structurer dans une ou plusieurs classes.
- lorsque la logique métier devient complexe et les appels de sub/fonctions ont tendance à se mélanger les pattes : quel bonheur de retrouver chaque petit bout de code juste là où tu en as besoin !
- lorsque tu as besoin d'utiliser de travailler sur des collections, en mémoire (Tu peux avoir besoin d'avoir sous la main tous les comptes du client actif, pour savoir s'il est globalement solvable. Un array ne stockera jamais toutes les propriétés, complexes, de chaque compte...)

Pense à la structure des données dans la base, et, si le besoin s'en fait sentir, reproduis la dans des objets contenant les données et le code lié à ces données -> n'importe qui (même toi, 6 mois plus tard) repasseras par là et tu comprendras tout de suite comment ça marche.

[cbleas]

Bonjour,
pour ma part j'ai pas encore compris comment cela fonctionne. peut etre tout simplement que la manière humaine que permet le langage objet. et trop différente de la manière "logique" qui m'a été apprise quand j'ai commencé l'informatique ou le langage machine avec un seul registre ne permettait pas toutes les facécies d'aujourd'hui.
Merci pour ce sondage qui montre que cette méthode n'est pas la seule et que les bonnes vieilles méthodes fonctionnent encore.

Bon WE

[mister3957]

Bonjour,
pour ma part j'ai pas encore compris comment cela fonctionne. peut etre tout simplement que la manière humaine que permet le langage objet. et trop différente de la manière "logique" qui m'a été apprise quand j'ai commencé l'informatique

Exactement

ou le langage machine avec un seul registre ne permettait pas toutes les facécies d'aujourd'hui.
Merci pour ce sondage qui montre que cette méthode n'est pas la seule et que les bonnes vieilles méthodes fonctionnent encore.

Mouais Orienté Objet n'est pas synonyme de dernière techno (Java, NET, etc.) Le C++ date de 1980...

[vodiem]

Papy Turbo:
tu triches un peu:

Je préfère 1000 fois le code ci-dessus à celui là :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
Dim NomPatient As String
Dim PrénomPatient As String
Dim MetierPatient As String
 
        NomPatient = "Haddock"
        PrénomPatient = "Capitaine"
        MetierPatient = "Marin d'eau douce"
        If CreerPatient() Then 
             MsgBox "Création de : " & NomPatient  & ", " & NomPatient  & " réussie."
        End If
    End With

on utilise plutot:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Type vPatient
    Nom As String
    Prenom As String
    Metier As String
    Creer As Boolean
End Type
[...]
Dim MonPatient As vPatient
With MonPatient
    .Nom = "Haddock"
    .Prenom = "Capitaine"
    .Metier = "Marin d'eau douce"
    .Creer = True
End With

où vPatient pourrais avoir plusieurs instances dans une liste de dynamique de données (donc être limité à la capacité mémoire).
sans faire de POO on peu arriver à la même simplicité et en consommant moins de mémoire.

je dirais que la grande différence réside dans le fait qu'en POO le traitement (codes) et les données (variables) sont intimmement lié dans ce qu'on a définit: un objet. Aux données lui sont associés leur traitement ce qui a pour conséquence surtout de sécuriser et donc de rendre plus facilement exportable donc exploitable.

perso j'utilise pas la POO dans access pour une simple raison: on se perd déjà dans la plétor d'objets fourni!
pour moi la principal utilité d'access et de pouvoir me concentrer sur la conceptualisation, sur le codage des objets: il y a d'autre language pour cela qui le font très bien et mieux et que l'on peut intégrer ensuite dans access au besoin.

cela dit je suis aussi ouvert comme noawsen à exploiter la POO dans access mais il y a encore qqc qui m'échappe c'est la corrélation entre objet métier et table/formulaire/etat. qq'un pourrais éclairer ma lanterne?

[mister3957]

Mouais moi j'étais plus axé sur la POO dans ce débats que sur la POO en VB/VBA

Faut sortir un peu du code, variable, traitement etc... Ce qui est intéressant dans la POO, c'est que tout est objet, et qu'ensuite chaque objet a ses données, ses fonctionnalité et ses responsabilités. Ca amène à adopter une méthode humaniste, et donc plus de facilité à résoudre un problème.

Après la POO en VB/VBA... si le problème à résoudre est simple et qu'on cherche pas forcément l'évolutivité, ça peut coller (en gélérant plus ou moins) mais pas d'héritage (sauf d'interface), pas de polymorphisme, pas de constructeur (donc moins de "+ de postes ouvertes" pour l'utilisateur de vos classes/librairies) et surtout beaucoup plus de code dès qu'on veut quelque chose de spécial en VB mais tout à fait naturel pour les "vrais langages OO".

En VB/VBA, faut se limiter à la logique, à l'évennementiel ainsi qu'à un projet de taille très réduite.

[rawsrc]

Papy Turbo a clavioté :

Sous Access, ce serait une hérésie d'écrire autant de code pour rien, puisque le binding est complètement intégré et marche parfaitement.

Tout dépend du niveau d'ergonomie à atteindre. Si tu veux rapidement manipuler les données (création, modification, suppression...) sans être obligé de passer par le formulaire correspondant au lien avec la source, l'objet est indispensable. Généralement, j'essaie dans tous mes programmes d'offrir une grande facilité d'accès aux données d'où l'approche objet. Tu manipules ce que tu veux, où tu veux. D'expérience, tu t'y retrouve au final malgré le temps supplémentaire pour coder tes classes. Et puis si tu files le code source de ton prog à ton client (qui s'y connait "vachement" sur Access) comme ça m'arrive régulièrement, il ne va pas s'amuser à l'améliorer et t'es sûr de retrouver tes petits lors des évolutions futures.

Ensuite, Papy Turbo a tapioté avec ses petites mimines :

Même si, Xysyo, je me permets, pour rigoler, de te demander pourquoi une propriété ".getNom" (en lecture seule ?) et une autre ".setNom" (en écriture seule ?) Ça me paraît pour le moins zarbi, et j'aurais préféré un bon :

Tout s'explique : dans l'ide d'access à l'écriture du code tu ne peut pas savoir ce qui est en lecture/écriture ou en lecture seule. La liste déroulante (intellisense) ne fait aucune distinction dans les attributs. Donc, la distinction je la fais moi en préfixant soit avec set soit avec get.

Une autre petite chose, j'ai aussi arrêté d'utiliser les Property. Je passe tout en Sub setNom(ByVal p As String) et en Function getNom As String. Cela ne te dérange pas j'espère ???? . Bien qu'en interne les Property soient gérés différemment des Sub ou des Function, j'ai opté pour cette approche car ça m'est plus simple.

Enfin, encore et toujours Papy Turbo s'est fendu d'un dernier petit mot :

la portabilité, uniquement si tu as plusieurs applications qui utilisent les mêmes 'objets' on 'fonctionalités'. En utilisant les modules de classe, tu transportes + que du code.

Tout à fait d'accord, en plus d'exporter le code tu exportes également une méthodologie. Une fois qu'un aspect d'un programme (la gestion des formulaires, l'accès aux données, création et destruction des objets...) a fait ses preuves, il est tout à fait normal d'en faire profiter les autres dev. Et puis, ça libère du temps pour le reste (sorties, plages, restau...)

Pour terminer, j'ai codé des programmes sur Access d'assez grande taille (80 000 lignes de code) avec des fonctinnalités en pagaille et je peux vous assurer que sans le découpage objet j'y serai encore. Et ceux qui disent que l'approche objet n'est pas "naturelle" c'est un non sens. La POO est une évolution prononcée d'une perception abstraite d'un environnement, cela s'apprend c'est comme les mathématiques.

[mister3957]

La POO est une évolution prononcée d'une perception abstraite d'un environnement, cela s'apprend c'est comme les mathématiques.

La POO c'est pas qu'une évolution, c'est une vision, vision concrète d'un système abstrait. Et ça s'apprend pas comme les mathématiques, en math, 1+1=2, en POO, il peut y avoir plusieurs façons de modéliser un problème, toutes "marcheront". En maths, la bonne logique, c'est celle qui marche, en POO, c'est celle qui est la plus naturelle.

Je veux dire par là que c'est pas le garagiste qui va aller demander à votre banque de l'argent, c'est vous qui ordonnez la banque de payer le garagiste. Ces deux manière de penser "marchent" (au final, le mec sera débité, le garage sera crédité), mais la première n'est pas correct (vous avez déjà acheté une voiture à un garage n'est-ce pas?) et les répercutions se sentirons qu'une fois qu'on voudra élargir le processus (ex: négocier... si dans votre vision des choses c'est entre le garagiste et la banque, c'est plus possible ou alors ça va demander pas mal d'effort supplémentaire donnant lieu à une conception de plus en plus surnaturel et donc de moins en moins évolutive, maintenable etc.).

[rawsrc]

vodiem a écrit :

on utilise plutot:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Type vPatient
    Nom As String
    Prenom As String
    Metier As String
    Creer As Boolean
End Type
[...]
Dim MonPatient As vPatient
With MonPatient
    .Nom = "Haddock"
    .Prenom = "Capitaine"
    .Metier = "Marin d'eau douce"
    .Creer = True
End With

Ta structure type n'est pas équivalente à la classe clsPatient : dans la classe, Creer est une fonction qui renvoie un boolean, dans ton type Creer est une simple variable.

pour moi la principal utilité d'access et de pouvoir me concentrer sur la conceptualisation, sur le codage des objets

=> si tu codes des objets, c'est que tu fais de la POO. Je pense que tu devrais te pencher un peu plus sur la théorie.

il y a encore qqc qui m'échappe c'est la corrélation entre objet métier et table/formulaire/etat. qq'un pourrais éclairer ma lanterne?

Imagines toi une pile : en bas tu as la table, au milieu le métier et sur le dessus tu as des formulaires et des états. Une fois la base définie (tables), elle reste généralement immuable. Par contre, le métier peut évoluer : par exemple le test de validité d'un nouveau Patient peut changer. Au début tu dois avoir juste un Nom pour créer un nouveau patient puis quelques temps plus tard, le patient doit obligatoirement avoir un nom et un prénom pour être créable. Ici, ta table ne change pas d'un pouce, juste ton métier évolue.
Les interfaces (formulaires, états) sont eux très généralement volatiles. L'ergonomie va très certainement changer, le look & feel devra peut-être respecter une charte graphique... Tu peux créer une application skinable. Cette vision te montre bien que plus un élément est susceptible de changer plus il doit être séparé du reste de manière à minimiser l'impact des changements sur la partie immuable de l'application. La POO te permet d'isoler toutes ces couches et de faire en sorte qu'elles soient très autonomes.

Chaque métier nécessite des compétences que le développeur n'a peut-être pas. Scinder le développement en couches te facilite l'intervention de tiers plus pointus dans un domaine particulier.

Enfin, la pureté de la POO en vba est loin d'être exceptionnelle. Je ne sais pas si démarrer en POO sur access est pertinent. Personnellement, j'ai commencé par Java/UML et après seulement j'ai regardé ce que ça donnerait en vba. Il ne faut surtout pas négliger la théorie, apprends large et vois ensuite les manières et limitations de chaque environnement.

[mister3957]

vodiem a écrit :


Ta structure type n'est pas équivalente à la classe clsPatient : dans la classe, Creer est une fonction qui renvoie un boolean, dans ton type Creer est une simple variable.


=> si tu codes des objets, c'est que tu fais de la POO. Je pense que tu devrais te pencher un peu plus sur la théorie.

En VB/VBA, il n'y a pas de constructeur, donc on ne peux pas imposer quoi que ce soit à l'instanciation de la classe. Par conséquent, c'est à la charge de l'utilisateur d'initialiser l'objet nouvellement créé.
Par contre l'information de savoir ou pas si l'objet a été initialisé peut rester interne. En effet, tu proposes une methode du style "Init", avec les paramètres obligatoire (ceux dont l'objet a besoin pour prendre ses responsabilités) et c'est dans cette méthode que l'objet pourra "s'auto flaguer" pour dire "ok c'est bon, je suis au complet, maintenant j'peux prendre mes fonctions". Donc créée en privé, faux par défaut et passe à true à l'issue de l'appelle d'une méthode d'initialisation...

Ensuite à chaque appelle de méthode, tu testes la viariable. Si elle est à Faux, bah tu renvoi un message, comme si l'objet lors de l'appelle à la fonction "RentreChezToi()" renvoyait à l'utilisateur "Je suis un client, ok, mais je sais même pas comment je m'appelles, qui je suis et encore moins où j'habite, alors comment veut-tu que je rentre chez moi?"

Naturellement, une fois que t'aura définit son nom et son prénom une première fois, tu ne pourras plus le changer (naturellement, pas logiquement). Donc tu laisses en lecture seule ces variables (GET mais pas de SET) et dans ta méthode Init, tu test si l'objet n'a pas déjà été initialisé auquel cas l'objet renverra "Bé nan j'vais pas changer de prénom et/ou de nom toutes les 2 min"

Notes: Pour ça il faut une classe, pas un type.
On est en VB/VBA mais un peu de respect pour l'encapsulation quoi.
Restez cohérents avec la réalité bon sens d'bonsoir

[rawsrc]

mister3957 a parlé :

La POO c'est pas qu'une évolution, c'est une vision, vision concrète d'un système abstrait. Et ça s'apprend pas comme les mathématiques, en math, 1+1=2, en POO, il peut y avoir plusieurs façons de modéliser un problème, toutes "marcheront". En maths, la bonne logique, c'est celle qui marche, en POO, c'est celle qui est la plus naturelle.

On ne va rentrer dans le débat sur la sémantique des mots. Mais juste une précision : je dirais plutôt que la POO est une vision abstraite d'un système concret et que ça s'apprend comme tout le reste. D'ailleurs la POO te permet même de modéliser ce qui est abstrait. La logique en mathématique n'est pas innée chez tout le monde, cela s'apprend avec plus ou moins de facilités. Et en mathématiques comme en POO il y a plusieurs façons de modéliser un même problème. Enfin 1+1=2 ça se démontre (espaces vectoriels) et il n'y a pas de "bonne logique qui marche", il y a la logique d'une part et l'expérience de l'autre. Quand les deux se rencontrent alors ça peut faire des étincelles.

[vodiem]

salut,
Xysyo: tu as coupé ma phrase, (j'aurais du mettre un point):

pour moi la principal utilité d'access et de pouvoir me concentrer sur la conceptualisation. Sur le codage des objets: il y a d'autre language pour cela qui le font très bien et mieux...

tu as écris:

Ta structure type n'est pas équivalente à la classe clsPatient : dans la classe, Creer est une fonction qui renvoie un boolean, dans ton type Creer est une simple variable.

j'avais vu Creer comme est le résultat à la création de MonPatient utilisé par CreerPatient() mais effectivement c'est une fonction.
enfin, le but était de relativiser le code de Papy Turbo: il y a du codage plus lisible que celui qu'il a proposé.

pour revenir sur les derniers post:
je ne pense pas que le fond du pb c'est de convaincre de passer à la POO et d'en vanter les vertus.
n'oublions pas: la POO est née d'un besoin = tant que l'on en sent pas l'utilité on peut s'en passer, d'ailleur on s'en est bien passé avant
si on est ici c'est plutot pour discuter de : comment on l'utilise.

je rappel le soucis de noawsen (et le mien aussi ):

je n'en vois pas trop l'interet, ni comment intégrer ce concept dans mes bases de données...

perso l'intérêt ne me préoccupe pas il viendra surement quand je s'aurais l'exploiter dans les BD.
j'ai connu les débuts de la POO et j'utilise dans delphi pour créer mes composants donc le concept je connais mais c'est l'exploitation dans les BD: là je vois pas.
je crée un objet et ses méthodes pour interagir avec les tables, là ok.
mais c'est avec les forms là j'ai du mal à voir. les méthodes peuvent ouvrir des forms mais si les forms lance d'autre traitements...

vous auriez pas un tout petit bout de prog (même des miettes) histoire de me mettre ca sous la dent et voir si c'est bon?

[Heureux-oli]

Je n'avais jamais utilisé la programmation Objet, et puis j'ai un peu lu la discussion, et quel charabia

Il y a peu, j'avais besoin de faire appel à une fonction, mais quatre fois de suite et avec des paramètres différents de même type.

Mais finalement pourquoi pas utiliser les objets, je me suis fait un type de donnée, contenant mes quatre paramètres,

Code :

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

1
2
3
4
5
6
7
 
Type Oli
   Param1 as Integer
   Param2 as integer
   Param3 as integer
   Param4 as integer
End Type

Puis l'appel de la fonction

Code :

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

1
2
3
4
5
6
7
8
Dim myOli as oli
'On rempli oli
with myOli
    .param1 = 
.........
End With
 
Mafonction( oli )

Une petite boucle dans la fonction.

Et bingo tout en une fois.

Et finalement c'est pas plus mal.

[vodiem]

Désolé Heureux-oli mais pour moi c'est pas un objet: c'est une variable typé.

[Heureux-oli]

Pour moi, c'est le début.