Avez vous des conseils pour débuter sereinement ?

Bonjour à toi,

Attention dans un premier temps je vais te raconter mon expérience avec le C++ (ma vie en gros :mouarf:) donc tu peux directement sauter cette partie (jusque les "#####" voilà ^^)


j'ai toujours été attiré par la programmation, je dois dire que j'ai commencé par la programmation orientée Web car elle est nettement plus accessible que la programmation logicielle :roll:.
Depuis quelques temps déjà j'aimerai passer à la vitesse supérieur, quitter le PHP et donc commencer à apprendre le C++. Je dois dire que ce ne sont pas les essais qui ont manqués :

j'ai tout d'abord commencé avec le "méga cours" de Christian Casteyde,
puis j'ai poursuivit avec le livre "Le Langage C++" de Bjarne Stroustrup,

Je dois avouer que j'ai du faire face à une absence cruelle de progrès et aussi faire face à mon incompréhension de la Programmation Orientée Objet. Pour alourdir un peu la peine que j'avais à apprendre le C++ j'étais en classe préparatoire et je n'avais pas d'ordinateur durant cette période. Je me suis donc dissipé et ai au final abandonné l'apprentissage du C++.

J'ai intégré un école et cette année nous avons suivit des cours de C et d'UML, ceci a ravivé mon envie de programmer. Aussi j'ai un laptop maintenant, ayant installé ma distribution linux préférée je désire participer à son developpement dans la mesure de mes capacités.

(bravo & merci aux courageux qui ont suporter la lecture de ma vie)


#####


Voilà je désire partir sur de bonne base et ne pas reproduire mes erreurs passées, c'est à dire je ne veux pas me lancer tête baissée dans un mur :aie:. J'aimerai que justement vous m'expliquiez quel a été votre façon d'apprendre, si vous avez eu des cours en école, si vous avez eu un mentor, si vous avez appris seul, ce que cela vous à apporter ce que vous regrettez par rapport à ça.

Si vous avez été mentor ce que vous avez apris de cette expérience grâce à votre padawan.

Si possible j'aimerai aussi que vous me conseillez une méthode d'apprentissage qui se présentera être efficace. Quelles étapes je devrais suivre, comment dois je progresser, comment valider mes connaissances et comment appliquer mes acquis.

