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

Langage Java Discussion :

Conception objet en java


Sujet :

Langage Java

  1. #1
    Membre régulier
    Conception objet en java
    Bonjour,

    Je me pose une question depuis longtemps, pourquoi mettre un attribut de même type que la classe, quel est l'intérêt ? je vois souvent cela dans le code source des frameworks.

    exemple
    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
     
    public class CachingConnectionFactory
    {
        private final CachingConnectionFactory factory;
     
       public CachingConnectionFactory(...){
           this.factory=new CachingConnectionFactory(...)
       } 
    }


    Si c'était pour mettre un proxy sur la classe CachingConnectionFactory, on l'aurait appellé autrement : CachingConnectionFactoryProxy.
    Ce n'est pas une construction pour faire un singleton, non plus !

    Merci pour vos lumières...car moi c'est un peu obscur !

  2. #2
    Modérateur

    Hum. Normalement c'est vraiment pour des histoires de proxy.

    On peut voir le vrai code ?

    Sinon, des classes qui ont des attributs de leur propre type, ça sert pour les structures récursives, comme les listes chaînées ou les arbres. Mais pas tellement pour les factories. A la rigueur les factories décorables, mais en principe elles s'appellent pas juste factory, en effet.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  3. #3
    Membre expérimenté
    ça me fait penser à technique utilisée pour le "pattern" décorateur ... mais est-ce le cas ici?
    J'ai des principes: je peux toujours trouver une bonne raison pour les contredire .... mais j'ai des principes!
    (un peu de pub pour mon site: http://scrountch.info/java )

  4. #4
    Membre habitué
    Le pattern Singleton utilise egalement ce principe.

  5. #5
    Modérateur

    Citation Envoyé par Yonito Voir le message
    Le pattern Singleton utilise egalement ce principe.
    Effectivement, mais la propriété serait "static" ce qui n'est pas le cas ici (à moins que ce ne soit pas le bon code)
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  6. #6
    Membre régulier
    comme je l'avais indiqué déjà...que ce n'était pas un singleton dans mon premier msg.


    le vrai code ? cela vient de cette classe org.springframework.amqp.rabbit.connection.CachingConnectionFactory
    --> mais j'ai déjà vu depuis des années ce type de construction, sans avoir saisi la raison de conception...vu le contexte actuel des choses en France, je resorts mes vieux TODO

    Je voulais savoir quel était le raisonnement initial pour construire ce type de code ?

    Décorateur ? j'en doute ??
    C'est pour décorer une autre classe, l'enrichir ? ici, c'est la même...

    merci de contribuer à me faire progresser..

  7. #7
    Membre expérimenté
    Citation Envoyé par valkeke Voir le message

    le vrai code ? cela vient de cette classe org.springframework.amqp.rabbit.connection.CachingConnectionFactory
    .
    où est ce code source? merci de nous passer une URL
    les codes sources sur lesquels je tombe n'ont pas ce champ!
    J'ai des principes: je peux toujours trouver une bonne raison pour les contredire .... mais j'ai des principes!
    (un peu de pub pour mon site: http://scrountch.info/java )

  8. #8
    Modérateur

    Citation Envoyé par valkeke Voir le message
    mais j'ai déjà vu depuis des années ce type de construction
    Moi pas. En revanche, j'ai vu beaucoup de choses qui, si on fait pas très attention, pourraient être prises par erreur comme étant construites telles que tu nous le montres.

    Du coup, il serait plus prudent de nous montrer du concret, au lieu de "non mais je me souviens j'ai vu des trucs comme ça"
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  9. #9
    Modérateur

    Citation Envoyé par valkeke Voir le message
    Je voulais savoir quel était le raisonnement initial pour construire ce type de code ?
    Le raisonnement ? La connerie plutôt...
    Avoir une instance d'une classe qui contient une propriété qui référence cette même instance... c'est pas ce qu'il y a de plus utile.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  10. #10
    Membre habitué
    Exemple tire de la classe LinkedList :

    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
     
    private static final class Entry<T>
     103:   {
     104:     /** The element in the list. */
     105:     T data;
     106: 
     107:     /** The next list entry, null if this is last. */
     108:     Entry<T> next;
     109: 
     110:     /** The previous list entry, null if this is first. */
     111:     Entry<T> previous;
     112: 
     113:     /**
     114:      * Construct an entry.
     115:      * @param data the list element
     116:      */
     117:     Entry(T data)
     118:     {
     119:       this.data = data;
     120:     }
     121:   } // class Entry


    Mais bon il est vrai que dans l'exemple donne dans le premier message, cela parait bizarre.

  11. #11
    Membre régulier
    Voici un lien pour la classe en question : https://github.com/spring-projects/s...onFactory.java

    Avec ce lien, tu vas pouvoir avoir du concret, sorry...

    OButterlin : j'aurai tendance à te suivre sur cette idée, mais je suis humble devant Spring, et donc je cherche tjrs : tout de même quel est l'intérêt ?

    quel est l'intérêt de mettre une proprièté du même type que la classe possédant cette propriété ? voilà ma question...si on met de côté le singleton(mais il faut rajouter static : pas le cas ici !) ou le wrapper, alors qu'on aurait pas nommé les classes du même nom...

    C'est clair, ce n'est pas le décorateur !

    alors, on en pense quoi ? merci d'avance pour toutes vos remarques..

  12. #12
    Modérateur

    D'accord je vois.

    En l'occurrence c'est parce qu'il y a une différence entre les publisher connections et les sous-connections. Du coup quand on veut faire du cache là-dessus un peu poussé, il faut distinguer par quoi les connections sont faites à l'origine et comment en faire des nouvelles.
    Comme tu peux le voir, des fois ce champ reçoit une valeur et des fois il est à null.

    Mais c'est un concept un peu spécifique à RabbitMQ là, le distingo entre publisher connection et sous-connections. Je veux dire, c'est pas qu'ils l'ont inventé, mais on trouve pas la même idée pour tout ce qui utilise une factory ni du cache des objets produits par factory.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  13. #13
    Membre régulier
    dsl thelvin, mais j'ai du mal à te suivre, tu pourrais expliciter un peu plus ton propos, merci

  14. #14
    Modérateur

    Ben pas trop non, pour être vraiment bien explicite sans dire une seule connerie, il faudrait être expert à la fois de l'implémentation de RabbitMQ, et des techniques de connection factory avec cache. C'est pas trop mon cas.

    Je dirais que le point important c'est ça :

    tu nous as pas montré un classique récurrent de la conception objet, là. Tu nous as montré un truc par et pour RabbitMQ, que les autres trucs qui font du cache ou du connection factory, n'ont pas.
    Je doute fort que tu puisses montrer un autre exemple. Ou alors c'est que tu es tombé par hasard sur deux trucs qui ont besoin d'une conception très spécifique et qui n'est pas un patron de conception.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  15. #15
    Membre régulier
    ok, merci bcp pour tes réponses...

    J'en conclue, que c'est un concept particulier qui répond au besoin de l'impl pour rabbitMQ. A ne pas faire, sauf dans des cas précis, mais lesquels ? et vraiment pourquoi ?

    ...peut-être comme a dit OButterlin..dans la majeure partie des cas, une connerie d'implémentation.

  16. #16
    Modérateur

    Citation Envoyé par valkeke Voir le message
    A ne pas faire, sauf dans des cas précis, mais lesquels ? et vraiment pourquoi ?
    Quand t'en a besoin.

    Quand, si l'idée te prenait de pas le faire, eh ben ça marcherait pas (ou alors ça forcerait à faire les choses de manière ridiculement compliquée, sans raison).

    Mais ce n'est pas des questions à se poser, ça.
    On peut se demander quand utiliser, ou ne pas utiliser, des techniques de programmation.

    Ici, il n'y a pas de technique de programmation. Il y a un truc fait pour programmer RabbitMQ. Ce n'est pas une technique. Ce n'est pas un machin connu en programmation. C'est juste un truc qui a été fait pour RabbitMQ parce que pour ça et sur le moment, c'est bien, dans le code de RabbitMQ.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java