Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Design Patterns Discussion :

Modélisation UML du pattern Observer [Observateur]


Sujet :

Design Patterns

  1. #1
    Futur Membre du Club
    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2017
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Cher (Centre)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Industrie

    Informations forums :
    Inscription : septembre 2017
    Messages : 1
    Points : 5
    Points
    5
    Par défaut Modélisation UML du pattern Observer
    Bonjour, je m'interroge sur le diagramme UML du pattern Observer. J'ai récemment eu une formation sur les design patterns. On nous a donc présenté le schéma suivant pour le pattern Observer.

    Nom : observer.gif
Affichages : 1349
Taille : 8,8 Ko

    Nous avons ensuite fait un exercice. Cet exercice ne mentionnait qu'un unique et seul sujet. N'ayant pas de raison d'implémenter les traitements d'abonnement dans une classe mère, j'ai réalisé le schéma suivant :

    Nom : Diagram(2).png
Affichages : 478
Taille : 9,6 Ko
    (J'ai renommé les classes pour ne pas mettre l'énoncé de l'exercice)

    Le formateur a ensuite déclaré que je ne respectais pas le design pattern car je n'avais pas d'association entre une classe abstraite et l'interface Observer.
    Après une recherche sur internet, on retrouve un schéma similaire sans la classe abstraite pour désigner le pattern Observer. Je suis conscient que si l'on a plusieurs sujets, le premier schéma est beaucoup plus générique car les méthodes Add, Remove et Notify sont définies dans une classe mère pouvant être utilisées pour chaque sujet.
    Mais si on a un seul sujet, la classe abstraite est-elle obligatoire ? Peut-on appeler cela un Pattern Observer ? Manque-t-il des informations pour rendre la modélisation UML compréhensible ?

    Merci pour vos réponses.

  2. #2
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    805
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : janvier 2011
    Messages : 805
    Points : 2 928
    Points
    2 928
    Par défaut
    Excellente question. C'est vrai qu'on voit souvent des schémas explicatifs de design patterns avec des classes abstraites ou des interfaces dans tous les sens, ce qui ne facilite pas toujours la compréhension du concept derrière. Autant certains patterns comme Strategy ou Abstract Factory nécessitent l'utilisation de classes abstraites car c'est la raison d'être du pattern d'avoir une famille ou une gamme de comportements, autant ce n'est pas la majorité des patrons de conception.

    Dans le cas d'Observer, la substance du pattern se situe davantage dans le mécanisme d'enregistrement et de notification que dans l'existence de plusieurs Observers et a fortiori de plusieurs Subject. Le fait que plusieurs Subject puissent partager un comportement commun d'enregistrement et de notification via une classe abstraite est anecdotique. Donc je suis d'accord avec toi : dans un schéma UML, pour rester dans l'explication pure du concept d'Observer, on pourrait (devrait ?) avoir une seule classe Subject sans héritage.

    Dommage que ton formateur soit aussi rigide sur la forme. Tu peux toujours te réconforter en te disant que sur la page Wikipedia du pattern Observer il y a grosso modo le même schéma que le tien, avec juste un Subject concret

    [Edit]

    Je me rends compte que c'est l'absence de classe abstraite Observer et pas de la classe abstraite Subject qui est reprochée. Donc personnellement :

    • Si on est sur un schéma pédagogique de ce qu'est le concept d'Observer, ton diagramme avec une interface me va très bien

    • Si on est sur un schéma d'implémentation qu'on va coder tel quel (mais aujourd'hui qui recode ce pattern à la main alors que toutes les librairies standard des langages l'ont déjà ?), on mettrait en effet volontiers une classe mère abstraite pour rendre réutilisable le comportement. Mais c'est un détail d'implémentation et ça ne veut pas dire que tu n'as pas compris ce qu'était un pattern Observer.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Quel outil de modélisation UML utilisez vous ?
    Par Matthieu Brucher dans le forum Outils
    Réponses: 78
    Dernier message: 11/01/2018, 14h33
  2. Modélisation à l'aide du design pattern Observer
    Par Pierre Castelain dans le forum Codes sources à télécharger
    Réponses: 0
    Dernier message: 03/02/2013, 17h26
  3. Modélisation UML d'un document XML
    Par zorely dans le forum UML
    Réponses: 3
    Dernier message: 28/01/2005, 20h45
  4. [Observateur] Précisions sur le design pattern Observer [UML]
    Par joquetino dans le forum Design Patterns
    Réponses: 2
    Dernier message: 07/10/2004, 22h35
  5. Interfaces, Pattern Observer
    Par IProg dans le forum Langage
    Réponses: 8
    Dernier message: 18/12/2003, 14h11

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo