Java: Justifier d'une classe/interface

Discutez d'informatique ici !
Avatar de l’utilisateur
Rockleader
Habitué(e)
Messages: 2126
Enregistré le: 11 Oct 2011, 18:42

Java: Justifier d'une classe/interface

par Rockleader » 14 Juin 2015, 09:08

Toujours dans l'optique de ces fameuses révisions, je vous livre la consigne du document de l'exam qui disait:

Vous implanterez les propriétés suivantes introduites progressivement à chaque question par des interfaces, des classes abstraites ou des classes concrètes dont vous justifierez le choix. A chaque fois, sauf indication contraire, le code java complet est demandé.



La toute première propriété est

1- Un salarié a un salaire (opération retournant un double). Définir en Java la notion de Salarié.


Sans spécialement donner la suite du devoir, si je m'arrêtais sur cette première question.

Quels sont les critères qui me permettent de déterminer si je dois faire de Salarié une classe abstraite, un interface ou bien une classe concrète ?
Parce que dans le fond, j'imagine que ce sont ces fameux critères qui vont servir de justification.


Deux problèmes dans mon choix: Déjà, je suis incapable de faire une différence entre une classe abstraite et un interface.

Et puis, le vocabulaire employé également.

Pour moi, un salarié a un salaire, il est clair qu'il s'agit d'une classe avec un attribut salaire.

sauf qu'après on précise pour salaire: opération retournant un double.

==> Comment faut il comprendre cela ? salaire serait une sorte de méthode retournant un double ? Auquel cas salarié serait plutôt une classe abstraite ?





EDIT: Après avoir fait quelques recherches, la grosse différence entre classe abstraite et interface se trouve sur la notion d'héritage multiple.

On ne peut hériter que d'une classe en java (et donc hériter seulement d'une classe abstraite)
En revanche on peut implémenter plusieurs interfaces, ce qui permet de contourner le problème de l'héritage multiple si je puis dire.

Mais dans ce cas là...pourquoi ne pas utiliser toujours des interfaces plutôt que des classes abstraites ? Parce que dans le fond ça fonctionne de la même façon...à moins que l'on ait des différence de performances ...
Cette histoire est entièrement vraie puisque je l'ai inventé du début à la fin !



Avatar de l’utilisateur
fatal_error
Membre Légendaire
Messages: 6610
Enregistré le: 22 Nov 2007, 12:00

par fatal_error » 14 Juin 2015, 13:18

il faut voir la classe abstraite comme une classe (avec des cases mémoires) mais qui peut pas être instanciée.

genre, imagine un jeu de plateau carré (genre go)
tu peux avoir un jeu de damme et un jeu de go.
sur le jeu quelconque, tu as une méthode: peutPoserJeton()
a priori, tu ne sais pas retourner quoique ce soit car tu n'as pas de règles pour un jeu quelconque.
Donc au lieu de faire un truc fantaisiste, tu peux déclarer Jeu comme classe abstraite.

Par contre, tu peux overrider peutPoserJeton dans ton jeu de go.

Jusque là, tu pourrais dire: au lieu de faire une classe abstraite jeu, je crèe une interface IJeu, et mon jeu de go implémente IJeu (idem tu sais que ta méthode peutPoserJeton doit exister et tu dois la définir dans jeuGo).

Maintenant penses à un pattern du style:
Dans jeu::peutPoserJeton, tu appèles les méthodes:
isMoveInBoard() && isPlayerTurn() && hasPiecesLeft()...
ces méthodes ne sont pas exposées publiquement, mais elles sont appelées au sein de ta classe (et c'est jeu de go qui doit les implémenter (de manière protégées donc) )

Ben une interface ne répond pas à ce problème. ca ne fait que définir les méthodes qui sont exposées à l'utilisateur.
Avec une classe abstraite, tu peux définir des comportements (accès aux propriétés, appel de méthode protégées, "factorisation" de code pour les classes filles, etc.

maintenant quand est-ce que tu utilises une interface ...
je sais pas, je fais pas de java :)
la vie est une fête :)

Avatar de l’utilisateur
Rockleader
Habitué(e)
Messages: 2126
Enregistré le: 11 Oct 2011, 18:42

par Rockleader » 14 Juin 2015, 14:17

Ok, merci pour ton aide, si je trouve la réponse, je vous ferais signe également ici ;)
Cette histoire est entièrement vraie puisque je l'ai inventé du début à la fin !

