Première question: quel nom porte une telle classe ? En français et/ou
en anglais, c'est pour faire des recherches.
J'utilise les méthodes de la classe sans l'instancier, c'est normal. Ce
qui me chagrine un peu, c'est que je peux sans problème écrire:
MyDate md1 = new MyDate();
MyDate md2 = new MyDate();
J'imagine que l'effet est quasi nul, proche de la création d'un alias.
D'où ma seconde question: existe-t-il une façon de déclarer cet aspect
purement statique de la classe, qui ferait qu'elle ne soit pas
instanciable. En faire un singleton ne change rien, puisque par essence
c'est un genre de "zéroton".
C'est surtout par curiosité, je comprends bien que je sodomise un peu
le diptère ...
nota: setDateFormat(String fs) est là à des fins pédagogiques, on peut
l'oublier, il est clair que si je change la chaine de format le coté
static de la classe n'a plus vraiment de sens.
J'utilise les méthodes de la classe sans l'instancier, c'est normal. Ce qui me chagrine un peu, c'est que je peux sans problème écrire: MyDate md1 = new MyDate(); MyDate md2 = new MyDate(); J'imagine que l'effet est quasi nul, proche de la création d'un alias.
Hum, ca créé quand même des instances :(
D'où ma seconde question: existe-t-il une façon de déclarer cet aspect purement statique de la classe, qui ferait qu'elle ne soit pas instanciable. En faire un singleton ne change rien, puisque par essence c'est un genre de "zéroton". C'est surtout par curiosité, je comprends bien que je sodomise un peu le diptère ...
passe le constructeur par défaut private, et n'en colle pas d'autre.
Pour le nom que ce type de classe porte, désolé ca je ne sais pas.
Cordialement,
Patrice Trognon http://www.javadevel.com
Bonjour,
J'ai une classe entièrement static:
J'utilise les méthodes de la classe sans l'instancier, c'est normal. Ce
qui me chagrine un peu, c'est que je peux sans problème écrire:
MyDate md1 = new MyDate();
MyDate md2 = new MyDate();
J'imagine que l'effet est quasi nul, proche de la création d'un alias.
Hum, ca créé quand même des instances :(
D'où ma seconde question: existe-t-il une façon de déclarer cet aspect
purement statique de la classe, qui ferait qu'elle ne soit pas
instanciable. En faire un singleton ne change rien, puisque par essence
c'est un genre de "zéroton".
C'est surtout par curiosité, je comprends bien que je sodomise un peu le
diptère ...
passe le constructeur par défaut private, et n'en colle pas d'autre.
Pour le nom que ce type de classe porte, désolé ca je ne sais pas.
J'utilise les méthodes de la classe sans l'instancier, c'est normal. Ce qui me chagrine un peu, c'est que je peux sans problème écrire: MyDate md1 = new MyDate(); MyDate md2 = new MyDate(); J'imagine que l'effet est quasi nul, proche de la création d'un alias.
Hum, ca créé quand même des instances :(
D'où ma seconde question: existe-t-il une façon de déclarer cet aspect purement statique de la classe, qui ferait qu'elle ne soit pas instanciable. En faire un singleton ne change rien, puisque par essence c'est un genre de "zéroton". C'est surtout par curiosité, je comprends bien que je sodomise un peu le diptère ...
passe le constructeur par défaut private, et n'en colle pas d'autre.
Pour le nom que ce type de classe porte, désolé ca je ne sais pas.
Cordialement,
Patrice Trognon http://www.javadevel.com
David
Le Mon, 08 May 2006 11:34:30 +0200, Pierre Maurette a écrit :
J'utilise les méthodes de la classe sans l'instancier, c'est normal. Ce qui me chagrine un peu, c'est que je peux sans problème écrire: MyDate md1 = new MyDate(); MyDate md2 = new MyDate(); J'imagine que l'effet est quasi nul, proche de la création d'un alias. D'où ma seconde question: existe-t-il une façon de déclarer cet aspect
Tout d'abord il est opportun de déclarer ta classe en final pour éviter qu'on en hérite. Ensuite tu mets ton constructeur en private.
Le Mon, 08 May 2006 11:34:30 +0200, Pierre Maurette a écrit :
J'utilise les méthodes de la classe sans l'instancier, c'est normal. Ce
qui me chagrine un peu, c'est que je peux sans problème écrire:
MyDate md1 = new MyDate();
MyDate md2 = new MyDate();
J'imagine que l'effet est quasi nul, proche de la création d'un alias.
D'où ma seconde question: existe-t-il une façon de déclarer cet aspect
Tout d'abord il est opportun de déclarer ta classe en final pour éviter
qu'on en hérite. Ensuite tu mets ton constructeur en private.
Le Mon, 08 May 2006 11:34:30 +0200, Pierre Maurette a écrit :
J'utilise les méthodes de la classe sans l'instancier, c'est normal. Ce qui me chagrine un peu, c'est que je peux sans problème écrire: MyDate md1 = new MyDate(); MyDate md2 = new MyDate(); J'imagine que l'effet est quasi nul, proche de la création d'un alias. D'où ma seconde question: existe-t-il une façon de déclarer cet aspect
Tout d'abord il est opportun de déclarer ta classe en final pour éviter qu'on en hérite. Ensuite tu mets ton constructeur en private.
Pierre Maurette
Le Mon, 08 May 2006 11:34:30 +0200, Pierre Maurette a écrit :
J'utilise les méthodes de la classe sans l'instancier, c'est normal. Ce qui me chagrine un peu, c'est que je peux sans problème écrire: MyDate md1 = new MyDate(); MyDate md2 = new MyDate(); J'imagine que l'effet est quasi nul, proche de la création d'un alias. D'où ma seconde question: existe-t-il une façon de déclarer cet aspect
Tout d'abord il est opportun de déclarer ta classe en final pour éviter qu'on en hérite. Ensuite tu mets ton constructeur en private.
Merci à vous et à Patrice pour vos réponses et conseils que j'ai sans problème mis en application.
-- Pierre Maurette
Le Mon, 08 May 2006 11:34:30 +0200, Pierre Maurette a écrit :
J'utilise les méthodes de la classe sans l'instancier, c'est normal. Ce
qui me chagrine un peu, c'est que je peux sans problème écrire:
MyDate md1 = new MyDate();
MyDate md2 = new MyDate();
J'imagine que l'effet est quasi nul, proche de la création d'un alias.
D'où ma seconde question: existe-t-il une façon de déclarer cet aspect
Tout d'abord il est opportun de déclarer ta classe en final pour éviter
qu'on en hérite. Ensuite tu mets ton constructeur en private.
Merci à vous et à Patrice pour vos réponses et conseils que j'ai sans
problème mis en application.
Le Mon, 08 May 2006 11:34:30 +0200, Pierre Maurette a écrit :
J'utilise les méthodes de la classe sans l'instancier, c'est normal. Ce qui me chagrine un peu, c'est que je peux sans problème écrire: MyDate md1 = new MyDate(); MyDate md2 = new MyDate(); J'imagine que l'effet est quasi nul, proche de la création d'un alias. D'où ma seconde question: existe-t-il une façon de déclarer cet aspect
Tout d'abord il est opportun de déclarer ta classe en final pour éviter qu'on en hérite. Ensuite tu mets ton constructeur en private.
Merci à vous et à Patrice pour vos réponses et conseils que j'ai sans problème mis en application.
-- Pierre Maurette
Patrick
Première question: quel nom porte une telle classe ?
Un singleton?
Première question: quel nom porte une telle classe ?
Première question: quel nom porte une telle classe ?
Un singleton?
Pierre Maurette
Première question: quel nom porte une telle classe ?
Un singleton?
Avec ce que je comprends de la POO, il ne me semble pas. Telle quelle, avec le pattern "HH'H'mm" codé en dur, ce serait plutôt un zéroton ;-) c'est à dire une classe conteneur de méthodes statiques. L'instancier même une seule fois ne fait pas de mal mais n'a aucun sens. Je l'ai d'ailleurs empêché suite aux autres réponses.
En revanche, en faire un singleton serait sans doute une bonne idée. Je m'explique: le pattern "HH'H'mm" serait toujours une constante unique, mais centralisée au niveau de l'application. Je créerais donc une instance unique pendant les initialisations de l'appli.
-- Pierre Maurette
Première question: quel nom porte une telle classe ?
Un singleton?
Avec ce que je comprends de la POO, il ne me semble pas. Telle quelle,
avec le pattern "HH'H'mm" codé en dur, ce serait plutôt un zéroton ;-)
c'est à dire une classe conteneur de méthodes statiques. L'instancier
même une seule fois ne fait pas de mal mais n'a aucun sens. Je l'ai
d'ailleurs empêché suite aux autres réponses.
En revanche, en faire un singleton serait sans doute une bonne idée. Je
m'explique: le pattern "HH'H'mm" serait toujours une constante unique,
mais centralisée au niveau de l'application. Je créerais donc une
instance unique pendant les initialisations de l'appli.
Première question: quel nom porte une telle classe ?
Un singleton?
Avec ce que je comprends de la POO, il ne me semble pas. Telle quelle, avec le pattern "HH'H'mm" codé en dur, ce serait plutôt un zéroton ;-) c'est à dire une classe conteneur de méthodes statiques. L'instancier même une seule fois ne fait pas de mal mais n'a aucun sens. Je l'ai d'ailleurs empêché suite aux autres réponses.
En revanche, en faire un singleton serait sans doute une bonne idée. Je m'explique: le pattern "HH'H'mm" serait toujours une constante unique, mais centralisée au niveau de l'application. Je créerais donc une instance unique pendant les initialisations de l'appli.
-- Pierre Maurette
David JOURAND
Bonjour,
Première question: quel nom porte une telle classe ?
Un singleton?
Avec ce que je comprends de la POO, il ne me semble pas.
Exact, ce n'est pas un singleton qui est une classe qui ne peut être instanciée qu'une seule fois (il n'existe qu'un objet, instance de cette classe dans l'application).
Telle quelle, avec le pattern "HH'H'mm" codé en dur, ce serait plutôt un zéroton ;-)
Cela n'a rien à voir...
L'instancier même une seule fois ne fait pas de mal mais n'a aucun sens. Je l'ai d'ailleurs empêché suite aux autres réponses.
L'instancier coûte en mémoire et en temps, même si c'est probablement ridicule. C'est une classe utilitaire qui "casse" (sans préjugé si c'est "bien" ou "mal") le modèle objet et qui n'a donc probablement pas de nom en POO... Maintenant en pratique, j'appelle cela une classe statique bien qu'elle ne puisse pas être déclarée comme telle, "public static class MaClass" par exemple. C'est le genre de classe que l'on trouve également dans le core java, comme Math.
En revanche, en faire un singleton serait sans doute une bonne idée. Je m'explique: le pattern "HH'H'mm" serait toujours une constante unique, mais centralisée au niveau de l'application. Je créerais donc une instance unique pendant les initialisations de l'appli.
En faire un signleton n'apporterai rien... et le pattern "HH'H'mm" n'a toujours rien à voir avec le fait que l'on ait un signleton ou une classe "statique".
-- David Jourand
Bonjour,
Première question: quel nom porte une telle classe ?
Un singleton?
Avec ce que je comprends de la POO, il ne me semble pas.
Exact, ce n'est pas un singleton qui est une classe qui ne peut être
instanciée qu'une seule fois (il n'existe qu'un objet, instance de cette
classe dans l'application).
Telle quelle, avec le pattern "HH'H'mm" codé en dur, ce serait plutôt
un zéroton ;-)
Cela n'a rien à voir...
L'instancier même une seule fois ne fait pas de mal mais n'a aucun
sens. Je l'ai d'ailleurs empêché suite aux autres réponses.
L'instancier coûte en mémoire et en temps, même si c'est probablement
ridicule.
C'est une classe utilitaire qui "casse" (sans préjugé si c'est "bien" ou
"mal") le modèle objet et qui n'a donc probablement pas de nom en POO...
Maintenant en pratique, j'appelle cela une classe statique bien qu'elle ne
puisse pas être déclarée comme telle, "public static class MaClass" par
exemple. C'est le genre de classe que l'on trouve également dans le core
java, comme Math.
En revanche, en faire un singleton serait sans doute une bonne idée. Je
m'explique: le pattern "HH'H'mm" serait toujours une constante unique,
mais centralisée au niveau de l'application. Je créerais donc une
instance unique pendant les initialisations de l'appli.
En faire un signleton n'apporterai rien... et le pattern "HH'H'mm" n'a
toujours rien à voir avec le fait que l'on ait un signleton ou une
classe "statique".
Première question: quel nom porte une telle classe ?
Un singleton?
Avec ce que je comprends de la POO, il ne me semble pas.
Exact, ce n'est pas un singleton qui est une classe qui ne peut être instanciée qu'une seule fois (il n'existe qu'un objet, instance de cette classe dans l'application).
Telle quelle, avec le pattern "HH'H'mm" codé en dur, ce serait plutôt un zéroton ;-)
Cela n'a rien à voir...
L'instancier même une seule fois ne fait pas de mal mais n'a aucun sens. Je l'ai d'ailleurs empêché suite aux autres réponses.
L'instancier coûte en mémoire et en temps, même si c'est probablement ridicule. C'est une classe utilitaire qui "casse" (sans préjugé si c'est "bien" ou "mal") le modèle objet et qui n'a donc probablement pas de nom en POO... Maintenant en pratique, j'appelle cela une classe statique bien qu'elle ne puisse pas être déclarée comme telle, "public static class MaClass" par exemple. C'est le genre de classe que l'on trouve également dans le core java, comme Math.
En revanche, en faire un singleton serait sans doute une bonne idée. Je m'explique: le pattern "HH'H'mm" serait toujours une constante unique, mais centralisée au niveau de l'application. Je créerais donc une instance unique pendant les initialisations de l'appli.
En faire un signleton n'apporterai rien... et le pattern "HH'H'mm" n'a toujours rien à voir avec le fait que l'on ait un signleton ou une classe "statique".
-- David Jourand
Pierre Maurette
Bonjour,
Première question: quel nom porte une telle classe ?
Un singleton?
Avec ce que je comprends de la POO, il ne me semble pas.
Exact, ce n'est pas un singleton qui est une classe qui ne peut être instanciée qu'une seule fois (il n'existe qu'un objet, instance de cette classe dans l'application).
Telle quelle, avec le pattern "HH'H'mm" codé en dur, ce serait plutôt un zéroton ;-)
Cela n'a rien à voir...
Je me suis sans doute mal exprimé. Telle que j'ai posté la classe, avec le pattern codé en dur dans la classe, je n'ai pas besoin d'instancier et je dois même l'éviter, et c'est ce comportement que j'appelle un "zéroton ;-)", le rigolard faisant partie du nom.
L'instancier même une seule fois ne fait pas de mal mais n'a aucun sens. Je l'ai d'ailleurs empêché suite aux autres réponses.
L'instancier coûte en mémoire et en temps, même si c'est probablement ridicule. C'est une classe utilitaire qui "casse" (sans préjugé si c'est "bien" ou "mal") le modèle objet et qui n'a donc probablement pas de nom en POO... Maintenant en pratique, j'appelle cela une classe statique bien qu'elle ne puisse pas être déclarée comme telle, "public static class MaClass" par exemple. C'est le genre de classe que l'on trouve également dans le core java, comme Math.
J'avais lu ça quelque part. Si j'ai besoin de nommer le machin, j'utiliserai votre suggestion de "classe statique".
En revanche, en faire un singleton serait sans doute une bonne idée. Je m'explique: le pattern "HH'H'mm" serait toujours une constante unique, mais centralisée au niveau de l'application. Je créerais donc une instance unique pendant les initialisations de l'appli.
En faire un signleton n'apporterai rien... et le pattern "HH'H'mm" n'a toujours rien à voir avec le fait que l'on ait un signleton ou une classe "statique".
J'en ai fait un singleton sur la base de: <code> public final class MyDate { private static SimpleDateFormat myDateHeureFormat_; private static MyDate instance;
/** * Crée l'instance unique de la classe singleton MyDate<p> * Remarque : le constructeur est rendu inaccessible */ public static void init(String s) { if (null == instance) { // Premier appel instance = new MyDate(s); } /** * Dans cette version, si on appelle une seconde fois init() rien ne se * passe. En particulier quand la seconde chaîne s est différente de la * première, c'est assez gênant. * * @todo gérer le cas d'un second appel */ }
/** * Constructeur appelé une seule fois par init() * * @param s String : pattern */ private MyDate(String s) { myDateHeureFormat_ = new SimpleDateFormat(s); } </code>
Effectivement comme actruellement la chaîne passée lors des zinites est dans une classe interface de paramètres "application", ça n'apporte rien. Mais quand ces paramètres seront lus dans un fichier, ce sera différent.
-- Pierre Maurette
Bonjour,
Première question: quel nom porte une telle classe ?
Un singleton?
Avec ce que je comprends de la POO, il ne me semble pas.
Exact, ce n'est pas un singleton qui est une classe qui ne peut être
instanciée qu'une seule fois (il n'existe qu'un objet, instance de cette
classe dans l'application).
Telle quelle, avec le pattern "HH'H'mm" codé en dur, ce serait plutôt
un zéroton ;-)
Cela n'a rien à voir...
Je me suis sans doute mal exprimé. Telle que j'ai posté la classe, avec
le pattern codé en dur dans la classe, je n'ai pas besoin d'instancier
et je dois même l'éviter, et c'est ce comportement que j'appelle un
"zéroton ;-)", le rigolard faisant partie du nom.
L'instancier même une seule fois ne fait pas de mal mais n'a aucun
sens. Je l'ai d'ailleurs empêché suite aux autres réponses.
L'instancier coûte en mémoire et en temps, même si c'est probablement
ridicule.
C'est une classe utilitaire qui "casse" (sans préjugé si c'est "bien" ou
"mal") le modèle objet et qui n'a donc probablement pas de nom en POO...
Maintenant en pratique, j'appelle cela une classe statique bien qu'elle ne
puisse pas être déclarée comme telle, "public static class MaClass" par
exemple. C'est le genre de classe que l'on trouve également dans le core
java, comme Math.
J'avais lu ça quelque part. Si j'ai besoin de nommer le machin,
j'utiliserai votre suggestion de "classe statique".
En revanche, en faire un singleton serait sans doute une bonne idée. Je
m'explique: le pattern "HH'H'mm" serait toujours une constante unique,
mais centralisée au niveau de l'application. Je créerais donc une
instance unique pendant les initialisations de l'appli.
En faire un signleton n'apporterai rien... et le pattern "HH'H'mm" n'a
toujours rien à voir avec le fait que l'on ait un signleton ou une
classe "statique".
J'en ai fait un singleton sur la base de:
<code>
public final class MyDate {
private static SimpleDateFormat myDateHeureFormat_;
private static MyDate instance;
/**
* Crée l'instance unique de la classe singleton MyDate<p>
* Remarque : le constructeur est rendu inaccessible
*/
public static void init(String s) {
if (null == instance) { // Premier appel
instance = new MyDate(s);
}
/**
* Dans cette version, si on appelle une seconde fois init() rien
ne se
* passe. En particulier quand la seconde chaîne s est différente
de la
* première, c'est assez gênant.
*
* @todo gérer le cas d'un second appel
*/
}
/**
* Constructeur appelé une seule fois par init()
*
* @param s String : pattern
*/
private MyDate(String s) {
myDateHeureFormat_ = new SimpleDateFormat(s);
}
</code>
Effectivement comme actruellement la chaîne passée lors des zinites est
dans une classe interface de paramètres "application", ça n'apporte
rien. Mais quand ces paramètres seront lus dans un fichier, ce sera
différent.
Première question: quel nom porte une telle classe ?
Un singleton?
Avec ce que je comprends de la POO, il ne me semble pas.
Exact, ce n'est pas un singleton qui est une classe qui ne peut être instanciée qu'une seule fois (il n'existe qu'un objet, instance de cette classe dans l'application).
Telle quelle, avec le pattern "HH'H'mm" codé en dur, ce serait plutôt un zéroton ;-)
Cela n'a rien à voir...
Je me suis sans doute mal exprimé. Telle que j'ai posté la classe, avec le pattern codé en dur dans la classe, je n'ai pas besoin d'instancier et je dois même l'éviter, et c'est ce comportement que j'appelle un "zéroton ;-)", le rigolard faisant partie du nom.
L'instancier même une seule fois ne fait pas de mal mais n'a aucun sens. Je l'ai d'ailleurs empêché suite aux autres réponses.
L'instancier coûte en mémoire et en temps, même si c'est probablement ridicule. C'est une classe utilitaire qui "casse" (sans préjugé si c'est "bien" ou "mal") le modèle objet et qui n'a donc probablement pas de nom en POO... Maintenant en pratique, j'appelle cela une classe statique bien qu'elle ne puisse pas être déclarée comme telle, "public static class MaClass" par exemple. C'est le genre de classe que l'on trouve également dans le core java, comme Math.
J'avais lu ça quelque part. Si j'ai besoin de nommer le machin, j'utiliserai votre suggestion de "classe statique".
En revanche, en faire un singleton serait sans doute une bonne idée. Je m'explique: le pattern "HH'H'mm" serait toujours une constante unique, mais centralisée au niveau de l'application. Je créerais donc une instance unique pendant les initialisations de l'appli.
En faire un signleton n'apporterai rien... et le pattern "HH'H'mm" n'a toujours rien à voir avec le fait que l'on ait un signleton ou une classe "statique".
J'en ai fait un singleton sur la base de: <code> public final class MyDate { private static SimpleDateFormat myDateHeureFormat_; private static MyDate instance;
/** * Crée l'instance unique de la classe singleton MyDate<p> * Remarque : le constructeur est rendu inaccessible */ public static void init(String s) { if (null == instance) { // Premier appel instance = new MyDate(s); } /** * Dans cette version, si on appelle une seconde fois init() rien ne se * passe. En particulier quand la seconde chaîne s est différente de la * première, c'est assez gênant. * * @todo gérer le cas d'un second appel */ }
/** * Constructeur appelé une seule fois par init() * * @param s String : pattern */ private MyDate(String s) { myDateHeureFormat_ = new SimpleDateFormat(s); } </code>
Effectivement comme actruellement la chaîne passée lors des zinites est dans une classe interface de paramètres "application", ça n'apporte rien. Mais quand ces paramètres seront lus dans un fichier, ce sera différent.
-- Pierre Maurette
David JOURAND
Je me suis sans doute mal exprimé. Telle que j'ai posté la classe, avec le pattern codé en dur dans la classe, je n'ai pas besoin d'instancier et je dois même l'éviter, et c'est ce comportement que j'appelle un "zéroton ;-)", le rigolard faisant partie du nom.
Je n'avais pas compris ;) [je ne suis pas très doué en rigolards !]
Effectivement comme actruellement la chaîne passée lors des zinites est dans une classe interface de paramètres "application", ça n'apporte rien. Mais quand ces paramètres seront lus dans un fichier, ce sera différent.
Là il faudrait voir l'architecture globale de l'application... Avez-vous regardé du côté des framework comment c'était fait ?
-- David Jourand
Je me suis sans doute mal exprimé. Telle que j'ai posté la classe, avec
le pattern codé en dur dans la classe, je n'ai pas besoin d'instancier
et je dois même l'éviter, et c'est ce comportement que j'appelle un
"zéroton ;-)", le rigolard faisant partie du nom.
Je n'avais pas compris ;) [je ne suis pas très doué en rigolards !]
Effectivement comme actruellement la chaîne passée lors des zinites est
dans une classe interface de paramètres "application", ça n'apporte
rien. Mais quand ces paramètres seront lus dans un fichier, ce sera
différent.
Là il faudrait voir l'architecture globale de l'application... Avez-vous
regardé du côté des framework comment c'était fait ?
Je me suis sans doute mal exprimé. Telle que j'ai posté la classe, avec le pattern codé en dur dans la classe, je n'ai pas besoin d'instancier et je dois même l'éviter, et c'est ce comportement que j'appelle un "zéroton ;-)", le rigolard faisant partie du nom.
Je n'avais pas compris ;) [je ne suis pas très doué en rigolards !]
Effectivement comme actruellement la chaîne passée lors des zinites est dans une classe interface de paramètres "application", ça n'apporte rien. Mais quand ces paramètres seront lus dans un fichier, ce sera différent.
Là il faudrait voir l'architecture globale de l'application... Avez-vous regardé du côté des framework comment c'était fait ?
-- David Jourand
Patrice Trognon
[...]
Je me suis sans doute mal exprimé. Telle que j'ai posté la classe, avec le pattern codé en dur dans la classe, je n'ai pas besoin d'instancier et je dois même l'éviter, et c'est ce comportement que j'appelle un "zéroton ;-)", le rigolard faisant partie du nom.
un trollotron ? (sic)
Patrice Trognon. http://www.javadevel.com
[...]
Je me suis sans doute mal exprimé. Telle que j'ai posté la classe, avec
le pattern codé en dur dans la classe, je n'ai pas besoin d'instancier
et je dois même l'éviter, et c'est ce comportement que j'appelle un
"zéroton ;-)", le rigolard faisant partie du nom.
Je me suis sans doute mal exprimé. Telle que j'ai posté la classe, avec le pattern codé en dur dans la classe, je n'ai pas besoin d'instancier et je dois même l'éviter, et c'est ce comportement que j'appelle un "zéroton ;-)", le rigolard faisant partie du nom.
un trollotron ? (sic)
Patrice Trognon. http://www.javadevel.com
Pierre Maurette
Je me suis sans doute mal exprimé. Telle que j'ai posté la classe, avec le pattern codé en dur dans la classe, je n'ai pas besoin d'instancier et je dois même l'éviter, et c'est ce comportement que j'appelle un "zéroton ;-)", le rigolard faisant partie du nom.
Je n'avais pas compris ;) [je ne suis pas très doué en rigolards !]
Effectivement comme actruellement la chaîne passée lors des zinites est dans une classe interface de paramètres "application", ça n'apporte rien. Mais quand ces paramètres seront lus dans un fichier, ce sera différent.
Là il faudrait voir l'architecture globale de l'application... Avez-vous regardé du côté des framework comment c'était fait ?
Non. En fait comme je l'expliquais dans un autre fil, c'est un projet de mon fils étudiant que je "corrige" (et je faisais allusion à une histoire d'aveugles conduisant d'autres aveugles). Il y a donc avantage à tester plusieurs solutions, par exemple c'est bien qu'il y ait une classe singleton dans le projet.
Maintenant, je suis au coeur du problème et c'est coton, surtout que c'est déjà codé à la cosaque, en premier jet. Il s'agit de la simulation d'un tableau d'affichage. On doit voir les points s'allumer un par un, mais ce qui coince c'est qu'il y a des Thread.sleep(TEMPORISATION); dans la méthode paint() et c'est pas beau quand ça rafraîchit.
-- Pierre Maurette
Je me suis sans doute mal exprimé. Telle que j'ai posté la classe, avec
le pattern codé en dur dans la classe, je n'ai pas besoin d'instancier
et je dois même l'éviter, et c'est ce comportement que j'appelle un
"zéroton ;-)", le rigolard faisant partie du nom.
Je n'avais pas compris ;) [je ne suis pas très doué en rigolards !]
Effectivement comme actruellement la chaîne passée lors des zinites est
dans une classe interface de paramètres "application", ça n'apporte
rien. Mais quand ces paramètres seront lus dans un fichier, ce sera
différent.
Là il faudrait voir l'architecture globale de l'application... Avez-vous
regardé du côté des framework comment c'était fait ?
Non. En fait comme je l'expliquais dans un autre fil, c'est un projet
de mon fils étudiant que je "corrige" (et je faisais allusion à une
histoire d'aveugles conduisant d'autres aveugles). Il y a donc avantage
à tester plusieurs solutions, par exemple c'est bien qu'il y ait une
classe singleton dans le projet.
Maintenant, je suis au coeur du problème et c'est coton, surtout que
c'est déjà codé à la cosaque, en premier jet. Il s'agit de la
simulation d'un tableau d'affichage. On doit voir les points s'allumer
un par un, mais ce qui coince c'est qu'il y a des
Thread.sleep(TEMPORISATION); dans la méthode paint() et c'est pas beau
quand ça rafraîchit.
Je me suis sans doute mal exprimé. Telle que j'ai posté la classe, avec le pattern codé en dur dans la classe, je n'ai pas besoin d'instancier et je dois même l'éviter, et c'est ce comportement que j'appelle un "zéroton ;-)", le rigolard faisant partie du nom.
Je n'avais pas compris ;) [je ne suis pas très doué en rigolards !]
Effectivement comme actruellement la chaîne passée lors des zinites est dans une classe interface de paramètres "application", ça n'apporte rien. Mais quand ces paramètres seront lus dans un fichier, ce sera différent.
Là il faudrait voir l'architecture globale de l'application... Avez-vous regardé du côté des framework comment c'était fait ?
Non. En fait comme je l'expliquais dans un autre fil, c'est un projet de mon fils étudiant que je "corrige" (et je faisais allusion à une histoire d'aveugles conduisant d'autres aveugles). Il y a donc avantage à tester plusieurs solutions, par exemple c'est bien qu'il y ait une classe singleton dans le projet.
Maintenant, je suis au coeur du problème et c'est coton, surtout que c'est déjà codé à la cosaque, en premier jet. Il s'agit de la simulation d'un tableau d'affichage. On doit voir les points s'allumer un par un, mais ce qui coince c'est qu'il y a des Thread.sleep(TEMPORISATION); dans la méthode paint() et c'est pas beau quand ça rafraîchit.
