DESIGN PATTERN OBSERVER : IMPLÉMENTATION RÉUTILISABLE

Commentaire de f0xi le 30/04/2006 22:29:23 administrateur CS

du beau, du costaud ...

un bel exemple pour apprécier les possibilitées des interfaces, a analyser a tete reposée.

cependant, le code manque de commentaires ou alors ils n'apparraissent pas dans l'editeur du site.
mais bon, vus le publique auquel il s'adresse, plus l'aide PDF fournie qui est de la meilleure qualitée.

cela merite un 20/10 ...

Commentaire de Delphiprog le 30/04/2006 23:42:58 administrateur CS

Merci pour vos remarques et suggestions.

Foxi : le pdf explique les points esentiels du code et la démarche suivie. De plus, j'ai pris la précaution d'écrire sur cette page web : "Le code source n'est volontairement pas commenté. Reportez-vous au document pdf joint à l'archive."

Mais, comme tu l'as dit, c'est du costaud. :o)

Commentaire de pouicky le 01/05/2006 12:27:40

Un super tuto qui élève l'esprit sur des horizons plus larges

J'en avais vu qui expliquaient la méthodologie Composition ou bien le méthodologie interface, mais là tout s'éclaire. Cependant, je me penche en ce moment sur MVC plus prisé en langages web, mais qui me semble tres lié au pattern observer. J'espere que le probleme que je pose maintenant tombe à propos:
Mon but est de faire une appli qui puisse changer de base de données avec un minimum d'efforts. (exemple Le SQL de Oracle et le SQL d'access, qui ne sont pas les mêmes).
Je pense décomposer l'appli en trois parties (Modele-Vue-Controleur:
1- Une classe de composants d'acces aux données (un module qui pourrait etre interchangé selon le sgbd et/ou l'architecture) - Le Modèle
2- Les objets "métiers" qui appelleraient des methodes de cette classe d'acces aux données (composition de composants)-Le controleur
3- Les formulaires qui observeraient les objets métiers, et implementeraient l'ergonomie- la vue

Or tout ce petit monde serait sujet et observateur des autres.
L'interface devrait se tenir au courant de l'état de la base de données et de l'état des objets métiers
Les objets doivent se tenir au courant de l'état de la base et de l'interface lorsque l'utilisateur agit.
Il y aura les acces aux données faits par les objets métiers
Il y aurait les acces aux données par les fiches (dbgrid relié par exemple) (pas tres souhaitable dans l'optique MVC)
Il y aurait autant de commandes sql à envoyer que d'objets modifiés + le retour des resultats à gérer.

Questions:
-Doit-on limiter les rôles sujets observateurs au minimum pour les performances ou cela altere t'il tres peu la fluidité d'une appli.?
-Les meilleurs choix sont il de "mapper les tablesBDD avec des composants DBTables ou plutôt d'utiliser un composant par type d'action :Objet"command", objet "Query" qu'on réutiliserait pour les differents acces??

Je n'aime pas trop les datamodules pleins de TABLES avec Maitre/esclave qui semblent trop proches de la base.
Dans quelles mesures peut on compter sur la puissance des composants BDD de delphi pour refléter l'état des données?
N'ayant pas d'expérience sur le sujet, quelqu'un peut-il m'indiquer une piste?

Commentaire de Delphiprog le 01/05/2006 19:25:35 administrateur CS

Cirec :
Tu as suivi les recommandations et tu as bien fait.
Je ne pouvais pas, à la simple lecture du code source, vous montrer la démarche qui fût la mienne. C'est en cela que les outils de modélisation comme UML apportent un plus en se situant au dessus du code source.

Model Maker fût livré avec Delphi 7. Ce n'est pas indispensable de l'avoir mais c'est bien utile quand même.
En passant, Model Maker permet l'application de certains design patterns dont l'observateur. Un conseil, n'utilisez pas le code généré, vous vous enfermeriez dans une hiérarchie de classes.

Les versions .Net de Delphi sont maintenant livrées avec ToGether.
Notez aussi que ce genre d'outil n'est pas livré avec les éditions perso.

Que Pouicky me pardonne, mais ses questions appellent des réponses plus développées et je lui consacrerai le temps nécessaire un peu plus tard.

Je sens qu'on va avoir un vrai débat de passionnés !

Commentaire de pouicky le 01/05/2006 21:57:52

Dans l'exemple, il ya 2 fiches Releves et Stats prévues pour observer, et ayant un constructeur qui enregistre leur membre observateur aupres du sujet observable passé en parametre.

Or l'exemple illustre 2 manieres de gérer l'inscription des observateurs au sujet : Pour la fiche de stat, c'est la fiche principale qui l'inscrit sur son propre FObservable. Alors que pour la fiche de releves c'est le constructeur qui inscrit la fiche sur le membre FObservable de la fiche relevé (j'essaie de résumer, et on est bien d'accord que les membre FOBservables des deux fiches sont le même objet, non?).
N'y a t'il pas alors deux inscriptions pour la fiche de stats?
pour verifier cela j'ai saisi testé cela dans l'unité Uobservable

procedure TObservable.AddObserver(Obs: IObserver);
begin
  if FObservers.IndexOf(Obs) = -1 then
    FObservers.Add(Obs);
    ShowMessage(inttostr(fobservers.Count));
end;

procedure TObservable.RemoveObserver(Obs: IObserver);
begin
  if FObservers.IndexOf(Obs) <> -1 then
    FObservers.Remove(Obs);
    ShowMessage(inttostr(fobservers.Count));
end;
et il y a  un truc bizarre : le clic sur "listing" est cohérent mais le clic sur "statistiques" provoque deux passages dans AddObservers et avec la meme valeur pour Fobservers.count (s'enregistre sans incrementation?? ya t'il une transmission sans traitement de la liste des observateurs entre la fiche principale et la fiche de stats?)

Commentaire de Delphiprog le 01/05/2006 22:57:42 administrateur CS

Shining : j'ai jeté un oeil sur les liens que tu as donné. L'implémentation du dp observer repose sur l'utilisation de l'interface Observable fournie par Java.
Delphi n'en disposant pas (je suis d'accord qu'on peut facilement la reproduire) et comme il est bon de comprendre les principes qui sous tendent, le code fourni ici permet de mieux saisir les mécanismes en jeu.

J'ai oublié de mentionner dans le tuto que Delphi pour .Net proposait le multicast, variante du dp observer. On peut en parler, mais il n'y aurait pas grand chose à dire puisque tout est déjà fait, un peu comme en Java.

Quant au choice pattern, s'il est présenté comme plus léger que le strategy pattern, l'exemple fourni ne démontre rien à mon avis puisque l'on appelle séquentiellement chacune des interfaces IChoicePattern au lieu de faire le bon choix comme dans le cas du strategy design pattern.

Commentaire de shining le 02/05/2006 21:34:18

Oui en effet DelphiProg, le ChoicePatterne quant à lui est assez limité dans ses possibilités et l'exemple choisit n'est pas vraiment très reprensative du choice pattern !!, allez pour me faire pardonner voici un lien très intérréssant à ne pas rater, qui d'une certaine façon pourrait-être un complément d'info à ce superbe tutoriel !!!

de la Strategy à l'Iterator tout y est ou presque !!!

http://www.felix-colibri.com/papers/design_patterns/the_lexi_editor/the_lexi_editor.html
@+

Commentaire de Delphiprog le 03/05/2006 00:11:14 administrateur CS

Tu n'as pas choisi n'importe qui comme référence. John COLIBRI est une référence !
Je connaissais son site mais je ne le trouve pas facile à lire. C'est un avis personnel.
Les ouvrages que j'ai cité dans la partie bibliographie sont tous publiés en langue française et ça aide pour bien comprendre les patterns et les maîtriser.

Shining : de même qu'il faut tourner sept fois sa langue dans bouche avant de parler, mieux vaut se relire deux fois avant de cliquer sur le bouton "ajouter votre commentaire", lol.
++

Commentaire de Delphiprog le 07/05/2006 12:02:38 administrateur CS

Je viens de mettre à jour le code ainsi que le pdf en espérant que cela sera moins "brumeux" pour certains :o)

