Discussion :

[samaury]

Bonjour
J'ai
- une interface MyInterface,
- un objet de type MyObjet1 qui possede une propriété de type MyObjet2
Pour les besoins de la cause MyObjet1 doit être déclaré comme implémentant MyInterface alors que en pratique c'est sa propritété MyObjet2 qui implémente effectivement MyInterface.
Ma question est : est-il possible de déléguer à MyObjet2 l'implementation de MyInterface tout en conservant la déclaration "MyObjet1 implements MyInterface"
Je sais ...c'est un peu tordu comme construction...
Merci de votre aide.

[bouye]

Aucun probleme. En quoi cela aurait-il pu etre genant ?

[samaury]

Aucun problème. En quoi cela aurait-il pu être gênant ?

Sais-tu si c'est possible de le faire en java...Je débute en java(Je viens du monde delphi et je le fais assez couramment sous delphi). Je n'ai pas encore trouvé de doc qui explique comment faire en java...
Merci

[CheryBen]

Personnellement je trouve cela très bizarre comme conception...pourquoi ce ne serait pas MyObjet2 qui implémenterait MyInterface ?

Si une classe est déclarée comme implémentant une interface, elle doit obligatoirement implémenter les méthodes de cette interface, SAUF si cette classe est abstraite. Dans ce cas ce seront les classes non abstraites héritant de cette classe abstraites qui devront implémenter les méthodes de l'interface.

[samaury]

Personnellement je trouve cela très bizarre comme conception...pourquoi ce ne serait pas MyObjet2 qui implémenterait MyInterface ?

Si une classe est déclarée comme implémentant une interface, elle doit obligatoirement implémenter les méthodes de cette interface, SAUF si cette classe est abstraite. Dans ce cas ce seront les classes non abstraites héritant de cette classe abstraites qui devront implémenter les méthodes de l'interface.

MyObjet1 implémente déjà plusieurs interfaces en plus de ses méthodes propres. Je ne veux pas avoir à gérer 150.000 lignes de code dans un même fichier mais encapsuler le plus possible dans des classes/fichiers dédiés aux différents traitements.

[CheryBen]

Dans ce cas pourquoi déclarer MyObjet1 implémentant MyInterface?
C'est cette contrainte "Pour les besoins de la cause" qui fait que tu as un problème.

Pour que tout soit plus clair, comme tu le dis, c'est MyObjet2 qui devrait implémenter MyInterface.

[bouye]

MyObjet1 et MyObjet2 implementent tous les deux MyInterface, MyObjet1 delegue a MyObjet2, MyObjet2 contient l'implementation concrete du traitement, il n'y a absolument rien de bizarre dans cette construction. Au contraire c'est une bonne utilisation du principe de la Delegation, voir meme ca ressemble a un debut de Decorateur (m'enfin, tous les flux fonctionnent de cette maniere ! )

[samaury]

MyObjet1 et MyObjet2 implementent tous les deux MyInterface, MyObjet1 delegue a MyObjet2, MyObjet2 contient l'implementation concrete du traitement, il n'y a absolument rien de bizarre dans cette construction. Au contraire c'est une bonne utilisation du principe de la Delegation, voir meme ca ressemble a un debut de Decorateur (m'enfin, tous les flux fonctionnent de cette maniere ! )

Merci pour ces infos/remarques. Si il est possible de le faire en java, quelle serait alors la syntaxe à utiliser?
@++

[bouye]

Ben... aussi simplement que ca...

Code :

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

1
2
3
4
5
6
public Interface MyInterface {
  /**
   * Do SOMETHING!
   */
  public void truc();
}

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
public class MyObject1 implements MyInterface {
  /**
   * Object to which we delegate the task.
   */
  private MyInterface delegated = new MyObject2();
 
  /**
   * {@inheritDoc}
   */
  public void truc() {
    delegated.truc();
  }
}

Code :

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

1
2
3
4
5
6
7
8
class MyObject2 implements MyInterface {
  /**
   * {@inheritDoc}
   */
  public void truc() { 
    [...]
  }
}

