Comprendre les Design Patterns

Posté par . Modéré par trollhunter.
Tags :
0
17
avr.
2002
Doc
Extrait :
« Vous pratiquez un langage dit "orienté objet" et vous avez l'impression que votre développement ne tient pas toujours la route, est difficile à maintenir, s'enlise progressivement à chaque version, alors cet article est fait pour vous éclairer. Nous allons ici réapprendre la conception objet et trouver les moyens pour simplifier votre codage grâce aux "design patterns" »
  • # Trobjet

    Posté par . Évalué à -10.

    Cette news pourrait bien faire l'OBJET d'un Troll :o)
    • [^] # Re: Trobjet

      Posté par . Évalué à -6.

      Pourquoi troller sur ce sujet ?
      • [^] # Re: Trobjet

        Posté par . Évalué à -5.

        Programmation orienté objet or not Programmation orienté objet, that is the troll. Mais vas plutôt sur la tribune, c'est là qu'il a lieu le troll en ce moment.
  • # Hep

    Posté par (page perso) . Évalué à -7.

    Vl'a ce qu'on apprend en IUT... Enfin bientôt... Nefin un jour peut-être que nos profs sauront nous expliquer ca...
    Arf...
    • [^] # Re: Hep IUT

      Posté par (page perso) . Évalué à -3.

      mdr... je vois qu'on a suivi la même expérience. glop !
      • [^] # Re: Hep IUT

        Posté par . Évalué à 9.

        Il n'y a pas qu'en BTS que les profs ont du mal à expliquer le principe des Design Patterns... en FAC aussi! Par contre, même si la présentation n'est pas top (expliquer les DP puis ensuite l'UML, y'a quelque chose qui ne va pas!), on nous avait conseillé d'acheter "Design Patterns, Catalogue de modèles de conception réutilisable" (éd. Vuibert) et je ne suis pas déçu de cette acquisition... même si la version que j'ai a plein de problèmes de traduction.
        • [^] # Re: Hep IUT

          Posté par (page perso) . Évalué à 10.

          Oui, le gof (gang of four : E. Gamma, R. Helm, R. Johnson, J. Vlissides) c'est vraiement un bouquin indispensable, mais c'est vrai que la traduction française est truffée d'erreurs. Heureusement, la version originale est fournie sur CD-ROM avec le livre.
          Par contre, le prix est vraiment élevé (surtout comparé à la grosseur du bouquin), même pour un livre d'info (qui sont TOUJOURS très cher) : entre 300/6,55957 et 350/6,55957 €.

          J'ai survolé l'article, et je pense qu'il a une mauvaise approche : il ne traite que du code java, alors que (par définition) on utilise les design patterns à la conception et non à l'implémentation. Il aurait donc été plus intéressant de commencer par des diagrammes UML. Il est beaucoup plus facile de comprendre un design pattern quand on a des diagrammes de classes et de séquence sous les yeux (et d'autres si besoin est), avant de l'utiliser ou de l'adapter au problème qu'on a à traiter.
  • # Une lecture intéressante

    Posté par (page perso) . Évalué à 6.

    Plus qu'une explication des design patterns (terme que je trouve un peu pompeux), je trouve que c'est un bon catalogue de méthodes assez répandues.

    Certaines d'entre elles (je pense en particulier à celles qui sont appellées modèles de structure) sont quand même clairement des bidouilles pour contourner des limitations du langage, C++ en l'occurrence. Personnellement, j'utilise plutôt Python, et le typage dynamique autorise tout ça sans avoir à s'emmerder à taper des trucs en plus.
    • [^] # Re: Une lecture intéressante

      Posté par (page perso) . Évalué à 10.


      > Certaines d'entre elles (je pense en particulier à
      > celles qui sont appellées modèles de structure) sont
      > quand même clairement des bidouilles pour contourner
      > des limitations du langage, C++ en l'occurrence.


      Erm. À vrai dire, le monsieur qui a écrit l'article est un développeur Java, et tous les exemples sont en Java (avec des interfaces et du Javadoc).

      Et puis, il n'est pas question de faire des bidouillages pour taper moins de trucs, mais de faire quelque chose de propre pour imposer certaines conditions ou bypasser certains élements de codes non-modifiables.

      seb.
      • [^] # Re: Une lecture intéressante

        Posté par (page perso) . Évalué à 5.

        Erm. À vrai dire, le monsieur qui a écrit l'article est un développeur Java, et tous les exemples sont en Java (avec des interfaces et du Javadoc).
        Oups... Ça y ressemblait pas mal, pourtant (j'ai jamais vu de Java et je connais mal C++).

        Et puis, il n'est pas question de faire des bidouillages pour taper moins de trucs, mais de faire quelque chose de propre pour imposer certaines conditions ou bypasser certains élements de codes non-modifiables.
        Je n'ai jamais dit ça ! J'explique juste que certains langages permettent de faire strictement la même chose avec une syntaxe bien plus légère.
        • [^] # Re: Une lecture intéressante

          Posté par (page perso) . Évalué à 5.

          Mais oui on sait tu fais du python et t'as raison !...
          Si il fallait soutenir tous ceux qui gueulent sur les toits "je fais du python et vous êtes tous des cons" ça en ferait des impots en plus !
          Et avant de critiquer faut se renseigner, par exemple Java supporte la détermination dynamique de type, et bien plus... Et en C++ les templates c'est pas fait pour les chiens.
          • [^] # Re: Une lecture intéressante

            Posté par (page perso) . Évalué à -9.

            Ouaaaah, bin c'est bon, si ça rend aussi agressif, je te laisse te tâter les roubignolles sur tes design patterns, et je retourne à des choses plus intéressantes. Coder, par exemple.

            (-1, on s'en tape)
      • [^] # Re: Une lecture intéressante

        Posté par . Évalué à 10.

        Erm. À vrai dire, le monsieur qui a écrit l'article est un développeur Java, et tous les exemples sont en Java (avec des interfaces et du Javadoc).

        De toute façon les design patterns sont sensés être indépendants du langage.

        A titre informatif, il n'y a pas que des design pattern d'ailleurs. A mon avis, les architectural patterns sont au moins aussi important pour le design d'une application.
        L'architecture MVC (modèle, vue, controleur), par exemple, a fait ses preuves pour des applications web. Franchement, je ne suis pas étonné que l'auteur de l'article developpe en java, puisque ce langage se prète bien aux patterns.
        Par exemple, réaliser une architecture MVC pour une application web est assez facile avec l'utilisation des Servlets pour le controleur, les JavaBeans pour les données et les JSP pour tout ce qui est vue, on peut pas vraiment en dire autant avec d'autre langage (en tout cas mes faibles connaissances en PHP ne m'ont pas permis de retrouver la même chose avec ce langage). Même si il faut bien avouer que les beans sont assez "chiants" à manipuler et que java a une conception assez curieuse de la durée d'une session.
        • [^] # Re: Une lecture intéressante

          Posté par (page perso) . Évalué à 2.

          Notons quand même que "sensés être"!="sont". Par exemple Visiteur/Visitable, c'est quand même très adapté aux templates. En Java, c'est implantable, mais c'est lourdaux. Il y aussi beaucoup de DP spécifiques, par exemple les DPs orientés Entreprise Java Beans, les DPs orientés Thread (le bouquin de Doug Lea) qui sont relativement spécifiques à Java, etc. Pour le reste, on est bien d'accord, Java c'est le langage de prédilection des patterns modernes (MVC, ça date de smalltalk !).
      • [^] # Re: Une lecture intéressante

        Posté par . Évalué à -1.

        Tous les exemples de gamma, helm, johnson et
        vlissides sont en C++ (et un tout petit peu
        de smalltalk histoire de).

        Donc :

        Erm. À vrai dire, les monsieurs qui ont écrits le bouquin sont des développeurs C++, et tous les exemples sont en C++.
        • [^] # Re: Une lecture intéressante

          Posté par (page perso) . Évalué à 2.

          À vrai dire, les monsieurs qui ont écrits le bouquin sont des développeurs C++

          Gamma participe aussi à JUnit ( http://junit.org/(...) ), framework de test unitaire en... Java.
        • [^] # Re: Une lecture intéressante

          Posté par . Évalué à 4.

          faut dire qu'en smalltalk, c'est pas vraiment un problème les patterns, y'en a des dizaines et c'est associé à la culture du langage.

          Donc pas besion d'en faire des tonnes.

          Un truc marrant : VisualWorks utilise le MVC alors que Dolphin utilise le MVP, les patterne c'est aussi un sujet de troll
    • [^] # Re: Une lecture intéressante

      Posté par (page perso) . Évalué à 3.

      Personnellement, j'utilise plutôt Python, et le typage dynamique autorise tout ça sans avoir à s'emmerder à taper des trucs en plus.

      Je ne suis pas sur de comprendre. Peux-tu donner un exemple concret ?
      • [^] # Re: Une lecture intéressante

        Posté par (page perso) . Évalué à 3.

        Par exemple, dans l'article, il est présenté des méthodes de création d'interfaces pour avoir plusieurs classes avec les mêmes méthodes. Ce qui est clairement bien pratique à avoir, on est d'accord.

        Mais avec un typage dynamique, peu importe que tu sois en présence de la classe toto ou de la classe titi, car si tu fais machin.méthode(truc) il se débrouillera dans les deux cas.

        Cela dit, le typage dynamique c'est aussi plein d'inconvénients à côté.
        • [^] # Re: Une lecture intéressante

          Posté par (page perso) . Évalué à 1.

          Par exemple, dans l'article, il est présenté des méthodes de création d'interfaces pour avoir plusieurs classes avec les mêmes méthodes.

          De quel pattern parles-tu ?
        • [^] # Re: Une lecture intéressante

          Posté par (page perso) . Évalué à 3.

          Mais avec un typage dynamique, peu importe que tu sois en présence de la classe toto ou de la classe titi, car si tu fais machin.méthode(truc) il se débrouillera dans les deux cas.

          Je ne comprends toujours pas. Je présume que "machin" est un nom d'objet d'un certain type (class toto ou titi).

          Partant de là, en Python ou n'importe quel autre langage objet, soit les classes toto et titi définissent la méthode 'méthode' prenant un 'truc' comme argument et ça passe, soit non et tu te prends une erreur à la compil dans le cas d'un langage fortement typé comme C++, ou une exception au runtime dans le cas d'un langage comme Python ou Ruby. Que tu ais un typage dynamique ou pas ne change rien au fond du problème, il faut que toto et titi aient la même interface.

          Ou alors tu veux peut-être dire qu'avec un typage dynamique, toto et titi peuvent définir deux méthodes avec le même nom et les mêmes arguments, mais sans hériter d'une classe commune, et qu'un truc comme

          def appelle_la_methode_foo (obj, arg)

          obj.foo(arg)

          end

          va passer, qu'on lui passe un objet toto ou titi. Là oui, c'est vrai. Mais le but de ce type de pattern est un peu plus complexe que ce cas là :-).
          • [^] # Re: Une lecture intéressante

            Posté par (page perso) . Évalué à 1.

            Ou alors tu veux peut-être dire qu'avec un typage dynamique, toto et titi peuvent définir deux méthodes avec le même nom et les mêmes arguments, mais sans hériter d'une classe commune, et qu'un truc comme

            def appelle_la_methode_foo (obj, arg)

            obj.foo(arg)

            end

            va passer, qu'on lui passe un objet toto ou titi. Là oui, c'est vrai. Mais le but de ce type de pattern est un peu plus complexe que ce cas là :-).


            Oui, c'est ce que je voulais dire.

            Auquel cas, quel est l'intérêt d'une interface comme décrit dans l'article sur des choses plus simples comme celles-ci ?
            • [^] # Re: Une lecture intéressante

              Posté par (page perso) . Évalué à 4.

              Auquel cas, quel est l'intérêt d'une interface comme décrit dans l'article sur des choses plus simples comme celles-ci ?

              En pratique, il y a plus d'une méthode commune aux deux classes, et tu veux qu'elles dérivent de la même classe, pas seulement pour des question de typage mais aussi parce que ça explicite bien ce que tu veux faire, et c'est beaucoup plus maintenable. Par ailleurs tu peux plus facilement tester les paramètres qu'on te passe avec un truc du genre

              if (machin.implements(telle_interface))
              ... ok
              else
              throw
              end

              Entre

              class Foo
              open()
              close()
              end

              class Bar
              open()
              close()
              end

              et

              Interface Stream
              open()
              close()
              end

              class Foo implements Stream
              ...
              end

              class Bar implements Stream
              ...
              end

              le 2nd cas est quand même plus clair, non ? Plus tu en dis au langage sur comment s'organisent tes classes, mieux c'est.

              Je crois que tu devrais lire le Design Patterns :-).
          • [^] # Re: Une lecture intéressante

            Posté par (page perso) . Évalué à 4.


            Ou alors tu veux peut-être dire qu'avec un typage dynamique, toto et titi peuvent définir deux méthodes avec le même nom et les mêmes arguments, mais sans hériter d'une classe commune, et qu'un truc comme ...


            c'est possible avec du typage statique : on peut faire ça en Objective Caml.
  • # Intéressant

    Posté par . Évalué à 10.

    Cet article est intéressant et de plus il propose un ensemble de liens utiles pour creuser le sujet.

    Les designs patterns peuvent paraitre anodins, mais comme le souligne l'auteur on fini à force d'entasser des lignes par se retrouver à coder plus ou moins comme un goret ;-) C'est là l'intéret des motifs objets. Meme si on ne les maitrise pas tous, les plus utilisés (Factory, Singleton) rendent bien des services.
  • # Hum... [première partie]

    Posté par . Évalué à 10.

    Alexandre a eu l'excellente idée d'aborder un sujet extrèmement important. Avant
    de me remettre à la physique, j'ai fait 2 ans d'informatique en SSII, et
    j'estime que les design patterns sont les connaissances en informatique les
    plus utiles que j'aie pu acquérir durant cette période.

    Mais j'aurais tellement aimé les découvrir plus tôt ! Personne autour de moi ne
    semblait les mettre en pratique, et les quelques sites ou articles que j'ai pu
    trouver à l'époque ne m'ont jamais convaincu. L'univers de l'informatique est
    rempli de gens qui vous proposent d'adopter leurs méthodes de conception et de
    développement parce qu'elles ont fonctionné pour eux. Il n'y a pas si longtemps
    par exemple, on ne parlait que de RAD (développement rapide d'applications). Ca
    marchait dans certains cas, ca devait donc être la solution universelle !
    Aujourd'hui, un vrai programmeur ne jure que par l'eXtreme Programming...peu
    importe. La grande difficulté dans cette jungle est de savoir distinguer parmi
    les expériences vécues, celles qui nous paraissent adaptées à nos besoins de
    celles qui sont trop particulières. Et à l'époque, j'ai cru que les design
    patterns n'étaient qu'une énième recette de cuisine, sûrement intéressante,
    mais pas plus ni moins que les autres.

    C'était une erreur. Et j'ai peur que beaucoup d'autres la commettent également.
    Alors, même si je crains de ne pas faire plaisir à Alexandre, je ne vous
    recommande pas la lecture de son article pour vous familiariser avec les
    modèles de conception. Justement parce que c'est ce genre d'articles qui
    m'a caché l'importance inestimable des modèles de conception.

    Il contient d'abord de grosses erreurs:

    Quelques rappels sur la conception objet

    Certaines classes ne sont pas complètement construites afin d'obliger les
    sous-classes à effectuer une surcharge. On parle alors de classes abstraites ou
    d'interfaces.L'interface est employée en Java pour compenser
    l'interdication d'utiliser l'héritage multiple (héritage de plusieurs classes),
    interdication qui n'apparaît pas en C++.

    Ici deux erreurs extrêmement graves. D'abord, le concept d'interface est tout à
    fait distinct de celui de classe abstraite. Une classe abstraite permet la
    factorisation de code, ni plus, ni moins. Une interface, c'est l'ensemble des
    requêtes auxquelles un objet peut fournir une réponse.

    Ensuite, l'auteur confond malheureusement héritage de classe et héritage
    d'interface. Une interface est une notion de programmation objet, à ce niveau de
    la discussion, on n'a pas à parler de java ou de c++. L'héritage de classes
    permet le partage de code. L'héritage d'interface décrit comment un objet peut
    être utilisé à la place d'un autre.

    Je ne saurais trop vous conseiller d'oublier ces "rappels" et de préférer des
    lectures plus sérieuses à ce sujet.

    Définition des design patterns

    Les designs patterns ne sont pas rééllement normalisés
    Au contraire. Les modèles de conception sont justement l'expression
    du bon sens de la conception sous forme de modèles standard. Quel standard ?
    celui du livre "Design Patterns" écrit par un groupe d'auteurs mondialement
    connu comme le "Gang des quatre" (Gang of Four, ou GoF)[1][2]. Ce sont les
    pères des modèles de conception. Leur livre, paru en 1995, présente les 23
    modèles de conception qui sont devenus un standard de fait. Le JDK a
    ainsi été construit en réutilisant fidèlement ces modèles. Ce sont bien
    évidemment les mêmes que vous retrouvez dans l'article d'Alexandre Brillant qui
    malheureusement ne cite pas cette référence.

    Les design patterns ou modèles de conception décrivent des organisations
    pratiques de classes objets. Ces organisations résultent souvent d'une
    conception empirique, le concepteur objet tente de faciliter la réutilisation et
    la maintenance du code

    Outre la première phrase, dont je ne comprends absolument pas le sens, on trouve
    encore une erreur grave. Les modèles de conception ne concernent pas du tout le
    réutilisation de code. La réutilisation de code est très difficile et n'est
    possible que dans des occasions bien précises. Par exemple, quelle bout de code
    d'une application web écrite en java pourrait-on réutiliser dans une application
    client écrite en c++ ?
    Les modèles de conception concernent la réutilisation de méthodes de
    conception
    ; ca n'a rien à voir.
    • [^] # Hum... [seconde partie]

      Posté par . Évalué à 10.

      Fabrique de création

      Une fabrique de création (ou factory) est une classe [...]
      Non, justement. Une fabrique définit une interface pour la création
      d'objets, pas une classe.

      Singleton

      Un singleton sert à contrôler le nombre d'instances d'une classe présent à
      un moment donné. C'est souvent trés pratique pour les classes sans état et
      effectuant toujours les mêmes traitements.

      N'importe quoi. Un singleton garantit qu'une classe n'a qu'une seule
      instance
      . Une classe sans état est une classe qu'on n'instancie pas
      (modifiant static en java).

      Le singleton limite le nombre d'instance en mémoire
      Et comment, puisqu'il ne doit y en avoir qu'une.

      Bon, je m'arrête là pour les erreurs.
      D'autre part, l'article comme beaucoup d'autres présente une liste de modèles de
      conception ; pour beaucoup d'entre eux, l'intention de ce modèle n'est pas
      présentée et on est réduit à un exemple de code. Mais les modèles de conception
      ne se réduisent pas à une recette de cuisine ! Il ne s'agit pas de dire qu'en
      réfléchissant un peu on peut programmer proprement ! Il s'agit d'expliquer en
      quoi un modèle peut répondre à une problématique, et en quoi la problématique et
      le modèle sont universels. Si l'exemple de code est une aide indispensable, il
      ne constitue pas à lui seul la description du modèle sous-jacent.

      Voilà mon conseil, qui peut ressembler à une attaque directe de l'auteur de
      l'article, mais qu'il faut simplement interpréter comme un cri du coeur.

      Le gang des quatre présente dans leur livre les modèles de conception de façon
      plus claire qu'aucun des articles que j'ai pu lire auparavant. Non seulement
      parce qu'ils en sont les pères, mais parce que leur livre n'a pas vieilli depuis
      1995. C'est toujours une référence, à tel point que je la considère comme une
      des rares références indispensables pour un développeur, disons "orienté objet".
      Je ne suis sûrement pas le seul, puisqu'il est par exemple une des deux lectures
      imposées pour la certification Sun, avec les Java Blueprints.

      Plutôt que d'écrire un article présentant mal --à mon avis-- les modèles de
      conception (c'est ce genre d'articles qui m'a fait perdre 1 an et demi, d'où ma
      réaction), Alexandre Brillant aurait été plus avisé de décrire leur importance
      et d'indiquer en référence le livre du GoF. Dont acte.

      eul'Bob

      Références:
      -----------
      [1] Design Patterns - Elements of reusable object-oriented software
      E. Gamma, R. Helm, R. Johnson, J. Vlissides
      Addison-Wesley, 1995

      [2] Traduction française, des mêmes auteurs:
      Design Patterns - Catalogue de modèles de conception réutilisables
      Vuibert, 1999
      • [^] # Re: Hum... [seconde partie]

        Posté par . Évalué à -2.

        Fabrique de création

        Et bien si, une fabrique est bien une classe, pas une interface. Une classe qui permet de construire des instances d'une interface donnée (ou de plusieurs interfaces d'ailleurs, comme dans son exemple).
        • [^] # Re: Hum... [seconde partie]

          Posté par . Évalué à 2.

          Un peu de c++ pour établir la contradiction:

          class Toto;
          Toto* create_toto ();


          Dans ce cas, create_toto est une fonction, pas une classe, et si je ne m'abuse il s'agit bien d'une factory. Cette fonction pourrait aussi etre une méthode statique de la classe Toto.
      • [^] # Re: Hum... [seconde partie]

        Posté par (page perso) . Évalué à 6.

        Completement d'accord avec toi.
        J'allais envoyer un commentaire de la meme veine ... et j'ai vu ton commentaire.
        Sinon, un truc qui m'a etonne c'est de ne pas voir le visiteur. Il me semble pourtant qu'avec le Singleton et l'Iterateur c'est le design le plus connu et le plus utilise ...
        Comme le dit bobert, une seule reference : Design Patterns par Gamma, Helm, Johnson et Vlissides ...
      • [^] # Re: Hum... [seconde partie]

        Posté par . Évalué à -1.

        Lorsque tu écris qu'une fabrique est une
        interface, cela n'à pour moi aucun sens puisqu'une
        interface désigne une abstraction afin
        d'interchanger l'implémentation sans rompre
        le cohérence de l'ensemble. L'interface couvre
        donc n'importe quel code Java y compris les
        fabriques si cela est utile.

        Un fabrique n'a selon toi aucun sens en dehors
        de l'interface mais puisque l'implémentation n'est
        pas délimitée comment pourrais - tu donné un
        sens à la fabrique ? La classe est ici à des
        fins pratiques, je ne veux pas embrouiller tout
        le monde au risque de choquer les
        pusillanimes de la programmation.
    • [^] # Re: Hum... [première partie]

      Posté par . Évalué à -1.

      Je pense que le terme Erreur Grave doit être
      remis dans un contexte saint.

      C'est une introduction donc je n'aborde pas
      tous les sujets.

      Concernant les interfaces et les classes abstraites,
      elles appartiennent à la même famille décrivant
      des squelettes de classes plus ou moins
      complet. La distinction n'est pas clairement faite
      ici car l'article tente (et je dis bien tente)
      d'être généraliste, or le concept d'interface
      se traduit par une classe abstraite en C++.

      D'autre part, l'héritage entre interface existe
      même avec une classe (hé oui, cela n'a
      à priori aucun sens), donc je te laisse conclure:

      // Ce code était présent dans l'outil WebObject
      public interface Toto extends java.lang.Object {
      }

      Donc l'interface Java est traitée comme une
      classe abstraite particulière. Je reconnais que
      extends et remplaçé par implements à l'usage mais
      c'est pour forcer l'usage de l'interface pas
      pour renforçé la différence de l'interface
      et de la classe abstraite.

      Concernant l'héritage de classe et l'héritage
      d'interface. Il faudrait peut être que tu
      lises l'article en entier et notamment la ligne
      suivante sur l'implémentation.

      Un standard est avant tout défini par un
      organisme indépendant, gamma et compagnie
      ne forme en aucun cas un organisme de contrôle
      et d'évolution des design patterns.

      Par exemple :

      Je viens de me définir une nouvelle norme pour
      les fabriques.

      public class ObjectBuilder {
      public ObjectBuilder( ClassLoader loader )...
      public Point getPoint( int x, int y )...
      public void setDelegate( ObjectBuilder ob )...
      }


      Encore une avec une hierarchie

      public class ObjectCreator {
      public Object getObjectForName( String name );
      public ObjectCreator getParent();
      }

      Encore une

      public class NewObject {
      public Instance getNewObject();
      }

      public interface Instance {
      public Object getObject();
      }

      Bref on peut faire tout et n'importe quoi autour
      des designs patterns alors pour moi il n'y a
      ni norme ni standard.

      Concernant ta dernière remarque toujours aussi
      grave, commence déjà par lire sérieusement
      l'article avant d'écrire au hasard.
      • [^] # Re: Hum... [première partie]

        Posté par . Évalué à 3.

        S'il y a un standard dans les DP, c'est sur le formalisme employé pour la description d'un pattern particulier, et il se trouve que ces descriptions ont bien souvent la structure utilisé dans le bouquin du GoF.
        Maintenant, il faut bien comprendre que les DP essayent de présenter des _concepts_ reutilisables, qui peuvent (doivent) être modifiés dans le programme en construction. Il ne s'agit pas d'une recette de cuisine qui s'applique à la lettre (et c'est bien ce que tu montres avec des différentes façons de voir les fabriques).
      • [^] # Re: Hum... [première partie]

        Posté par . Évalué à 3.

        «Bref on peut faire tout et n'importe quoi autour
        des designs patterns alors pour moi il n'y a
        ni norme ni standard.»

        Non ! comme te l'a fait remarquer Bobert, «il s'agit d'expliquer en quoi un modèle peut répondre à une problématique, et en quoi la problématique et le modèle sont universels». Le bouquin du gof décrit les problématiques qui reviennent régulièrement pour les programmeurs ainsi que les modèles qui leur répondent; tes factories sont très jolies mais je doute qu'elle soit souvent utiles, et tu n'as pas expliqué à quels problèmes elle répondent.
        • [^] # Re: Hum... [première partie]

          Posté par . Évalué à -1.

          La remarque de Bobert va dans mon sens, mais pour
          bien éclairer le sens de ma phrase, un protocole
          HTTP est normalisé, l'usage en fait un standard.
          Les DP ne peuvent entrer dans cette catégorie.
          Quant aux factory c'est vrai que je n'ai pas trés
          appronfondi mais il suffit de regarder
          l'introduction aux modèles de création une ligne
          au-dessus pour avoir l'explication. RTFM
    • [^] # Re: Hum... [première partie]

      Posté par (page perso) . Évalué à 8.

      Très intéressant, ton post. Quelques remarques :

      Sur les interfaces et les classes abstraites :
      J'irais plus loin que toi. Je pense que l'interface est le terme "objet" pour désigner un type abstrait, quelque chose qui est au moins aussi vieux que l'objet. Un type abstrait, c'est une catégorie de "machins" qu'on peut manipuler pour construire un algorithme. Pour définir un type abstrait, on fait en gros la liste des opérations disponibles sur les "machins" en question. Bien sûr, actuellement on parle objet, donc on ne dit pas "machin", mais objet. Mais bon, sur le fond c'est la même chose. Effectivement, comme C++ ne possède pas la notion d'interface, on l'implante en ce langage par une classe abstraite. A ce niveau, d'ailleurs tu fais une erreur. De fait en C++, une classe abstraire permet justement de représenter la notion d'interface et permet donc plus de chose que le partage de code.

      Pour distinction entre récupération de code (héritage au sens classique des langages objets) et celle de type, je pense que la meilleure chose est tout simplement de ne pas appeler la deuxième héritage. Effectivement en Java une interface peut hériter d'une autre, mais c'est de l'implantation. Au niveau de la conception, il s'agit d'une relation sur les types abstraits : on définit un type abstrait dérivé à partir d'un autre type (c'est la notion de sous-typage de Sather). Ce genre de construction dépasse largement le cadre de la programmation objet. C'est utilisé par exemple dans les schémas XML.

      sur la définition de DP
      Là, je ne suis pas d'accord avec toi. Certains DP sont justement écrits pour faciliter la réutilisation de code (sans parler d'héritage). C'est le cas par exemple de la plupart des DPs de structure qui permettent d'adapter un code existant pour l'utiliser à partir d'un autre code existant. Bien entendu, il n'y a pas de magie : utiliser du code C++ dans une appli Java c'est lourdingue.

      sur le Singleton
      Alors là, non ! Un Singleton pur, c'est une seule instance, mais tout le monde comprend quand on parle de Singleton pour désigner une classe qui contrôle son nombre d'instances, même si ce n'est pas exactement un (je pense aux pools de Thread, par exemple).
      D'autre part ta phrase "Une classe sans état est une classe qu'on n'instancie pas (modifiant static en java)." ne veut pas dire grand chose. Il existe effectivement (en Java) des classes qu'on n'instancie pas. Ce sont de "fausses" classes, c'est-à-dire des groupes de méthodes de classe (celles qui ont le modifieur static), c'est-à-dire une sorte de petite bibliothèque (je pense en particulier à la classe Math qui joue le rôle en Java de math.h en C). Je pense que l'auteur voulait parler dans son article d'objet sans état, c'est-à-dire d'objet sans variable. Par exemple quand on construit un Comparator en Java (un ordre), il est très classique que celui ni ne contienne pas de variable. L'objet joue alors le rôle d'un pointeur sur fonction orienté objet (et d'ailleurs, on utilise souvent une classe anonyme pour programmer ça en Java). L'objet est bien entendu instancié !
  • # Des excellents livres

    Posté par . Évalué à 10.

    Bruce Eckel écrit de super livre qui sont disponibles sur son site, ainsi que des futurs livres (dont un sur le python et les design pattern).

    http://www.bruceeckel.com/(...)

    Certains de ces livres comme "Thinking in Java" sont traduit en françait sur le net (cherchez sur google).

    Pour en revenir aux design pattern, ç'est vraiment qqc de fontamental, certains sont assez triviaux, mais d'autres peuvent être des révélation dans votre vie de programmeur. Un de mes préféré et que j'utilise relativement souvent: les visiteurs
    • [^] # Re: Des excellents livres

      Posté par (page perso) . Évalué à 10.

      N'oublie pas l'excellentissime "Thinking in C++", qui est une intro (enfin plus que ca quand même) à la programmation objet et au C++ absolument géniale.

      Il est bon aussi de rappeler que les livres de Bruce Eckel sont disponibles, gratuitement et en intégralité, sur le net (voir son site, http://www.bruceeckel.com(...)). Cela pendant leur écriture (pour récupérer des commentaires) et même après leur parution. Bruce part du principe que diffuser librement sur le net ne change rien a ses ventes (voire même les améliore) car pour un gros pavé de 500 pages, rien de mieux que le papier!

      D'ailleurs, si j'ai acheté "Thinking in C++", c'est parce que la version HTML m'a dépanné une ou deux fois et que j'ai été impressionné par la qualité de l'ouvrage.

      Bref, un auteur génial à tous les points de vue. Ses libres (en Anglais seulement hélas) peuvent être commandés facilement à partir des libraries en lignes (genre amazon)
    • [^] # Re: Des excellents livres

      Posté par (page perso) . Évalué à 4.

      Pour les designs patterns, il a d'abord la référence : "Design Patterns, Elements of Reusable Object-Oriented Software" de Gamma, Helm, Johnson et Vlissides, Addison-Wesley, ISBN 0-201-63361-2 . Après l'avoir lu, je pense que c'est un livre que tout programmeur se doit d'avoir dans sa bibliothèque...

      Sinon j'ai trouvé un autre bouquin, dans un style plus pédagogique je trouve, "The Joy of Patterns, Using Patterns for Enterprise Development", de Goldfedder, toujours chez Addison-Wesley, ISBN 0-201-65759-7 . Un peu moins dense que "Design Patterns", mais plus agrèable à lire, bref ... :)

      L'intérêt des Designs Patterns est qu'il s'agit de design; les concepts expliqués peuvent s'implémenter dans n'importe quel langage (bien que les langages OO facilitent grandement les choses :) ObjectiveC, Java, C++ ...)

      Et franchement, un bon design facilite énormément le codage et la maintenance du code. Ce qui m'étonne, c'est de ne pas avoir eu des cours sur les DP en fait, tellement ça me paraît une lecture indispensable ...
      • [^] # Re: Des excellents livres

        Posté par . Évalué à 1.

        Juste pour dire: certains design pattern ne peuvent pas s'implémenter dans tous les languages. Un exemple: certains pattern sont basé sur l'héritage multiple. On ne peut donc pas les mettre en place en java par exemple.
  • # A propos des pattern

    Posté par . Évalué à 7.

    Avant de parler des pattern, on peut rappeler l'ensemble des principes sous-jacents à ces concepts.

    Cela a été très bien formulé par Robert Martin.
    On peut trouver une adaptation française à l'adresse suivante:

    http://www.design-up.com/design/principesoo/index.html(...)
  • # Les patterns en exemple

    Posté par . Évalué à 5.

    Une petite url (in english) qui reprend les patterns et donne des exemples de tous les jours pour les expliquer: http://www.agcs.com/supportv2/techpapers/patterns/papers/patexample(...)
    http://www.agcs.com/supportv2/techpapers/patterns/papers/tutnotes/(...)
  • # Complément à l'introduction

    Posté par . Évalué à 1.

    Tous les design patterns du livre de gamma sont résumés ici :

    http://www.djefer.com/articles/design/index.htm(...)


    Bonne lecture
  • # Encore plus de de Design Patterns

    Posté par . Évalué à 2.

    Le site www.programmationworld.com propose également des explications sur les Design Patterns (en se basant sur divers langages) dans la section Langages/Programmation Avancée. Une dizaine de patterns sont d'ores et déjà disponibles.
  • # conception, vous avez dit conception ?

    Posté par . Évalué à 0.

    J'ai de gros doutes quant à l'intérêt de cet article. L'auteur tente de vulgariser les design patterns en s'attardant plus sur des effets de bord que sur l'explication des concepts qui les sous tendent (ce qui est un comble lorsque l'on fait des rappels sur la conception objet).

    A ce sujet, il vaut mieux se plonger dans le livre du gof qui outre le catalogue de modèles propose une introduction d'une trentaine de pages très abordables et enrichissantes. On y apprend entre autre que les design patterns ont vu le jour dans les années 70 grâce à un architecte nommé Alexanders et qu'ils adressaient des problèmes de construction de bâtiments.

    Mon sentiment sur « les rappels de conception objet » :

    Contrairement aux langages de type procéduraux comme le C ou le Pascal, la conception objet ne divise pas l'espace de données (attributs) et l'espace de traitements (méthodes). Cet espace commun s'applique à une partie du problème à gérer sous la forme d'une classe.
    Donc en gros, la différence entre le paradigme objet et procédural se réduit à :
    - en procédural, on a, d'un coté les données et de l'autre les traitements
    - en objet, données et traitements sont fusionnés au sein d'un concept appelé classe

    Une classe est une représentation abstraite décrivant comment faire fonctionner des objets.
    Drôle de façon de voir les choses. Si "Alexandre" est une instance de la classe "Homme", la classe "Homme" décrirait donc comment faire fonctionner "Alexandre". Une classe définit une unité sémantique basée sur la statique (attributs et méthodes) et la dynamique (états) et c'est ce complexe statique-dynamique que l'on appelle le comportement.

    Les objets sont construits à partir de cette classe lors de l'exécution par un processus d'instanciation (en Java l'opérateur new). Chacune des déclarations dans une classe peut être limitée dans sa portée (portée locale ou privée, portée de groupe ou package, portée de descendance ou protégée, portée globale ou publique).
    Hors sujet par rapport à "Quelques rappels sur la conception objet"

    Une classe peut être associée à d'autre classes pour faciliter la réutilisation.
    Pas d'accord. Une classe doit être associée à d'autres classes de même niveau de granularité et même niveau d'abstraction sous peine de souffrir de manque de cohésion (l'un des facteurs de non-réutilisation)

    L'association la plus commune est l'héritage.
    Je ne pense pas : une relation d'association simple est beaucoup plus commune que l'héritage. Il suffit de s'interroger sur la nature des relations que l'on entretient avec notre environnement (réseaux de connaissances, possessions personnelles, etc.) pour s'apercevoir qu'il y a très peu de relations d'héritage.

    L'héritage sert à spécialiser une classe existante (lien de généralisation/spécialisation) par la modification/l'ajout de nouvelles méthodes et de nouvelles données. Cette spécialisation conduit à la construction de nouvelles classes (appelées aussi sous-classes). Le concept d'héritage peut être vu comme la conception d'un élément "est une sorte de".
    L'héritage doit être vu comme une relation "est une sorte de". Lorsque ce n'est pas le cas, il faut être capable d’expliquer pourquoi sinon, on va au devant de problèmes de conception et de non-réutilisabilité (que ce soit des modèles ou des implémentations).

    Lorsqu'une méthode d'une classe est redéfinie par une sous-classe, on dit qu'il y a surcharge. Comme nous le verrons dans la suite cette possibilité donne une grande souplesse à l'introduction de classes génériques déléguant certains comportements aux sous-classes.
    Je ne pense pas que le terme "classe générique" soit approprié. Une classe générique s'appelle, dans le méta model d'UML, « Parameterised Class » (les adeptes de C++ auront reconnu les templates).

    Certaines classes ne sont pas complètement construites afin d'obliger les sous-classes à effectuer une surcharge. On parle alors de classes abstraites ou d'interfaces.
    Encore une fois, c'est une drôle de façon de voir les choses. Si je décide que la classe "Mammifère" est abstraite, ce n'est pas pour obliger les sous classes à implémenter certaines méthodes mais plutôt parce l'on ne peut pas trouver d'individus de cette espèce qui ne soient que des mammifères.

    L'interface est employée en Java pour compenser l'interdication d'utiliser l'héritage multiple (héritage de plusieurs classes), interdication qui n'apparaît pas en C++.
    Bof. L'interface n'est un outil qui permet de "simuler" le multi héritage. La notion d'interface permet de donner à une classe une "empreinte" supplémentaire, cela relève plus du polymorphisme que du simple moyen de compensation. Il est a noter que même si le C++ autorise le multi héritage, il n'est pas préconisé d'en abuser (risque d'héritage en diamant,...) et en général, on fait en sorte d'hériter simplement d'une classe concrète et de multi hériter de classes abstraites. C'est ce genre de principe qu'ont appliqué les personnes qui ont créé Java.

    Une interface est associée à une ou plusieurs classes d'implémentation.
    Non, c'est plutôt le contraire : ce sont les classes concrètes qui sont en relation avec les interfaces (relire les specs d'UML à ce sujet). Une interface peut être en relation avec autre chose à partir du moment où le autre chose est une autre interface et que la relation est une relation d'héritage.

    Une classe d'implémentation contient donc le code de réalisation de l'interface.
    Je préfère dire que la classe qui dispose d'une nouvelle « empreinte » doit être équipée des méthodes qui lui permettent d'assumer sa nouvelle forme.

    Dans la suite de l'article, nous proposerons des exemples en Java. Ces exemples sont facilement transposables en C++ ou dans tout autre langage objet.
    Je ne vois pas ce que le reste de l'article apporte de plus par rapport au gof.
    • [^] # Re: conception, vous avez dit conception ?

      Posté par . Évalué à 0.

      Tout d'abord comme tu le fais remarqué, il ne s'agit
      pas de rétablir toute l'étendu du paradigme objet
      en 10 lignes. Cet article s'adresse avant tout à
      des gens qui ne connaissent pas l'objet, me faire
      le reproche de ne pas être à la hauteur de gamma
      est ridicule, aucun débutant ne commencera par
      gamma, c'est comme de commençer le piano avec
      les préludes de Bach, irréaliste et sans intérêt.

      - Concernant la première remarque :
      Enlève le terme "se réduit" s.t.p. sinon la
      connotation est négative

      - 2° remarque : Le comportement n'est
      pas le résultat d'une exécution de la description
      d'une classe ? J'aimerai bien voir un objet
      qui ne serait pas "décrit" par une classe.

      - 3° remarque : Hors sujet aussi

      - 4° remarque : D'accord avec toi,
      cela porte à confusion

      - 5° remarque : Commune était à prendre
      au sens de "dans tous les languages Objets"

      - 6° remarque : "est une sorte de"
      appartient à un niveau sémantique, il ne s'agit
      pas d'une obligation. Par exemple regarde le
      dernier exemple et le DP "Template", cette
      relation n'existe pas

      - 7° remarque : C'est vrai que cela peut porter
      à confusion lorsque l'on connaît l'objet

      - 8° remarque : Théoriquement tu as raison, mais
      je me réfère avant tout à la pratique et à la
      pratique seulement. L'objet comme les réseaux
      de neurone n'ont pas grand chose à voir avec la
      réalité sinon comment classes-tu
      l'ornithorynque ? :)

      - 9° remarque : Tu as parfaitement raison, mais
      voir la remarque 3°

      - 10° remarque : Le contraire ne donnes pas
      une vision trés subtil du polymorphisme, mais
      il est vrai que les interfaces peuvent avoir des
      associations entre elles par héritage.

      - 11° remarque : Pourquoi pas, mais chacun
      sa manière.

      - 12° remarque : Mais tu t'attends à quoi ?
      J'ai pourtant bien écrit "Introduction", tu
      reconnais toi même qu'il s'agit d'une
      vulgarisation qui n'est pas à ton goût. Quant
      tu achètes un bouquin sur l'objet/UML tu ne
      prends pas les bouquins pour débutant et tu
      ne dénigres par les auteurs associés puisque
      ces mêmes auteurs t'ont permis de progresser ??

      Bonne continuation

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.