C'est sûr que quand on parle architecture logicielle, mieux vaut avoir l'esprit clair et un minimum d'expérience dans ce domaine.

Pouicky, je ne t'oublie pas, mais...

L'urgent est déjà parti,
L'impossible est en train de se faire,
Pour les miracles, je demande un délai !

Commentaire de pouicky le 08/05/2006 21:49:45

j'ai planché et ai buté sur des impasses dans le cas du pattern observer avec sgbd. Puis je me suis aperçu qu'avec la vcl et ses controles de données, on fait du pattern observer sans le savoir. J'ai essayé de jouer avec les datamodules et les composants ado et ai posté un code qui illustre deux manieres d'utiliser les datamodules pour des comportement "observer" ou "non observer". Je ne sais pas si c'est dans les "bonnes pratiques" mais ça permet de reflechir.. http://www.delphifr.com/codes/UTILISATION-DATAMODULES-VCL-POUR-IMPLEMENTER-PATTERN-OBSERVER-OU_37511.aspx

Commentaire de Delphiprog le 28/11/2006 23:36:52 administrateur CS

Question très pertinente mon cher DeltaFx !

Dans le code source proposé ici, on peut dire que les identifiants uniques des interfaces utilisées ne servent à rien.

En revanche, c'est une bonne habitude de les utiliser si tu dois faire usage de la méthode QueryInterface ou de la fonction Supports qui réclament un identifiant d'interface (IID).

C'est aussi important si tu crées un serveur automation qui a besoin d'être enregistré sur une machine pour être appelé. La base de registres de Windows en est remplie.

On ne choisit pas le contenu des clés mais on l'obtient :
- soit par la combinaison de touches [Shift][Ctrl][G]
- soit par programmation en appelant la fonction CoCreateGuid déclarée dans ActiveX.pas (ou encore CreateGuid déclarée dans SsyUtils.pas) de la façon suivante :
var
  Guid: TGUID;
begin
  CoCreateGuid(Guid);
  Memo1.Lines.Add(GuidToString(Guid));
end;

"Autant je saisis bien tout" : ce genre de commentaire fait bien plaisir.
Merci de porter un intérêt à ce code.