Discussion :

[dZastreux]

Salut adiGuba et merci beaucoup pour ta réponse.

Donc, pour transposer ton exemple, ( très clair, merci ) avec celui de Komando, le log devant être mis à jour de .txt dans la v.1 vers .xml dans la v.2, serait facilité de ce que :
Constituant une couche d'abstraction, une interface communément implémentée par ces deux-là ( txt & xml ) - genre "serializable" - serait un type d'Objet suffisamment abstrait et indifféremment utilisable en paramètre dans la fonction finale chargée d'écrire le LOG...Cette fonction d'arrivée pourrait éventuellement se charger d'identifier s'il s'agit ou non d'une instance de telle ou telle class, mais il n'y aurait pas besoin de changer le type dans chaque appel.

OK, j'achète ...Merci pour la démonstration

[Pacma]

Bonjour !

Sans vouloir rajouter de l huile sur le feu, quel est l intérêt des classes abstraites depuis la sortie de Java 8 ?

En effet, si j'ai bien suivi votre discussion, avant Java 8 nous étions dans cette situation :

Une classe abstraite permet de factoriser du code commun aux classes filles (attributs et méthodes avec signatures + code). Une classe abstraite permet aussi d obliger les classes filles à implémenter des signatures de méthodes identiques.

Une interface contrairement à une classe abstraite ne permet pas de factoriser du code. Une interface permet d obliger l utilisation de mêmes signatures de méthodes comme une classe abstraite.
Cependant, une classe peut implémenter plusieurs interfaces mais peut hériter que d une seule classe abstraite.

Or avec les méthodes "default" présentes dans Java 8, les seules différences entre une classe abstraite et une interface concernent les attributs (non présents dans une interface) et cette sorte d "héritage" multiple ?

Merci ! :-)

(Veuillez m excuser si mon post ne doit pas être dans ce topic, je trouve qu'il s y prête)

[adiGuba]

Cette fonction d'arrivée pourrait éventuellement se charger d'identifier s'il s'agit ou non d'une instance de telle ou telle class, mais il n'y aurait pas besoin de changer le type dans chaque appel.

Si tu vérifies le type exact (instanceof ou autre) tu sors déjà des clous. Bien souvent c'est pas trop utile.

Le truc c'est qu'en utilisant une interface tu ne t'imposes pas une implémentation, et donc tu peux en changer plus facilement.
En utilisant une classe c'est différent car tu dois soit passer par de l'héritage (qui ne sera pas forcément cohérent), soit par du refactoring (à condition d'être dans ton code à toi uniquement).


En utilisant une interface tu imposes uniquement un contrat à respecter, quelque soit la manière dont c'est fait.

Or avec les méthodes "default" présentes dans Java 8, les seules différences entre une classe abstraite et une interface concernent les attributs (non présents dans une interface) et cette sorte d "héritage" multiple ?

La grosse différence c'est justement que les méthodes par défaut ne peuvent pas gérer d'attribut, et donc d'état.
Ainsi elles ne peuvent se baser que sur le contrat de l'interface, sans connaitre son implémentation précise.

A l'inverse une classe abstraite peut définir une partie de l’implémentation, en gérant un état, etc.


a++

[dZastreux]

Si tu vérifies le type exact (instanceof ou autre) tu sors déjà des clous.

Oui, je comprends.
J'ai écris ça parce qu'au fond, utilisé comme ça, les interfaces ressemblent à un genre de "Casting"

les méthodes "default" présentes dans Java 8

Ah ben super ; je suis pas venu pour rien, avec toutes ces infos (merci) !
Je sors de 3 ans de LUA et autres scripts divers et je n'ai regardé à nouveau Java que depuis 3 jours...
( Donc autant vous dire que je dois parfois relire plusieurs fois ce que vous écrivez pour que ça rentre ! )
Par contre, juste pour confirmation, je lis ici :
http://muhammadkhojaye.blogspot.com/...in-java-8.html
"Java 8 introduces “Default Method” or (Defender methods) new feature, which allows developer to add new methods to the Interfaces without breaking the existing implementation of these Interface."
Si la formulation est correcte, ça signifie que,l'on restera dans l'obligation de procéder aux déclarations d'usage dans les nouvelles class écrites après la "default one" ?

La grosse différence c'est justement que les méthodes par défaut ne peuvent pas gérer d'attribut,

Là aussi, super explication adiGuba, merci
Pas de "this." dans les interfaces : C'est tabou ! ( Pour l'instant ? )

[thelvin]

Oui, je comprends.
J'ai écris ça parce qu'au fond, utilisé comme ça, les interfaces ressemblent à un genre de "Casting"

Ouais enfin, ça ressemble au fait de ne pas avoir besoin de casting... Puisqu'il n'y en a pas besoin.
Ce serait donc plutôt l'inverse.

Par contre, juste pour confirmation, je lis ici :
http://muhammadkhojaye.blogspot.com/...in-java-8.html
"Java 8 introduces “Default Method” or (Defender methods) new feature, which allows developer to add new methods to the Interfaces without breaking the existing implementation of these Interface."
Si la formulation est correcte, ça signifie que,l'on restera dans l'obligation de procéder aux déclarations d'usage dans les nouvelles class écrites après la "default one" ?

Non. La formulation indique que sans l'existence du mécanisme "default methods," lorsqu'on ajoute une méthode à une interface existante, cette méthode ne fournissant pas d'implémentation par défaut, toutes ses implémentations doivent être changées pour en fournir une. Les anciennes et les nouvelles.
Or, changer toutes les anciennes implémentations, c'est au moins monstrueux, et souvent impossible car c'est pas forcément nous qui les avons faites.

Avec les default methods les classes ne sont pas obligées de fournir une implémentation, ce qui veut dire que les classes existantes n'ont plus ce problème. Les nouvelles classes n'avaient déjà pas ce problème, donc pour elles ça ne change pas grand-chose.

[adiGuba]

Pas de "this." dans les interfaces : C'est tabou ! ( Pour l'instant ? )

