Bien, mais pour quelle raison ? Si c'est plus pratique de retourner plusieurs valeurs, pourquoi s'en passer ?
Comme je le disais, je préfère réserver des exceptions pour des erreurs de déroulement de l'application : fichier ou base de données inaccessibles/inexistantes alors que leur présence est requise, permission de fichier insuffisante (dans le cadre d'un jeu web, si tu codes un OS ce n'est pas une exception).
Par exemple, dans eve quand tu te fais péter ton ship tu spammes comme un demeuré le bouton de warp. dans wow, quand ta super technique qui va te sauver la peau a encore 3 secondes de CD tu la spamme comme un boeuf. Bon ben ça c'est un déroulement normal.
en tapant sur ta techinque, ça déclenche un bout de code qui peut retourner plusieurs valeurs:
(lancée) ; (cooldown, 3 secondes) ; (silenced) ; (no target) ; (bad target, friend) ; (trop loin, 25 mètres)
Le paradigme objet voudrait qu'on renvoie des instances de retour d'action, et que la classe retour d'action de type cooldown propose un méthode pour connaitre le temps restant.
Si tu veux faire de l'objet pur et dur alors vos propositions d'un objet de retour est la plus logique.
Sans pattern matching en PHP c'est pas facile de faire autrement que sonder un tableau si on ne souhaite pas utiliser un objet. Mais ce n'est pas un problème.
Si tu as un constructeur qui t'assure que le membre temps restant de ton objet cooldown soit bien enregistré, afin que ta méthode get_cd renvoie bien une donnée juste, il n'y a pas de raison que quand tu vas mettre ce temps dans la case 2 de ton tableau elle n'y soit plus quand tu le récupère de l'autre côté de ta fonction.
L'objet n'apporte pas ici de robustesse supplémentaire. Mais bien sur il ne faut pas faire n'importe quoi avec son tableau ensuite. On respectera la structure comme elle a été définie. Si cette structure devient au fil des améliorations un truc à 50 cases avec des sous-sous-objets, bon ben là oui on se fait un système d'héritage de classes, c'est clair. (Enfin, en php ou autre langage objet)
Comme je le disais, je préfère réserver des exceptions pour des erreurs de déroulement de l'application : fichier ou base de données inaccessibles/inexistantes alors que leur présence est requise, permission de fichier insuffisante (dans le cadre d'un jeu web, si tu codes un OS ce n'est pas une exception).
Par exemple, dans eve quand tu te fais péter ton ship tu spammes comme un demeuré le bouton de warp. dans wow, quand ta super technique qui va te sauver la peau a encore 3 secondes de CD tu la spamme comme un boeuf. Bon ben ça c'est un déroulement normal.
en tapant sur ta techinque, ça déclenche un bout de code qui peut retourner plusieurs valeurs:
(lancée) ; (cooldown, 3 secondes) ; (silenced) ; (no target) ; (bad target, friend) ; (trop loin, 25 mètres)
Le paradigme objet voudrait qu'on renvoie des instances de retour d'action, et que la classe retour d'action de type cooldown propose un méthode pour connaitre le temps restant.
Si tu veux faire de l'objet pur et dur alors vos propositions d'un objet de retour est la plus logique.
Sans pattern matching en PHP c'est pas facile de faire autrement que sonder un tableau si on ne souhaite pas utiliser un objet. Mais ce n'est pas un problème.
Si tu as un constructeur qui t'assure que le membre temps restant de ton objet cooldown soit bien enregistré, afin que ta méthode get_cd renvoie bien une donnée juste, il n'y a pas de raison que quand tu vas mettre ce temps dans la case 2 de ton tableau elle n'y soit plus quand tu le récupère de l'autre côté de ta fonction.
L'objet n'apporte pas ici de robustesse supplémentaire. Mais bien sur il ne faut pas faire n'importe quoi avec son tableau ensuite. On respectera la structure comme elle a été définie. Si cette structure devient au fil des améliorations un truc à 50 cases avec des sous-sous-objets, bon ben là oui on se fait un système d'héritage de classes, c'est clair. (Enfin, en php ou autre langage objet)