Mon but ultime étant : je désire créer un traitement de texte (style mousepad - http://www.xfce.org/projects/mousepad/)

Aussi dans mon apprentissage j'aimerai utiliser que des outils gratuits (bibliothèques). j'ai pour l'instant code::blocks, le compilateur GCC, mon OS est une gentoo fraichement réinstallée. Voilà je penses être paré.

N'hésitez pas à être réaliste même si ça peut metre un coup au moral autant que je sois prêt à ce qui viendra après.

J'espère ne pas subir de modération et ne pas avoir fait trop de fautes :s
Merci d'avoir pris le temps de me lire, et Merci d'avance à ceux qui prendront le temps de me répondre. Très bonne soirée à vous.

Citation:

---

J'aimerai que justement vous m'expliquiez quel a été votre façon d'apprendre, si vous avez eu des cours en école, si vous avez eu un mentor, si vous avez appris seul, ce que cela vous à apporter ce que vous regrettez par rapport à ça.

---

En ce qui me concerne, c'est un peu par hasard que je suis tombé dedans, de la prog je parle, un peu paumé à mes 18 ans sur ce que je voulais faire, j'ai essayé une école d'info, j'ai adoré.
Un premier diplôme en poche, j'ai travaillé quelques temps, puis retourné sur les bancs d'école pour un autre, que je suis en train de compléter.
Ce que m'apporte la programmation? De la stimulation intellectuelle sans fin
Ce que je regrette? une stimulation intellectuelle sans fin :aie:
Mouais, parfois quand je regarde des amis dans d'autres domaines, ils n'ont pas à se former continuellement sur de nouvelles technologies, de nouvelles versions de <mettre ce que tu veux ici>, de nouvelles plateformes, bref ça ne finit jamais, c'est pire qu'un Gom Jabbar ce domaine :D Quelques périodes de lassitudes qui finissent, pour le moment, toujours par passer.

Citation:

---

Si possible j'aimerai aussi que vous me conseillez une méthode d'apprentissage qui se présentera être efficace. Quelles étapes je devrais suivre, comment dois je progresser, comment valider mes connaissances et comment appliquer mes acquis.

---

Difficile d'énoncer une seule méthode, il doit y en avoir autant que de programmeurs je dirais. Cela dit, en ce qui me concerne, les premiers temps, j'étais plus prés du code, mon univers se résumant aux classes et fonctions....puis avec l'école et le travail, des projets plus gros...et là, simplement bien connaitre son langage ne suffit plus, en plus de devoir apprendre à bien coder(de saines habitudes pour minimiser les bugs), il faut apprendre à faire beaucoup plus d'abstraction, du génie logiciel, de l'analyse, de la conception avec de l'UML , les designs patterns, et on s'aperçoit que souvent, ces parties sont encore plus critiques que le code en lui même.
C'est souvent cette partie qui est dure, car moins concrète que le code qu'on peut exécuter la-tout-de-suite-maintenant.....et qui ne doit pas être facile à apprendre en autodidacte.
Bref, si je devais résumer ma vision des choses: bouffer du code un premier temps, en veillant à apprendre les bonnes habitudes de codage, tâter de plusieurs langages, bien comprendre la la programmation objet et les pièges à éviter( BAD SMELLS IN CODE et autres )...et faire passer tout ça par de solides notions de génie logiciel(à moins de vouloir être un monkey coder toute sa vie)
Ah oui....et l'anglais...ne pas hésiter à s'améliorer la dedans, car même si Developpez est une source francophone géniale(je commence toujours par là :D), l'informatique reste en anglais, se restreindre juste au français, c'est se fermer des portes, suffit de voir le nombre de frameworks, outils, libraires donc la doc est en anglais.

Si tu as des questions plus spécifiques, n'hésite pas!

La voie du Fedaykin est longue, mais riche d'apprentissages.
Bon courage!

Avant de te dire merci Galateo j'aimerai te dire que tu es un grand malade de Dune, ce que tu dois surement savoir depuis belle lurette; mais c'est quelque chose qui m'a beaucoup plus dans ton message :king: c'est mon livre préféré :yaisse2: !! Voilà ça c'est dit je peux (enfin) te dire : Merci !

Dans mon école nous venons d'approcher l'UML, l'OO devrait bientôt suivre, car c'est vraiment un domaine que je n'arrive pas à me représenter ni même à comprendre l'intérêt. Enfin c'est comme les pointeurs en C il y a quelques années :D je penses qu'un jour ça "popuperas" dans ma tête et que je comprendrai.

En ce qui concerne tâter de plusieurs langages je ne penses pas être capable de pouvoir tester autre chose que du C++. Je ne sais pas pourquoi je suis exclusivement réservé au C++ ;). Ce qui me rassure c'est que j'adore l'anglais donc ce ne sera pas un point faible pour moi.

Faut il apprendre pour faire un projet ou faut il faire un projet pour l'apprendre ?
Est il préférable d'appliquer ce qu'on apprends dans un "projet" ou faire du code brute ça suffit, comme par exemple des tableau de tableau de pointeurs qui pointent vers des tableurs etc etc ... ?

Tu as eu l'opportunité d'apprendre dans une école d'info, moi normalement l'année prochaine je me retrouve dans un tout autre domaine, le Bio-médical. Donc je voulais savoir, peut on se passer d'après toi d'un apprentissage académique de l'UML ou du génie Logiciel & cie.

Merci encore,
Shai.

Citation:

---

Avant de te dire merci Galateo j'aimerai te dire que tu es un grand malade de Dune, ce que tu dois surement savoir depuis belle lurette; mais c'est quelque chose qui m'a beaucoup plus dans ton message c'est mon livre préféré !! Voilà ça

