[Language]Synchroniser une méthode abstraite

Version imprimable

Voir 40 message(s) de cette discussion en une page

Bonjour à tous,

J'aimerais savoir quelle déclaration je dois utiliser pour imposer qu'une méthode sera synchronisée dans toutes les classes filles qui heriteront de la classe ou cette méthode sera déclarée ? (phrase à prononcer sans respirer)

Exemple :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 abstract class plop{ abstract public int toto(); } //cette classe compile class plic extend plop { synchronized public int toto(){ //traitement } } //cette classe ne compile pas class pluc extend plop{ public int toto(){ //traitement } }
Des idées ?

13/12/2005, 14h55
FreshVic
Etant donné que je ne pense pas que le mot clé synchronized fasse parti de la signature d'une methode tu peux difficilement forcé l'implementation a etre synchronized directement (enfin ce n'est que mon avis )
mais tu dois pouvoir faire ca :
Code:

1 2 3 4 5 6 7 8 9 10 public abstract class TotoSynch { public synchronized int indirect(){ return toto(); } abstract int toto(); }
Reste a interdire l'appelle de toto directement dans les classe implementer par private , de cette façon l'appelle a toto se fait uniquement par indirect du coup forcement synchronized .

Mais bon peut etre que ce n'est pas LA solution , mais ca devrait marché :wink:
13/12/2005, 14h58
FreshVic

Apres reflexion rien n'empeche la personne qui implemente toto de ne pas mettre toto en public , du coup ma solution n'est pas top :roll:
13/12/2005, 14h58
adiGuba

Salut,

Ce n'est pas possible... La synchronisation est du ressort de l'implémentation et non pas des spécifications...

Le mieux serait d'indiquer dans la documentation de la méthode qu'elle doit être thread-safe... mais même sans être déclaré synchronized, une méthode peut très bien être sécurisé en multi-thread...

Citation:

Envoyé par FreshVic

Reste a interdire l'appelle de toto directement dans les classe implementer par private

Tu veux sans doute dire par protected car les méthode private ne sont pas hérité ;)

a++

a++
13/12/2005, 15h05
Glob

Citation:

Envoyé par FreshVic

Apres reflexion rien n'empeche la personne qui implemente toto de ne pas mettre toto en public

Hello.
Je pense qu'on peut l'empêcher, même si c'est de façon tordue... Y'a toujours moyen de chopper (par réflexion) une méthode, de vérifier si elle est publique et de faire péter une exception... :roll:
13/12/2005, 15h05
FreshVic

Citation:

Envoyé par adiGuba

Citation:

Envoyé par FreshVic

Reste a interdire l'appelle de toto directement dans les classe implementer par private

Tu veux sans doute dire par protected car les méthode private ne sont pas hérité ;)

a++

Justement sur le meme principe que le synchronized , la visibilité d'une methode est lié à l'implementation non ? (jen suis pas certain :roll: )
ce que je veux dire c'est: est ce qu'une methode abstraite declarer comme public peut etre implementer comme private ?

Si j'ai bien compris une methode abstraite declaré comme private n'a aucun sens ???

ou peut etre que rajouter la visibiliter lors de la declaration d'une methode abstraite n'as aucun sens ??
13/12/2005, 15h13
jeje99

Bon, donc c'est pas possible....

Pour le coup de la javadoc c'est ce que j'ai déjà fait.
13/12/2005, 15h15
MangeurVasqué

Citation:

Envoyé par FreshVic

Justement sur le meme principe que le synchronized , la visibilité d'une methode est lié à l'implementation non ? (jen suis pas certain :roll: )
ce que je veux dire c'est: est ce qu'une methode abstraite declarer comme public peut etre implementer comme private ?

Si j'ai bien compris une methode abstraite declaré comme private n'a aucun sens ???

ou peut etre que rajouter la visibiliter lors de la declaration d'une methode abstraite n'as aucun sens ??

Hello,

La visibilité d'une méthode est définie à la déclaration et tu ne peux pas réduire la visibilité d'une méthode héritée.

De plus abstract n'est compatible qu'avec public et protected car il n'a pas de sens avec la visibilité par défaut ou avec private
13/12/2005, 15h21
adiGuba
Citation:

Envoyé par FreshVic

Justement sur le meme principe que le synchronized , la visibilité d'une methode est lié à l'implementation non ? (jen suis pas certain :roll: )
ce que je veux dire c'est: est ce qu'une methode abstraite declarer comme public peut etre implementer comme private ?

