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...