Discussion :

[poubda]

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
interfaceA {
   f1()
   f2()
}
 
class service1 implements interfaceA<modelX> {
   @override
   f1() { ... }
 
   @override
   f2() { ... }
}

plusieurs classes (service1, service2...) existe sur la meme classe avec divers model


disons que je veux uniquement pour service1 ajouter une fonction f3, j'hesite entre 2 façons car les 2 fonctionnent :

(1)

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
 
interfaceA {
   f1()
   f2()
}
 
class service1 implements interfaceA<modelX> {
   @override
   f1() { ... }
 
   @override
   f2() { ... }
 
   f3() { ... }      // pas d'override
}

(2)

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
 
interfaceA {
   f1()
   f2()
}
 
interfaceF3 {
   f3()   
}
 
class service1 implements interfaceA<modelX>, interfaceF3  {
   @override
   f1() { ... }
 
   @override
   f2() { ... }
 
   @override
   f3() { ... }     
}

en terme de bonne pratique (1) ou (2) ?

plusieurs avis si possible !

[thelvin]

Ben là on entre dans les cas où les avis divergent.

En principe (1) n'est pas spécialement mauvais.


Mais on pourra préférer le principe de toujours programmer par interface. Du coup, (2) ? Beeeeen, (2) peut aller dans certains cas, mais dans le cas général :

tu vas l'assigner à quelle variable, ton objet de classe service1 ? Il faut que ce soit une variable sur laquelle on peut appeler f1(), f2(), et f3(). Du coup elle sera de quel type ? service1 ? C'est pas programmer par interface, ça.
Les solutions dépendent d'un peu tout :

- f3() a-t-elle vraiment besoin, ou est-ce vraiment très logique, de faire partie du même service que f1() et f2() ? (Si non, un autre service semble plus logique)
- Tu pourrais avoir besoin de définir une nouvelle interface, InterfaceAF3, qui hérite de interfaceA et de interfaceF3.
- Tu pourrais enlever interfaceF3 et créer directement InterfaceAF3 qui hérite de interfaceA et qui ajoute f3().
- Pas impossible que programmer par interface ne soit pas vraiment utile dans ton cas, il faut voir.

[duke666]

et dans ce cas ?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
interfaceA {
   speed()
   conso()
}
 
class service1 implements interfaceA<Car> {
   @override
   speed() { ... }
 
   @override
   conso() { ... }
}

par exemple service1 on implémente avec plusieurs type de vehicule: car,airplane, boat
pour car on veut ajouter une fonction capacity() pour la batterie

(1) ou (2) ?

[thelvin]

On ne peut pas utiliser les génériques pour un cas de ce genre.

Ou alors il faut gruger de manière assez sale, genre avec des UnsupportedOperationException quand le programmeur appelle des combinaisons qui ne marchent pas. Vu qu'on parle de meilleures pratiques, c'est à éviter.

[dukoid]

ok et sans les génériques ?

[thelvin]

....... Ben sans les génériques ça peut pas être <Car>

[OButterlin]

Il y a aussi la possibilité de créer une InterfaceB qui étend InterfaceA, y ajouter la méthode f3() et dire que la classe service1 étend cette nouvelle interface.
Du coup, service1 pourra être "vu" comme une InterfaceA ou comme une InterfaceB

Mais bon, tout dépend de ce qu'on veut faire.
Faire des interfaces pour le plaisir n'a pas vraiment de sens, il faut une raison ou une contrainte.

[gervais.b]

Si vous voulez garder un système propre, regardez du côté de la composition également.
Quelques "design patterns" comme facade ou proxy mais aussi adapter, composite et decorator peuvent vous aider à implémenter proprement votre solution.