CLASSE SIMPLE EMAIL

Signaler
Messages postés
100
Date d'inscription
mardi 7 novembre 2000
Statut
Membre
Dernière intervention
13 juillet 2009
-
Messages postés
4
Date d'inscription
mercredi 7 mai 2008
Statut
Membre
Dernière intervention
9 mai 2008
-
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.

https://codes-sources.commentcamarche.net/source/46590-classe-simple-email

Messages postés
4
Date d'inscription
mercredi 7 mai 2008
Statut
Membre
Dernière intervention
9 mai 2008

Ok je vois beaucoup mieux ce que tu veux dire maintenant !
Quand je disais "aussi fatigant", ça voulait dire que je trouvais cela équivalent (d'où le "aussi") en terme de quantité de code et pensant que tu parlais des return pour économiser du code je contre-argumentais la dessus, d'autant plus que les return sont plus évidents pour moi donc ce n'est vraiment pas une question de paresse... Maintenant effectivement je comprend mieux ton point de vue sur les exceptions.
Messages postés
12
Date d'inscription
mercredi 15 janvier 2003
Statut
Membre
Dernière intervention
9 mai 2008

Pour ce qui est de mon avis (soulant), j'ai repris ce que tu disais " cependant il me semble que mettre des return est aussi fatigant que de lancer des exceptions".
Dans mon sens saoulant = fatigant.

Sinon, y'a une erreur là:
if($exp = filter_var($exp,FILTER_VALIDATE_EMAIL))
dans le meilleur des cas, c'est ==, mais il vaut mieux tester si tu reçois false:
if(filter_var($exp,FILTER_VALIDATE_EMAIL)===false)

Pour ce qui est des exceptions, c'est simple. Une exception doit rester... une exception et non pas une règle, et puis un utilisateur ne pensera peut être pas au fait que tu ais utilisé des exceptions et soit obligé de faire un try / catch sous peine de voir planter son programme.
Imagine qu'il y ait:
prise de commande
validation de la commande
envoi d'un mail
autre traitement
s'il ne pense pas à faire un try / catch et que par malheur ta classe sorte une exception non traitée, la partie qui suit l'envoi du mail ne sera pas faite.

Maintenant, si tu as envie de bosser de cette manière, dans cette philosophie après tout pourquoi pas :) le tout c'est de choisir et de t'y tenir.
Messages postés
4
Date d'inscription
mercredi 7 mai 2008
Statut
Membre
Dernière intervention
9 mai 2008

Oups désolé, bon j'ai refait l'affectation de la confirmation, et modifié
la méthodes is_email.
(Euh sinon je ne sais pas ce qui te laisse croire que faire une classe me "saoule", c'est
une analyse tout à fait hors contexte à laquelle tu te livres en me prétant ce sentiment.)

D'autre part (je reprecise encore que la POO est trés neuve pour moi) je ne comprends
pas pourquoi faire des return serait plus pratique que faire des exceptions, quand doit
on décider d'utiliser des exceptions et pour quelles raisons ? Quel type de contraintes
apporte un try/catch à l'utilisateur?
Je tiens à préciser que ce sont des vrais et candides questions...
Messages postés
12
Date d'inscription
mercredi 15 janvier 2003
Statut
Membre
Dernière intervention
9 mai 2008

Bah si c'est juste pour faire un exemple, ok.
Ceci dit, pour les exceptions, je trouvais juste lourdingue d'obliger l'utilisateur de ta classe à utiliser un try / catch dans le code principal, c'est tout :)

Ceci dit, tu utilises $confirmation dans ta classe, mais il n'est jamais initialisé, il sert à quoi?
A moins que ce soit le résultat du mail?
return "Your email have been sent";
dans ce cas il faudrait plutôt faire: $this->confirmation="Your email have been sent";

-> Bon, sinon ça sert pas à grand chose de faire le ==TRUE:
if(($this->verifAdMail($this->exp)&&$this->verifAdMail($this->dest)
&&$this->verifCont($this->cont)&&$this->verifSubject($this->subject))==TRUE
soit tu ne mets rien (pas de ==TRUE), soit tu mets ===TRUE pour vérifier qu'en plus c'est un booléen, mais bon, très honnêtement vu que c'est ton code, tu peux t'en dispenser.
D'autre part, comme tu mets des throw exception partout au cas où la vérification échoue on se demande même si ça sert à quelque chose de mettre ça dans un if? Autant faire appel aux méthodes directement vu que ta classe va "planter" en cas de problème.
$this->verifAdMail($this->exp);
$this->verifAdMail($this->dest);
$this->verifCont($this->cont);
$this->verifSubject($this->subject);

-> Ensuite, pour ta vérification d'email:
private function is_email($exp){
if(!empty($exp)){
$exp = filter_var($exp,FILTER_VALIDATE_EMAIL);
Ca peut ne pas être correct. En effet filter_var renverra bien un email dans le cas où $exp est un mail correct, mais il peut également renvoyer un booléen false si le check a échoué! Dans ce cas $exp ne sera pas empty mais $exp sera failse mais ta fonction renverra true...
D'autre part, tu changes la valeur de $exp, ce qui pourrait poser soucis par la suite...

Pour les fonctions non compatibles Windows, tu peux déjà voir si elles sont accessibles par des tests sur l'existence des fonctions.

Comme disait mon prof d'informatique: "un bon programmeur est un fainéant, il fait aussi peu de code possible." mais ça n'est pas à prendre non plus au pied de la lettre. Si déjà faire une classe te saoule (return) imagine plus tard dans un vrai soft... Tu ne vas pas pouvoir caser des exceptions de partout sinon imagine la tronche de ton code.
Afficher les 10 commentaires