Retour d'une Methode

Nicolas ROBERT wrote:

J'ai écrit une classe ServiceHandler, qui gère un liste de Services. Les
objets Services sont des instances d'une classe Service. Ils ont un
identifiant unique qui me permet de les retrouver dans ma liste des
services.

Je veux écrire une méthode qui me renvoie un objet service, à partir de
l'identifiant passé en parametre.

Service ServiceHandler::GetService(int serviceid){
if(!ServiceExiste(serviceid))
return NULL;
else{
//Je retourne mon service
}
}//fin------------------

Mon problème est le suivant: si le service n'existe pas je ne sais pas quoi
renvoyer. Le fait que je renvoie NULL me génère des erreurs de compilation :
"error C2664: cannot convert from 'const int' to 'const class Service' "

Je comprends que le compilateur n'accepte pas le renvoi d'un NULL à la place
d'un objet Service, mais je ne sais pas quoi renvoyer.
Quelqu'un aurait-il une idée ? S'il vous manque des précisions, n'hésitez
pas à me les demander.

Il y a deux possibilités (plus, mais bon, deux grandes familles de
possibilités) :
1 - La classe Service a une sémantique d'objet
Dans ce cas, un service est un objet unique, bien identifié, et
l'erreur serait de passer cet objet par valeur. Ce qu'il faut, c'est un
pointeur (ou l'équivalent) qui désigne cet objet unique.
Si c'est le cas, GetService devrait s'écrire
Service* ServiceHandler::GetService(int serviceid);
et peut très bien renvoyer NULL.

2- La classe Service a une sémantique de valeur
Dans ce cas, effectivement, on peut retourner par valeur le Service.
Mais alors, rien n'interdit de prévoir une "valeur" pour un Service qui
corresponde à aucun service.
Souvent, dans ce cas, cette valeur est aussi une constante statique
de la classe à laquelle on peut comparer l'objet qu'on reçoit:
if (ServiceHandler::GetService(id) != Service::NULL) {
// ... utilisation du service ...
}
et dans la classe Service
classe Service {
// definition
public:
static const Service NULL;
};
Service Service::NULL = Service();

Il y a une troisième possibilité qui est un pattern connu cité par
Barton et Nackman : la classe Faillible
(http://gcc.gnu.org/ml/gcc/2003-11/msg00670.html). Elle permet
d'encapsuler une valeur, mais de permettre que celle-ci ne soit pas
valide. Mais c'est plutôt lorsqu'on veut se greffer sur des classes déjà
existantes.

--
Arnaud
(Supprimez les geneurs pour me répondre)

Arnaud Meurgues <arnaud@meurgues.non.fr.invalid> writes:

1 - La classe Service a une sémantique d'objet
Service* ServiceHandler::GetService(int serviceid);

2- La classe Service a une sémantique de valeur
static const Service NULL;
Il y a une troisième possibilité qui est un pattern connu cité par Barton
et Nackman : la classe Faillible

4/ Une exception.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Le Fri, 24 Sep 2004 15:47:10 +0200, Nicolas ROBERT a écrit :

Bonjour,

Je veux écrire une méthode qui me renvoie un objet service, à partir de
l'identifiant passé en parametre.

Mon problème est le suivant: si le service n'existe pas je ne sais pas quoi
renvoyer.

Je comprends que le compilateur n'accepte pas le renvoi d'un NULL à la place
d'un objet Service, mais je ne sais pas quoi renvoyer.

ne renvoie rien, lance une exception en cas de problème.

Jean-Marc Bourguet wrote:

4/ Une exception.

Oups, oui. Je n'ai pas le réflexe des exceptions pour des comportements
trop "normaux". J'ai tendance à les réserver pour des cas qui ne
devraient pas arriver.
Mais effectivement, c'est peut-être un cas qui ne doit pas arriver.

--
Arnaud
(Supprimez les geneurs pour me répondre)

Arnaud Meurgues <arnaud@meurgues.non.fr.invalid> writes:

Jean-Marc Bourguet wrote:

4/ Une exception.

Oups, oui. Je n'ai pas le réflexe des exceptions pour des comportements
trop "normaux". J'ai tendance à les réserver pour des cas qui ne devraient
pas arriver.
Mais effectivement, c'est peut-être un cas qui ne doit pas arriver.

Si ca ne doit pas arriver, c'est assert :-)

Ce qui m'interesse quand je decide si j'utilise des exceptions ou pas
c'est si le cas doit etre generalement traite dans l'appelant immediat
(auquel cas l'exception est generalement inadaptee) ou bien plus haut
dans la pile d'appel.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Arnaud Meurgues <arnaud@meurgues.non.fr.invalid> writes:

|> Il y a deux possibilités (plus, mais bon, deux grandes familles de
|> possibilités) :
|> 1 - La classe Service a une sémantique d'objet
|> Dans ce cas, un service est un objet unique, bien identifié, et
|> l'erreur serait de passer cet objet par valeur. Ce qu'il faut, c'est
|> un pointeur (ou l'équivalent) qui désigne cet objet unique.
|> Si c'est le cas, GetService devrait s'écrire
|> Service* ServiceHandler::GetService(int serviceid);
|> et peut très bien renvoyer NULL.

|> 2- La classe Service a une sémantique de valeur
|> Dans ce cas, effectivement, on peut retourner par valeur le
|> Service. Mais alors, rien n'interdit de prévoir une "valeur" pour un
|> Service qui corresponde à aucun service.
|> Souvent, dans ce cas, cette valeur est aussi une constante
|> statique de la classe à laquelle on peut comparer l'objet qu'on reçoit:
|> if (ServiceHandler::GetService(id) != Service::NULL) {
|> // ... utilisation du service ...
|> }
|> et dans la classe Service
|> classe Service {
|> // definition
|> public:
|> static const Service NULL;
|> };
|> Service Service::NULL = Service();

|> Il y a une troisième possibilité qui est un pattern connu cité par
|> Barton et Nackman : la classe Faillible
|> (http://gcc.gnu.org/ml/gcc/2003-11/msg00670.html). Elle permet
|> d'encapsuler une valeur, mais de permettre que celle-ci ne soit pas
|> valide. Mais c'est plutôt lorsqu'on veut se greffer sur des classes
|> déjà existantes.

Pas forcément. Mais cela implique que la classe a un constructeur par
défaut.

Il y a aussi la possibilité de créer un état invalide à Service, est
renvoyer une instance avec l'état invalide.

Toutefois... D'après les noms, je verrais bien du polymorphisme là
dedans. Ce qui veut dire soit un pointeur, soit, si on tient vraiment à
la sémantique de valeur, une lettre/envéloppe (qui lui pourrait être
facilement étendu à supporter un isValid()).

--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

Jean-Marc Bourguet <jm@bourguet.org> writes:

|> Arnaud Meurgues <arnaud@meurgues.non.fr.invalid> writes:

|> > Jean-Marc Bourguet wrote:

|> > > 4/ Une exception.

|> > Oups, oui. Je n'ai pas le réflexe des exceptions pour des
|> > comportements trop "normaux". J'ai tendance à les réserver pour
|> > des cas qui ne devraient pas arriver. Mais effectivement, c'est
|> > peut-être un cas qui ne doit pas arriver.

|> Si ca ne doit pas arriver, c'est assert :-)

|> Ce qui m'interesse quand je decide si j'utilise des exceptions ou
|> pas c'est si le cas doit etre generalement traite dans l'appelant
|> immediat (auquel cas l'exception est generalement inadaptee) ou bien
|> plus haut dans la pile d'appel.

Ce qui vaut pour le cas général. Il m'arrive aussi d'utiliser des
exceptions même quand je m'attends à ce que l'erreur soit traitée
immédiatement par l'appelant. Dans un constructeur, par exemple:-).

Et en passant, on a oublié encore une possibilité -- il peut passer une
des valeurs de retour par paramètre de sortie, c-à-d une référence
non-const. Un peu du genre :

bool getService( int code, Service& dest ) ;

--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

Merci pour votre réactivité.


Cdt
nicolas ROBERT