Bonjour, je ne sais pas si j'ai bien compris l'exo

Si on a deux fenêtres w_a (déjà ouverte) et w_b

dans w_a :

// instance
w_b iw_b

// quelquepart dans w_a
Open( iw_b )
iw_b.of_set_param1( 'hello world' )

dans w_b :

// instance
Private String is_param1

// setter
Public of_set_param1(String as_param1)

This.is_param1 = as_param1
Messagebox( 'param1', This.is_param1 )

Pas sûr que l'utilisation du Yield() soit très orienté objet

J'ai bien une solution qui fonctionne avec w_b de type response :

Si on a deux fenêtres w_a (déjà ouverte) et w_b

dans w_a :

// instance
w_b iw_b


// événement
Event ue_call_back()

iw_b.of_set_param1( 'hello world' )


// quelquepart dans w_a
Open( iw_b )

dans w_b :

// instance
Private String is_param1


// setter
Public of_set_param1( String as_param1 )

This.is_param1 = as_param1


// open
w_a.TriggerEvent( 'ue_call_back' )
sle_param1.Text = This.is_param1

si c'est l'événement qui gêne, je peux le remplacer par une fonction

dans w_a :

// instance
w_b iw_b


// fonction
Public subroutine of_call_back()

iw_b.of_set_param1( 'hello world' )


// quelquepart dans w_a
Open( iw_b )

dans w_b :

// instance
Private String is_param1


// setter
Public subroutine of_set_param1( String as_param1 )

This.is_param1 = as_param1


// open
w_a.of_call_back( )
sle_param1.Text = This.is_param1

Dadone a écrit:

Il y pas plus simple, non ?

passer par un objet tierce, un manager de pages p.ex

Dadone a écrit:

Par conséquent : l’utilisation de la fonction openwithParm() (de même closeWithParm) ne respecte pas l’encapsulation car cela consiste à faire transiter des informations via l’objet Message sans passer par l’interface Publique des classes.
Alors comment peut-on faire ?

la solution utilise l'objet message, donc quel est le gain par rapport à openwithParm ?

la solution utilise l'objet message, donc quel est le gain par rapport à openwithParm ?

La différence est le respect de la programmation objet !
Si je regarde l’interface d’une classe est que toutes les routines de son interface non événementielle est protégée alors cette classe est autonome est ne communique avec aucune classe. Ce qui n’est le pas le cas, si on utilise la fonction openwith qui implique une communication qui n’apparaît pas dans l’interface de la classe.
De plus, la lisibilité des programmes est considérablement renforcée, il n’y pas besoin de déclarer des structures globales permettant le transit d’information entre les classes.
Le pire étant l’utilisation de structures abstraites ce qui rend illisible la compréhension des programmes.
Enfin allez expliquer à un programmeur Java, qui a l’habitude d’utiliser les fonction get() et set() de comprendre l’intérêt de openwithParm ! Selon moi ce type de fonction est directement hérité de système Coboliste totalement désuet de nos jours.

Pour finir comparons, le code « naturel » suivant :

Open(w_1)
w_1.of_set(a,b,c,…)

et déclaration de la routine publique of_set() de w_1, avec tous les commentaires qui vont bien au niveau du cartouche de la routine pour ce qui concerne ses arguments.
Au bilan : lisibilité du code et respect de la POO.

En passant par l’objet Message, nous avons :
Déclaration d’une structure pouvant contenir les données a,b,c,…

StructureA strA
renseignement de str A
openwithParm(w_1,str_a)

puis encore une déclaration de la même dans w_1
afin de récupérer les données…

En tant que formateur, inutile de dire qu’il n’y a pas photo dans la rapidité de compréhension entre les deux codes… !

Dernière modification par Dadone (18-12-2007 18:07:51)

Dadone a écrit:

pick ouic a écrit:

pour info, certaines variables de l'objet message ne passent pas sous appeon... arghh, je me suis trompé de topic...

On peut utiliser une autre classe de transit, c'était juste un exemple.
Au faite sa marche APEON ?
Avec l'orientation WinForm et WebForm de la V11, ce produit a t'il encore un avenir ?

bon, on est hors sujet...
mais APPEON tourne tres vite, par rapport au webform de pb11...  pas un seul postback...

Tron a écrit:

Bonjour

Pour moi, l'écriture la plus naturelle est open( w_1, paramètre 1 , ... paramètre n... )

La fonction openWithParm est celle qui ressemble le plus à ce type d'écriture. Même s'il elle ne respecte pas les principes de la POO en utilisant l'objet message, c'est avant tout une fonction système à PB. Ne peut-on pas considérer que la façon dont elle implémente ce passage de paramètres, même s'il est malheureux, ne nous concerne pas directement ?

Autrement dit cette solution ne reste-elle pas la plus simple et donc la meilleure ?

A+