---

Je ne vois vraiment pas de quoi tu parles....;)

Citation:

---

dans mon école nous venons d'approcher l'UML,

---

Excellent, c'est le "langage" à connaitre pour la modélisation, si tu n'as pas encore fait de l'OO ni de la BD, l'intérêt ne sera pas évident encore, mais ça viendra.

Citation:

---

l'OO devrait bientôt suivre, car c'est vraiment un domaine que je n'arrive pas à me représenter ni même à comprendre l'intérêt.

---

L'OO est un paradigme de programmation, pour le moment, tu es dans la programmation impérative, l'OO va venir changer la façon même que tu auras d'appréhender le "monde" que tu veux représenter, puisque l'OO se base sur une représentation par objet: dans l'impératif, pour representer des utilisateurs, tu vas avoir un tableau de string par exemple, avec des fonctions qui s'appliquent dessus, mais sans aucun lien direct à ce tableau, et qu'on pourrait appliquer à d'autres tableaux, bref, aucun regroupement "logique", par sémantique, fonction, l'OO, on va avoir une classe utilisateur, avec ses propres données, ses propres fonctions, et on va pouvoir instancier un objet de cette entité logique, qui va intéragir avec son envirronement(d'autres objets d'autres classes). L'intérêt de tout ça? plus tes projets grossiront, plus il devient difficile de modéliser/structurer le "monde", car les informations deviennent complexes, l'OO aide, en partie seulement, à alléger cette complexité. On me propose un projet de bibliotheque, avec des usagers , des employés, des documents, des prets, tout de suite, je visualise au minimum les classes dont je vais avoir besoin(enfin, en simplifiant énormément). Mais bon, c'est la façon dont moi je percois l'OO, maintenant j'ai tâté d'un autre type de programmation, avec Haskell, et j'ai eu de la difficulté au début, car mon cerveau était devenu trop formaté par OO...c'est le propre des paradigmes, pire que le Bene Gesserit, on ne voit plus les choses que sous une certaine perspective.

Citation:

---

Enfin c'est comme les pointeurs en C il y a quelques années je penses qu'un jour ça "popuperas" dans ma tête et que je comprendrai.

---

Ah les pointeurs....que de vieux souvenirs!

Citation:

---

En ce qui concerne tâter de plusieurs langages je ne penses pas être capable de pouvoir tester autre chose que du C++. Je ne sais pas pourquoi je suis exclusivement réservé au C++ .

---

De ce que je comprends, tu as fait du C, puis du C++....excellentes bases, après, si tu voulais, le passage vers Java, C# ou autre serait un jeu d'enfant. Ceci dit, quand on aime un langage, pourquoi en changer?

Citation:

---

Faut il apprendre pour faire un projet ou faut il faire un projet pour l'apprendre ?

---

Je pense qu'on a évidemment d'une base pour commencer un projet, mais après c'est le projet qui t'imposera ses problématiques propres, et donc des recherches de solutions et des séances d'arrachage de cheveux, qui font qu'on approfondit vraiment les choses.

Citation:

---

Est il préférable d'appliquer ce qu'on apprends dans un "projet" ou faire du code brute ça suffit,

---

heu, je ne comprends pas trop cette question, quand tu dis ce qu'on apprends, de quoi parles tu?

