Je me pose une question philosophique à propos des ressources de connexion
(renvoyées par la fonction mysql_connect() par exemple) :
Afin de programmer "proprement", dois-je passer systématiquement en argument
à mes créateurs de classes une ressource de connexion ?
Exemple :
$bdd=mysql_connect();
$truc=new truc($bdd);
Ou bien dois-je utiliser la possibilité de la fonction mysql_query() qui est
la suivante : "Si link_identifier n'est pas précisé, la dernière connexion
est utilisée" ?
Exemple :
mysql_connect();
$truc=new truc();
Question subsidiaire : Si la réponse à la première question est "oui",
comment organiser au mieux mon passage d'argument ?
Je m'explique : je serais tenté de mettre l'argument $bdd en dernier dans la
liste et en argument facultatif, au cas où je dérive ma classe "truc" et que
je ne veuille plus utiliser de base de données pour stocker les propriétés
de cet objet.
Exemple :
function truc($x, $y, $bdd=NULL)
Mais, dans ce cas, je ne peux pas utiliser le passage d'argument par
référence, qui me semble plus efficace pour transmettre ce type de donnée
(ressource). Mais peut-être me trompe-je...
Exemple :
function truc(&$bdd, $x, $y)
Merci de me donner votre avis,
--
Frédéric Rouchouze
mailto:fredchou@nospam.free.fr
Afin de programmer "proprement", dois-je passer systématiquement en argument à mes créateurs de classes une ressource de connexion ? Ou bien dois-je utiliser la possibilité de la fonction mysql_query() qui est la suivante : "Si link_identifier n'est pas précisé, la dernière connexion est utilisée" ?
Je te dirais que c'est fonction de ton utilisation: si tu n'utilise qu'une base, il n'y a aucun intérêt à t'inquiéter de la ressource de connexion vu que tu utiliseras toujours la même.
Si par contre tu dois utiliser des bases distinctes, dans ce cas il te faut t'en inquiéter. Et dans ce cas, pourquoi ne pas utiliser tes connexions en variable globales si tu en as besoin fréquemment?
-- Découvrez Original War: http://www.original-war.org Humour: http://www.chatfou.com Tchattez en liberté: http://www.crazy-irc.net
Frederic Rouchouze wrote:
Afin de programmer "proprement", dois-je passer systématiquement en argument
à mes créateurs de classes une ressource de connexion ?
Ou bien dois-je utiliser la possibilité de la fonction mysql_query() qui est
la suivante : "Si link_identifier n'est pas précisé, la dernière connexion
est utilisée" ?
Je te dirais que c'est fonction de ton utilisation: si tu n'utilise
qu'une base, il n'y a aucun intérêt à t'inquiéter de la ressource de
connexion vu que tu utiliseras toujours la même.
Si par contre tu dois utiliser des bases distinctes, dans ce cas il te
faut t'en inquiéter. Et dans ce cas, pourquoi ne pas utiliser tes
connexions en variable globales si tu en as besoin fréquemment?
--
Découvrez Original War: http://www.original-war.org
Humour: http://www.chatfou.com
Tchattez en liberté: http://www.crazy-irc.net
Afin de programmer "proprement", dois-je passer systématiquement en argument à mes créateurs de classes une ressource de connexion ? Ou bien dois-je utiliser la possibilité de la fonction mysql_query() qui est la suivante : "Si link_identifier n'est pas précisé, la dernière connexion est utilisée" ?
Je te dirais que c'est fonction de ton utilisation: si tu n'utilise qu'une base, il n'y a aucun intérêt à t'inquiéter de la ressource de connexion vu que tu utiliseras toujours la même.
Si par contre tu dois utiliser des bases distinctes, dans ce cas il te faut t'en inquiéter. Et dans ce cas, pourquoi ne pas utiliser tes connexions en variable globales si tu en as besoin fréquemment?
-- Découvrez Original War: http://www.original-war.org Humour: http://www.chatfou.com Tchattez en liberté: http://www.crazy-irc.net
Marc
Merci de me donner votre avis,
* il s'agit ici d'un probleme de conception objet. * l'identifiant d'une BD est une ressource (php), a ce titre elle peut tres bien etre passée par valeur puisqu'il s'agit juste d'un nombre (id). * si tu veux creer un systeme de classes, il est tout de meme un peu ennuyeux de se limiter à une seule base de données, meme si les cas d'utilisation de plusieurs bases sont assez rares.
maintenant voici comment cela peut se concevoir :
class Db { var $db; # l'identifiant de connection
function Db(... les params){ $this->db = $this->db_connect(); }
function db_connect(){ # methode virtuelle }
function query($sql){ # fonction virtuelle } }
class DbMysql extends Db {
function db_connect(...){ return mysql_connect(...); }
function query($sql){ return mysql_query($this->db, $sql); } }
utilisation
$db = new DbMysql(...); $res = $db->query('SELECT * FROM ma_table');
Conclusion : on voit ici que les arguments internes de gestion de la base sont encapsulés dans la classe. Il n'est meme point besoin de s'en préoccuper. L'utiliser de la classe ne sait meme pas que ca existe.
L'avantage de cette conception "tres simple", facile a maintenir est de masquer les vilaines choses et d'offrir un minimum d'encapsulation. C'est juste de l'encapsulation. Je ne crois pas que cela donne de la portabilité sauf a changer la classe d'instentiation et a redefinir des sous-classes spécialisées fonction du type et de la version de la base de données.
Merci de me donner votre avis,
* il s'agit ici d'un probleme de conception objet.
* l'identifiant d'une BD est une ressource (php), a ce titre elle
peut tres bien etre passée par valeur puisqu'il s'agit juste d'un
nombre (id).
* si tu veux creer un systeme de classes, il est tout de meme
un peu ennuyeux de se limiter à une seule base de données, meme
si les cas d'utilisation de plusieurs bases sont assez rares.
maintenant voici comment cela peut se concevoir :
class Db {
var $db; # l'identifiant de connection
function Db(... les params){
$this->db = $this->db_connect();
}
function db_connect(){
# methode virtuelle
}
function query($sql){
# fonction virtuelle
}
}
class DbMysql extends Db {
function db_connect(...){
return mysql_connect(...);
}
function query($sql){
return mysql_query($this->db, $sql);
}
}
utilisation
$db = new DbMysql(...);
$res = $db->query('SELECT * FROM ma_table');
Conclusion : on voit ici que les arguments internes de gestion de la
base sont encapsulés dans la classe. Il n'est meme point besoin de s'en
préoccuper. L'utiliser de la classe ne sait meme pas que ca existe.
L'avantage de cette conception "tres simple", facile a maintenir
est de masquer les vilaines choses et d'offrir un minimum
d'encapsulation. C'est juste de l'encapsulation. Je ne crois pas
que cela donne de la portabilité sauf a changer la classe
d'instentiation et a redefinir des sous-classes spécialisées
fonction du type et de la version de la base de données.
* il s'agit ici d'un probleme de conception objet. * l'identifiant d'une BD est une ressource (php), a ce titre elle peut tres bien etre passée par valeur puisqu'il s'agit juste d'un nombre (id). * si tu veux creer un systeme de classes, il est tout de meme un peu ennuyeux de se limiter à une seule base de données, meme si les cas d'utilisation de plusieurs bases sont assez rares.
maintenant voici comment cela peut se concevoir :
class Db { var $db; # l'identifiant de connection
function Db(... les params){ $this->db = $this->db_connect(); }
function db_connect(){ # methode virtuelle }
function query($sql){ # fonction virtuelle } }
class DbMysql extends Db {
function db_connect(...){ return mysql_connect(...); }
function query($sql){ return mysql_query($this->db, $sql); } }
utilisation
$db = new DbMysql(...); $res = $db->query('SELECT * FROM ma_table');
Conclusion : on voit ici que les arguments internes de gestion de la base sont encapsulés dans la classe. Il n'est meme point besoin de s'en préoccuper. L'utiliser de la classe ne sait meme pas que ca existe.
L'avantage de cette conception "tres simple", facile a maintenir est de masquer les vilaines choses et d'offrir un minimum d'encapsulation. C'est juste de l'encapsulation. Je ne crois pas que cela donne de la portabilité sauf a changer la classe d'instentiation et a redefinir des sous-classes spécialisées fonction du type et de la version de la base de données.
bruno modulix
CrazyCat wrote:
Frederic Rouchouze wrote:
(snip)
Ou bien dois-je utiliser la possibilité de la fonction mysql_query() qui est la suivante : "Si link_identifier n'est pas précisé, la dernière connexion est utilisée" ?
Je te dirais que c'est fonction de ton utilisation: si tu n'utilise qu'une base, il n'y a aucun intérêt à t'inquiéter de la ressource de connexion vu que tu utiliseras toujours la même.
Je dirais que c'est fonction de l'utilisation qui va être faite de ce code. Si c'est du jetable, cf réponse ci-dessus. Si tu a un quelconque espoir de réutilisation, fait tout de suite propre. Ca ne coûte pas vraiment plus cher.
Si par contre tu dois utiliser des bases distinctes, dans ce cas il te faut t'en inquiéter. Et dans ce cas, pourquoi ne pas utiliser tes connexions en variable globales si tu en as besoin fréquemment?
Pour éviter que l'implémentation des classes concernées ne dépende de variables globales ?
Honnêtement, je ne vois pas vraiment l'intérêt de faire de l'OO si c'est pour mettre des globales. Bon, on peut aussi discuter de l'intérêt de l'OO en PHP, voire de l'intérêt de l'OO tout court, mais c'est un autre troll^Mdébat
-- bruno desthuilliers ruby -e "print ''.split('@').collect{|p| p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"
CrazyCat wrote:
Frederic Rouchouze wrote:
(snip)
Ou bien dois-je utiliser la possibilité de la fonction mysql_query()
qui est la suivante : "Si link_identifier n'est pas précisé, la
dernière connexion est utilisée" ?
Je te dirais que c'est fonction de ton utilisation: si tu n'utilise
qu'une base, il n'y a aucun intérêt à t'inquiéter de la ressource de
connexion vu que tu utiliseras toujours la même.
Je dirais que c'est fonction de l'utilisation qui va être faite de ce
code. Si c'est du jetable, cf réponse ci-dessus. Si tu a un quelconque
espoir de réutilisation, fait tout de suite propre. Ca ne coûte pas
vraiment plus cher.
Si par contre tu dois utiliser des bases distinctes, dans ce cas il te
faut t'en inquiéter. Et dans ce cas, pourquoi ne pas utiliser tes
connexions en variable globales si tu en as besoin fréquemment?
Pour éviter que l'implémentation des classes concernées ne dépende de
variables globales ?
Honnêtement, je ne vois pas vraiment l'intérêt de faire de l'OO si c'est
pour mettre des globales. Bon, on peut aussi discuter de l'intérêt de
l'OO en PHP, voire de l'intérêt de l'OO tout court, mais c'est un autre
troll^Mdébat
--
bruno desthuilliers
ruby -e "print 'onurb@xiludom.gro'.split('@').collect{|p|
p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"
Ou bien dois-je utiliser la possibilité de la fonction mysql_query() qui est la suivante : "Si link_identifier n'est pas précisé, la dernière connexion est utilisée" ?
Je te dirais que c'est fonction de ton utilisation: si tu n'utilise qu'une base, il n'y a aucun intérêt à t'inquiéter de la ressource de connexion vu que tu utiliseras toujours la même.
Je dirais que c'est fonction de l'utilisation qui va être faite de ce code. Si c'est du jetable, cf réponse ci-dessus. Si tu a un quelconque espoir de réutilisation, fait tout de suite propre. Ca ne coûte pas vraiment plus cher.
Si par contre tu dois utiliser des bases distinctes, dans ce cas il te faut t'en inquiéter. Et dans ce cas, pourquoi ne pas utiliser tes connexions en variable globales si tu en as besoin fréquemment?
Pour éviter que l'implémentation des classes concernées ne dépende de variables globales ?
Honnêtement, je ne vois pas vraiment l'intérêt de faire de l'OO si c'est pour mettre des globales. Bon, on peut aussi discuter de l'intérêt de l'OO en PHP, voire de l'intérêt de l'OO tout court, mais c'est un autre troll^Mdébat
-- bruno desthuilliers ruby -e "print ''.split('@').collect{|p| p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"
bruno modulix
Frederic Rouchouze wrote:
Je me pose une question philosophique à propos des ressources de connexion (renvoyées par la fonction mysql_connect() par exemple) :
Afin de programmer "proprement", dois-je passer systématiquement en argument à mes créateurs de classes une ressource de connexion ?
<demi-troll> Ca dépend... Pour une classe chargée de générer un PDF à partir d'un fichier XML, ce n'est peut-être pas nécessaire ?
Hein ? Je sors ? Bon, ok, je sors --->[] </demi-troll>
(snip)
Ou bien dois-je utiliser la possibilité de la fonction mysql_query() qui est la suivante : "Si link_identifier n'est pas précisé, la dernière connexion est utilisée" ?
Personnellement, je trouve ça très laid et très crade. Mais bon, je suis peut-être un poil maniaque, hein ?
(snip)
Question subsidiaire : Si la réponse à la première question est "oui", comment organiser au mieux mon passage d'argument ?
Je m'explique : je serais tenté de mettre l'argument $bdd en dernier dans la liste et en argument facultatif, au cas où je dérive ma classe "truc" et que je ne veuille plus utiliser de base de données pour stocker les propriétés de cet objet.
<oo> Dans ce cas, la solution 'propre' en OO n'est pas de dériver la classe, mais d'extraire la partie persistance de la classe "truc", et d'utiliser l'aggrégation/délégation:
// exemple à la con class TrucBddPersistance { function TrucBddPersistance($bdd) { $this->_bdd = $bdd; }
function read(...) {} function save(...) {} function delete(...) {} }
class Truc { function Truc(&$persistance) { $this->_$persistance =& $persistance; ... }
function read() { return $this->_persistance->read(); } // etc }
$bdd=mysql_connect(); $truc = new Truc(new TrucBddPersistance($bdd));
</oo>
Maintenant, dans la pratique, cette approche n'est pas forcément la plus appropriée en PHP.
Mais, dans ce cas, je ne peux pas utiliser le passage d'argument par référence, qui me semble plus efficace pour transmettre ce type de donnée (ressource).
Mmm... A moins que tu n'ai des milliers d'instances à créer, je ne pense pas que ce soit bien grave.
-- bruno desthuilliers ruby -e "print ''.split('@').collect{|p| p.split('.').collect{|w| w.reverse}.join('.')}.join('@')" python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
Frederic Rouchouze wrote:
Je me pose une question philosophique à propos des ressources de connexion
(renvoyées par la fonction mysql_connect() par exemple) :
Afin de programmer "proprement", dois-je passer systématiquement en argument
à mes créateurs de classes une ressource de connexion ?
<demi-troll>
Ca dépend... Pour une classe chargée de générer un PDF à partir d'un
fichier XML, ce n'est peut-être pas nécessaire ?
Hein ? Je sors ? Bon, ok, je sors
--->[]
</demi-troll>
(snip)
Ou bien dois-je utiliser la possibilité de la fonction mysql_query() qui est
la suivante : "Si link_identifier n'est pas précisé, la dernière connexion
est utilisée" ?
Personnellement, je trouve ça très laid et très crade. Mais bon, je suis
peut-être un poil maniaque, hein ?
(snip)
Question subsidiaire : Si la réponse à la première question est "oui",
comment organiser au mieux mon passage d'argument ?
Je m'explique : je serais tenté de mettre l'argument $bdd en dernier dans la
liste et en argument facultatif, au cas où je dérive ma classe "truc" et que
je ne veuille plus utiliser de base de données pour stocker les propriétés
de cet objet.
<oo>
Dans ce cas, la solution 'propre' en OO n'est pas de dériver la classe,
mais d'extraire la partie persistance de la classe "truc", et d'utiliser
l'aggrégation/délégation:
// exemple à la con
class TrucBddPersistance
{
function TrucBddPersistance($bdd) {
$this->_bdd = $bdd;
}
function read(...) {}
function save(...) {}
function delete(...) {}
}
class Truc
{
function Truc(&$persistance)
{
$this->_$persistance =& $persistance;
...
}
function read() { return $this->_persistance->read(); }
// etc
}
$bdd=mysql_connect();
$truc = new Truc(new TrucBddPersistance($bdd));
</oo>
Maintenant, dans la pratique, cette approche n'est pas forcément la plus
appropriée en PHP.
Mais, dans ce cas, je ne peux pas utiliser le passage d'argument par
référence, qui me semble plus efficace pour transmettre ce type de donnée
(ressource).
Mmm... A moins que tu n'ai des milliers d'instances à créer, je ne pense
pas que ce soit bien grave.
--
bruno desthuilliers
ruby -e "print 'onurb@xiludom.gro'.split('@').collect{|p|
p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
Je me pose une question philosophique à propos des ressources de connexion (renvoyées par la fonction mysql_connect() par exemple) :
Afin de programmer "proprement", dois-je passer systématiquement en argument à mes créateurs de classes une ressource de connexion ?
<demi-troll> Ca dépend... Pour une classe chargée de générer un PDF à partir d'un fichier XML, ce n'est peut-être pas nécessaire ?
Hein ? Je sors ? Bon, ok, je sors --->[] </demi-troll>
(snip)
Ou bien dois-je utiliser la possibilité de la fonction mysql_query() qui est la suivante : "Si link_identifier n'est pas précisé, la dernière connexion est utilisée" ?
Personnellement, je trouve ça très laid et très crade. Mais bon, je suis peut-être un poil maniaque, hein ?
(snip)
Question subsidiaire : Si la réponse à la première question est "oui", comment organiser au mieux mon passage d'argument ?
Je m'explique : je serais tenté de mettre l'argument $bdd en dernier dans la liste et en argument facultatif, au cas où je dérive ma classe "truc" et que je ne veuille plus utiliser de base de données pour stocker les propriétés de cet objet.
<oo> Dans ce cas, la solution 'propre' en OO n'est pas de dériver la classe, mais d'extraire la partie persistance de la classe "truc", et d'utiliser l'aggrégation/délégation:
// exemple à la con class TrucBddPersistance { function TrucBddPersistance($bdd) { $this->_bdd = $bdd; }
function read(...) {} function save(...) {} function delete(...) {} }
class Truc { function Truc(&$persistance) { $this->_$persistance =& $persistance; ... }
function read() { return $this->_persistance->read(); } // etc }
$bdd=mysql_connect(); $truc = new Truc(new TrucBddPersistance($bdd));
</oo>
Maintenant, dans la pratique, cette approche n'est pas forcément la plus appropriée en PHP.
Mais, dans ce cas, je ne peux pas utiliser le passage d'argument par référence, qui me semble plus efficace pour transmettre ce type de donnée (ressource).
Mmm... A moins que tu n'ai des milliers d'instances à créer, je ne pense pas que ce soit bien grave.
-- bruno desthuilliers ruby -e "print ''.split('@').collect{|p| p.split('.').collect{|w| w.reverse}.join('.')}.join('@')" python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in ''.split('@')])"
CrazyCat
bruno modulix wrote:
Si par contre tu dois utiliser des bases distinctes, dans ce cas il te faut t'en inquiéter. Et dans ce cas, pourquoi ne pas utiliser tes connexions en variable globales si tu en as besoin fréquemment? Pour éviter que l'implémentation des classes concernées ne dépende de
variables globales ?
L'honorable initiateur du sujet parlait de fonctions et non pas de classes, j'en ai déduit que c'était du procédural.
Si c'est en OO, effectivement il ne faut pas utiliser de variables globales mais plutot utiliser (patapé si ke me trompe) des namespaces
-- Découvrez Original War: http://www.original-war.org Humour: http://www.chatfou.com Tchattez en liberté: http://www.crazy-irc.net
bruno modulix wrote:
Si par contre tu dois utiliser des bases distinctes, dans ce cas il te
faut t'en inquiéter. Et dans ce cas, pourquoi ne pas utiliser tes
connexions en variable globales si tu en as besoin fréquemment?
Pour éviter que l'implémentation des classes concernées ne dépende de
variables globales ?
L'honorable initiateur du sujet parlait de fonctions et non pas de
classes, j'en ai déduit que c'était du procédural.
Si c'est en OO, effectivement il ne faut pas utiliser de variables
globales mais plutot utiliser (patapé si ke me trompe) des namespaces
--
Découvrez Original War: http://www.original-war.org
Humour: http://www.chatfou.com
Tchattez en liberté: http://www.crazy-irc.net
Si par contre tu dois utiliser des bases distinctes, dans ce cas il te faut t'en inquiéter. Et dans ce cas, pourquoi ne pas utiliser tes connexions en variable globales si tu en as besoin fréquemment? Pour éviter que l'implémentation des classes concernées ne dépende de
variables globales ?
L'honorable initiateur du sujet parlait de fonctions et non pas de classes, j'en ai déduit que c'était du procédural.
Si c'est en OO, effectivement il ne faut pas utiliser de variables globales mais plutot utiliser (patapé si ke me trompe) des namespaces
-- Découvrez Original War: http://www.original-war.org Humour: http://www.chatfou.com Tchattez en liberté: http://www.crazy-irc.net
ftc
Honnêtement, je ne vois pas vraiment l'intérêt de faire de l'OO si c'est pour mettre des globales.
Parce que PHP4 a de gros problèmes avec les static, mettre une variable en global est un moyen de pallier à ce défaut notament lorsqu'on a besoin d'un singleton.
Honnêtement, je ne vois pas vraiment l'intérêt de faire de l'OO si c'est
pour mettre des globales.
Parce que PHP4 a de gros problèmes avec les static, mettre une variable
en global est un moyen de pallier à ce défaut notament lorsqu'on a
besoin d'un singleton.
Honnêtement, je ne vois pas vraiment l'intérêt de faire de l'OO si c'est pour mettre des globales.
Parce que PHP4 a de gros problèmes avec les static, mettre une variable en global est un moyen de pallier à ce défaut notament lorsqu'on a besoin d'un singleton.
John GALLET
Bonjour,
Parce que PHP4 a de gros problèmes avec les static,
Jamais entendu parlé, mais j'en utilise très peu. Source de cette information SVP ?
JG
Bonjour,
Parce que PHP4 a de gros problèmes avec les static,
Jamais entendu parlé, mais j'en utilise très peu. Source de cette
information SVP ?