Quoique vous en disiez la fonction openwithParm n’est pas une programmation « naturelle ».  Je dirais même plus, la fonction open() tout court n’est pas non plus naturelle. En effet, en POO , toute classe devrait être créée de la même manière (new()  pour certains langages, create() pour d’autres). Admettre une particularité pour la classe de type window est déjà pas normal. Si de plus, il y a une classe système partagée permettant le passage de paramètres, là on est typiquement dans une particularité du langage non conforme à un langage objet.
Je pense que les raisons sont historiques. Les créateurs de PB avait forcément une culture gros système et la notion de fenêtre est au cœur des systèmes d’informatique de gestion. C’est cette culture qui a fait adopter des abus de langage non conforme à la POO. C’est cette même culture qui a fait adopter la convention absurde que toutes propriétés (c-a-d variables d’instances, encore une anomalie de vocabulaire car le terme « propriété » aurait dû être la norme) est par défaut public alors que la POO impose que toutes les propriétés soient protégées et que l’on accède à celles-ci par les fonctions publiques de type get() et set().
Les conséquences de cet état de fait, est que la culture objet dans le monde PowerBuilder est pratiquement inexistante entraînant des dérives de code très préjudiciable pour la maintenabilité des projets et plus fondamentalement pour la crédibilité du produit vis-à-vis des décideurs.
Un décideur m’a dit une fois. « Au niveau de la maintenance informatique, les coûts des projets PB sont bien supérieurs aux coûts des projets VB est c’est une des raisons pour laquelle nous abandonnons le produit ».
Autrement dit, mal programmé un projet PowerBuilder devient vite un cauchemar à maintenir ce qui nuit très fortement à la réputation du produit.
C’est pour cette raison que depuis plus de 10 ans, j’ai écris plusieurs ouvrages pour démontrer que rationnellement utilisé PowerBuilder à une productivité sans égal mais cela passe inévitablement par le respect stricte des concepts objets et même plus. En effet, la notion d’interface événementielle implique une adaptation des concepts objets à la particularité des routines événementielles, particularité qui n’est pas incluse dans la théorie de la POO « classique ». La distinction fondamentale entre les routines non événementielles et événementielles fait partie d’un des thèmes centraux de mes ouvrages.

Dernière modification par Dadone (20-12-2007 11:52:44)

Tron a écrit:

Effectivement, mais la fonction open n'est finalement qu'un synonyme de create ou new, le fait d'avoir des synonymes est-il contraire à la POO ?

Dans framwork, on peut toujours créer une fonction globale f_create pour instancier toutes les classes et passer des paramètres à l'image des constructeurs paramétrés de Java et autre...

D'autre part, un langage n'est qu'un outil et c'est seulement le développeur qui est garant de la qualité du code !

A+

Je fais souvent la comparaison entre le jeu d’échecs et la programmation.
Les règles du jeu sont simples mais bien jouer est très complexe.
En PowerBuilder, n’importe quel programmeur peut rapidement produire du code, il en va autrement si on lui demande du produire du « bon » code, autrement dit qui respecte les critères du génie logiciel.
C’est le cœur du problème, si on se contente de connaître les règles on ne seras jamais un bon joueur d’échec. Il faut, pour progresser, connaître la théorie du jeu pour bien jouer, théorie qui est longue et complexe a assimiler. Il en va de même en PB, si on se contente de produire du code, on ne progresse pas réellement dans « l’art » de programmer. Comme aux échecs, il convient de connaître la théorie pour ensuite l’appliquer. Ors cette théorie n’est pas simple et surtout elle n’est pas enseignée. J’ai eu l’occasion de le signaler un jour dans un article paru dans 01 Informatique, l’enseignement supérieur en informatique de gestion est sinistrée car les personnes responsables de ces enseignements n’ont, elles mêmes, jamais développées un projet en informatique de gestion. Donc elles sont incapables d’enseigner la théorie. A l’arrivée cela a un coût exorbitant pour l’ensemble de la société. La caricature étant l’utilisation d’un langage comme Java (à l’origine prévu pour faire des automates) en informatique de gestion en lieu et place de langages comme PB, fortement spécialisés à la problèmatique soulevée par l'informatique de gestion!
______________________________________
Apprendre c’est bien, comprendre c’est mieux !

Dernière modification par Dadone (20-12-2007 12:20:44)

Tron a écrit:

Faire de la qualité est un investissement lourd en temps… Il implique tous les maillons de la chaine du développement et beaucoup d’entreprises préfèrent privilégiées malheureusement le résultat à court terme au détriment de la qualité…

Enfin, j’ai personellement beaucoup progressé en lisant vos livres et j’attends avec impatience les prochains... c’est pour bientôt ?

A+

Le problème n'est pas d'écrire un livre (c'est le premier livre qui est difficile à concevoir moins les suivants) que de trouver un éditeur. Ors plus aucun n'est intéressé par le sujet...
Mais peut être qu'avec le renouveau de PB que l'on sent au niveau de nombreuses entreprises (dont beaucoup ont énormément perdu d'argent avec Java) cela peut peut être évoluer...
Mais je ne manquerai pas de vous tenir informé si les choses était ammenées à évoluer via cet excellent outil qu'est ce forum, signe justement d'un renouveau du produit.

Dernière modification par Dadone (20-12-2007 13:53:22)