Discussion :

[vmolines]

Ce qui revient à abandonner la prog objet au sens uml du terme pour rester sur du procédurale et du code un peu partout dans les boutons entre autre.

C'est un peu extrême comme conclusion. Il y a des solutions intermédiaires entre :

- ne pas appeler l'ouverture de la fenêtre depuis une méthode de ta classe
et
- abandonner l'objet

L'idée de départ étant de regrouper tout le code dans une classe.

C'est la difficulté de la conception objet. Délimiter le role de chaque classe et ne pas avoir des classes qui grossissent pour se charger de choses qu'elles n'ont finalement pas à faire.

Il n'est pas forcément heureux d'avoir une méthode qui gère l'interface dans votre couche métier/dao.

Imaginons que vous deviez développer 2 fenêtres différentes qui manipulent le même type de données. Celà afin de répondre à un besoin d'ergonomie particulier (exemple : une fiche de saisie simple qui présente les informations principales et une complexe qui permet plus de choses mais plus lourde à utiliser). Allez vous implémenter autant de méthodes qu'il existe de moyen IHM pour accéder à cet objet ? Cela fonctionnerait mais vous sentez bien qu'il y a une lourdeur avec cette conception.

J'ai pris un exemple grossier pour montrer l'intérêt et la difficulté de séparer les couches. Et il est clair que ce n'est pas une classe de définir comment l'IHM va l'utiliser.

Et enfin, ce n'est pas parce qu'on a fait une classe que c'est forcément bien fait. L'objet ne nous met pas à l'abri de fautes de conception.

[ritchi46]

Pour répondre à Vmolines

L'utilisation de la commande "objet" permet apparemment de remplacer le this dans la méthode.
J'avais pas réussi à l'utiliser , mais aujourd'hui c'est ok et assez logique finalement.

L'appel de la méthode devient plus léger, sans le passage de l'objet ce qui était un contre-sens comme l'a justement souligné vmolines

Code :

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

1
2
3
4
5
6
7
 
planDeFinancement est un objet CfinanceVehic( TABLE_VehicFinance.COL_IDVehicFinance )
// Ouverture de la fiche du fichier VehicFinance en mode
IF planDeFinancement:modifiePlan() THEN
	// Rafraichissement de la table
	TableAffiche(TABLE_VehicFinance,taCourantBandeau)
FIN

et le code de la méthode devient

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
PROCEDURE ajoutePlan()
// Création d'un nouvel enregistrement
HRAZ(VehicFinance)
// Ouverture de la fiche du fichier VehicFinance en mode création
IF Ouvre(FinEntete_Fic, objet) THEN 
	:idPlan = VehicFinance.IDVehicFinance
	RENVOYER Vrai
ELSE
	RENVOYER Faux
END

Et le code d'ouverture de la fenêtre

Code :

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

1
2
 
PROCEDURE ouvreFen(PointeurObjet)

Merci à Tatayo qui dès son premier message avait flairé la piste.

Voila une solution qui commence à ressembler à quelque chose d'intéressant.
Sur le fond (qui n'est pas le moins important)
Tu vois vmolines, d'où que tu ais besoins de créer des plans dans ton projet tu passes dans cette méthode, si tu as un problème c'est là qu'il faut venir travailler, si ça doit évoluer c'est également là qu'il faut venir.
Enfin, c'est peu visible du reste du projet, et cela permet l'héritage

Je n'ai pas très compris ton problème d'interfaces multiples pour un même projet mais avec le mécanisme de la surcharge, je pense que tu pourrais trouver des solutions intéressantes.

Cette recherche s'inscrit dans un projet important (120 tables avec autant d'interfaces et d'états) et qui est structuré en 4 sous projets (bibliothèque externe) correspondand à des fonctions et comportant chacun leur classes, donc le nombre est raisonnable et facilement gérable.
Je cherchais une solution qui me permette de sortir de la prog d'interface et d'ancapsuler ces interfaces dans des actions métier (je suis un garçon plutôt branché fonctionnel).
Qu'en pensez-vous ?