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.

Pièce jointe 315029

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 :

Pièce jointe 315033
(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.

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.