Bonjour à tous,

je me permet de faire un petit sujet, car je me pose une question d'ordre général. Je suis plutôt programmation orienté objet, on utilise donc pas mal tous ce qui est interface et les class abstraite. J'ai un niveau plutôt moyenet donc je suis encore loin de maîtriser le tout. Néanmoins plus je lis des choses sur l'abstraction plus je me demande si trop d'abstraction ne peu pas posé un problème. Bref avant que j'embrouille tous le monde, je pose ma question le plus simplement du monde :

Est ce qu'un des but d'un programme orienté objet et de pouvoir faire un maximum dans l'abstrait ? C'est a dire utlisé de préférence les 'abstract' et 'interface' que les objet en eux même ?

Si ça se trouve cette question est complètement idiote, mais j'ai l'impression qu'on pousse la plupart du temps a passé par ces choses là. Et j'ai du mal a saisir le pourquoi du comment, ou si c'est juste moi qui me retrouve avec cette idée en tête a force de le lire et d'utiliser ces choses là.

Voilà, merci si vous prenez le temps de me fournir une réponse, ou même si vous avez un article sous la main qui peu éclairer cette interrogation.

Bonne journée

Oui trop d'abstraction peut etre un probleme. C'est un probleme typique des programmes oriente objets de faire trop d'abstraction. Ca rends la programmation du logiciel plus complique au final parcequ'il faut traverser 40 abstraction pour atteindre la donnee qu'il te faut.

Un exemple typique de trop d'abstractino apparait en C++ avec Boost. (bon ok, c'est un probleme de template et pas d'objet.) C'est cense etre une lib abstraite pour tout faire et tout est parametrique. En pratique, j'arrive pas a me servir de la moitie parceque c'est impossible de comprendre comment ca marche.

Ouai j'avais plus ou moins évaluez la même chose. Plus l'abstrait et présent moins on capte exactement. Enfin ca me conforte dans mon idée. Merci de ton intervention en tous cas

Cependant, pas d'abstraction du tout est certainement une mauvaise chose egalement. Il faut trouver la bonne balance.

Les avantages de l'abstraction, c'est :
- d'avoir les composants les plus génériques possibles, afin de pouvoir les réutiliser le plus simplement possible dans d'autres contextes.
- de séparer un peu mieux implémentation et utilisation : en Java par exemple on peut manipuler des List sans se préoccuper de savoir si ce sont des ArrayList ou des LinkedList. Par exemple, récemment j'ai du développer une interface de communication avec un simulateur, pour cela j'ai créé une interface SimulatorInterface puis une classe NetworkSimulatorCommunication qui implémentait l'interface précédente, puis dans mon code je faisais systématiquement référence à SimulatorInterface et non à NetworkSimulatorCommunication. De cette manière, je sais que si à l'avenir un autre moyen de communication que le réseau venait à être choisi (par exemple des IPC), alors il me suffirait de créer la nouvelle classe assurant la communication, et de remplacer une seule et unique ligne (l’instanciation de ma SimulatorInterface) pour le reste du programme.

Personnellement je suis un fervent défenseur d'un maximum d'abstraction dans un programme. Mais il faut que ce soit bien fait. L'architecture d'un programme ça se réfléchit sagement et ça ne se code pas à l'arrache. Mais globalement j'utilise les generics autant que possible (même si au final je ne l'utilise que pour des structures de données), idem pour les interfaces, afin, comme je l'ai dit précédemment, de pouvoir séparer au maximum utilisation et implémentation, et par contre j'utilise avec énormément de précautions l'héritage, et quasi-uniquement pour économiser de l'écriture de code.

Au niveau conception, je préfère par moment utiliser les interfaces, mais j'ai toujours une impression que je risque de m'embrouiller tôt ou tard...Mais certainement que c'est dû à mon peu d'expérience avec l'utilisation de tous ca. J'imagine que lorsque maîtrise bien la conception de l'architecture avec beaucoup d'abstraction on ne se sent pas si perdu.

Quoiqu'il en soit, mon prochain projet se finalise sur le papier, je pense que je vais tenter d'appliquer ca au mieux pour la réutilisabilité (c'est francais comme mot ca ? ^^) de mon code pour l'avenir, c'est un peu l'objectif au final.

Merci pour vos commentaire