Quant à faire du code brute(ce que je comprends de ça, c'est démarrer son projet en codant directement), il suffit d'avoir un projet moindrement moyen, et c'est le plantage presque assuré. Enfin non j'exagère, ça va finir par fonctionner, mais ça prendra fort certainement plus de temps, et on ne parle même pas si tu as à faire des modifications dessus quelques mois plus tard ou si quelqu'un d'autre à travailler dessus. Mais bon, je dis ça, mais ce n'est pas tout à fait vrai, il existe des méthodes de génie qui vont un peu dans ce sens, je pense à l'agile, surtout au XP(Xtreme Programming), mais même là, y a certaines règles et façons de faire!

Citation:

---

comme par exemple des tableau de tableau de pointeurs qui pointent vers des tableurs etc etc ... ?

---

Ou comment devenir masochiste :aie:

Citation:

---

peut on se passer d'après toi d'un apprentissage académique de l'UML ou du génie Logiciel & cie.

---

La réponse est oui! tout est faisable, ca dépendra de ta volonté, à l'école, les profs sont surtout là pour nous guider dans l'apprentissage en nous mâchant les notions de base, mais après, c'est surtout dans les bouquins qu'on va chercher le cœur de la matière.
Alors sans vouloir devenir un pro de l'analyse, mais comprendre les bases, de la conception(patterns par exemple), de bons bouquins judicieusement choisis(et ça tombe bien, la section de livres suggérés/sujet de Developpez est excellente en général) et bien potassés suffiraient! Mais faut être motivé pour passer au travers de tout ça, seul dans son coin!


Mais bon, là c'est aller trop vite, avec l'OO, tu en as déjà pour un bon moment, il sera toujours temps quand le besoin s'en fera ressentir de passer au reste.

Voilou!

Bonjour,

Première chose que j'aime dire c'est : "C'est en programmant que l'on devient programmeur"
Je dirai qu'il n'y a pas de miracle, le meilleur moyen d'apprendre c'est de pratiquer. Car lorsque l'on pratique on tombe sur des problèmes nouveaux, qui demande un peu de patiente, un peu de recherche, mais qui apporte de la joie ( oui on est heureux quand on vient de trouver ce qui deconnait ), et surtout de l'expérience ( la prochaine fois que tu vois ce problème tu sera quoi faire ;) ).
Autre chose, certe tu as un projet de faire un mousepad like :p , je ne saurais trop te conseiller de le garder pour plus tard ( enfin je suis pas sur de ce que dit, mais si tu te lance maintenant et que tu te trouve confronter à trop de problèmes cela va te décourager, et après il se peut que tu es moins envie de recommencer le même truc ). Pour ce projet là il te faudra surement une reflexion ( style UML ) avant de commencer, pour ne pas partir dans tout les sens et faire une base solide.
Et pour finir avec la partie projet, comme il te faut apprendre, commence par faire des petits projets ( je parle pas de faire des tableaux de pointeurs qui pointe sur des tableaux de structures de pointeurs ( je trouve cela un peu exagéré, même si je ne suis pas contre qu'il faut apprendre les structures de données de base , liste chainées , arbres ... ) ), mais comme petit projet, si demain tu te lève, et que tu te dise tient je veux faire un pendu , bah suis ton envie et prend du plaisir. ( Bon le pendu, il y a pas trop d'objet dedans ), par contre une sorte de jeux de roles consoles ( même non interactif avec evenement simple et statique ( codé en dur dans le code) est un bon exercice pour de l'orienté objet. ( Merci à un des profs que j'ai eu, pour avoir concocter un sujet de ce style, pour apprendre entre autre les foncteurs ).

Finalement, je vais parler un peu de moi, l'UML j'ai jamais aimé cela, je le laissé toujours à mon camarade, et je coder plus, ( souvent salement, vive les mauvaises habitudes ) directement sans reflexion. À l'ecole nous commencions le C++, je n'arrivais pas à appliquer la notion orientée objet et je voyais pas à quoi cela servait. Nous avons continuer, je m'en sortais du mieux que je pouvais, et puis maintenant je ne code plus qu'en C++ , très orientée objet. Donc effectivement ( peut être comme pour les pointeurs ) il y a une sorte de déclic.
Maintenant je vois le C++ et l'orientée objet, comme un mur de brique ( ou un jeu de lego ) au debut, on prepare le design de l'application ( architecture de notre mur de brique ) et on commence par faire des classes simples qui seront les foncdations. Après on va rajouter des briques, qui peuvent être des classes hérités des autres ou encore, de nouvelles classes qui s'implémentent. ( Bon j'arrête avec une comparaison que j'arrive pas à trop à expliquer ). Mais ce que je veux dire, le C++ c'est un truc ou tu construit une class, tu la test, et puis une fois que tu la testé tu sais qu'elle marche et tu la laisse tranquille. Tu n'y touche presque plus. Tu sais qu'elle marche et tu ne fais que la reutiliser. Après dès que tu as besoin d'une nouvelle fonctionnalité, tu rajoute une class, qui elle aussi sera testé, mais que tu sais que il n'y a qu'elle qui peut faire des bugs pendant cette phase, car tu es sur de ce que tu as fait auparavant. Ainsi au fur et à mesure, tu va construire ton application en rajoutant des morceaux. Et c'est ça le C++ un truc que tu peux ajouter facilement des morceaux, qui est "sans bug" et entièrement réutilisable .

Voilà ( en espérant ne pas avoir raconter trop de betises ).

Bonne chance, si tu veux continuer de coder, sans avoir de cours, et même , en ayant d'autre cours, j'ai peur que tu n'ai pas trop le temps de tout faire (enfin c'est toi qui voit ;) ).
Dès que tu aura des problèmes ( ce n'est pas spécialement ce que je veux que tu ai ) n'hésitent pas à poster sur le forum ;)

