• [^] # Re: Mes deux centimes ...

    Posté par . En réponse au journal Repenser les langages et le développement logiciel. Évalué à 3.

    Moi non plus comme Sylvain je ne vois pas le besoin d'héritage multiple dans ces exemples.
    On peut très bien s'en passer à mon avis.


    Alors montre concrètement comment faire pour modéliser l'exemple avec les formes géométriques.

    Si on rencontre des cas où on a besoin d'hériter de plusieurs classes à la fois, n'est ce pas parce que la classe mère n'est pas assez complète ?

    Tu restes dans la théorie. Raisonne sur mon exemple. Je ne vois pas en quoi les classes mères de formes géométrique ou la classe mère des formes éditables graphiquement sont incomplètes.


    J'en profite pour répondre à sa réponse pour pas te laisser faire la même :

    - ou tu sépares proprement application et interface (c'est-à-dire que tu fais un modèle pour le calcul, un modèle-proxy pour donner à l'UI et une UI (avec ses objets à elle : widgets de toutes sortes)) ;

    Ca veut dire quoi séparer proprement ? Je vais pas m'amuser à dupliquer (proxy) pour le plaisir d'avoir un beau design qui plait aux théoriciens. Avoir plusieurs classes permet de "séparer", et au contraire je trouve bien plus élégant de réutiliser dans l'interface des composants du backend (hériter de ses classes). On est ici dans un cas de réutilisabilité utile et pratique.

    Dans la pratique, le backend définit des classes pour des formes géométriques avec des données précises ; dans l'interface je veux éditer ces formes géométriques, je trouve ça troublant de suggérer de ne pas utiliser ces classes existantes.

    - ou tu ne fais qu'un modèle qui mélange à la fois les structures et les services pour le calcul et pour l'UI.

    Je ne comprends pas ce que ça veut dire (est-ce que parler de « services » est une façon cachée de parler d'interfaces ?).