[samaury]

Ben... aussi simplement que ca...

Code :

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

1
2
3
4
5
6
public Interface MyInterface {
  /**
   * Do SOMETHING!
   */
  public void truc();
}

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
public class MyObject1 implements MyInterface {
  /**
   * Object to which we delegate the task.
   */
  private MyInterface delegated = new MyObject2();
 
  /**
   * {@inheritDoc}
   */
  public void truc() {
    delegated.truc();
  }
}

Code :

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

1
2
3
4
5
6
7
8
class MyObject2 implements MyInterface {
  /**
   * {@inheritDoc}
   */
  public void truc() { 
    [...]
  }
}

Effectivement ça parait évident je te remercie.
Je m'attendait quelque chose un peu comme dans delphi/pascal qui fait que une fois que on a déclaré (dans MyObjet1)
".... delegated : MyInterface;implements MyInterface..."
on n'a plus besoin d'implémenter "truc()" dans MonObjet1 mais l'appel de "truc()" est automatiquement redirigé vers "delegated.truc()"
Merci encore
@++

[bouye]

Non, ce genre de constructions automatiques n'existe pas dans Java (a proposer pour Java 8 ?).

[TickerOpcvm]

Bonjour a tous,

Un petit grain de sel pour pimenter la discussion et pousser à de bonnes pratiques
Plutôt que d'écrire :

Code :

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

private MyInterface delegated = new MyObject2();

Il me semble plus souple d'appliquer l'Inversion de Contrôle :

Code :

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

1
2
3
4
5
6
7
8
9
10
private MyInterface delegated;
 
  public MyInterface getDelegated()
  {
    return delegated;
  }
  public void setDelegated(MyInterface delegated)
  {
    this.delegated = delegated;
  }

et ainsi permettre à un conteneur extérieur d'injecter une implémentation concrète qui pourra ainsi facilement evoluer voire changer au cours du temps sans affecter le code de MyObject1.

Hope this helps
Ticker

[bouye]

Pourquoi pas... mais a-t-il besoin de le faire dans son contexte ?
Car franchement, de meme qu'on ne change pas le flux sous-jacent d'une flux decore*, il n'a peut-etre pas du tout besoin de faire ce genre de chose.

*Qui aurait l'idee de changer le flux destination d'un BufferedOutputStream en plein milieu d'une operation IO ????????

Un autre exemple : dernierement j'avais besoin d'une Shape qui ait un fonctionnement similaire a Area mais avec le comportement de RectangularShape (setFrameFromCenter() etc). Or bizarrement Area n'etend pas RectangularShape (etonnant vu qu'Area est une Shape et donc dispose d'une methode getBounds() et getBounds2D() qui retournent... les rectangles englobants de la forme...).

Enfin bref, ma RectangularArea etend RectangularShape et delegue tout le boulot a une Area tout en reprenant une signature similare pour faire des operations arithmethiques que les formes et les aires. A AUCUN moment je n'ai besoin de mofidier l'objet delegue ni le veux le faire. Ma classe a moi implemente Shape et c'est suffisant pour l'utiliser dans un contexte graphique, de plus JE NE VEUX PAS exposer le fonctionnement interne de la classe en permettant d'acceder a l'Area qui y est contenue et la manipuler a l'exterieur pourrait mener a un defaut de synchronisation entre l'etat de la RectangularArea et l'Area sur laquelle elle delegue.

Bref, attention a ne pas vouloir refourguer des accesseurs ou des patterns la ou il n'y en a pas besoin et la ou c'est inutile voir dangereux d'en mettre. Tout depends bien sur du contexte dans lequel ceci est utilise.

[TickerOpcvm]

Je suis entièrement d'accord, il ne sert à rien d'exposer des classes internes dont rien ne dit qu'elles seront amenées à changer.
Le but de ma remarque était plutot de dire qu'une instanciation "en dur" dans une classe peut être ennuyeuse lors d'un changement d'implémentation. Mais pour cela il faut avoir bien analysé ce que l'on veut faire. Ce qui rejoint ta remarque