Discussion :

[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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ?

[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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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é

[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

[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...

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++

[Glob]

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...

[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 )
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 ??

[jeje99]

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

Pour le coup de la javadoc c'est ce que j'ai déjà fait.

[MangeurVasqué]

Justement sur le meme principe que le synchronized , la visibilité d'une methode est lié à l'implementation non ? (jen suis pas certain )
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

[adiGuba]

Justement sur le meme principe que le synchronized , la visibilité d'une methode est lié à l'implementation non ? (jen suis pas certain )
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 ?

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

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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++

[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

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

[dlemoing]

Il existe un pattern qui s'appelle Template Method :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[fabszn]

Hello,

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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?

[FreshVic]

Hello,

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 !

[fabszn]

Hello,

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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?

[dlemoing]

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

[FreshVic]

Hello,

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 !!

[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.

[FreshVic]

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

COmme ca c'est clair !!

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.

[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....

[dlemoing]

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é ?