Non, la visibilité fait partie des spécifications, tu dois les respecter. Par exemple tu ne peut pas changer la visibilité de la méthode toString() car elle est défini comme étant public dans la classe Object.

Par contre tu peux modifier la visibilité d'une méthode si tu respectent les spécification d'origine. Par exemple une méthode protected peut devenir public (puisque tu élargit la visibilité), mais l'inverse n'est pas vrai...
CF la FAQ : Quelles sont les règles à respecter pour redéfinir/implémenter une méthode ?

Citation:

Envoyé par FreshVic

Si j'ai bien compris une methode abstraite declaré comme private n'a aucun sens ???

Tout à fait... d'ailleurs cela provoque une erreur de compilation ;)

Citation:

Envoyé par FreshVic

ou peut etre que rajouter la visibiliter lors de la declaration d'une methode abstraite n'as aucun sens ??

Cela a un sens, puisque généralement on utilise l'implémentation en tant que méthode abstraite (voir d''interface). Par exemple dans le code de jeje99, si on fait :
Code:

1 2 Plop p = new Plic(); p.toto();
C'est la visibilitée défini dans la classe Plop qui est pris en compte...

a++
13/12/2005, 15h36
FreshVic

Merci pour ces eclaircissement , c'est probablement un trcu que j'ai su pendant ma formation a la fac , mais depuis que je travaille j'ai jamais eu a me poser cette question, du coup voila le resultat :wink:

Citation:

Envoyé par adiGuba

Par contre tu peux modifier la visibilité d'une méthode si tu respectent les spécification d'origine. Par exemple une méthode protected peut devenir public (puisque tu élargit la visibilité), mais l'inverse n'est pas vrai...

OK donc si on reprend la solution que je proposais a jeje99, il n'est pas possible d'obliger l'implementation d'etre protected afin que l'appelle a toto ne se fasse qu'indirectement via indirect

Il existe un pattern qui s'appelle Template Method :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
public interface Interface {
    public void toto();
}
 
public abstract class ClasseAbstraite implements Interface{
    public final void toto() {
        ...
        synchronized(this) {
            this.tata();
        }
        ...
    }
 
    protected abstract void tata();
}
 
public class MaClasse extends ClasseAbstraite {
    protected void tata() {
        ...
    }
}

Il reste à implémenter tata() qui s'executera dans un bloc synchronisé quelque soit l'implémentation.

Autre solution, utiliser un Decorator (ou Proxy suivant le point de vue) :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
public interface Interface {
    public void toto();
}
 
public class Decorateur implements Interface{
    public Interface objetConcret
 
    public final synchronized void toto() {
        objetConcret.toto();
    }
}
 
public class MaClasse implements Interface {
    public void toto() {
        ...
    }
}

Personnellement, je préfère la deuxième solution qui offre plus de fléxibilité et qui répond à la deuxième règle des Design Patterns : préférer la composition à l'héritage

Re: Synchroniser une méthode abstraite

Hello,
Citation:
Envoyé par jeje99
Bonjour à tous,

J'aimerais savoir quelle déclaration je dois utiliser pour imposer qu'une méthode sera synchronisée dans toutes les classes filles qui heriteront de la classe ou cette méthode sera déclarée ? (phrase à prononcer sans respirer)

Exemple :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 abstract class plop{ abstract public int toto(); } //cette classe compile class plic extend plop { synchronized public int toto(){ //traitement } } //cette classe ne compile pas class pluc extend plop{ public int toto(){ //traitement } }
Des idées ?
Juste pour info? qu'est ce qui ne compile pas dans la deuxieme classe?

Re: Synchroniser une méthode abstraite

Citation:
Envoyé par fabszn
Hello,
Citation:
Envoyé par jeje99
Bonjour à tous,

J'aimerais savoir quelle déclaration je dois utiliser pour imposer qu'une méthode sera synchronisée dans toutes les classes filles qui heriteront de la classe ou cette méthode sera déclarée ? (phrase à prononcer sans respirer)

Exemple :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 abstract class plop{ abstract public int toto(); } //cette classe compile class plic extend plop { synchronized public int toto(){ //traitement } } //cette classe ne compile pas class pluc extend plop{ public int toto(){ //traitement } }
Des idées ?
Juste pour info? qu'est ce qui ne compile pas dans la deuxieme classe?
Ce que j'ai compris c'est qu'il aurais voulu que ca ne compile pas !! mais a priori ca doit tres bien compiler !