Avatar de l’utilisateur
Zorro_X
Membre Naturel
Messages: 77
Enregistré le: 16 Avr 2012, 16:40

par Zorro_X » 14 Juin 2015, 15:07

Le problème est toujours le même, rien ne t'empêche dans la pratique de te passer des interfaces et de ne jamais les utiliser... Par contre lorsque tu rechercheras à rendre ton code "facile à comprendre" donc "maintenable" (reprenable aussi bien par quelqu'un d'autre que par toi même quelques années après avoir codé) tu vas chercher des solutions telles que les interfaces d'abstraction.

Petite parenthèse, dans les librairies fournies avec Java, la notion d'interface est presque systématiquement utilisée dans leurs objets pour permettre à l'utilisateur de définir des comportements ou un paramétrage spécifique. Chez Java ils sont en effet assez "fans" des fameux "design patterns" ("modèles de conception" en français), sortes de façon de faire "standardisées" pour modéliser et résoudre certains problèmes. Ces "design patterns" sont très basés sur la notion d'interface pour permettre de faire du code "générique" et qui peut évoluer facilement sans avoir à tout reprendre. Enfin, la connaissance des design patterns est de plus en plus demandée lorsque tu souhaites travailler (donc te faire embaucher) pour coder dans un langage objet... (si ca t'intéresse, ce livre est une excellente introduction avancée où ils prennent bien du début pour tout expliquer et bien l'expliquer : http://www.eyrolles.com/Informatique/Livre/design-patterns-tete-la-premiere-9782841773503 )

Pour en revenir à ta question, la notion d'interface sert donc à "abstraire" des fonctions, attributs ou comportements que tu souhaites rendre communs à plusieurs classes.
Pour reprendre un exemple qui ressemble au tien, supposons que tu travailles dans l'automobile et que tu souhaites pouvoir consulter combien de portes a une voiture quel qu'en soit le type/modèle : tu te fais une classe abstraite / interface, nomée "Voiture" qui contient la fonction "int nombreDePortes();", c'était un attribut, mais là tu le convertis en "interface". Toute classe qui hérite de "Voiture" devra implémenter sa fonction "nombreDePortes()" et renvoyer combien de portes elle a.
Maintenant suppose que t'as un modèle, disons "Super 5" au hasard qui s'est fabriqué en 3 & 5 portes, là tu peux créer ton attribut "int nombrePortes;" privé à ta classe "Super5", et dans ta fonction "nombreDePortes()" tu renvoies cet attribut.
En résumé, une interface qui n'est autre qu'une classe abstraite, sert à "forcer" ou "garantir" une interface pour toute classe qui en hériterait. Son utilité est certaine pour faire du code avec peu de dépendances et évolutif, mais cela vient avec les notions de "méthodes de conception" de ton code, dont les design patterns, qui sont très en vogue actuellement, en font partie.

Avatar de l’utilisateur
Rockleader
Habitué(e)
Messages: 2126
Enregistré le: 11 Oct 2011, 18:42

par Rockleader » 14 Juin 2015, 16:06

Je pense avoir saisi un peu mieux Zorro, pour être certain, je t'ai envoyé en mp le lien vers le sujet complet d'où j'ai extrait cette partie d'énoncé.
Cette histoire est entièrement vraie puisque je l'ai inventé du début à la fin !

Avatar de l’utilisateur
Rockleader
Habitué(e)
Messages: 2126
Enregistré le: 11 Oct 2011, 18:42

par Rockleader » 16 Juin 2015, 13:11

Après avoir posé la question à mon prof, pour le sujet que je vous ai montré, on aurait pu faire un interface OU une classe abstraite, les deux auraient marché.

Dans ce genre de situation, il faut prendre ce qu'il y a de plus flexible, et donc l'interface car il permet l'héritage multiple ce qui n'est pas le cas d'une classe.



Voilà voilà...
Cette histoire est entièrement vraie puisque je l'ai inventé du début à la fin !

Avatar de l’utilisateur
Zorro_X
Membre Naturel
Messages: 77
Enregistré le: 16 Avr 2012, 16:40

par Zorro_X » 16 Juin 2015, 15:44

En C++ t'aurais pas eu ce problème... :P

 

Retourner vers ϟ Informatique

Qui est en ligne

Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 3 invités

Tu pars déja ?



Fais toi aider gratuitement sur Maths-forum !

Créé un compte en 1 minute et pose ta question dans le forum ;-)
Inscription gratuite

Identification

Pas encore inscrit ?

Ou identifiez-vous :

Inscription gratuite