Pour commencer trouve toi un bon bouquin et potasse à fond. Y'a pas de solution miracle. (y'a plein d'exemple de bon bouquin sur ce site).
Pose des questions, ça fait beaucoup avancé, lis lis et relis. Et code deux fois plus que tu lis :p.
C'est en forgeant qu'on devient forgeron. x)

Salut, et bienvenue sur le forum

Je n'ai pas lu toutes les réponses, dont certaines m'ont semblé aussi longues que les fois où je suis personnellement pris de diarrhée mentale face à une explication (et tu te rendra compte à l'usage du forum que je suis un habitué du fait:D:P)

Je vais donc peut être répéter des choses qui ont déjà été dites ;)

J'ai la conviction que, pour obtenir quelque chose de correct en programmation, plusieurs points sont réellement importants:

• analyser correctement les besoins et les directions dans lesquels ils sont susceptibles d'évoluer
• Concevoir une "architecture" pour ta création qui permette, non seulement de respecter les besoins actuels, mais qui permette également à ta création d'évoluter en fonction des besoins futurs
• disposer des algorithmes les plus adaptés à l'obtention du résultat souhaité
• Etre en mesure de choisir les outils les mieux adaptés à l'objectif final

NOTA:Les trois premiers points sont importants, mais sont tous susceptibles d'être repris en cours de développement:

Il n'est pas rare que, lorsque tu commence à coder quelque chose, tu te rende compte que tu n'a pas pris un point particulier en compte, qui peut être au choix un besoin non évoqué (nécessitant de revenir sur l'analyse des besoins), non pris en compte (nécessitant de revenir sur conception) ou non étudié dans sa phase active et logique (nécessitant de revenir sur les algorithmes)

L'analyse des besoins correspond finalement au fait d'énoncer correctement ce que tu veux et les spécifications particulières qui concerne ce que tu veux...

C'est donc principalement basé sur une capacité d'écoute et de compréhension de la personne qui demande le développement ;)

Le fait de prévoir l'évolution des besoins revient souvent à jouer à "madame irma", mais, l'une des bonnes pratiques pour y arriver consiste déjà "simplement" à se demander si, pour un besoin particulier, nous ne risquons pas "plus tard" de nous retrouver face à un besoin "presque" identique, mais adapté à une situation donnée.

La conception de l'architecture de l'application fait appel à des techniques telles que l'UML, rose, etc et doit prendre en compte au minimum les besoins actuels, et, *idéalement* prévoir justement, qu'un besoin puisse évoluer ;)