Hello,
Citation:
Envoyé par dlemoing
Autre solution, utiliser un Decorator (ou Proxy suivant le point de vue) :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 public interface Interface { public void toto(); } public class Decorateur implements Interface{ public Interface objetConcret public final synchronized void toto() { objetConcret.toto(); } } public class MaClasse implements Interface { public void toto() { ... } }
Personnellement, je préfère la deuxième solution qui offre plus de fléxibilité et qui répond à la deuxième règle des Design Patterns : préférer la composition à l'héritage
Je ne suis pas sur de bien comprendre la relation entre la classe Decorateur et MaClasse , ou alors il manque un
Code:

1 2 3 4 public void setObjetConcret(Interface ob){ objetConcret = ob; }
Et la valeur ajouter du decorateur est de rendre la methode toto synchronized.

Est ce que je me trompre?

14/12/2005, 16h35
dlemoing

Exact, je l'avais oublié cette méthode.

Citation:
Envoyé par fabszn
Hello,
Citation:
Envoyé par dlemoing
Autre solution, utiliser un Decorator (ou Proxy suivant le point de vue) :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 public interface Interface { public void toto(); } public class Decorateur implements Interface{ public Interface objetConcret public final synchronized void toto() { objetConcret.toto(); } } public class MaClasse implements Interface { public void toto() { ... } }
Personnellement, je préfère la deuxième solution qui offre plus de fléxibilité et qui répond à la deuxième règle des Design Patterns : préférer la composition à l'héritage
Je ne suis pas sur de bien comprendre la relation entre la classe Decorateur et MaClasse , ou alors il manque un
Code:

1 2 3 4 public void setObjetConcret(Interface ob){ objetConcret = ob; }
Et la valeur ajouter du decorateur est de rendre la methode toto synchronized.

Est ce que je me trompre?
oui c'est ce que je pense aussi mais cela n'empeche pas les personnes qui utiliserons ces classes d'apeller toto directement a partir d'une implementation d'interface , du coup la synchronisation n'est pas sur a 100% et depend de ce que feront les personnes implementant l'interface et celle utilisant les classes, je pense pas qu'il y ai une solution efficace a 100% au probleme de jeje99 !!

14/12/2005, 16h41
alheim

arretez de vous prendre la tete...ON NE PEUT PAS EMPECHER LES GENS DE FAIRE DES CONNERIES...

Quand tu fournies une API, il en va de la responsabilité des gens qui implementent les interfaces de suivre les specifications. Sinon, pas de support.

Mieux vaut se focaliser sur une architecture valide, suffisemment ouverte, et qui en plus respecte les designs patern.

Le pattern Decorateur est EXACTEMENT ce qu'il faut faire dans ce genre de cas.
14/12/2005, 16h52
FreshVic

Citation:

Envoyé par alheim

arretez de vous prendre la tete...ON NE PEUT PAS EMPECHER LES GENS DE FAIRE DES CONNERIES...

:) COmme ca c'est clair !!

Citation:

Envoyé par alheim

Le pattern Decorateur est EXACTEMENT ce qu'il faut faire dans ce genre de cas.

Sachant qu'il nous en dit pas plus sur le probleme , je dirais que le TEMPLATE correspond plus que le Decorateur puisqu'il parle d'heritage et que meme si les design pattern incite a la composition plutot qu'a l'heritage , lorsque la modelisation necessite un heritage vaut mieux garder l'heritage.
14/12/2005, 16h59
alheim

C'est vrai FreshVic...Je me suis enflammé sur Decorateur. Mais c'est assez rare les gens qui essayent de suivre les design pattern et qui inventent des trucs tordus pour faire des choses simples (j'en cotois tous les jours).

Bref, je concluerais qu'un pattern ou l'autre, le principal est de faire les choses proprement plutot que de se triturer la tete a faire des trucs crades pour empecher les gens de faire des trucs crades.

Quite a faire des trucs crades autant que ce soit sur des bases propres...
oula je suis en forme moi....
:yaisse3:
14/12/2005, 17h02
dlemoing

Citation:

Envoyé par FreshVic

lorsque la modelisation necessite un heritage vaut mieux garder l'heritage.

Il ne vaut pas mieux changer la modélisation si on en a la possibilité ?

Voir 40 message(s) de cette discussion en une page

Fuseau horaire GMT +2. Il est actuellement 12h25.