Non tu peux tout à fait utiliser this dans une méthode par défaut !
Par contre this correspond à l'interface, et donc tu ne peux utiliser que ses méthodes (et donc pas d'attribut).

a++

[dZastreux]

Reçu, merci

[OButterlin]

Le gars n'ose même plus répondre... si ça se trouve, il ne se rappelle même plus de sa question après avoir lu tout ce que vous avez mis

Allez, j'en remets une couche : l'intérêt de l'interface est (à mon sens) plus à chercher du côté d'une classe utilisatrice.

Un exemple serait un programme de gestion d'objets mobiles (genre contrôle aérien, routier, etc...)
De ce point de vue, le contrôleur se fiche de savoir comment sera fait réellement l'action qu'il demande, lui voit des objets mobiles, c'est tout.
Pour un contrôle aérien, il demanderait de monter, descendre, aller à droite ou à gauche (pour un jet, ce sera très différent d'un hélicoptère)
En pratique, on aura donc une interface "Mobile" qui définira ces opérations (monter, descendre...)
On aura plusieurs classes qui implémenteront cette interface, Avion, Helicoptere etc...
Le "programme" de contrôle aérien verra une liste de "Mobile" et pourra interagir avec ces mobiles sans se préoccuper de savoir comment ce sera fait.

[dZastreux]

Salut OButterlin

Non, non, "le gars" a bien compris l'intérêt des interfaces, et les restrictions/possibilités ajoutées par les "default methods" de Java8 - même si sur ce plan-là, un peu d’expérimentation personnelle me vaudra sans doute d'affiner quelque-peu les "je peux" des "je ne peux pas" ( et donc d'éviter ici certaines questions ou suppositions supplémentaires superflues ).
...Du coup, "le gars" (moi) a préféré dire "merci" et ne rien rajouter de plus

Ton exemple du contrôle aérien, par exemple, est certes peut-être plus censé que les animaux lavables ...Mais ne m'aurait pas aidé car, comme pour la plupart des messages en début de ce thread, il avise du type de structure dont on parle, mais pas de l'intérêt pratique que cela peut constituer de coder ainsi.
Tu pourrais trés bien avoir une class ( abstract ou non ) "mobile" dont tu hérites différemment selon le type de mobile en question... Bref : C'est un exemple d'utilisation, pas une raison d'utilisation.

adiGuba, en particuliers, m'a fourni la réponse nécessaire à les envisager sous un nouvel angle pour désormais ne plus faire l'impasse sur elles :
L'utilisation d'interfaces offrira d'avantage de souplesse en ce qu'elle permettra le passage, en paramètre de fonction, d'un type plus générique d'objet...
Ce qui, comme l'a signalé thelvin constitue en quelque sorte l'inverse d'un Casting
"Le gars" te salue, modérateur OButterlin !

[adiGuba]

@dZastreux : je pense qu'OButterlin voulait plutôt parler d'opeo, l'initiateur de ce topic qui n'y a plus participé hormis le premier post


a++

[dZastreux]

Ah oui, certes ( "Le Gars", c'est un peu abstract quand-même ! ) ; 6 ans ! c'était il y a longtemps !!!
Ceci dit, le sujet était encore d'actualité, au moins pour moi, et je ne doute pas qu'il le sera pour d'autres, car avant d'arriver ici, j'ai écumé différents sites ( FR ou US ) et la question revient assez souvent.
...Ce qui prouve à mon sens, d'ailleurs, que le sujet est trop souvent mal expliqué, justement par le fait de défendre la cohérence de la structure au lieu de mettre l'accent sur l'intérêt pratique

[OButterlin]

Ah oui, certes ( "Le Gars", c'est un peu abstract quand-même ! ) ; 6 ans ! c'était il y a longtemps !!!

J'avoue, c'était un peu abstrait... d'autant que je n'avais même pas fait gaffe que ça datais de 2008 !
Mais comme l'avais compris adiGuba, je parlais d'opeo... il y en a au moins UN qui suit !

[Sennad]

Je trouve ça étrange que personne n'ai parlé de polymorphisme !
C'est pour moi l'utilité la plus importante des interfaces.
Avec le design pattern DAO / Factory ça prend tout son sens !

Mettons que j'ai une base de donnée mySql et mon programme java.
Je choisi d'utiliser mettons le driver jdbc pour pouvoir communiquer avec ma DB.
On pourra donc créer une classe d'accès aux données (Couche métier).
Cette classe s'appelle par exemple JdbcUserDao et a des méthodes du style addUser(String name, String passwd .... )
Je vais donc devoir de partout dans mon code appeler la méthode JdbcUserDao.addUser(nom, passwd ..)
Ce qui n'est pas top top.
On va donc créer une interface IUserDao qui a une méthode addUser(...)
la classe JdbcUserDao implémente cette interface et défini donc la méthode addUser().
On va maintenant créer une classe Factory, qui aura une méthode getUserDao() ressemblant à ça :

Code :

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

1
2
3
public static final IUserDao getUserDao() {
        return new JdbcUserDao();
    }

On utilise donc le polymorphisme pour retourner un JdbcUserDao sous forme de IUserDao.
On pourra donc faire ailleurs dans le code, Factory.getUserDao.addUser(nom, passwd ...) et ainsi ajouter un user a la DB sans savoir quel driver (ici jdbc) est utilisé.
Si un jour on souhaite changer de driver (je n'en connais pas d'autre donc on dira XX), on créera notre class XXUserDao qui implémente IUserDao, on sera donc obligé de créer la méthode addUser, et on aura SEULEMENT à changer le code de la Factory (return new XXUserDao), et nulle part ailleurs dans le code, puisque l'on récupère des IUserDao !

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
public interface IUserDao {
        void addUser(String name, String passwd ..) ;
}
 
public class JdbcUserDao implements IUserDao {
 
        @Override
        public void addUser(String name String passwd …) {
	        // Code (requette insert DB)
        }
}
 
public final class DaoFactory {
         public static final IUserDao getUserDao() {
      		return new JdbcUserDao();
   	}
}
public static void main(String[] args) {
	DaoFactory.getUserDao.addUser(“MonNom”, “MonPasswd” …);
}

Et c'est seulement une petite partie de ce que l'on peut faire avec ce pattern, et donc avec les interfaces!
Si tu veux plus d'infos sur ce pattern tu peux regarder ICI

J’espère avoir était assez clair !
A++

[thelvin]

Je trouve ça étrange que personne n'ai parlé de polymorphisme !
C'est pour moi l'utilité la plus importante des interfaces.

... Parce que le polymorphisme marche parfaitement avec des classes ?

[OButterlin]

Sauf erreur de ma part, ce que tu décris là n'est pas du polymorphisme au sens POO, c'est juste qu'en fonction d'une configuration, tu vas avoir telle implémentation de classe ou telle autre, le contrat (l'interface) restant le même.
Le point clé pour moi c'est qu'au travers d'une interface, on se fiche de savoir comment c'est fait, on demande juste à le faire.
L'objet lui doit être adapté en fonction de ce qu'il sait faire pour remplir ce contrat.

[Sennad]

... Parce que le polymorphisme marche parfaitement avec des classes ?

Et alors ? C'est pas parce que tu peux faire du polymorphisme avec des classes que ça n'a pas une immense utilité avec les interfaces Oo.
Je ne vois absolument pas le rapport.

Le point clé pour moi c'est qu'au travers d'une interface, on se fiche de savoir comment c'est fait, on demande juste à le faire.

C'est justement ce que j'ai expliqué.
On se fiche de savoir quel driver est utiliser derrière, mais combinant justement cette abstraction, avec du polymorphisme, on obtient une plus grosse abstraction de ce qui se passe "derrière".

C'est bien beau d'expliquer le fonctionnement d'une interface, mais là au moins on voit également l'utilité que ça peut apporter, combiné avec du polymorphisme.
On n’aurait jamais pu faire ça si on n’utilisait pas le polymorphisme et les interfaces, donc oui c'est du polymorphisme, dans tous les sens (POO ou pas, je vois pas quel autre sens le polymorphisme peut avoir...)

[thelvin]

Et alors ? C'est pas parce que tu peux faire du polymorphisme avec des classes que ça n'a pas une immense utilité avec les interfaces Oo.
Je ne vois absolument pas le rapport.

Ça a pas de sens ce que tu dis. Tu nous demandes pourquoi on parle pas du polymorphisme comme intérêt des interfaces. Parce qu'on n'a pas besoin d'interfaces pour en faire bien sûr. On peut déjà le faire sans interface, et c'est la même chose. La question posée ne verra clairement rien dans cette réponse.

[Sennad]

Mais ta pas compris que je parle de faire encore plus d'abstraction qu'avec une simple interface, en ajoutant le polymorphisme.
Interface + polymorphisme = Abstraction élevé.
Chose que tu ne peux absolument pas faire avec de simples classes.
Donc oui le polymorphisme a un grand intérêt avec les interfaces.

[thelvin]

Alors, plusieurs choses :
- On ne peut pas "ajouter" le polymorphisme aux interfaces. Sans ton idée de polymorphisme, les interfaces n'existent pas. Elles n'ont pas d'implémentation, donc elles sont incapables de servir à quelque chose s'il n'y a pas moyen de leur fournir une implémentation. Et forcément on peut en fournir plus d'une, sinon la notion même n'aurait aucun intérêt.
Le polymorphisme va de soi avec les interfaces, il n'y est pas ajouté, il est évident, inévitable.

- Oui, on peut faire tout ce que tu as décrit avec des classes plutôt qu'avec des interfaces. Je ne sais pas pourquoi tu te figures le contraire.
Ce serait moins flexible du fait d'impossibilité d'héritage multiple, c'est vrai. Mais ça veut dire que l'intérêt des interfaces ici, c'est leur système de sous-typage multiple. Et oui, nous en avons parlé.

Ce qu'il faut retenir c'est que c'est moins intéressant de le faire avec des classes. Parce que les classes imposent des contraintes, ou peuvent potentiellement imposer des contraintes, dont nous n'avons pas besoin. Utiliser une interface à la place permet de mieux comprendre l'enchaînement des classes, et d'éviter des erreurs de conception. C'est ça qui est important.

[Mao237]

Oui d'accord, mais ça n'explique toujours pas ce qu'apporte les interfaces...