Discussion :

[Antonio81]

Désolé de poser une question qui pourrait être stupide mais je n'arrive pas à comprendre ce concept :

quand on déclare un objet de sa propre classe, on fait :
MaClasse test = new MaClasse();

mais quand on déclare un objet venant du framework alors on fait ceci :
Sequencer testSeq = MidiSystem.getSequencer();

pourquoi n'emploie-t-on pas le mot-clé "new" ? testSeq n'est-il pas crée dans le memory heap ?

[fr1man]

Le new est appelé en interne de la classe MidiSystem.
On utilise ce genre de procédé dans les patterns factory ou singleton.
Dans le cas du singleton, c'est pour éviter d'avoir plusieurs instances de la même classe.

[Antonio81]

merci !

Si je regarde le tutoriel sur les design pattern dans la section factory, on a ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
public class CanvasFactory 
{
       public Point getPoint( int x, int y ) 
       {
             return new PointImpl( x, y );
        }
}

Si on map cela avec mon exemple du MidiSystem, peut-on dire que :
CanvasFactory correspond à MidiSystem
getPoint correspond à getSequencer
?

[Pill_S]

en gros oui, mais c'est un peu plus compliqué.

dans le cas de factory, le but est de séparer la création des objets du reste du code. Pourquoi? parce que créer un objet avec "new" c'est super rigide, impossible de changer le type de l'objet: "new" impose que l'on connaisse la classe qui sera utilisée.

En utilisant factory, on délègue cette tâche à un autre agent (la "factory"), et comme cela c'est beaucoup plus facile de modifier la manière dont sont créés les objets: tu veux changer le mode de fonctionnement, bam tu créé une nouvelle factory, tu adaptes un peu le code qui permet de récupérer la factory, et c'est bon partout dans ton programme.

Pour singleton, c'est plus simple: il y a plus ou moins la même notion que factory (déléguer l'instanciation à un agent), mais dans ce cas-là, on ne recherche pas la simplicité de changement, mais la garantie de n'avoir qu'une seule instance d'une classe partout dans le programme.

On reconnait très facilement le pattern factory dans un programme java: le nom de la classe se termine presque toujours par "factory" (mais bon ça reste assez peu fréquent d'utiliser factory, c'est un pattern relativement lourd)

[Antonio81]

Merci pour vos explications sur les design patterns.

pour revenir au framework, pourquoi avoir choisi cette méthode :
Sequencer testSeq = MidiSystem.getSequencer();

plutôt que celle-ci :
Sequencer testSeq = new Sequencer();
le système me dit "cannot instanciate the type Sequencer" => Pourquoi ?

Pourtant, dans ce cas, on est sûr de la classe que l'on veut créer.

[OButterlin]

Et bien, comme expliqué précédemment, c'est pour n'avoir qu'une seule instance de l'objet en mémoire...

[adiGuba]

OButterlin > Non ce n'est pas un singleton : chaque appel renvoi bien un nouvel objet...

Pourtant, dans ce cas, on est sûr de la classe que l'on veut créer.

Justement tu ne sais pas quelle classe tu vas utiliser Sequencer est une interface et ne peut donc pas être instancié !

La méthode getSequencer() se charge de trouver la bonne classe selon ta configuration : chez moi elle renvoi un objet non-standard de type com.sun.media.sound.RealTimeSequencer. Il est donc probable que cette méthode renvoie un autre objet sur une autre JVM (et en particulier sur une JVM autre que Sun)

Il est possible que la classe renvoyée varie selon plusieurs critères (mais je connais trop peu cette API pour citer ces critères).

a++

[Invité]

en gros oui, mais c'est un peu plus compliqué.

dans le cas de factory, le but est de séparer la création des objets du reste du code. Pourquoi? parce que créer un objet avec "new" c'est super rigide, impossible de changer le type de l'objet: "new" impose que l'on connaisse la classe qui sera utilisée.

Pill_S, pourrais-tu s'il te plaît donner un exemple d'un cas où on ne connaîtrait pas la classe au moment de l'instanciation ?

Est-ce là le seul avantage de la factory ?

[Pill_S]

Bah typiquement, lorsque ton programme gère des plugins: tu ne sais pas à l'avance lesquels sont installés, donc tu ne peux pas les créer "statiquement".

Et oui, le gros avantage de factory c'est vraiment d'éviter l'utilisation du mot clé "new", car le gros défaut de new, c'est qu'il faut connaitre précisément la classe ET le constructeur à invoquer lorsqu'on l'utilise (c'est vraiment très très rigide).

Factory peut aussi être pratique pour garantir l'initialisation correcte d'objets, ou de graphes d'objets (structures d'objets se référençant les uns les autres), en permettant d'exécuter du code avant même l'appel des constructeurs (y'a des situations où les constructeurs ne devraient pas être invoqués sans que l'on soit certain qu'ils ne lèveront pas d'exception, factory permet de s'assurer de cela).

Y'aurait encore des miliers de choses à dire sur factory, mais le mieux c'est de les découvrir soi-même