Discussion :

[valkeke]

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 !

[thelvin]

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.

[professeur shadoko]

ça me fait penser à technique utilisée pour le "pattern" décorateur ... mais est-ce le cas ici?

[Yonito]

Le pattern Singleton utilise egalement ce principe.

[OButterlin]

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)

[valkeke]

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..

[professeur shadoko]

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!

[thelvin]

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"

[OButterlin]

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.

[Yonito]

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.

[valkeke]

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..

[thelvin]

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.

[valkeke]

dsl thelvin, mais j'ai du mal à te suivre, tu pourrais expliciter un peu plus ton propos, merci

[thelvin]

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.

[valkeke]

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.

[thelvin]

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.