Discussion :

[threaded]

Bonjour,
désolé si ma question est redondante, mais je construis actuellement une application en utilisant SWT et j'essaie tant bien que mal de respecter une architecture "MVC".
J'ai construit des interfaces en utilisant "GWT designer" dans éclipse avec des widgets SWT. Quand on crée un shell ou un composite, il crée une classe qui étend automatiquement shell ou composite. Cela me semblait parfait jusqu'à ce que je comprenne le sens de la méthode overridée "checkSubClasses", qui semble indiquer que ce n'est pas la marche à suivre. (sans elle, une exception "sub classing not allowed" apparaît)

Vaut-il mieux créer une classe Fenêtre qui contient un shell et ses composants plutôt que de l'étendre ?

[sinok]

C'est même un conseil d'ordre général en POO, il vaut mieux préférer la délégation/composition à l'héritage.

[threaded]

Merci
Effectivement c'est la décision que j'ai prise finalement, ça me semblait logique et pratique
Par contre, j'aimerais comprendre pourquoi c'est plus judicieux ?

[Washmid]

Dans le cas de SWT et d'un point de vue purement conceptuel, il est "interdit" de sous-classer les composants parce que ceux-ci ne sont qu'un intermédiaire vers les widgets natifs du système d'exploitation qui ne sont pas des objets.

La possibilité de contourner cette interdiction a été prévu (à ma connaissance) afin de permettre la correction de bug sans attendre les releases de SWT, certainement pas afin d'autoriser les "bidouilles" de designers.

De manière plus générale, en recourant à l'héritage :
- on expose des méthodes qui ne sont pas forcément prévues pour (utilisation non "prévues")
- on est plus sensible aux évolutions de la classe parente
- on obtient une dépendance directe de l'appelant vers la classe parente
- etc.

Bref, composition, délégation et dérivés.

[threaded]

Merci pour cet éclairage,
effectivement j'ai opté pour la composition, etc .. c'est limpide, logique et ça fonctionne

[Washmid]

Avec plaisir