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

[Antonio81]

Ok merci,

concernant la déclaration suivante :

Sequencer testSeq = MidiSystem.getSequencer();

pour moi cela signifie qu'un objet MidiSystem existe déjà dans le programme.
Or je ne voie nulle part une déclaration du genre :

ClasseInconnue MidiSystem = new ClasseInconnue();

Est-ce que cela est caché dans import javax.sound.midi.* ?


Edit : merci pour ta réponse adiGuba mais pour la classe Sequencer, j'ai pris cela au hasard, je cherche juste à comprendre le concept car des appels de ce genre, j'en vois plein sur le net dès qu'on doit créer un objet du framework

[CheryBen]

Sequencer testSeq = MidiSystem.getSequencer();

Ici, MidiSystem n'est pas un nom de variable, mais bien le nom d'une classe. La méthode getSequencer est static, on peut donc l'appeler directement sans avoir instancié de MidiSystem.

FAQ : Que signifie le mot-clé static ?

[Antonio81]

Merci à vous,

c'est maintenant beaucoup plus clair dans mon esprit !

[OButterlin]

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

Désolé, je n'avais pas réalisé qu'il s'agissait d'une classe "officielle"

[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

[Invité]

Un truc que je ne pige pas dans ce tuto .

Ok dans le Main on ne spécifie pas qu'on veut instancier la classe A ou la classe B mais c'est dans la fabrique A et B qu'on le précise. Désolé de faire le boulet mais je pige pas l'intérêt. On doit quand même connaître le type de la classe avant de l'instancier là... non ?

[fr1man]

L'intérêt est que le new est centralisé dans une classe.
Si tu veux changer d'implémentation, il te suffit de faire les modifs seulement à cet endroit, et non pas à tous les new de ton projet.

[Invité]

Okay super

Merci

[Invité]

Bon le temps que j'y suis et comme c'est une question assez triviale, il y a une question que je me pose par rapport à cet exemple. Je sais c'est la base du polymorphisme mais je ne comprend pas trop son intérêt.

Quand on a :

Code :

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

1
2
Fabrique lFactoryA = new FabriqueA();
        Fabrique lFactoryB = new FabriqueB();

Pourquoi ne pas mettre :

Code :

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

1
2
FabriqueA lFactoryA = new FabriqueA();
        FabriqueB lFactoryB = new FabriqueB();

Est-ce par exemple pour pouvoir faire éventuellement un

Code :

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

Fabrique lFactoryA = new FabriqueB();

par la suite ?

Autre question qui peut paraître bête mais si je fais un

Code :

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

Fabrique lFactoryA = new FabriqueA();

comment mon objet IFactoryA a-t-il accès aux méthodes définies dans la classe FabriqueA sachant qu'il a une référence de type Fabrique (qui ne connait pas les méthodes propres à sa classe fille, la classe FabriqueA) ?

Je sais c'est des notions vraiment très basiques mais j'ai un peu de mal là ...

[adiGuba]

Bon le temps que j'y suis et comme c'est une question assez triviale, il y a une question que je me pose par rapport à cet exemple. Je sais c'est la base du polymorphisme mais je ne comprend pas trop son intérêt.

C'est le principe de l'abstraction des types.
Dans l'exemple Fabrique est une classe abstraite qui définit en autre une méthode creerClasse() permettant de créer un objet de type AbstractClasse. Cette classe étant également abstraite...

En fait l'intérêt est de coder quelque chose sans se soucier du type réel : il peut y avoir plusieurs implémentations différentes mais on continuera toujours à l'utiliser de la même manière.

Si demain tu dois modifier ta fabrique et que tu as utilisé en dur FabriqueB, alors tu devras changer cela partout... alors que ce n'est pas le cas avec Fabrique.


L'exemple le plus parlant est peut-être celui des collections. Prenons par exemple le code suivant :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
public class MaClasse {
 
	private final LinkedList<String> list;
 
	public MaClasse(LinkedList<String> list) {
		this.list = list;
	}
 
	public LinkedList<String> getList() {
		return list;
	}
 
}

Une simple classe qui utilise une LinkedList, que l'on retrouve dans le constructeur et en retour d'une méthode.

Le problème de cette classe vient du fait que tu forces l'utilisation d'une LinkedList, alors qu'il existe plusieurs types de liste et qu'on pourrait avoir besoin d'un autre type.

Si demain tu dois utiliser une ArrayList, tu devras soit dupliquer la classe, soit la modifier et la rendre incompatible avec le code existant.

Maintenant, si dès le début tu avais fait abstraction du type réel et utiliser un type abstrait, tu n'aurais pas ce problème :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
public class MaClasse {
 
	private final List<String> list;
 
	public MaClasse(List<String> list) {
		this.list = list;
	}
 
	public List<String> getList() {
		return list;
	}
 
}

On utilise désormais List, qui est une interface décrivant les méthodes de base d'une liste. Alors bien sûr il y a certaines méthodes spécifiques à ArrayList ou LinkedList qui ne sont pas défini dans List, mais leurs utilité est moindre car très spécifique (et dans ce cas là on ne pourrait pas faire de code générique).



Bref en utilisant un type abstrait, on conserve la possibilité de changer facilement le type réel, et on améliore donc la généricité du code.

Dans l'exemple on utilise une Fabrique pour créer des AbstractClasse, et à la rigueur on n'a pas besoin de savoir s'il s'agit d'une FabriqueA qui créera des ClasseA ou une FabriqueB qui créera des ClasseB...

Autre question qui peut paraître bête mais si je fais un

Code :

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

Fabrique lFactoryA = new FabriqueA();

comment mon objet IFactoryA a-t-il accès aux méthodes définies dans la classe FabriqueA sachant qu'il a une référence de type Fabrique (qui ne connait pas les méthodes propres à sa classe fille, la classe FabriqueA) ?

Tu as accès à toutes les méthodes définies dans le type de la référence. Donc ici tu peux appeler les méthodes définies dans la classe abstraite Fabrique (et les méthodes des classes parentes dont Object).

Par contre en Java par défaut toutes les méthodes sont "virtuelles". C'est à dire qu'à l'exécution la JVM va vérifier le type réel de l'objet, et appeler la méthode correspondante. Ainsi lorsque tu fais ceci :

Code :

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

1
2
3
Fabrique lFactory = new ????();
 
AbstractClasse c = lFactory.creerClasse();

On appelera la méthode creerClasse() sur un type Fabrique, mais à l'exécution cela dépendra du type réel indique dans les "????"...



a++

[Invité]

EXCELLENT ! Mille mercis !

Ça me débloque sur pas mal de truc, là j'ai bien pigé

Sacrée JVM