Accueil -|- Visuel -|- Logistique -|- Applications réparties
| La pseudo-archive
Java est un service proposé par la SARL diaam informatique,
et il est hébergé par la
Sogid.
|
 |
| Pseudo-Archive Java : Accueil -|- Visuel -|- Logistique -|- Applications réparties |
|
||
|
|||
From: "Nicolas Delsaux" <nicolas.delsaux@free.fr> To: <java@u-strasbg.fr> Subject: Interfaces et methodes protected Date sent: Mon, 15 Oct 2001 11:00:31 +0200 Send reply to: java@u-strasbg.fr Salut, Ca fait plusieurs fois que je rencontre le problème, et à chaque fois, j'en suis très peu satisfait : Suivant les spécifications de Java, il est impossible dans une interface de définir une méthode protected ou private. Autant, dans le cas d'une méthode private, je comprends le sens de la chose, mais pour protected, j'ai un peu plus de mal : protected garantit que la méthode soit visible dans le package entier, et permet donc de définir au sein de ce package des interfaces d'utilisation qui lui soient locales, c'est-à-dire non visibles de l'extérieur. Par conséquent, j'aimerais, une fois de temps en temps, définir des interfaces dans lesquelles les méthodes soient protected. Or Java me l'interdit. Alors quoi ? J'ai loupé un concept important lié à l'utilisation de méthodes protected ou les spécifications de Java ne correspondent pas à mes besoins ? Nicolas Delsaux
From: ROUSSEL Yohann <yohann.roussel@criltelecom.com> To: "'java@u-strasbg.fr'" <java@u-strasbg.fr> Subject: RE: Interfaces et methodes protected Date sent: Mon, 15 Oct 2001 11:08:28 +0200 Send reply to: java@u-strasbg.fr une methode protected est libre d'acces pour le reste du package ? -----Message d'origine----- De : Nicolas Delsaux [mailto:nicolas.delsaux@free.fr] Envoyé : lundi 15 octobre 2001 11:01 À : java@u-strasbg.fr Objet : Interfaces et methodes protected Salut, Ca fait plusieurs fois que je rencontre le problème, et à chaque fois, j'en suis très peu satisfait : Suivant les spécifications de Java, il est impossible dans une interface de définir une méthode protected ou private. Autant, dans le cas d'une méthode private, je comprends le sens de la chose, mais pour protected, j'ai un peu plus de mal : protected garantit que la méthode soit visible dans le package entier, et permet donc de définir au sein de ce package des interfaces d'utilisation qui lui soient locales, c'est-à-dire non visibles de l'extérieur. Par conséquent, j'aimerais, une fois de temps en temps, définir des interfaces dans lesquelles les méthodes soient protected. Or Java me l'interdit. Alors quoi ? J'ai loupé un concept important lié à l'utilisation de méthodes protected ou les spécifications de Java ne correspondent pas à mes besoins ? Nicolas Delsaux
Date sent: Mon, 15 Oct 2001 11:15:43 +0200 From: Jerome Moliere <moliere@viveo-montpellier.com> To: java@u-strasbg.fr Subject: Re: Interfaces et methodes protected Send reply to: java@u-strasbg.fr Nicolas Delsaux wrote: >Salut, >Ca fait plusieurs fois que je rencontre le problème, et à chaque fois, >j'en suis très peu satisfait : Suivant les spécifications de Java, il est >impossible dans une interface de définir une méthode protected ou >private. Autant, dans le cas d'une méthode private, je comprends le sens >de la chose, mais pour protected, j'ai un peu plus de mal : protected >garantit que la méthode soit visible dans le package entier, et permet >donc de définir au sein de ce package des interfaces d'utilisation qui >lui soient locales, c'est-à-dire non visibles de l'extérieur. Par >conséquent, j'aimerais, une fois de temps en temps, définir des >interfaces dans lesquelles les méthodes soient protected. Or Java me >l'interdit. Alors quoi ? J'ai loupé un concept important lié à >l'utilisation de méthodes protected ou les spécifications de Java ne >correspondent pas à mes besoins ? > si je puis me permettre le concept important que tu as peut etre loupe est surement celui de l'interface: une interface n'existe que pour declarer des services!!! or un service se doit d'etre public , et donc une interface ne te permet pas de declarer une methode protected et heureusement selon moi.... je rajouterai que le probleme selon moi avec l'implementation de Sun provient de la possibilite de declarer des attributes...cela ne sert a rien et ne fait que violer l'encapsulation... Jerome
From: Gloom <gloom@codeshebang.org>
Send reply to: gloom@codeshebang.org
To: java@u-strasbg.fr
Subject: Re: Interfaces et methodes protected
Date sent: Mon, 15 Oct 2001 11:15:13 +0200
Le Lundi 15 Octobre 2001 11:00, vous avez écrit :
> Salut,
hello
> Ca fait plusieurs fois que je rencontre le problème, et à chaque fois,
> j'en suis très peu satisfait : Suivant les spécifications de Java, il
> est impossible dans une interface de définir une méthode protected ou
> private. Autant, dans le cas d'une méthode private, je comprends le sens
> de la chose, mais pour protected, j'ai un peu plus de mal : protected
> garantit que la méthode soit visible dans le package entier, et permet
> donc de définir au sein de ce package des interfaces d'utilisation qui
> lui soient locales, c'est-à-dire non visibles de l'extérieur. Par
> conséquent, j'aimerais, une fois de temps en temps, définir des
> interfaces dans lesquelles les méthodes soient protected. Or Java me
> l'interdit. Alors quoi ? J'ai loupé un concept important lié à
> l'utilisation de méthodes protected ou les spécifications de Java ne
> correspondent pas à mes besoins ?
>
> Nicolas Delsaux
En fait tu peut définir une methode sans modificateur, qui elle à vraiment
un vision de niveau package :
public interface Test {
public void method1() {} // visibilité globale
void method2() {} // visibilité package
}
Le modificateur protected inclu une vision package + un vision pour les
classes qui en heritent sans être dans le package. Note donc que le
supléments concernant l'héritage n'a pas de raison d'être dans une
interface, d'où la contrainte.
Si tu a besoin de préciser des methode sans corp que devrons implémenter
les sous-classes de la classes que tu fait, penche toi plutot vers les
class abstraite avec methodes abstraites.
Gloom
From: "Thibaut Fagart" <tfagart@soleri.com> To: <java@u-strasbg.fr> Subject: RE: Interfaces et methodes protected Date sent: Mon, 15 Oct 2001 11:21:39 +0200 Send reply to: java@u-strasbg.fr plus exactement, protected, est un "surdroit" de package, qui permet EN PLUS l'acces aux sous classes -----Message d'origine----- De : ROUSSEL Yohann [mailto:yohann.roussel@criltelecom.com] Envoyé : lundi 15 octobre 2001 11:08 À : 'java@u-strasbg.fr' Objet : RE: Interfaces et methodes protected une methode protected est libre d'acces pour le reste du package ? -----Message d'origine----- De : Nicolas Delsaux [mailto:nicolas.delsaux@free.fr] Envoyé : lundi 15 octobre 2001 11:01 À : java@u-strasbg.fr Objet : Interfaces et methodes protected Salut, Ca fait plusieurs fois que je rencontre le problème, et à chaque fois, j'en suis très peu satisfait : Suivant les spécifications de Java, il est impossible dans une interface de définir une méthode protected ou private. Autant, dans le cas d'une méthode private, je comprends le sens de la chose, mais pour protected, j'ai un peu plus de mal : protected garantit que la méthode soit visible dans le package entier, et permet donc de définir au sein de ce package des interfaces d'utilisation qui lui soient locales, c'est-à-dire non visibles de l'extérieur. Par conséquent, j'aimerais, une fois de temps en temps, définir des interfaces dans lesquelles les méthodes soient protected. Or Java me l'interdit. Alors quoi ? J'ai loupé un concept important lié à l'utilisation de méthodes protected ou les spécifications de Java ne correspondent pas à mes besoins ? Nicolas Delsaux
From: "Nicolas Delsaux" <nicolas.delsaux@free.fr>
To: <java@u-strasbg.fr>
Subject: Re: Interfaces et methodes protected
Date sent: Mon, 15 Oct 2001 11:26:33 +0200
Send reply to: java@u-strasbg.fr
----- Original Message -----
From: "Gloom" <gloom@codeshebang.org>
To: <java@u-strasbg.fr>
Sent: Monday, October 15, 2001 11:15 AM
Subject: Re: Interfaces et methodes protected
>
> hello
et l'huile
>
> En fait tu peut définir une methode sans modificateur, qui elle à
> vraiment
un
> vision de niveau package :
>
> public interface Test {
> public void method1() {} // visibilité globale
> void method2() {} // visibilité package
> }
>
> Le modificateur protected inclu une vision package + un vision pour les
> classes qui en heritent sans être dans le package. Note donc que le
> supléments concernant l'héritage n'a pas de raison d'être dans une
interface,
> d'où la contrainte.
??? pas tout compris là, tu peux réexpliquer comme si tu paorlais à un
enfant de deux ans ? > > Si tu a besoin de préciser des methode sans corp
que devrons implémenter les > sous-classes de la classes que tu fait,
penche toi plutot vers les class > abstraite avec methodes abstraites.
Oui, je l'ai déja fait, justement dans les cas précédents où j'avais déja
rencontré ce type de problème, mais c'est une méthode qui me convient très
peu, car elle me semble peu compatible avec la séparation définition de
contrat/implémentation que fournit justement l'utilisation d'interfaces.
De plus, on ne peut plus alors faire dériver les classes remplissant ce
contrat de classes autres, ce qui est très génant, du moins en théorie. >
> Gloom > Nicolas Delsaux
From: "Thibaut Fagart" <tfagart@soleri.com> To: <java@u-strasbg.fr> Subject: RE: Interfaces et methodes protected Date sent: Mon, 15 Oct 2001 11:31:58 +0200 Send reply to: java@u-strasbg.fr Comme le dit Jerome, En general on utilise des interfaces pour des declarations de service. Ces services permettent a des classes (clientes) de s'abstraire de l'identité du fournisseur de services, autorisant de changer la classe d'implementation avec peu ou pas d'impact sur les classes clientes. A partir du moment ou tu ETENDS une classe tu connais son identité, et donc l'interface ne t'apportes plus rien ... Par contre, tu ne peux declarer de methodes package dans une interface, que tu specifie opu pas le modificateur d'acces, elles seront toutes publiques. -----Message d'origine----- De : Jerome Moliere [mailto:moliere@viveo-montpellier.com] Envoyé : lundi 15 octobre 2001 11:16 À : java@u-strasbg.fr Objet : Re: Interfaces et methodes protected Nicolas Delsaux wrote: >Salut, >Ca fait plusieurs fois que je rencontre le problème, et à chaque fois, >j'en suis très peu satisfait : Suivant les spécifications de Java, il est >impossible dans une interface de définir une méthode protected ou >private. Autant, dans le cas d'une méthode private, je comprends le sens >de la chose, mais pour protected, j'ai un peu plus de mal : protected >garantit que la méthode soit visible dans le package >entier, et permet donc de définir au sein de ce package des interfaces >d'utilisation qui lui soient locales, c'est-à-dire non visibles de >l'extérieur. Par conséquent, j'aimerais, une fois de temps en temps, définir >des interfaces dans lesquelles les méthodes soient protected. >Or Java me l'interdit. Alors quoi ? J'ai loupé un concept important lié à >l'utilisation de méthodes protected ou les spécifications de Java ne >correspondent pas à mes besoins ? > si je puis me permettre le concept important que tu as peut etre loupe est surement celui de l'interface: une interface n'existe que pour declarer des services!!! or un service se doit d'etre public , et donc une interface ne te permet pas de declarer une methode protected et heureusement selon moi.... je rajouterai que le probleme selon moi avec l'implementation de Sun provient de la possibilite de declarer des attributes...cela ne sert a rien et ne fait que violer l'encapsulation... Jerome
Date sent: Mon, 15 Oct 2001 11:43:56 +0200
From: Remi Forax <forax@univ-mlv.fr>
To: gloom@codeshebang.org, javalist <java@u-strasbg.fr>
Subject: Re: Interfaces et methodes protected
Send reply to: java@u-strasbg.fr
Gloom wrote:
> En fait tu peut définir une methode sans modificateur, qui elle à
> vraiment un vision de niveau package :
>
> public interface Test {
> public void method1() {} // visibilité globale
> void method2() {} // visibilité package
Et non, c'est un piege de la specification Java.
Une méthode déclarée dans une interface est automatiquement
public et abstract.
> }
...
> Gloom
>
Remi
To: gloom@codeshebang.org Copies to: java@u-strasbg.fr Subject: Re: Interfaces et methodes protected From: Jean-Yves Pere <toga.kiryu@free.fr> Organization: Ohtori Academy Date sent: Mon, 15 Oct 2001 11:49:18 +0200 Send reply to: java@u-strasbg.fr Gloom <gloom@codeshebang.org> writes: > Le Lundi 15 Octobre 2001 11:00, vous avez écrit : > > Salut, > > hello Bonjour `tous, > > En fait tu peut définir une methode sans modificateur, qui elle à > vraiment un vision de niveau package : Dans les interfaces, ne pas mettre d'accesseur aux membres de l'interface revient à les déclarer implicitement public. cf http://java.sun.com/docs/books/jls/second_edition/html/nterfaces.doc.html 9.1.4 -- >Une RedHat (je ne connais pas les autres distributions) ce configure >aussi simplement que windows pour un poste client. Hélas, elle génère un maximum de traffic sur Usenet -+- TP in guide du linuxien pervers - "Je veux revoir ma SLS ! -+-
Date sent: Mon, 15 Oct 2001 12:12:24 +0200
From: Guillaume Desnoix <guillaume@desnoix.com>
To: java@u-strasbg.fr
Subject: Re: Interfaces et methodes protected
Send reply to: java@u-strasbg.fr
Nicolas Delsaux:
> Ca fait plusieurs fois que je rencontre le problème, et à chaque fois,
> j'en suis très peu satisfait : Suivant les spécifications de Java, il
> est impossible dans une interface de définir une méthode protected ou
> private. Autant, dans le cas d'une méthode private, je comprends le sens
> de la chose, mais pour protected, j'ai un peu plus de mal : protected
> garantit que la méthode soit visible dans le package entier, et permet
> donc de définir au sein de ce package des interfaces d'utilisation qui
> lui soient locales, c'est-à-dire non visibles de l'extérieur. Par
> conséquent, j'aimerais, une fois de temps en temps, définir des
> interfaces dans lesquelles les méthodes soient protected. Or Java me
> l'interdit. Alors quoi ? J'ai loupé un concept important lié à
> l'utilisation de méthodes protected ou les spécifications de Java ne
> correspondent pas à mes besoins ?
Grace aux classes internes, tu as la possibilite de definir des
interfaces de paquet. C'est a priori une solution a ton probleme meme si
je ne recommande pas son usage.
package MonPaquet;
public class MesInterfaces
{
static interface MonInterface
{
void hello();
}
}
Guillaume
Date sent: Mon, 15 Oct 2001 12:28:26 +0200 (MEST) From: koutch <koutch@shom.fr> Send reply to: koutch <koutch@shom.fr> Subject: Re: Interfaces et methodes protected To: java@u-strasbg.fr Salut, >Grace aux classes internes, tu as la possibilite de definir des >interfaces de paquet. C'est a priori une solution a ton probleme meme si >je ne recommande pas son usage. Que pense tu alors de l'interface Highlighter.HighlightPainter ? http://java.sun.com/j2se/1.3/docs/api/javax/swing/text/Highlighter.HighlightPainter.html Une interface interne à la classe Highlighter qu'on est bien obligé d'implémenter pour faire son propre Highlighter... Rémi
Date sent: Mon, 15 Oct 2001 13:00:39 +0200
From: Guillaume Desnoix <guillaume@desnoix.com>
To: koutch <koutch@shom.fr>, java@u-strasbg.fr
Subject: Re: Interfaces et methodes protected
Send reply to: java@u-strasbg.fr
Salut,
>> Grace aux classes internes, tu as la possibilite de definir des
>> interfaces de paquet. C'est a priori une solution a ton probleme meme
>> si je ne recommande pas son usage.
koutch:
> Que pense tu alors de l'interface Highlighter.HighlightPainter ?
> Une interface interne à la classe Highlighter qu'on est bien obligé
> d'implémenter pour faire son propre Highlighter...
Beaucoup de mal ;-). Dans la mesure ou cette interface est publique, il
n'y a aucune raison de la rendre interne. Il s'agit alors juste d'une
question d'espace de nommage et je ne pense pas qu'on devrait utiliser les
classes internes dans ce but.
PS: dans le code precedement poste, le mot-clef static est superflu,
toutes les interfaces etant static par definition.
Autre sujet mais en relation, on peut definir des classes a l'interieur
d'une methode (j'ai decouvert ca dans les sources du JDK il n'y a pas
longtemps).
public class Hello
{
public static void hello()
{
class Bye { }
}
}
Et ca donne en sortie Hello$1$Bye.class . Genial, non ;-)))
Guillaume
From: "Nicolas Delsaux" <nicolas.delsaux@free.fr> To: <java@u-strasbg.fr> Subject: Re: Interfaces et methodes protected Date sent: Mon, 15 Oct 2001 13:52:51 +0200 Send reply to: java@u-strasbg.fr ----- Original Message ----- From: "Jerome Moliere" <moliere@viveo-montpellier.com> To: <java@u-strasbg.fr> Sent: Monday, October 15, 2001 11:15 AM Subject: Re: Interfaces et methodes protected > si je puis me permettre le concept important que tu as peut etre loupe > est surement celui de l'interface: une interface n'existe que pour > declarer des services!!! Ca, je l'avais bien compris. Déclarer un service ne revient-il pas à déclarer que la classe l'implémenter remplit un contrat : elle est utilisable dans un contexte précis, et effectue dans ce contexte une tâche grâce à différentes opérations spécifiées. > or un service > se doit d'etre public , et donc une interface ne te permet pas > de declarer une methode protected et heureusement selon moi.... Si je suis ta logique, l'interface ne permet pas de déclaration protected car il ne s'agit plus alors d'un service public, mais d'un service privé. Ne s'agit-il pas d'une clarification du modèle objet ? > je rajouterai que le probleme selon moi avec l'implementation de Sun > provient de la possibilite de declarer des attributes...cela ne sert a > rien et ne fait que violer l'encapsulation... > Foula, on change de sujet là. Mais c'est vrai que les déclaration d'attributs dans une interface ressemblent plus à une magouille visant à cacher un peu de l'implémentation dans une interface pour qu'en bénéficient toutes les classes l'implémentant. > > Jerome > Nicolas Delsaux
Date sent: Mon, 15 Oct 2001 14:33:17 +0200 From: Guillaume Desnoix <guillaume@desnoix.com> To: java@u-strasbg.fr Subject: Re: Interfaces et methodes protected Send reply to: java@u-strasbg.fr Jerome Moliere: >> je rajouterai que le probleme selon moi avec l'implementation de Sun >> provient de la possibilite de declarer des attributes...cela ne sert a >> rien et ne fait que violer l'encapsulation... Heureusement, on ne peut pas declarer d'attributs, juste des constantes. Nicolas Delsaux: > Foula, on change de sujet là. Mais c'est vrai que les déclaration > d'attributs dans une interface ressemblent plus à une magouille visant à > cacher un peu de l'implémentation dans une interface pour qu'en > bénéficient toutes les classes l'implémentant. Idem. C'est impossible. Guillaume
From: "Herve AGNOUX" <herve.agnoux@diaam-informatique.com> To: java@u-strasbg.fr Date sent: Mon, 15 Oct 2001 14:37:55 +0200 Subject: Re: Interfaces et methodes protected Send reply to: herve.agnoux@diaam-informatique.com Priority: normal Le 15 Oct 01, Nicolas Delsaux a écrit : > lesquelles les méthodes soient protected. Or Java me l'interdit. Alors > quoi ? J'ai loupé un concept important lié à l'utilisation de méthodes > protected ou les spécifications de Java ne correspondent pas à mes > besoins ? > Je connais pas le pourquoi du comment, mais moi aussi j'ai buté sur ce problème. Pour le contourner, j'ai utilisé des classes abstraites. Conceptuellement, c'est bon ? -- Sur le Web, tout de suite. Herve AGNOUX - diaam informatique http://www.diaam-informatique.com
From: "Herve AGNOUX" <herve.agnoux@diaam-informatique.com> To: java@u-strasbg.fr Date sent: Mon, 15 Oct 2001 14:37:55 +0200 Subject: Re: Interfaces et methodes protected Send reply to: herve.agnoux@diaam-informatique.com Priority: normal Le 15 Oct 01, Guillaume Desnoix a écrit : > > Beaucoup de mal ;-). Dans la mesure ou cette interface est publique, il > n'y a aucune raison de la rendre interne. Il s'agit alors juste d'une > question d'espace de nommage et je ne pense pas qu'on devrait utiliser > les classes internes dans ce but. > Allons bon, c'est souvent ce que je fais ! Peux-tu en dire plus, Tonerre de Brest ! -- Sur le Web, tout de suite. Herve AGNOUX - diaam informatique http://www.diaam-informatique.com
From: "Cedric Beust" <cedric@beust.com> To: <java@u-strasbg.fr> Subject: RE: Interfaces et methodes protected Date sent: Mon, 15 Oct 2001 06:05:13 -0700 Send reply to: java@u-strasbg.fr > From: Guillaume Desnoix [mailto:guillaume@desnoix.com] > Heureusement, on ne peut pas declarer d'attributs, juste des constantes. Ce serait pourtant bien pratique et ca eviterait les tres verbeux getFoo() et setFoo() que beaucoup d'interfaces sont obligees de declarer. -- Cedric
From: "Cedric Beust" <cedric@beust.com> To: <herve.agnoux@diaam-informatique.com>, <java@u-strasbg.fr> Subject: RE: Interfaces et methodes protected Date sent: Mon, 15 Oct 2001 06:06:37 -0700 > From: Herve AGNOUX [mailto:herve.agnoux@diaam-informatique.com] > Je connais pas le pourquoi du comment, mais moi aussi j'ai buté > sur ce problème. Pour le contourner, j'ai utilisé des classes > abstraites. Conceptuellement, c'est bon ? C'est moins fragile que des interfaces, qui font casser ton code des que tu leur ajoutes une methode (contrairement aux classes abstraites, pour lesquelles tu peux fournir une implementation par defaut). -- Cedric
From: Gloom <gloom@codeshebang.org> Send reply to: gloom@codeshebang.org To: java@u-strasbg.fr Subject: Re: Interfaces et methodes protected Date sent: Mon, 15 Oct 2001 15:39:23 +0200 Le Lundi 15 Octobre 2001 11:15, vous avez écrit : > une interface n'existe que pour declarer des services!!! or un service > se doit d'etre public Je vois pas pourquoi ! On peut avoir besoin de classes remplissants un contrat, et que le tout sois interne à un package ! Non ? > Jerome Nicolas REPIQUET
From: "Nicolas Delsaux" <nicolas.delsaux@free.fr> To: <java@u-strasbg.fr> Subject: Re: Interfaces et methodes protected Date sent: Mon, 15 Oct 2001 15:45:11 +0200 Send reply to: java@u-strasbg.fr ----- Original Message ----- From: "Jean-Yves Pere" <toga.kiryu@free.fr> To: <java@u-strasbg.fr> Cc: <herve.agnoux@diaam-informatique.com> Sent: Monday, October 15, 2001 3:46 PM Subject: Re: Interfaces et methodes protected > Rien ne t'empeche de definir une interface et de fournir une > implmeentation par defaut par une classe abstraite dont heritent > toutes tes autres classes. Cela te permet d'avoir l'avantage des deux. Là, je ne suis pas d'accord : l'intérêt essentiel des interfaces est de fournir uniquement un contrat. Si tu associes une classe abstraite disposant de toutes les implémentations, pas la peine d'avoir une interface car la classe abstraite fait double emploi avec. Nicolas Delsaux
To: java@u-strasbg.fr Copies to: <herve.agnoux@diaam-informatique.com> Subject: Re: Interfaces et methodes protected From: Jean-Yves Pere <toga.kiryu@free.fr> Organization: Ohtori Academy Date sent: Mon, 15 Oct 2001 15:46:17 +0200 "Cedric Beust" <cedric@beust.com> writes: > > C'est moins fragile que des interfaces, qui font casser ton code des que > tu leur ajoutes une methode (contrairement aux classes abstraites, pour > lesquelles tu peux fournir une implementation par defaut). Rien ne t'empeche de definir une interface et de fournir une implmeentation par defaut par une classe abstraite dont heritent toutes tes autres classes. Cela te permet d'avoir l'avantage des deux. -- SP: Un OS connu, simple à utiliser, mais avec une fondation Unix CF: La théière ? SP: On a dit "connu". -+- SP in Guide du Macounet Pervers : BeOS, à l'heure du thé -+-
From: OLIVIER CAYRON <OLIVIER.CAYRON@orfi.fr> To: "'java@u-strasbg.fr'" <java@u-strasbg.fr> Subject: RE: Interfaces et methodes protected Date sent: Mon, 15 Oct 2001 15:59:31 +0200 Send reply to: java@u-strasbg.fr Yo ! > -----Message d'origine----- > De : Guillaume Desnoix [mailto:guillaume@desnoix.com] > Envoyé : lundi 15 octobre 2001 14:33 > À : java@u-strasbg.fr > Objet : Re: Interfaces et methodes protected > > > Jerome Moliere: > >> je rajouterai que le probleme selon moi avec > l'implementation de Sun > >> provient de la possibilite de declarer des attributes...cela ne > >> sert a rien et ne fait que violer l'encapsulation... > > Heureusement, on ne peut pas declarer d'attributs, juste des > constantes. Ah, une bien belle chose que ces constantes Java !!! Sauf erreur, c'est la référence qui est constante, pas l'instance. Donc, rien n'empêche de faire des setXXXX sur la constante. Donc, faut éviter les "constantes" non immuables dans les interfaces, AMHA. Olivier > > Nicolas Delsaux: > > > Foula, on change de sujet là. Mais c'est vrai que les déclaration > > d'attributs dans une interface ressemblent plus à une > magouille visant à > > cacher un peu de l'implémentation dans une interface pour > qu'en bénéficient > > toutes les classes l'implémentant. > > Idem. C'est impossible. > > Guillaume >
From: "Nicolas Delsaux" <nicolas.delsaux@free.fr> To: <java@u-strasbg.fr> Subject: Re: Interfaces et methodes protected Date sent: Mon, 15 Oct 2001 16:05:18 +0200 Send reply to: java@u-strasbg.fr ----- Original Message ----- From: "Jean-Yves Pere" <toga.kiryu@free.fr> To: <java@u-strasbg.fr> Sent: Monday, October 15, 2001 4:04 PM Subject: Re: Interfaces et methodes protected > non, car l'interface est plus souple. Principalement en utilisant > cela, cela te permet de faire une classe implementant 2 interfaces et > heritant d'une des classes abstraites, héritant par delegation de > l'autre. Comme cela ta nouvelle classe se contraint aux deux contrats, > ce qui n'est pas faisable avec les 2 classes abtraites. Dans mon idée, > l'interface fournit le role et la classe abstraite n'est la que pour > concentrer le code en commun. > D'accord, et comme le disait Gloom, les listes l'utilisent, et avec pas mal de bonheur. Là où j'étais un peu surpris, c'était en lisant que pour une interface, tu crées une classe abstraite qui l'implémente et tu dérives toutes tes classes concrètes de cette classe abstraite de manière à t'affranchir des limitations que tu t'imposes avec ton interface. Même si je concois que pour certains interfaces, une implémentation par deéfaut est utile, je pense que l'interface est aussi utile, dans la mesure où Java ne permet l'héritage multiple que pour les contrats. Nicolas Delsaux
From: "Cedric Beust" <cedric@beust.com> To: <java@u-strasbg.fr> Copies to: <herve.agnoux@diaam-informatique.com> Subject: RE: Interfaces et methodes protected Date sent: Mon, 15 Oct 2001 07:16:44 -0700 > From: Jean-Yves Pere [mailto:toga.kiryu@free.fr] > > C'est moins fragile que des interfaces, qui font casser ton code des > > que tu leur ajoutes une methode (contrairement aux classes abstraites, > > pour lesquelles tu peux fournir une implementation par defaut). > > Rien ne t'empeche de definir une interface et de fournir une > implmeentation par defaut par une classe abstraite dont heritent > toutes tes autres classes. Cela te permet d'avoir l'avantage des deux. Oui, c'est une "pattern" que j'utilise souvent. -- Cedric
Date sent: Mon, 15 Oct 2001 17:19:03 +0200 From: Guillaume Desnoix <guillaume@desnoix.com> To: herve.agnoux@diaam-informatique.com Copies to: java@u-strasbg.fr Subject: Re: Interfaces et methodes protected >> Tu utilises souvent des interfaces internes ? Je ne pense pas mais tu >> as un exemple ? Herve AGNOUX: > Ben, heu... j'en fais de plus en plus :-) > Je les fais par exemple lorsque une classe utilise un objet > paramètre. > Soit par exemple les célèbres classes Listener etc, par exemple > ComponentListener, ComponentEvent, ComponentAdapter. Moi, si > j'avais été à la place de Sun (ce qui est impossible, d'accord), > j'aurai casé dans ma classe Component une interface statique > "Listener", une classe "Event", et une classe statique "Adapter" > dans l'interface Listener (moi quand je fais une bêtise je la fais à > fond). Donc, j'obtiens comme classes / interfaces : Component.Listener > Component.Listener.Adapter Component.Event. Moi je trouve ça beaucoup > plus clair que les laborieux ComponentListener etc. Ton exemple est convaincant et pourtant je doute... Je pense que ce n'est pas assez modulaire. Suppose que j'ecrive une nouvelle classe Composant qui doit remplacer completement Component et donc se comporter comme elle. Elle doit donc utiliser Listener, Adapter, ... Au chargement, du fait que Listener, ... sont des classes internes a Component, la classe Component va etre chargee (et occuper de la memoire) alors que je n'en ai pas besoin. > L'exemple des Listeners montre qu'il peut y avoir des classes ou > interfaces spécifiques à une classe, et que cette dernière rend > public pour assouplir son fonctionnement. "Moi, un Component, > j'envoie toujours un événement de tel format que c'est moi seul qui le > décide, à vous, qui pouvez réagir comme vous voulez". A mon avis, une interface n'est *jamais* specifique a un composant dans la mesure ou elle definit un service. Ce service peut etre propose par une autre classe. Et pourquoi Component.Listener.Adapter et non Component.Event.Listener (plus logique AMHA ;-) ) ? > Quand la classe interne est statique, c'est simple, il n'y a pas de > relations spéciales avec la classe interne. Moi j'exploite juste les > propriétés de nommage. Le nom du ComponentEvent est relié à Component, > cela me parait parfaitement clair et justifié. Les noms sont lies, les contextes d'utilisation le seront aussi generalement. Mais les classes elles-memes ne le sont pas. Allez, encore un argument massue: Component.Listener est plus long a ecrire que ComponentListener ;-) A+ Guillaume
From: "Herve AGNOUX" <herve.agnoux@diaam-informatique.com> To: Guillaume Desnoix <guillaume@desnoix.com> Date sent: Tue, 16 Oct 2001 14:50:58 +0200 Subject: Re: Interfaces et methodes protected Send reply to: herve.agnoux@diaam-informatique.com Copies to: java@u-strasbg.fr Priority: normal Le 15 Oct 01, Guillaume Desnoix a écrit : > > Je pense que ce n'est pas assez modulaire. Suppose que j'ecrive une > nouvelle classe Composant qui doit remplacer completement Component et > donc se comporter comme elle. Elle doit donc utiliser Listener, Adapter, Le modèle que je propose est pour le cas où tu es sûr qu'un service est attaché à une classe. C'est un cas qui est très courant. Le service "Faire du café" est attaché aux cafetières, pas aux théhières. Tu as une classe, et des services associés. Certes si tu veux faire une autre cafetière, tu risque d'être obligé de refaire ton service. Il faut, au départ, avoir une classe "cafetière" suffisament générique. C'est ce qui est difficile, mais c'est ce qu'il faut faire. > ... Au chargement, du fait que Listener, ... sont des classes internes a > Component, la classe Component va etre chargee (et occuper de la > memoire) alors que je n'en ai pas besoin. > Non, je ne crois pas. Les classes internes statiques n'ont pas besoin de la classe englobante pour être instanciées. > > A mon avis, une interface n'est *jamais* specifique a un composant dans > la mesure ou elle definit un service. Ce service peut etre propose par > une autre classe. Et pourquoi Component.Listener.Adapter et non > Component.Event.Listener (plus logique AMHA ;-) ) ? > "Service" n'est-il pas le nouveau mot à la mode pour dire "fonction" ? C'est ce qu'il me semble, en tout cas... Donc, si on repart des bases objet, tu pars d'un objet. A cette objet est attaché différents services, qui ne se comprennent et ne se conçoivent que sur cet objet. Si on peut concevoir un même service sur plusieurs types d'objets, alors c'est que probablement il existe une classe parente, plus générique, que l'on a tout avantage à créer. Enfin, c'est l'hypothèse de départ de la programmation objet, il me semble ? > > Les noms sont lies, les contextes d'utilisation le seront aussi > generalement. Mais les classes elles-memes ne le sont pas. > Si : un service / fonction, pour moi, est forcément lié à une classe, à un truc objet. Maintenant je peux mettre de l'eau dans mon vin, j'imagine qu'on peut toujours trouver des services "virtuels", "immanents", ok, ok, ok. Je suis pas sectaire, je créée alors deux fichiers séparés, ce n'est pas un problème :-) > Allez, encore un argument massue: > Component.Listener est plus long a ecrire que ComponentListener ;-) > Ouais, mais t'as pas besoin de créer 2 fichiers séparés... -- Sur le Web, tout de suite. Herve AGNOUX - diaam informatique http://www.diaam-informatique.com
