Discussion :

[Vincent PETIT]

Bonjour,
Ayant toujours fait du C sur microcontrôleur ou du VHDL dans une moindre mesure (donc deux langages utilisés dans des applications à l'extrême opposées de la POO), je dois dire que j'ai un mal de chien a réellement me mettre au Java.

Mon programme de test : un Aquarium (j'ai rien trouvé de mieux pour démarrer)
Normalement ma super classe doit être un aquarium avec dedans, un environnement (des limites géographiques et des zones de nourritures)

- Il m'a paru naturelle de créer une interface "Comportement" avec dedans des méthodes vides telles que des directions : droite(), gauche(), haut(), bas(), approcher(), fuir(), suivre() communes à toutes sortes de poissons.
- Ensuite, je verrai bien 3 classes abstraites car il y a des prédateurs, des proies vivants à plusieurs et d'autres proies vivants seuls. Les prédateurs mangent des proies et celles ci mangent la nourriture dans l'environnement principal.
- Enfin des classes suivants les types de poissons (prédateurs/proies seules/proies en communautés) héritant des classes abstraites ci dessus et une description de leur comportement offensif / défensif (camouflage, esquive rapide, se cacher).

Mes questions sont : Est ce que ma vision du problème est bonne ? Est ce que je me plante dans ces notions d'héritages, interfaces ?

Je m'interroge sur la méthode fuir() dans l'interface puisqu'un prédateur n'est pas sensé fuir. Est ce que la place de cette méthode n'est pas plus dans la classe abstraite ?


D'avance merci.

[tchize_]

Mes questions sont : Est ce que ma vision du problème est bonne ? Est ce que je me plante dans ces notions d'héritages, interfaces ?

Elle se défend. Chacun aura surement sa propre vision de comment réaliser le problème, mais ce n'est pas relevant aux mécanismes de java. Il y a plein de manières de faire et ça en est une.

Je m'interroge sur la méthode fuir() dans l'interface puisqu'un prédateur n'est pas sensé fuir. Est ce que la place de cette méthode n'est pas plus dans la classe abstraite ?

Bah tu pourrais imaginer des condition qui fassent fuir dans le futur. Genre un autre prédateur de sa taille. Ce ne paie pas de mine de laiser ça en interface. Rien n'empêche la méthode de renvoyer un boolean false pour marquer qu'elle refuse de fuir, ou lancer une exception. C'est assez courant les méthodes d'interface non implémentées. Il existe même l'exception UnsupportedOperationxception que tu peux utiliser.

La question est finalement plutôt de te poser la question de comment tu va utiliser cette méthode. Est-ce que l'appelant aura d'office une proie? Tu peux aussi créer deux interface "Predateur" avec des méthodes genre attaquer() suivre(), et Proie avec fuir(). Tu aurais alors des circuits dédiés dans ton aquarium pour gérer les prédateur et les proies séparément. Ensuite ta classe AbstractPredateur implements Predateur, Comportement
ta classe ProieSeule implements Proie, Comportement
ta classe ProieGroupe implements Proie, Comportement

Et rien ne t'empêchera d'avoir un prédateur qui est aussi une proie



Bref c'est surtout une question d'équilibre de ton code. Si t'as du code générique à fournir, il vaut mieux une classe abstraite. Si tu veux que tout le monde puisse changer son comportement, il vaut mieux partir d'une interface.

[Vincent PETIT]

Salut tchize_,

C'est assez courant les méthodes d'interface non implémentées. Il existe même l'exception UnsupportedOperationxception que tu peux utiliser.

C'est exactement la question que je me posais car je suis dans ce cas là. Je me suis demandé si je n'étais pas entrain de faire une erreur de conception et je cherchais absolument a avoir une interface depuis la quelle j'implémenterais toutes les méthodes.

Bref c'est surtout une question d'équilibre de ton code. Si t'as du code générique à fournir, il vaut mieux une classe abstraite. Si tu veux que tout le monde puisse changer son comportement, il vaut mieux partir d'une interface.

J'ai compris maintenant !

Merci pour ta vision de mon problème et tes exemples, j'y vois encore plus clair dans les notions d'héritages.
A+

[bouye]

J'en profite pour recoller ici ce que je viens de mettre dans l'autre discussion sur le sujet :

Note : la distinction est déjà devenue un peu plus floue avec le JDK8 qui a ajouté les méthodes par défaut dans les interfaces mais elle le sera encore plus avec le JDK9 qui va introduire les méthodes privées et les méthodes statique privées dans les interfaces (dans le but d’éviter de dupliquer du code dans les méthodes par défaut)

Voir : http://blog.joda.org/2016/09/private...in-java-9.html

public static - supported
public abstract - supported
public default - supported
private static - supported
private abstract - compile error
private default - compile error
private - supported

[Vincent PETIT]

Mes questions tournent aussi sur tout ça. Merci pour ce complément d'info.

[bouye]

JDK8: en gros, le principe qui va prévalu pour le support des méthodes par défaut c'est d'ajouter de nouvelles fonctionnalités dans une API déjà existante pour éviter de devoir en recoder ces mêmes fonctionnalités de partout.

On peut en voir les effets dans l'ajout support des streams ou du tri dans les collections. L'API des collections date de Java 1.2 (dont la bêta a eu lieu en 1998/1999) et est elle-même en partie basée sur des classes existantes depuis la version 1.0 de Java (Vector et Hashtable). Donc l'API est vieille datant d'une époque ou personne n'avait songé au stream ou à la programmation fonctionnelle / lambda en Java, énorme et, outre les dizaines classes publiques ou privées fournies par le JDK, des tas de gens ont créé leurs propres sous-classes a partir des interfaces existantes servant d’implémentations spécifiques. Donc il aurait été compliqué d'ajouter le support des streams avec le simple ajout de signature : ça aura tout cassé de partout et aurait obligé à rajouter pas mal de code partout dans le JDK mais aussi chez les libs/utilisateurs tiers.

Par contre je ne sais pas trop le pourquoi de l'ajout du support des méthodes statiques. Généralement il était plutôt de bon gout de placer ce genre de chose dans une classe singleton utilitaire (ou un enum singleton) pour éviter justement de transgresser le fait que l'interface apporte un type / comportement.

JDK9: le but est apparemment devenu d’éviter la duplication de code dans les méthodes par défaut et méthodes statiques nouvellement introduites.

Bien sur entre le principe guidant ce que les gens en charge des évolutions du langage et ce qu'en font les programmeurs a la longue, il y un monde... et donc faudra pas s’étonner si c'est détourné a un moment ou un autre. Après réflexion on se rapproche vraiment du coup d'une certaine gestion de l’héritage multiple, ce qui pourrait devenir problématique.

[tchize_]

J'allais le dire, autant j'apprécie l'idée des méthodes defaut, autant je le sens bien venir le foutoir de l'héritage multiple chez certains dev