Discussion :

[Faiche]

Bonjour,

J'aimerais savoir un truc, et je vais essayer au maximum d'être clair mais c'est pas évident :

Imaginons une classe dont le constructeur prend en argument une String représentant une liste d'entiers.

Si jamais cette String contient autre chose, alors ça devrait sauter.

Je ne peux pas dans le constructeur faire un "return null", du coup je suis obligé de lever une exception.

La solution que j'utilise en général dans ces cas la, c'est une fonction create en static, qui renvoie l'objet ou null :

Code :

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

public static MyObject create(String bla)

Ma question, donc, est : est ce que c'est inutilement compliqué de passer par une fonction create, et si oui, on doit faire comment quand on est malin ?

Merci d'avance.

[le y@m's]

En général, lorsque une méthode (ou un constructeur) reçoit un paramètre inadéquat (un String qui doit avoir un certain format, un int qui ne doit avoir que certaines valeurs spécifiques, etc), il est d'usage de levé une IllegalArgumentException .

Code :

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

1
2
3
4
5
6
public MyObject(String bla) {
    if(...) { // Si le paramètre ne respecte pas le format attendu
        throw new IllegalArgumentException("invalid string");
    }
    ...
}

[adiGuba]

Salut,


Pourquoi ne pas faire les deux ?


a++

[le y@m's]

Salut,


Pourquoi ne pas faire les deux ?


a++

A moins que le fait de passer par une méthode static soit un choix de design (Singleton ou Factory avec constructeur privé), je ne vois pas trop l'intérêt de faire les deux puisque la méthode static aurait le même comportement que le constructeur.

[jhaythem]

Je ne peux pas dans le constructeur faire un "return null", du coup je suis obligé de lever une exception.

pourquoi ca te pose probleme de lever une exception au constructeur?
comme t a dit le yam's, je crois que c est la meilleur solution.

[Faiche]

pourquoi ca te pose probleme de lever une exception au constructeur?
comme t a dit le yam's, je crois que c est la meilleur solution.

En fait, j'essaye au maximum d'éviter les exceptions quand un simple != null suffirait. J'imagine qu'en terme de charge et tout, l'exception est plus lourde.

Mais bon, je me trompe surement.. Si qqun pouvait rentrer dans les détails

Merci

[jhaythem]

tu peux toujours gerer ton expection a ta guise apres.
Mais en question de design, tu es certain d avoir tes objet proprement consctruit que de te balader avec =null et qui sait apres ce qui peut se passer...
Et personellement je trouve pour le maintien du code apres par d autres personnes sera plus facile avec une exception leve au constructeur.

Cheers,

[adiGuba]

je ne vois pas trop l'intérêt de faire les deux puisque la méthode static aurait le même comportement que le constructeur.

Le constructeur (public ou protected) permet l'héritage.
La méthode static permet une "simplification" du fait de l'absence d'exception

J'imagine qu'en terme de charge et tout, l'exception est plus lourde.

Oui et non : j'avais fait des tests il y a quelques temps, et grosso-modo la différence vient de la génération du stacktrace lors de la création de l'exception. Mais ce n'est sensible que sur de grosse quantité d'appel. De plus en fonctionnement normale (sans erreur) il n'y a pas de différence.

Par contre les exceptions comportent bien plus d'information et ne devraient pas être dénigré

Plus d'info : Exception & Performance


Bref la solution de la méthode static peut être très intéressante si tu dois traiter un grand nombre de donnée potentiellement erroné et que tu n'a pas besoin des infos de l'exception. Mais dans ce cas là il est quand même préférable de proposer également un constructeur pour l'évolutivité de ta classe. Cela pourrait donner ceci :

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
class MyObject {
 
	/** Méthode privée de vérification de la chaine en entrée */
	private static boolean isValid(String bla) {
		return true; // ...;
	}
 
	/** Constructeur privée permettent de 'sauter' la vérification */
	private MyObject (String bla, boolean checkEntry) {
		if (checkEntry && MyObject.isValid(bla)==false) {
			throw new IllegalArgumentException("invalid string");
		}
		// Code du constructeur
	}
 
	/** Constructeur public qui impose la vérification */
	public MyObject(String bla) throws IllegalArgumentException {
		this(bla, true); // On se contente d'appeller le constructeur privée
	}
 
	/** Factory static qui évite la génération de l'exception */
	public static MyObject create(String bla) {
		if (MyObject.isValid(bla)) {
			return new MyObject(bla, false); // Appel du constructeur privé
		}
		return null;
	}
}

Mais en question de design, tu es certain d avoir tes objet proprement consctruit que de te balader avec =null et qui sait apres ce qui peut se passer...

Ben si une exception est généré lors de la construction de l'objet le problème est un peu le même...



a++

[le y@m's]

je ne vois pas trop l'intérêt de faire les deux puisque la méthode static aurait le même comportement que le constructeur.

Le constructeur (public ou protected) permet l'héritage.
La méthode static permet une "simplification" du fait de l'absence d'exception

Ok, j'avais mal compris, je croyais que tu parlais de faire une méthode static qui lèverait elle aussi une exception .

[Faiche]

Merci, c'est déjà plus clair