Discussion :

[Didier 69]

Bonjour,

la solution pour écrire un singleton est bien connue par le pattern e même nom.
Par contre si à partir d'une classe Singleton, je veux écrire une sous classe Singleton, y a t'il un pattern ou équivalent pour bien écrire tout ça ?

Merci !

[Baptiste Wicht]

Bonjour,

la solution pour écrire un singleton est bien connue par le pattern e même nom.
Par contre si à partir d'une classe Singleton, je veux écrire une sous classe Singleton, y a t'il un pattern ou équivalent pour bien écrire tout ça ?

Merci !

Je ne sais pas s'il y a un pattern, mais c'est vrai que c'est pas pratique...

Mais je pense qu'une classe Singleton ne devrait pas être redéfinie. Tu devrais faire une classe mère sans singleton et des classes filles qui auront quand à elles un singleton.

Rien ne t'empêche de définir une nouvelle méthode getInstanceFille dans la classe fille qui iraient quand à elles récupérer une instance de la classe Fille. Mais je ne sais pas ce que ca vaut d'un niveau conceptuel

[pseudocode]

Bonjour,

la solution pour écrire un singleton est bien connue par le pattern e même nom.
Par contre si à partir d'une classe Singleton, je veux écrire une sous classe Singleton, y a t'il un pattern ou équivalent pour bien écrire tout ça ?

Merci !

Non. Le singleton est traditionnelement fait en marquant le constructeur comme "privé". Donc pour l'heritage, c'est mort.

[adiGuba]

Salut,

Non. Le singleton est traditionnelement fait en marquant le constructeur comme "privé". Donc pour l'heritage, c'est mort.

Pas forcément, il peut y avoir des cas où cela peut être intéressant d'avoir plus implémentation du Singleton, par exemple pour gérer plusieurs versions du JRE ou différents système d'exploitation...

Dans ce cas on utilisera la visibilité de package (pas de mot-clef de visibilité) et on déterminera la sous-classe à utilisé lors de la création du singleton, par exemple :

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
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
public abstract class Singleton {
	
	/** Instance unique du Singleton */
	private static final Singleton INSTANCE = createSingleton();
	
	/**
	 * Constructeur par défaut.
	 * La visibilité 'package-only' permet d'éviter d'hériter de la classe
	 * (sauf si la classe appartient au même package)
	 */
	Singleton() {
	}
	
	/**
	 * Accesseur unique.
	 */
	public static Singleton getInstance() {
		return INSTANCE;
	}
	
	/**
	 * Création du Singleton, selon la version du JRE
	 */
	private static Singleton createSingleton() {
		String javaVersion = System.getProperty("java.version");
		if ("1.6.0".equals(javaVersion)) {
			return new Singleton6();
		} else if ("1.5.0".equals(javaVersion)) {
			return new Singleton5();
		}
		return new SingletonOld();
	}
	
	/**
	 * Méthode qui dépend de la version de Java
	 */
	public abstract void maMethodeQuiDependDuLaVersionDeJava();
}

Chacune des sous-classe doit faire partie du même package (afin de pouvoir hériter de Singleton) et proposeront chacune une implémentation spécifique :

Code :

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

1
2
3
4
5
6
class SingletonOld extends Singleton {
	@Override
	public void maMethodeQuiDependDuLaVersionDeJava() {
		// Code Java 1.4 ou inférieur
	}
}

Code :

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

1
2
3
4
5
6
class Singleton5 extends Singleton {
	@Override
	public void maMethodeQuiDependDuLaVersionDeJava() {
		// Code Java 5
	}
}

Code :

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

1
2
3
4
5
6
class Singleton6 extends Singleton {
	@Override
	public void maMethodeQuiDependDuLaVersionDeJava() {
		// Code Java 6
	}
}

a++

[pseudocode]

Ah oui, c'est vrai. Toutes mes confuses.

J'avais pas pensé a entendre une classe dans le meme package. J'utilise la visibilité packaque seulement pour isoler les composants les uns des autres.