je ne parlais pas seulement de l'overloading de functions, mais aussi d'operator, faire :
$a=new Vector(1, 3, 5);
$b=new Vector(5, 3, 1);
$c=$a+$b;
comme on peut le faire en Cpp... moi ca me manque (d'autant plus que j'ai fait quelques classes lignes pour positionner des points en "live")
"Si ce n'est pas le cas, rien ne dit que les évolutions de l'application ou de l'objet n'amèneront pas ces contraintes."
Si on utilise les propriétés publiques, on se doute bien qu'au final il n'y aura pas d'évolution dans ce domaine. Je m'explique.
Prenons le cas d'une propriété de débug. Pas besoin de get/set pour du débug, on s'en carre le cornichon :)
Même si il y a évolution du projet derrière :
class x {
public $debug = false;
//
}
class y extends x {
//
}
$y = new y;
$y->debug = true;
Bon et voila :)
Dans ce cas la, le "public" fonctionne très bien et tu n'as pas besoin de faire :
$y->setDebug(true); ou $y->ActiveDebug();
C'est une perte de temps :o
Comme dit Coucou, ce qui manque, c'est la redéclaration des méthodes. Rien de plus beau (comme en Java) de faire :
public function __construct($var);
public function __construct($var, $truc);
public function __construct(Object $x, Object $y);
Sans avoir à se faire chier avec func_*() et autre fonction de ce genre.
Le namespace, tu peux y arriver via le statissisme :
class x {
static public function x1();
}
x::x1();
Et tu peux très bien arriver à un résultat de ce genre :
x::x1()->...()->...->...::...()->...();
Techniquement, je crois que ca passe.
Pour en revenir plus, chacun est libre de faire comme il veut.
Pour ma part, c'est simple :
abstract class Item {
public $debug = false;
}
abstract class Factory extends Item {
//
}
abstract class Element extends Item {
//
}
class NewsFactory extends Factory {
//
}
class News extends Element {
//
}
Pas besoin de m'ennuyer avec des méthodes qui servent à rien :)
En fait les get/set ont d'autres raisons d'être systématiques; par exemple, quand on met à jour la valeur d'un attribut, il peut y avoir d'autres choses à faire (test de valeurs limites, autre(s) attribut(s) à modifier, etc.). Si ce n'est pas le cas, rien ne dit que les évolutions de l'application ou de l'objet n'amèneront pas ces contraintes. Si on n'a pas mis les get/set, il faut modifier tout le code qui modifie les attributs publiques...
Enfin, la philosophie objet (en tous les cas tel que je la perçois) dit que l'on doit utiliser un objet comme une boite noire, donc que l'on n'a pas savoir ce qui se passe dedans, donc les attributs en private et des get/Set.
"Une classe se définit ainsi : 1 nom, des données membres (attributs), 1 constructeur et des méthodes."
Pour ca, on est tous d'accord. On peut rajouter quelques trucs, mais la base y est.
"Il appelle donc l'action avalerMedicament() qui va mettre à jour l'état de son foie mais il ne peut pas appliquer directement $corpsHumain->foie = 'truc'"
Pourquoi ? Parce que ta méthode avalerMedicament fait appel à d'autres procédés avant d'arriver à une purification de ton foie. Voila pourquoi ta propriété foie doit être privé/protégé dans ce cas précis.
Maintenant, jouons la autrement.
Notre foie est toujours malade. Mais nous allons ajouter une propriété "auto_soin_foie" qu'on va mettre à vrai.
Hors, pour une raison X ou Y, on se retrouve avec : $corpsHumain->auto_soin_foie = false;
Mais de toute facon, que la réparation du foie soit automatique ou non, on va faire avaleMedicament().
Ici, auto_soin_foie n'a pas besoin d'être privé, car, bien que son comportement influe sur l'instance, il n'est pas nécessaire de faire un controle strict dessus.
Pas la peine de faire :
public function setAutoSoin($var) {
$this->auto_soin_foie = (bool) $var;
}
public function getAutoSoin() {
return $this->auto_soin_foie;
}
La par exemple, le privé/protégé ne sert à rien.
Si tu me dis "nan on ne controle pas ce qui rentre..." bien sur que si, c'est du vrai/faux. Et regarde, si je jète un oeil à ma méthode avaleMedicament(), j'ai ca :
if ( (bool) $this->auto_soin_foie ) {
//
} else {
//
}
J'ai réglé tout mes problèmes.
Pour un traitement de nombres/chaines/objets/flottants etc... tu peux/doit passer par du get/set, surtout à cause du set.
Pour un traitement en booléan, bof bof :)
>> Pourquoi rajouter un setter alors qu'avec l'attribut public, nous pouvons accéder au variable de la session ? Surtout que c'est pas comme si c'était un identifiant de base de donnée ou tout autre variable critique...
Une classe se définit ainsi : 1 nom, des données membres (attributs), 1 constructeur et des méthodes. Quand tu définis une classe, tu modélises un objet. Cet objet a ses propres propriétés (attributs) et ses propres actions (méthodes). En déclarant tes attributs privés, tu forces la visibilité et l'accès à ces derniers par l'objet lui même. Seul l'objet doit pouvoir mettre à jour ses données membres via l'utilisation de setter(). Je prends un exemple métaphorique, peut-être peu approprié mais qui illustre ce principe.
Prends un être humain. Le+ corps humain est composé d'organes (ses attributs) et est capable d'agir (courrir, respirer, marcher, réfléchir). On visualise donc ici une modélisation schématique du corps humain composé d'attributs et de méthodes. Admettons que le corps humain d'une personne tombe malade. Le foie (attribut) est touché par une hépatite C. Comment le guérir ? Solution pour le patient : il doit avaler différents médicaments. Dans ce cas, cela signifie que seul lui même peut se guérir en avalant un médicament. Il appelle donc l'action avalerMedicament() qui va mettre à jour l'état de son foie mais il ne peut pas appliquer directement $corpsHumain->foie = 'truc'
J'essaie de montrer par cet exemple un peu tiré par les cheveux, l'intérêt d'utiliser des setters pour mettre à jour les attributs d'une classe.
Séparer la logique de la présentation sans utiliser de moteur de template avec des pseudos languages et des tonnes de méthodes pour aboutir au même résultat tout en réduisant le temps d'éxecution d'une page.
Avec cette classe il est possible de gérer un système de thème et de mettre en cache.
Je ne vois pas en quoi je "remplace" echo(), si j'aurais voulus remplacer echo(), j'aurais utiliser print() :)
Oui et Non, car dans ce cas on se limiterait à nos simple méthodes et non à celle d'orgine dans PHP, car il faudrait rajouter plusieurs méthodes et ce n'est pas mon but.
je vais suivre ton raisonement : utiliser echo directement, ca marche tres bien, et c'est imbatable en perfs, pourquoi se faire chier avec autre chose ?
utiliser un truc complique avec d'autres balises, ca fait un systeme plus souple, plus propre, plus modifiable, etc...
tu inseres une template comme une variable, c'est ca que je veux dire, t'as rien pour l'inserer comme ca avant, et inserer les variables une seule fois pour toute les templates... du coup, c'est normal que ca marche, meme si t'as rien fait pour...
"La perfection est atteinte, non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il n'y a plus rien à retirer."
Antoine de Saint-Exupéry.
Pourquoi rajouter un setter alors qu'avec l'attribut public, nous pouvons accéder au variable de la session ? Surtout que c'est pas comme si c'était un identifiant de base de donnée ou tout autre variable critique...
Pourquoi rajouter un système de pseudo language, le but est d'utiliser le moins possible de ressources, de codes, de méthodes... Actuellement, l'imbrication est effectivement illimité et je ne vois pas le rapport avec "j'ai pas code la fonctionalite, j'ai pose du scotch, et ca tient, si ca tombe, je poserais une agraphe". D'ailleurs, les requêtes ne doivent pas être executer par la Vue mais par le ModelDAO... j'aime bien séparé les différentes choses...
dire que l'imbrication de template est illimitee avec un systeme comme :
$user_list_render = $tpl->render('user_list.php');
$tpl->setVar('user_list_render', $user_list_render);
c'est tres "j'ai pas code la fonctionalite, j'ai pose du scotch, et ca tient, si ca tombe, je poserais une agraphe"...
enfin on aurait pu penser a un tag genre {template "machin.tpl"} avec des options genre pour un resultat de requette : {template "machin.tpl" requetteNom -All} ou {template "machin.tpl" requetteNom -Limit 1 to 10} voir encore {template "machin.tpl" requetteNom -Once}
et des variables genre {variable ici}
ou une combinaison : {template "machin_{variable}.tpl" requetteNom -Once}
Ce qui me chagrine surtout ce sont les attributs publics qui sont largement déconseillés. Pourquoi ne les mets-tu private ? Tu fais un setter() pour mettre sa valeur à jour. D'ailleurs tu pourrais plutôt définir le template de cette manière :
<?php
$tpl = new Template('monTemplate.tpl');
?>
Sinon je plussoie Coucou747 par rapport aux tags que tu utilises.
- Messages postés
-
2350
- Date d'inscription
- mercredi 13 octobre 2004
- Statut
- Membre
- Dernière intervention
- 18 avril 2015
3- Messages postés
-
2350
- Date d'inscription
- mercredi 13 octobre 2004
- Statut
- Membre
- Dernière intervention
- 18 avril 2015
3D'après ce que j'ai lu, il semblerait que ce soit pour PHP6.
Peut être :)
- Messages postés
-
12303
- Date d'inscription
- mardi 10 février 2004
- Statut
- Modérateur
- Dernière intervention
- 30 juillet 2012
39je ne parlais pas seulement de l'overloading de functions, mais aussi d'operator, faire :
$a=new Vector(1, 3, 5);
$b=new Vector(5, 3, 1);
$c=$a+$b;
comme on peut le faire en Cpp... moi ca me manque (d'autant plus que j'ai fait quelques classes lignes pour positionner des points en "live")