Un exemple qui te permettra surement d'en comprendre d'avantage sur l'évolutivité des besoins est la discussion sur la gestion des lecteurs de cartes banquaires dans laquelle nous nous sommes rendus compte que, bien qu'il n'y en ait que deux à prendre en compte pour l'instant, il n'était pas exclus d'en voir la liste croitre et se multiplier...

Un principe à garder en permanence en tête est celui de la "délégation des tâches": Si "quelque chose" (une classe, une fonction, ou quoi que ce soit d'autre) a plus d'une responsabilité, c'est sans doute... que ça a trop de responsabilités ;)

L'algorithme a pour but d'indiquer clairement la logique à suivre pour, en partant d'un point connu, être sur d'obtenir un résultat prévisible et souhaité.

A titre personnel, j'apprécie énormément la méthode du "nassi-schneiderman" (j'hésite toujours sur l'orthographe :aie:) éventuellement couplée à la méthode "jackson" s'il s'agit de gérer des ruptures...

Mais d'aucuns estiment que le nassi-schneiderman fait un peu trop "petit dessin"... je te laisse seul juge sur ce point ;)

Il faut aussi être conscient du fait que certains concepts tels que les structures de contrôle sont communs à tous les langages (y compris au PHP), que certains autres (comme l'héritage ou l'encapsulation des données) sont communs aux langages orientés objet, et que d'autres enfin son "typique" du langage que tu étudie (C++ a une manière "bien à lui" d'envisager l'héritage multiple et / ou le polymorphisme, par exemple)

Le choix des outils enfin va dépendre d'une foule de facteurs et d'appréciations plus ou moins personnels, comme le souhait de faire quelque chose de portable, le "feeling" que tu as par rapport à une bibliothèque externe ou à un EDI (Environnement de Développement Intégré) et de facteurs clairement plus objectifs, comme la capacité de l'outil à te permettre d'atteindre les objectifs fixés (si tu veux que ton application soit en mesure de discuter avec d'autres ordinateurs via un réseau, il faut trouver l'outil qui te permettra de gérer cette discussion ;))

A titre personnel, j'ai suivi des cours du soir, où j'ai appris plus ou moins simultanément:

1. l'algorithmie, la conception de base de données (finalement, la conception d'une table de base de données est fort proche de celle d'une structure de données de programme ;)), l'utilisation de Access suivie de l'utilisation d'Oracle et le C
2. La conception de bases de données (deuxième partie), l'utilisation de SqlServer et COBOL
3. La conception de base de données (troisième partie), la conception OO, Java, C++, C#, VB.net

Il y avait d'autres cours, mais qui n'ont pas énormément de rapport ;)

Le fait est que l'on peut considérer le fait d'écrire le code qui suit la logique mise au point, quel que soit le langage envisagé, comme "un long et fastidieux travail de dactylographie" car, "dans un monde idéal", tout le travail intéressant aura été fait bien avant d'écrire la première ligne de code ;)

Par contre, il est aussi vrai que, surtout quand on débute, le fait de pouvoir "juger sur pièces" ce que l'on a fait est souvent source de joie, quand ca fonctionne ;)

Pour ce qui est de l'apprentissage du C++ en lui-même, s'il y a un conseil à garder en permanence en tête, c'est de privilégier les solutions propres au C++ à toute alternative issue du C...

Beaucoup de cours, de tuto et même de profs considèrent que, comme le C++ dérive du C, il reste cohérent d'utiliser les méthodes issues du C pour apprendre le C++.

De mon avis personnel, cette optique est tout à fait erronée: il ne suffit absolument pas d'inclure <iostream> au lieu de <stdio.h> et d'utiliser cout et cin à la place de printf et de gets, voir d'utiliser new au lieu de malloc pour programmer en C++ plutôt qu'en C ;)

Le C++ fournit en effet de manière standard énormément de classes et de fonctions très largement plus sécuritaires et plus faciles à l'utilisation que ce qui se fait en C:

