J'ai une p'tite question métaphysique qui me turlup..ne :
Si je crée une nouvelle classe, il y a deux moyens de créer une instance de
cette classe :
- soit je propose un constructeur "public"
- soit je propose une méthode statique publique qui crée l'instance en
appelant un constructeur "private"
Le résultat est le même, mais l'une ou l'autre possibilité dépend
certainement du type de la classe, ou de la conception générale du projet.
Y a-t-il une ou plusieurs règles de conception qui déterminent le choix de
l'une ou l'autre solution ?
Si l'explication est ardue, peut-être connaissez-vous un site qui pourra
m'éclairer sur ce point ?
Merci de vos nombreuses réponses ;-)
--
Pour me répondre, supprimez le spam.
---------------------------------------------------------------
[...] même si tu comprends pas ce que je dis, tu le comprends
(Jean-Claude Van Damme)
---------------------------------------------------------------
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Eric Meallier
Pour ma part, j'utilise la creation avec method static pour les singleton ( cad une seule instance pour tout ton projet)
c'est utile pour les configuration par exemple: tout le monde appelle getConfiguration() et ca roule. Le premier qui appelle il instancie et les autres ont une "copie".
sinon dans le cas d'objet metier, tu mets systematiquement un constructeur.
pour le reste , a toi de voir.
A+
"GilloS" a écrit dans le message de news:bnrco5$2r7s$
Bonjour à tous
J'ai une p'tite question métaphysique qui me turlup..ne :
Si je crée une nouvelle classe, il y a deux moyens de créer une instance de
cette classe :
- soit je propose un constructeur "public" - soit je propose une méthode statique publique qui crée l'instance en appelant un constructeur "private"
Le résultat est le même, mais l'une ou l'autre possibilité dépend certainement du type de la classe, ou de la conception générale du projet.
Y a-t-il une ou plusieurs règles de conception qui déterminent le choix de l'une ou l'autre solution ? Si l'explication est ardue, peut-être connaissez-vous un site qui pourra m'éclairer sur ce point ?
Merci de vos nombreuses réponses ;-)
-- Pour me répondre, supprimez le spam.
--------------------------------------------------------------- [...] même si tu comprends pas ce que je dis, tu le comprends (Jean-Claude Van Damme) ---------------------------------------------------------------
Pour ma part, j'utilise la creation avec method static pour les singleton
( cad une seule instance pour tout ton projet)
c'est utile pour les configuration par exemple: tout le monde appelle
getConfiguration() et ca roule. Le premier qui appelle il instancie et les
autres ont une "copie".
sinon dans le cas d'objet metier, tu mets systematiquement un constructeur.
pour le reste , a toi de voir.
A+
"GilloS" <toto@toto.com> a écrit dans le message de
news:bnrco5$2r7s$1@news5.isdnet.net...
Bonjour à tous
J'ai une p'tite question métaphysique qui me turlup..ne :
Si je crée une nouvelle classe, il y a deux moyens de créer une instance
de
cette classe :
- soit je propose un constructeur "public"
- soit je propose une méthode statique publique qui crée l'instance en
appelant un constructeur "private"
Le résultat est le même, mais l'une ou l'autre possibilité dépend
certainement du type de la classe, ou de la conception générale du projet.
Y a-t-il une ou plusieurs règles de conception qui déterminent le choix de
l'une ou l'autre solution ?
Si l'explication est ardue, peut-être connaissez-vous un site qui pourra
m'éclairer sur ce point ?
Merci de vos nombreuses réponses ;-)
--
Pour me répondre, supprimez le spam.
---------------------------------------------------------------
[...] même si tu comprends pas ce que je dis, tu le comprends
(Jean-Claude Van Damme)
---------------------------------------------------------------
Pour ma part, j'utilise la creation avec method static pour les singleton ( cad une seule instance pour tout ton projet)
c'est utile pour les configuration par exemple: tout le monde appelle getConfiguration() et ca roule. Le premier qui appelle il instancie et les autres ont une "copie".
sinon dans le cas d'objet metier, tu mets systematiquement un constructeur.
pour le reste , a toi de voir.
A+
"GilloS" a écrit dans le message de news:bnrco5$2r7s$
Bonjour à tous
J'ai une p'tite question métaphysique qui me turlup..ne :
Si je crée une nouvelle classe, il y a deux moyens de créer une instance de
cette classe :
- soit je propose un constructeur "public" - soit je propose une méthode statique publique qui crée l'instance en appelant un constructeur "private"
Le résultat est le même, mais l'une ou l'autre possibilité dépend certainement du type de la classe, ou de la conception générale du projet.
Y a-t-il une ou plusieurs règles de conception qui déterminent le choix de l'une ou l'autre solution ? Si l'explication est ardue, peut-être connaissez-vous un site qui pourra m'éclairer sur ce point ?
Merci de vos nombreuses réponses ;-)
-- Pour me répondre, supprimez le spam.
--------------------------------------------------------------- [...] même si tu comprends pas ce que je dis, tu le comprends (Jean-Claude Van Damme) ---------------------------------------------------------------
Alexandre Touret
De + si c est les methodes sont du genre dateToString, formatDate .... ou celle qu il y a ds les classes Collections ou Arrays, vaudra mieux faire des methodes statiques
AT
Eric Meallier wrote:
Pour ma part, j'utilise la creation avec method static pour les singleton ( cad une seule instance pour tout ton projet)
c'est utile pour les configuration par exemple: tout le monde appelle getConfiguration() et ca roule. Le premier qui appelle il instancie et les autres ont une "copie".
sinon dans le cas d'objet metier, tu mets systematiquement un constructeur.
pour le reste , a toi de voir.
A+
"GilloS" a écrit dans le message de news:bnrco5$2r7s$
Bonjour à tous
J'ai une p'tite question métaphysique qui me turlup..ne :
Si je crée une nouvelle classe, il y a deux moyens de créer une instance
de
cette classe :
- soit je propose un constructeur "public" - soit je propose une méthode statique publique qui crée l'instance en appelant un constructeur "private"
Le résultat est le même, mais l'une ou l'autre possibilité dépend certainement du type de la classe, ou de la conception générale du projet.
Y a-t-il une ou plusieurs règles de conception qui déterminent le choix de l'une ou l'autre solution ? Si l'explication est ardue, peut-être connaissez-vous un site qui pourra m'éclairer sur ce point ?
Merci de vos nombreuses réponses ;-)
-- Pour me répondre, supprimez le spam.
--------------------------------------------------------------- [...] même si tu comprends pas ce que je dis, tu le comprends (Jean-Claude Van Damme) ---------------------------------------------------------------
De + si c est les methodes sont du genre dateToString, formatDate ....
ou celle qu il y a ds les classes Collections ou Arrays, vaudra mieux
faire des methodes statiques
AT
Eric Meallier wrote:
Pour ma part, j'utilise la creation avec method static pour les singleton
( cad une seule instance pour tout ton projet)
c'est utile pour les configuration par exemple: tout le monde appelle
getConfiguration() et ca roule. Le premier qui appelle il instancie et les
autres ont une "copie".
sinon dans le cas d'objet metier, tu mets systematiquement un constructeur.
pour le reste , a toi de voir.
A+
"GilloS" <toto@toto.com> a écrit dans le message de
news:bnrco5$2r7s$1@news5.isdnet.net...
Bonjour à tous
J'ai une p'tite question métaphysique qui me turlup..ne :
Si je crée une nouvelle classe, il y a deux moyens de créer une instance
de
cette classe :
- soit je propose un constructeur "public"
- soit je propose une méthode statique publique qui crée l'instance en
appelant un constructeur "private"
Le résultat est le même, mais l'une ou l'autre possibilité dépend
certainement du type de la classe, ou de la conception générale du projet.
Y a-t-il une ou plusieurs règles de conception qui déterminent le choix de
l'une ou l'autre solution ?
Si l'explication est ardue, peut-être connaissez-vous un site qui pourra
m'éclairer sur ce point ?
Merci de vos nombreuses réponses ;-)
--
Pour me répondre, supprimez le spam.
---------------------------------------------------------------
[...] même si tu comprends pas ce que je dis, tu le comprends
(Jean-Claude Van Damme)
---------------------------------------------------------------
De + si c est les methodes sont du genre dateToString, formatDate .... ou celle qu il y a ds les classes Collections ou Arrays, vaudra mieux faire des methodes statiques
AT
Eric Meallier wrote:
Pour ma part, j'utilise la creation avec method static pour les singleton ( cad une seule instance pour tout ton projet)
c'est utile pour les configuration par exemple: tout le monde appelle getConfiguration() et ca roule. Le premier qui appelle il instancie et les autres ont une "copie".
sinon dans le cas d'objet metier, tu mets systematiquement un constructeur.
pour le reste , a toi de voir.
A+
"GilloS" a écrit dans le message de news:bnrco5$2r7s$
Bonjour à tous
J'ai une p'tite question métaphysique qui me turlup..ne :
Si je crée une nouvelle classe, il y a deux moyens de créer une instance
de
cette classe :
- soit je propose un constructeur "public" - soit je propose une méthode statique publique qui crée l'instance en appelant un constructeur "private"
Le résultat est le même, mais l'une ou l'autre possibilité dépend certainement du type de la classe, ou de la conception générale du projet.
Y a-t-il une ou plusieurs règles de conception qui déterminent le choix de l'une ou l'autre solution ? Si l'explication est ardue, peut-être connaissez-vous un site qui pourra m'éclairer sur ce point ?
Merci de vos nombreuses réponses ;-)
-- Pour me répondre, supprimez le spam.
--------------------------------------------------------------- [...] même si tu comprends pas ce que je dis, tu le comprends (Jean-Claude Van Damme) ---------------------------------------------------------------
Eric Meallier
je confirme: pour les methodes utilitaires, c'est pratique de les mettre en static mais il faut remarquer que l'object n'est plus instancie en principe dans ce cas.
"Alexandre Touret" a écrit dans le message de news:
De + si c est les methodes sont du genre dateToString, formatDate .... ou celle qu il y a ds les classes Collections ou Arrays, vaudra mieux faire des methodes statiques
AT
Eric Meallier wrote:
Pour ma part, j'utilise la creation avec method static pour les singleton
( cad une seule instance pour tout ton projet)
c'est utile pour les configuration par exemple: tout le monde appelle getConfiguration() et ca roule. Le premier qui appelle il instancie et les
autres ont une "copie".
sinon dans le cas d'objet metier, tu mets systematiquement un constructeur.
pour le reste , a toi de voir.
A+
"GilloS" a écrit dans le message de news:bnrco5$2r7s$
Bonjour à tous
J'ai une p'tite question métaphysique qui me turlup..ne :
Si je crée une nouvelle classe, il y a deux moyens de créer une instance
de
cette classe :
- soit je propose un constructeur "public" - soit je propose une méthode statique publique qui crée l'instance en
appelant un constructeur "private"
Le résultat est le même, mais l'une ou l'autre possibilité dépend certainement du type de la classe, ou de la conception générale du projet.
Y a-t-il une ou plusieurs règles de conception qui déterminent le choix de
l'une ou l'autre solution ? Si l'explication est ardue, peut-être connaissez-vous un site qui pourra m'éclairer sur ce point ?
Merci de vos nombreuses réponses ;-)
-- Pour me répondre, supprimez le spam.
--------------------------------------------------------------- [...] même si tu comprends pas ce que je dis, tu le comprends (Jean-Claude Van Damme) ---------------------------------------------------------------
je confirme: pour les methodes utilitaires, c'est pratique de les mettre en
static mais il faut remarquer que l'object n'est plus instancie en principe
dans ce cas.
"Alexandre Touret" <alexandre.touretNOSPAM@cgbi.fr> a écrit dans le message
de news:3FA13C93.1070706@cgbi.fr...
De + si c est les methodes sont du genre dateToString, formatDate ....
ou celle qu il y a ds les classes Collections ou Arrays, vaudra mieux
faire des methodes statiques
AT
Eric Meallier wrote:
Pour ma part, j'utilise la creation avec method static pour les
singleton
( cad une seule instance pour tout ton projet)
c'est utile pour les configuration par exemple: tout le monde appelle
getConfiguration() et ca roule. Le premier qui appelle il instancie et
les
autres ont une "copie".
sinon dans le cas d'objet metier, tu mets systematiquement un
constructeur.
pour le reste , a toi de voir.
A+
"GilloS" <toto@toto.com> a écrit dans le message de
news:bnrco5$2r7s$1@news5.isdnet.net...
Bonjour à tous
J'ai une p'tite question métaphysique qui me turlup..ne :
Si je crée une nouvelle classe, il y a deux moyens de créer une instance
de
cette classe :
- soit je propose un constructeur "public"
- soit je propose une méthode statique publique qui crée l'instance
en
appelant un constructeur "private"
Le résultat est le même, mais l'une ou l'autre possibilité dépend
certainement du type de la classe, ou de la conception générale du
projet.
Y a-t-il une ou plusieurs règles de conception qui déterminent le choix
de
l'une ou l'autre solution ?
Si l'explication est ardue, peut-être connaissez-vous un site qui pourra
m'éclairer sur ce point ?
Merci de vos nombreuses réponses ;-)
--
Pour me répondre, supprimez le spam.
---------------------------------------------------------------
[...] même si tu comprends pas ce que je dis, tu le comprends
(Jean-Claude Van Damme)
---------------------------------------------------------------
je confirme: pour les methodes utilitaires, c'est pratique de les mettre en static mais il faut remarquer que l'object n'est plus instancie en principe dans ce cas.
"Alexandre Touret" a écrit dans le message de news:
De + si c est les methodes sont du genre dateToString, formatDate .... ou celle qu il y a ds les classes Collections ou Arrays, vaudra mieux faire des methodes statiques
AT
Eric Meallier wrote:
Pour ma part, j'utilise la creation avec method static pour les singleton
( cad une seule instance pour tout ton projet)
c'est utile pour les configuration par exemple: tout le monde appelle getConfiguration() et ca roule. Le premier qui appelle il instancie et les
autres ont une "copie".
sinon dans le cas d'objet metier, tu mets systematiquement un constructeur.
pour le reste , a toi de voir.
A+
"GilloS" a écrit dans le message de news:bnrco5$2r7s$
Bonjour à tous
J'ai une p'tite question métaphysique qui me turlup..ne :
Si je crée une nouvelle classe, il y a deux moyens de créer une instance
de
cette classe :
- soit je propose un constructeur "public" - soit je propose une méthode statique publique qui crée l'instance en
appelant un constructeur "private"
Le résultat est le même, mais l'une ou l'autre possibilité dépend certainement du type de la classe, ou de la conception générale du projet.
Y a-t-il une ou plusieurs règles de conception qui déterminent le choix de
l'une ou l'autre solution ? Si l'explication est ardue, peut-être connaissez-vous un site qui pourra m'éclairer sur ce point ?
Merci de vos nombreuses réponses ;-)
-- Pour me répondre, supprimez le spam.
--------------------------------------------------------------- [...] même si tu comprends pas ce que je dis, tu le comprends (Jean-Claude Van Damme) ---------------------------------------------------------------
GilloS
Effectivement, ce qui m'intéresse, c'est plutôt les constructeurs.
De plus, j'ai déjà dû écrire certaines classes avec plusieurs constructeurs ; peut-être était-ce une erreur de conception, mais en tout cas j'ai trouvé que c'était plutôt merdique à gérer, surtout que ces constructeurs ne sont souvent que des variantes...
Merci en tout cas de vos premières réponses...
"Eric Meallier" wrote in message news:3fa13ffb$0$223$
je confirme: pour les methodes utilitaires, c'est pratique de les mettre en
static mais il faut remarquer que l'object n'est plus instancie en principe
dans ce cas.
"Alexandre Touret" a écrit dans le message
de news:
De + si c est les methodes sont du genre dateToString, formatDate .... ou celle qu il y a ds les classes Collections ou Arrays, vaudra mieux faire des methodes statiques
AT
Eric Meallier wrote:
Pour ma part, j'utilise la creation avec method static pour les singleton
( cad une seule instance pour tout ton projet)
c'est utile pour les configuration par exemple: tout le monde appelle getConfiguration() et ca roule. Le premier qui appelle il instancie et les
autres ont une "copie".
sinon dans le cas d'objet metier, tu mets systematiquement un constructeur.
pour le reste , a toi de voir.
A+
"GilloS" a écrit dans le message de news:bnrco5$2r7s$
Bonjour à tous
J'ai une p'tite question métaphysique qui me turlup..ne :
Si je crée une nouvelle classe, il y a deux moyens de créer une instance
de
cette classe :
- soit je propose un constructeur "public" - soit je propose une méthode statique publique qui crée l'instance
en
appelant un constructeur "private"
Le résultat est le même, mais l'une ou l'autre possibilité dépend certainement du type de la classe, ou de la conception générale du projet.
Y a-t-il une ou plusieurs règles de conception qui déterminent le choix
de
l'une ou l'autre solution ? Si l'explication est ardue, peut-être connaissez-vous un site qui pourra
m'éclairer sur ce point ?
Merci de vos nombreuses réponses ;-)
-- Pour me répondre, supprimez le spam.
--------------------------------------------------------------- [...] même si tu comprends pas ce que je dis, tu le comprends (Jean-Claude Van Damme) ---------------------------------------------------------------
Effectivement, ce qui m'intéresse, c'est plutôt les constructeurs.
De plus, j'ai déjà dû écrire certaines classes avec plusieurs constructeurs
; peut-être était-ce une erreur de conception, mais en tout cas j'ai trouvé
que c'était plutôt merdique à gérer, surtout que ces constructeurs ne sont
souvent que des variantes...
Merci en tout cas de vos premières réponses...
"Eric Meallier" <eric.meallier@free.fr> wrote in message
news:3fa13ffb$0$223$626a54ce@news.free.fr...
je confirme: pour les methodes utilitaires, c'est pratique de les mettre
en
static mais il faut remarquer que l'object n'est plus instancie en
principe
dans ce cas.
"Alexandre Touret" <alexandre.touretNOSPAM@cgbi.fr> a écrit dans le
message
de news:3FA13C93.1070706@cgbi.fr...
De + si c est les methodes sont du genre dateToString, formatDate ....
ou celle qu il y a ds les classes Collections ou Arrays, vaudra mieux
faire des methodes statiques
AT
Eric Meallier wrote:
Pour ma part, j'utilise la creation avec method static pour les
singleton
( cad une seule instance pour tout ton projet)
c'est utile pour les configuration par exemple: tout le monde appelle
getConfiguration() et ca roule. Le premier qui appelle il instancie et
les
autres ont une "copie".
sinon dans le cas d'objet metier, tu mets systematiquement un
constructeur.
pour le reste , a toi de voir.
A+
"GilloS" <toto@toto.com> a écrit dans le message de
news:bnrco5$2r7s$1@news5.isdnet.net...
Bonjour à tous
J'ai une p'tite question métaphysique qui me turlup..ne :
Si je crée une nouvelle classe, il y a deux moyens de créer une
instance
de
cette classe :
- soit je propose un constructeur "public"
- soit je propose une méthode statique publique qui crée
l'instance
en
appelant un constructeur "private"
Le résultat est le même, mais l'une ou l'autre possibilité dépend
certainement du type de la classe, ou de la conception générale du
projet.
Y a-t-il une ou plusieurs règles de conception qui déterminent le
choix
de
l'une ou l'autre solution ?
Si l'explication est ardue, peut-être connaissez-vous un site qui
pourra
m'éclairer sur ce point ?
Merci de vos nombreuses réponses ;-)
--
Pour me répondre, supprimez le spam.
---------------------------------------------------------------
[...] même si tu comprends pas ce que je dis, tu le comprends
(Jean-Claude Van Damme)
---------------------------------------------------------------
Effectivement, ce qui m'intéresse, c'est plutôt les constructeurs.
De plus, j'ai déjà dû écrire certaines classes avec plusieurs constructeurs ; peut-être était-ce une erreur de conception, mais en tout cas j'ai trouvé que c'était plutôt merdique à gérer, surtout que ces constructeurs ne sont souvent que des variantes...
Merci en tout cas de vos premières réponses...
"Eric Meallier" wrote in message news:3fa13ffb$0$223$
je confirme: pour les methodes utilitaires, c'est pratique de les mettre en
static mais il faut remarquer que l'object n'est plus instancie en principe
dans ce cas.
"Alexandre Touret" a écrit dans le message
de news:
De + si c est les methodes sont du genre dateToString, formatDate .... ou celle qu il y a ds les classes Collections ou Arrays, vaudra mieux faire des methodes statiques
AT
Eric Meallier wrote:
Pour ma part, j'utilise la creation avec method static pour les singleton
( cad une seule instance pour tout ton projet)
c'est utile pour les configuration par exemple: tout le monde appelle getConfiguration() et ca roule. Le premier qui appelle il instancie et les
autres ont une "copie".
sinon dans le cas d'objet metier, tu mets systematiquement un constructeur.
pour le reste , a toi de voir.
A+
"GilloS" a écrit dans le message de news:bnrco5$2r7s$
Bonjour à tous
J'ai une p'tite question métaphysique qui me turlup..ne :
Si je crée une nouvelle classe, il y a deux moyens de créer une instance
de
cette classe :
- soit je propose un constructeur "public" - soit je propose une méthode statique publique qui crée l'instance
en
appelant un constructeur "private"
Le résultat est le même, mais l'une ou l'autre possibilité dépend certainement du type de la classe, ou de la conception générale du projet.
Y a-t-il une ou plusieurs règles de conception qui déterminent le choix
de
l'une ou l'autre solution ? Si l'explication est ardue, peut-être connaissez-vous un site qui pourra
m'éclairer sur ce point ?
Merci de vos nombreuses réponses ;-)
-- Pour me répondre, supprimez le spam.
--------------------------------------------------------------- [...] même si tu comprends pas ce que je dis, tu le comprends (Jean-Claude Van Damme) ---------------------------------------------------------------
O.
De plus, j'ai déjà dû écrire certaines classes avec plusieurs constructeurs
Un constructeur par défaut (sans paramètres) et des constructeurs paramétrisés ? Rien de plus normal. On peut éviter ça avec C++ grâce aux paramètres par défauts, mais pas en Java je pense... alors il est logique de parfois avoir plusieurs constructeurs.
-- Pas de promo perso à la con dans ma signature... avouez que ça fait du bien dans ce monde de pubs...
De plus, j'ai déjà dû écrire certaines classes avec plusieurs constructeurs
Un constructeur par défaut (sans paramètres) et des constructeurs
paramétrisés ? Rien de plus normal. On peut éviter ça avec C++ grâce
aux paramètres par défauts, mais pas en Java je pense... alors il est
logique de parfois avoir plusieurs constructeurs.
--
Pas de promo perso à la con dans ma signature... avouez que ça fait du
bien dans ce monde de pubs...
De plus, j'ai déjà dû écrire certaines classes avec plusieurs constructeurs
Un constructeur par défaut (sans paramètres) et des constructeurs paramétrisés ? Rien de plus normal. On peut éviter ça avec C++ grâce aux paramètres par défauts, mais pas en Java je pense... alors il est logique de parfois avoir plusieurs constructeurs.
-- Pas de promo perso à la con dans ma signature... avouez que ça fait du bien dans ce monde de pubs...
Cyrille
que c'était plutôt merdique à gérer, surtout que ces constructeurs ne sont souvent que des variantes...
c'est souvent nécessaire, et bien pratique.
en fait tu peux avoir un construteur avec toutes les paramètes qui fait vraimenet tout le boulot d'initialisation, et les autres contructeurs font appel à lui, en construisant les paramètres par défaut. c'est pas bordélique à gérer ;o)
cyrille
-==-==-==- ... FAQ Mozilla/Netscape 7 en français : http://pascal.chevrel.free.fr -==-==-==-
que c'était plutôt merdique à gérer, surtout que ces constructeurs ne sont
souvent que des variantes...
c'est souvent nécessaire, et bien pratique.
en fait tu peux avoir un construteur avec toutes les paramètes qui fait vraimenet tout le boulot d'initialisation,
et les autres contructeurs font appel à lui, en construisant les paramètres par défaut.
c'est pas bordélique à gérer ;o)
cyrille
-==-==-==-
... FAQ Mozilla/Netscape 7 en français : http://pascal.chevrel.free.fr
-==-==-==-
que c'était plutôt merdique à gérer, surtout que ces constructeurs ne sont souvent que des variantes...
c'est souvent nécessaire, et bien pratique.
en fait tu peux avoir un construteur avec toutes les paramètes qui fait vraimenet tout le boulot d'initialisation, et les autres contructeurs font appel à lui, en construisant les paramètres par défaut. c'est pas bordélique à gérer ;o)
cyrille
-==-==-==- ... FAQ Mozilla/Netscape 7 en français : http://pascal.chevrel.free.fr -==-==-==-
Patrick Gras
"GilloS" wrote in message news:bnrco5$2r7s$
Bonjour à tous
J'ai une p'tite question métaphysique qui me turlup..ne :
Si je crée une nouvelle classe, il y a deux moyens de créer une instance de
cette classe :
- soit je propose un constructeur "public" - soit je propose une méthode statique publique qui crée l'instance en appelant un constructeur "private"
Le résultat est le même, mais l'une ou l'autre possibilité dépend certainement du type de la classe, ou de la conception générale du projet.
Y a-t-il une ou plusieurs règles de conception qui déterminent le choix de l'une ou l'autre solution ? Si l'explication est ardue, peut-être connaissez-vous un site qui pourra m'éclairer sur ce point ?
Merci de vos nombreuses réponses ;-)
-- Pour me répondre, supprimez le spam.
--------------------------------------------------------------- [...] même si tu comprends pas ce que je dis, tu le comprends (Jean-Claude Van Damme) ---------------------------------------------------------------
Hello,
Une méthode statique est une méthode de la classe plutôt que d'une instance de classe.
Donc la question à te poser c'est de savoir si tu dois avoir accès à la classe (par exemple pour limiter le nombre d'instances pour un singleton...)
Tu peux aussi considérer la possibilité d'utiliser une classe Factory pour construire tes objets...
Si tu ne dois pas avoir accès à la classe le constructeur public est suffisant...
Un dernier point, si tu utilise le couple "méthode statique publique qui crée l'instance en appelant un constructeur private" et que tu désérialise ta classe, le constructeur (private?) sans argument sera utilisé...
-Patrick
"GilloS" <toto@toto.com> wrote in message
news:bnrco5$2r7s$1@news5.isdnet.net...
Bonjour à tous
J'ai une p'tite question métaphysique qui me turlup..ne :
Si je crée une nouvelle classe, il y a deux moyens de créer une instance
de
cette classe :
- soit je propose un constructeur "public"
- soit je propose une méthode statique publique qui crée l'instance en
appelant un constructeur "private"
Le résultat est le même, mais l'une ou l'autre possibilité dépend
certainement du type de la classe, ou de la conception générale du projet.
Y a-t-il une ou plusieurs règles de conception qui déterminent le choix de
l'une ou l'autre solution ?
Si l'explication est ardue, peut-être connaissez-vous un site qui pourra
m'éclairer sur ce point ?
Merci de vos nombreuses réponses ;-)
--
Pour me répondre, supprimez le spam.
---------------------------------------------------------------
[...] même si tu comprends pas ce que je dis, tu le comprends
(Jean-Claude Van Damme)
---------------------------------------------------------------
Hello,
Une méthode statique est une méthode de la classe plutôt que d'une instance
de classe.
Donc la question à te poser c'est de savoir si tu dois avoir accès à la
classe (par exemple pour limiter le nombre d'instances pour un singleton...)
Tu peux aussi considérer la possibilité d'utiliser une classe Factory pour
construire tes objets...
Si tu ne dois pas avoir accès à la classe le constructeur public est
suffisant...
Un dernier point, si tu utilise le couple "méthode statique publique qui
crée l'instance en appelant un constructeur private" et que tu désérialise
ta classe, le constructeur (private?) sans argument sera utilisé...
J'ai une p'tite question métaphysique qui me turlup..ne :
Si je crée une nouvelle classe, il y a deux moyens de créer une instance de
cette classe :
- soit je propose un constructeur "public" - soit je propose une méthode statique publique qui crée l'instance en appelant un constructeur "private"
Le résultat est le même, mais l'une ou l'autre possibilité dépend certainement du type de la classe, ou de la conception générale du projet.
Y a-t-il une ou plusieurs règles de conception qui déterminent le choix de l'une ou l'autre solution ? Si l'explication est ardue, peut-être connaissez-vous un site qui pourra m'éclairer sur ce point ?
Merci de vos nombreuses réponses ;-)
-- Pour me répondre, supprimez le spam.
--------------------------------------------------------------- [...] même si tu comprends pas ce que je dis, tu le comprends (Jean-Claude Van Damme) ---------------------------------------------------------------
Hello,
Une méthode statique est une méthode de la classe plutôt que d'une instance de classe.
Donc la question à te poser c'est de savoir si tu dois avoir accès à la classe (par exemple pour limiter le nombre d'instances pour un singleton...)
Tu peux aussi considérer la possibilité d'utiliser une classe Factory pour construire tes objets...
Si tu ne dois pas avoir accès à la classe le constructeur public est suffisant...
Un dernier point, si tu utilise le couple "méthode statique publique qui crée l'instance en appelant un constructeur private" et que tu désérialise ta classe, le constructeur (private?) sans argument sera utilisé...
-Patrick
GilloS
Un exemple qui peut faire appel à l'une ou l'autre des méthodes de construction d'objets :
J'ai ouvert sur un serveur un objet "Session" qui me permet de gérer des objets "Variable". J'ai donc besoin d'une classe "Variable" et d'une classe "Session" dont dépend les objets "Variable".
Si j'ai besoin de créer une "Variable", je peux :
- soit créer un constructeur "public" : public Variable( Session s ) { ... }
- soit créer une méthode publique dans "Session" : public Variable createVariable( ) { return new Variable( this ); } et dans ce cas, je déclare mon constructeur "Variable( )" private ou protected.
Y a-t-il une méthode plus "propre" que l'autre ou les deux sont-elles équivalentes ? Ou peut-être que cela doit dépendre d'un contexte plus général ?
A noter que dans les API Sun, c'est souvent la deuxième méthode qui est utilisée, même si ce ne sont pas des singletons.
Exemple : Connection.createStatement( ) dans les API JDBC
Bon, bien sûr, vous allez me répondre, c'est normal, createStatement( ) renvoie un objet de type Statement qui est une interface, donc pas de constructeur Statement( ), mais c'était pour alimenter le débat.
Autre exemple : Calendar.getInstance( )
Cette méthode statique renvoie un objet "Calendar" ; ici le constructeur "Calendar( )" est "protected". Pourtant, la classe "Calendar" n'est ni une interface, ni une classe abstraite...
Merci encore de vos réponses...
Un exemple qui peut faire appel à l'une ou l'autre des méthodes de
construction d'objets :
J'ai ouvert sur un serveur un objet "Session" qui me permet de gérer des
objets "Variable".
J'ai donc besoin d'une classe "Variable" et d'une classe "Session" dont
dépend les objets "Variable".
Si j'ai besoin de créer une "Variable", je peux :
- soit créer un constructeur "public" :
public Variable( Session s ) {
...
}
- soit créer une méthode publique dans "Session" :
public Variable createVariable( ) {
return new Variable( this );
}
et dans ce cas, je déclare mon constructeur "Variable( )" private ou
protected.
Y a-t-il une méthode plus "propre" que l'autre ou les deux sont-elles
équivalentes ?
Ou peut-être que cela doit dépendre d'un contexte plus général ?
A noter que dans les API Sun, c'est souvent la deuxième méthode qui est
utilisée, même si ce ne sont pas des singletons.
Exemple : Connection.createStatement( ) dans les API JDBC
Bon, bien sûr, vous allez me répondre, c'est normal, createStatement( )
renvoie un objet de type Statement qui est une interface, donc pas de
constructeur Statement( ), mais c'était pour alimenter le débat.
Autre exemple : Calendar.getInstance( )
Cette méthode statique renvoie un objet "Calendar" ; ici le constructeur
"Calendar( )" est "protected".
Pourtant, la classe "Calendar" n'est ni une interface, ni une classe
abstraite...
Un exemple qui peut faire appel à l'une ou l'autre des méthodes de construction d'objets :
J'ai ouvert sur un serveur un objet "Session" qui me permet de gérer des objets "Variable". J'ai donc besoin d'une classe "Variable" et d'une classe "Session" dont dépend les objets "Variable".
Si j'ai besoin de créer une "Variable", je peux :
- soit créer un constructeur "public" : public Variable( Session s ) { ... }
- soit créer une méthode publique dans "Session" : public Variable createVariable( ) { return new Variable( this ); } et dans ce cas, je déclare mon constructeur "Variable( )" private ou protected.
Y a-t-il une méthode plus "propre" que l'autre ou les deux sont-elles équivalentes ? Ou peut-être que cela doit dépendre d'un contexte plus général ?
A noter que dans les API Sun, c'est souvent la deuxième méthode qui est utilisée, même si ce ne sont pas des singletons.
Exemple : Connection.createStatement( ) dans les API JDBC
Bon, bien sûr, vous allez me répondre, c'est normal, createStatement( ) renvoie un objet de type Statement qui est une interface, donc pas de constructeur Statement( ), mais c'était pour alimenter le débat.
Autre exemple : Calendar.getInstance( )
Cette méthode statique renvoie un objet "Calendar" ; ici le constructeur "Calendar( )" est "protected". Pourtant, la classe "Calendar" n'est ni une interface, ni une classe abstraite...
Merci encore de vos réponses...
Thomas Luyt
"GilloS" wrote in news:bnu064$1ufd$:
[...]
Autre exemple : Calendar.getInstance( )
Cette méthode statique renvoie un objet "Calendar" ; ici le constructeur "Calendar( )" est "protected". Pourtant, la classe "Calendar" n'est ni une interface, ni une classe abstraite... ^
Je me garderais bien d'affirmer que Calendar n'est pas une classe abstraite.
-- Thomas
"GilloS" <toto@toto.com> wrote in news:bnu064$1ufd$1@news5.isdnet.net:
[...]
Autre exemple : Calendar.getInstance( )
Cette méthode statique renvoie un objet "Calendar" ; ici le
constructeur "Calendar( )" est "protected".
Pourtant, la classe "Calendar" n'est ni une interface, ni une classe
abstraite...
^
Je me garderais bien d'affirmer que Calendar n'est pas une classe
abstraite.
Cette méthode statique renvoie un objet "Calendar" ; ici le constructeur "Calendar( )" est "protected". Pourtant, la classe "Calendar" n'est ni une interface, ni une classe abstraite... ^
Je me garderais bien d'affirmer que Calendar n'est pas une classe abstraite.
-- Thomas
GilloS
Oops, désolé, j'avais mal lu ma doc :-(
Merci de ta remarque.
"Thomas Luyt" wrote in message news:
"GilloS" wrote in news:bnu064$1ufd$:
[...]
Autre exemple : Calendar.getInstance( )
Cette méthode statique renvoie un objet "Calendar" ; ici le constructeur "Calendar( )" est "protected". Pourtant, la classe "Calendar" n'est ni une interface, ni une classe abstraite... ^
Je me garderais bien d'affirmer que Calendar n'est pas une classe abstraite.
-- Thomas
Oops, désolé, j'avais mal lu ma doc :-(
Merci de ta remarque.
"Thomas Luyt" <nospam@club-internet.fr> wrote in message
news:Xns9425F3FB49935tluytaediancominvali@194.158.104.32...
"GilloS" <toto@toto.com> wrote in news:bnu064$1ufd$1@news5.isdnet.net:
[...]
Autre exemple : Calendar.getInstance( )
Cette méthode statique renvoie un objet "Calendar" ; ici le
constructeur "Calendar( )" est "protected".
Pourtant, la classe "Calendar" n'est ni une interface, ni une classe
abstraite...
^
Je me garderais bien d'affirmer que Calendar n'est pas une classe
abstraite.
Cette méthode statique renvoie un objet "Calendar" ; ici le constructeur "Calendar( )" est "protected". Pourtant, la classe "Calendar" n'est ni une interface, ni une classe abstraite... ^
Je me garderais bien d'affirmer que Calendar n'est pas une classe abstraite.