• La classe string remplace parfaitement la chaine de caractères "C style" (le tableau de caractères terminé par '\0'
• La classe vector remplace parfaitement... les tableaux dont la taille est gérée dynamiquement
• Les conteneurs standard remplacent "idéalement" tout ce que tu pourrais faire en C pour gérer une pile, une file, une liste ou un tableau associatif d'objets divers
• ...

Enfin, je resterai dans la lignée des intervenants précédents pour te conseiller de partir sur des projets plus "simples" pour commencer...

Cela te permettra d'évoluer plus "sereinement" et de pouvoir faire appel à ce que t'auront appris les problèmes auxquels tu as déjà été confronté pour trouver une solution adaptée sur des gros projets ;)

D'autant plus si le projet est destiné à être géré par la suite par plusieurs personnes: la complexité d'un projet est exponentielle au nombre d'instructions qui le composent et au nombre de personnes qui travaillent dessus ;)

Tu peux, te baser sur les défis C qui sont régulièrement lancés (il est possible de les résoudre en C++ ;)) pour trouver les idées de "petits projets" d'études ;)

Le dernier défi en date a été clôturé dimanche, c'est donc un peu tard pour essayer d'y participer, mais un nouveau défi sera lancé dans deux semaines ;)

Un livre récent qui me semble particulièrement bon pour démarrer (y compris pour un 'faux débutant') serait l'ouvrage tout récent du concepteur et implémenteur de C++, Bjarne Stroustrup :
Programming, Principles and Practise Using C++
Voir le site du livre :
http://www.stroustrup.com/Programming/

Pour le débuter sereinement, c'est comme l'a dit Koala: privilégie l'approche moderne plutôt que l'approche historique.
(AC++ c'est bien, mangez-en, on le le répètera jamais assez)

Pour le perfectionnement. Pratiquer. Pratiquer. Et recommencer.
Personnellement, j'avais beaucoup appris grâce aux forums (fclc++ pour le citer). Essaie de lire les discussions qui passent. Au début observe, cherche la solution. Arrivera un moment où tu te sentiras de proposer des solutions. Au début on les reprendra, et puis au fur et à mesure tu progresseras et reprendras les solutions proposées par d'autres.


Pour l'OO, le premier point clé, c'est l'abstraction : la notion de type abstraits de données. Un pile ou une liste, on se moque de savoir comment c'est réalisé, ce qui compte c'est de savoir que l'on peut enfiler des éléments d'un côté, et les récupérer du bon par la suite. C'est aussi comme FILE en C: pas besoin de savoir comment c'est foutu dedans. On a un jeu de fonctions qui s'appliquent dessus, et c'est d'elles dont on se sert.

Le second point clé c'est, c'est la substituabilité. Reprenons FILE. Certains sont des fichiers, d'autres sont des pipes et pourtant les fonctions de lectures/ecritures sont essentiellement les mêmes. Quelques part on pourrait vouloir aller plus loin et se dire que c'est pareil pour des zones de mémoire, ou ce qui arrive depuis des sockets. (et voilà le polymorphisme d'inclusion)

Merci à tous pour vos réponses.

j'espérai poster une réponse digne des votre mais le fait est que vous écrivez beaucoup trop :mouarf: en remettre ça au lendemain n'a pas été une bonne solution :).

Anyway, je suis en train de tourner mon cerveau dans tous les sens pour trouver un "projet" applicatif, je ne cherche pas non plus un projet simple ni un projet complexe. Par exemple faire un automount de device externes pour linux mais j'ai peur que le projet se révèle beaucoup, beaucoup plus complexe que supposé :D si vous avez un avis sur la question j'aimerai beaucoup l'avoir.
J'ai pensé au programme des plus inutiles au plus rébarbatifs en passant par les plus communs et ...... j'avoue bloquer.

Si vous avez des sujet qui vous viennent "à la volée" n'hésitez surtout pas à me faire partager s'il vous plait :D.

C'est rigolo ça doit être une question récurente : "ouiiiin je sais pas quoi coder :("

Merci encore pour vos conseils et vos avis :)