Salut tout le monde

J'avais déjà commencé un peu à apprendre le C++ il y a 2-3 mois et j'aimerais reprendre, j'avais abandonné à cause de la POO et du manque d'imagination.

(Ca me fait mal d'écrire un tas de ligne en POO tout en sachant que je suis extrêmement mauvais pour avoir au final une fenêtre qui te dit une phrase selon ce que tu écris (c'est un exemple))

Je voulais savoir en combien de temps je pourrais apprendre à faire des fenêtres stylisées, modernes avec tout plein de boutons à l'intérieur ?

Et aussi comment ne pas abandonner ? Parce que la POO j'la sens vraiment pas trop

Merci!

Bin, en prenant une bibliothèque qui n'utilise pas un langage POO.

Mais bon, des langages non POO, y en a plus des masses, reste plus que les langages fonctionnels, et si t'as du mal en POO, en programmation fonctionnel, c'est vraiment pas gagné.

Faire des fenêtres avec des boutons, c'est pas le plus dur, très loin de là.

Que la POO ne te soit pas naturel, c'est normal.

Si tu ne comprends pas tout, c'est pas trop grave, on apprend de ces erreurs, mais faut prendre la peine d'essayer.

Arrête l'informatique ? La POO n'est pas ce qu'il y a de plus compliqué, si tu n'y arrives pas, peut être n'es tu pas fait pour la programmation

Si tu continues le C++, cela te prendra de toute façon des mois pour apprendre les bases. Si tu continues plus loin, c'est plusieurs années d'apprentissage pour maîtriser

"Dans un voyage, le plus long est de franchir le seuil."

Si tu veux des coups de pieds au cul pour te motiver, t'as trouvé une bonne adresse.

gbdivers, piques pas mon rôle de méchant.

Salut ,

Alors comme disait Bacelar, la POO n'est pas évidente au début mais tu vas sûrement très vite apprendre si tu pratiques sur des petits exercices. Je ne sais pas sur quoi tu bloques exactement mais en commençant par écrire des classes correctes avec getter/setter  et affichage de tes données sur un joli cmd ce sera parfait

Pour faire un peu plus compliqué tu peux y impliquer des listes.

Petit exemple très simple que l'on nous donnait à l'IUT, créer une classe étudiant composée d'un numéro, d'un nom/prénom et d'une adresse. Tu fais un affichage sur cmd donc et puis tu peux mettre tes étudiants dans une liste pour les trier par numéro. Si c'est encore trop simple tu peux utiliser l'héritage en supposant que chaque élève hérite d'une classe Personne. A force de pratiquer ça viendra tout seul

Pour répondre à ta question sur la fenêtre stylisée, il n'y a pas de librairie graphique de base avec C++, tu devra en installer une. Personnellement j'ai complétement adhéré à la SFML qui se veut tournée vers les jeux vidéo. Maintenant si tu veux un bon conseil essaie de te concentrer à fond sur la console Windows avant de chercher à vouloir faire des fenêtres, ce sera plus simple, peut -être moins intéressant mais tu fera quelque chose que tu pourra maitriser et surtout cela te servira de base de connaissance pour tes prochains programmes super mega bien qui seront sur une superbe fenêtre !

Ce que je vais te dire va en contradiction avec ce que j'ai écrit au-dessus mais au moins tu sera au courant, si tu es très pressé de créer des fenêtres tu peux regarder du coté de Java ou VB.net qui, eux, pour le coup ont une librairie graphique "intégrée" avec un designer qui te permet de faire ce que tu veux avec de simples clics de souris ! VB.net commence à se faire vieux mais pour l'instant je trouve que c'est le langage le plus simple que j'ai vu (évidemment il faut connaitre l'objet sur le bout des doigts pour l'utiliser ). Bref, très pratique pour l'informatique de gestion.

Voila je crois que j'ai fini de taper,

Bonne chance !

Oh, c'est pas méchant de dire à quelqu'un qui n'y arrive pas avec les bases qu'il faut qu'il envisage de changer de métier ?

Je suis un gentil moi

mickab a écrit:

écrire des classes correctes avec getter/setter

Fail. Comment une classe peut être correcte si elle a des getter/setter :D 

-
Edité par gbdivers 15 septembre 2014 à 22:00:41

Moi je débute et je me trouve nul en programmation. Malgré ca je trouve que ce n'est pas difficile d'utiliser des bibliothèques en POO. Il suffit de comparer la SDL avec la SFML.

On dirait que la POO n'a été inventée que pour ça.

Il est vrai par contre que créer des classes, c'est une autre paire de manches je trouve. Je trouve qu'il faut beaucoup reflechir si on veut que les classes soient "rentables" par rapport a des fonctions "libres".

De la pratique, et après, c'est l'inverse, on met des classes partout, même là où ça sert à rien.

(Après, ces la méta-programmation avec des templates partout, après ces la programmation fonctionnel avec des lambda partout, etc...)

Est on obligé de faire tout le programme avec un seul paradigme ? C'est mal vu de ne faire par exemple, qu'une deux classes pour ses algorithmes et faire le reste, disons, façon C ?

Cf les algos de la bibliothèque standard, c'est que des fonctions libres. Donc pas de problème d'utiliser plusieurs paradigmes, c'est fait pour

Par contre, il ne faut pas faire du C

Vous êtes vaches les amis.

La POO est souvent mal expliquée et comprise (cf la remarque sur les setters/getter). Si cela ne te parle pas, peut-être n'as-tu pas eu la présentation qui te parle. Et n'aies crainte, beaucoup de ceux qui en connaissent la syntaxe dans tel ou tel langage ne l'ont pas comprise pour autant.

Il y a deux axes essentiels dans la POO. Ailleurs, on va parler d'abstraction et de décomposition d'un problème en sous-problèmes. La POO, c'est le pressing. Tu débarques avec tes fringues à laver, tu les donnes à la réception, tu paies et tu reçois un ticket. Plus qu'à te pointer quelques jours plus tard avec le ticket et tu récupèreras tes habits propres, lavés comme il se doit selon le textile, et repassés. Un objet, le pressing va te rendre le service qu'il sait réaliser.

A l'inverse, tu as l'approche control-freak, ou orientée données. Là, tu ne fais confiance à personne : tu te pointes à la laverie automatique avec tes fringues. Tu choisis une machine non utilisée. Tu te procures du détergent compatible (à ton avis) avec les habits que tu veux laver, et l'insères dans la machine. Tu choisis aussi un programme adaptés aux textiles. Tu tries ton linge et le mets dans la machine. tu lances le programmes, et tu attends. Il te faudra encore ensuite reprendre le linge de la machine, trouver soit un sèche-linge, soit un fil/étendoir/... etc, puis repasser et ainsi de suite. Ca, ce n'est pas la POO -- sauf si tu veux décrire ce qu'il se passe à l'intérieur du pressing, mais ce n'est plus toi qui agit.

Le deuxième axe essentiel de la POO est le polymorphisme. On le retrouve aussi sous d'autres formes ailleurs. Je te passe les détails. Le principe est que l'on est capable de définir une procédure commune à plein de choses, et qu'il y a des points dans la procédure qui vont varier en fonction des choses exactes qui sont impliquées dans la procédure.
Typiquement, pour enlever la poussière au sol dans une pièce, on sort l'appareil de nettoyage de là où il est rangé, on s'assure qu'il va être opérationnel, et on l'utilise en parcourant la pièce, puis on jette la poussière accumulée, et enfin on range l'appareil. Ben, le comment on rend opérationnel (brancher une prise/ rien faire / brancher un tuyau dans un mur), le comment on le passe dans la pièce, le comment on vide la poussière accumulée vont dépendre du type exact d'appareil utilisé (aspirateur, balai, aspiration centralisée, ...). Dans un monde sans polymorphisme, les points de variation seront gérés avec des ifs, chaque if étant propre à un cas particulier. Dans un monde avec polymorphisme, les points de variation seront gérés par l'objet exact employé.  Ainsi, si on veut rajouter un nouvel appareil de nettoyage (p.ex. robot automatique), on ne va pas avoir à modifier le code existant, on va juste se contenter de plugguer un nouveau truc qui va s'insérer automatiquement dans l'infrastructure commune.

Pour les fenêtres. Il y a peu de rapport avec la POO. Pondre des IHM est une activité sans intérêt, et quand on les programme (au lieu de les décrire), c'est encore plus fastidieux. La POO va nous servir à définir des frameworks d'IHM, mais côté utilisation, oublie qu'il y a un lien avec la POO si ça te perturbe.

Si ce qui te motives, ce sont les IHMs, regarde plutôt les technos dédiées. Au hasard, je dirais PyQt (quoique c'est peut-être programmé ce truc encore), ou QtQuick/QML.

mickab a écrit:

Salut ,

Alors comme disait Bacelar, la POO n'est pas évidente au début mais tu vas sûrement très vite apprendre si tu pratiques sur des petits exercices. Je ne sais pas sur quoi tu bloques exactement mais en commençant par écrire des classes correctes avec getter/setter  et affichage de tes données sur un joli cmd ce sera parfait

Aarrrghhh... ca, ca mérite d'être pendu par les pieds au dessus d'un nid de fourmis...

Et la loi de Déméter, c'est fait pour les chiens ???

Et ce n'est pas la seule bêtise que tu aies écrite ;-)

Bon, ce qu'il y a de bien avec C++, c'est que tu peux commencer par apprendre les bases de la programmation en n'utilisant que du procédural, avant de t'intéresser aux différents principes qui s'appliquent à l'OO et, si tu est très volontaire, terminer par le paradigme générique.

Bien sur, cela ne doit pas t'empêcher d'utiliser dés le début certaines classes fournies par la bibliothèque standard, bien au contraire... Grâce à ces classes, la courbe d'apprentissage devient particulièrement douce ;-)

La première chose à faire : se convaincre que C++ (ou n'importe quel autre langage, d'ailleurs) n'est qu'un ensemble "simple" de conventions qui permettent d'expliquer à "quelque chose d'aussi bête qu'un ordinateur" ce que l'on attend de lui.  Une fois que c'est bien entré et que tu en es bien conscient, tu devrais t'intéresser aux principes de base de la programmation procédurale. 

Je te rassure tout de suite, il n'est pas question de t'inciter à ingurgiter un ouvrage digne de l'encyclopédie universelle : juste quelques principes que tu retrouveras partout : ce qu'est une variable, un test "vrai/faux" ou à "choix multiple", les différents types de boucles, éventuellement savoir ce qu'est la récursivité et comment l'utiliser à bon escient, et, surtout, savoir quelles sont les possibilités qui nous sont offertes (du point de vue purement théorique) de regrouper plusieurs données d'un type identique dans une seule variable. 

Autrement dit, savoir ce qu'est une collection de variables, quels sont les différents types de collections que l'on peut utiliser et savoir comment choisir la collection qui correspondra le mieux à tes besoins.

Pour ca, il faut compter entre vingt et 40 heures, plus quelques essais si tu arrives à te motiver pour essayer de faire le lien entre la théorie et la manière dont elle est mise en oeuvre en C++.

Ensuite, C++ c'est quoi ? quelques règles de syntaxe, quelque règles de grammaire et une petite centaine de mots clé, dont tu peux oublier une bonne moitié dans un premier temps.  Pour cela aussi, il ne faut pas plus d'une 40aine d'heures pour s'y habituer.  Tu en resteras sans doute à un simple affichage console, mais il faut savoir marcher avant de savoir courir.

Viendra ensuite l'approche OO.  Là encore, la théorie se limite à quelques principes qu'il faut comprendre et tenter d'appliquer le mieux possible : Déméter (dont j'ai parlé plus haut :-D) et les cinq principes SOLID (SRP, OCP, LSP, ISP, DIP de leur petits noms ;-))

Il faudra peut être t'accrocher un peu pour arriver à comprendre ce qu'est la substituabilité, mais, autrement, la POO tend à t'inciter à réfléchir en termes de comportements (comprends :tes classes doivent pouvoir répondre à des questions et réagir à des ordres) plutôt qu'en termes de données.  Une fois que tu as compris cela, ca devient de nouveau assez simple, même s'il est parfois difficile de mettre les six principes que je viens de citer en oeuvre.

Une fois que tu auras compris comment C++ met le paradigme orienté objet en oeuvre, tu en sauras assez pour envisager de te tourner vers une bibliothèque graphique comme SFML ou Qt.  Ce sont des bibliothèques qui permettent de faire des interfaces correspondant à ta définition, mais il ne faut pas croire qu'elles s'utilisent aussi facilement qu'un crayon et un papier pour faire un "zoli dessin". 

Enfin, si tu es encore motivé après tout cela, un petit tour vers le paradigme générique te permettra de faire des choses encore plus folles.

Personnellement, j'estime qu'en dédiant à peu près 200 heures à l'apprentissage du C++ et des principes des différents paradigmes, tu devrais pouvoir arriver à un niveau de "débutant bien éclairé", capable de se sortir de la plupart des situations sans difficulté majeure.

Par contre, si tu vises la maitrise du langage, cela se compte en années.... Cela fait une douzaine d'année que je me suis spécialisé en C++, et je n'en ai pas encore fait le tour

Eh bien, vous êtes en forme pour écrire ce soir

koala01 a écrit:

Aarrrghhh... ca, ca mérite d'être pendu par les pieds au dessus d'un nid de fourmis...

Et la loi de Déméter, c'est fait pour les chiens ???

Et ce n'est pas la seule bêtise que tu aies écrite ;-)

Okay je dis plus rien :X

Je n'ai que 2 ans d'expérience de C++, je viens tout juste d'obtenir mon DUT info, pour moi les getter/setter c'est cool

C'est nul.

Il faut que tu raisonnes en terme de services offert par l'objet et non pas en terme de données stockées par l'objet.

Sinon ça casse toute l'encapsulation objet.

T'en fait pas, la majorité des programmeurs JAVA font aussi cette erreur, car les 1ers best-practice de Sun ont popularisés cette hérésie.

-
Edité par bacelar 16 septembre 2014 à 19:03:42

Et potentiellement des profs mal éduqués la perpétuent. Il suffit qu'ils racontent qu'encapsuler c'est mettre en privé, sans expliquer/comprendre qu'un setter est un décapsuleur, et pouf. De la POO non comprise. On ne veut pas savoir de quoi sont fait les objets, mais au contraire ce qu'ils peuvent faire pour nous. Migrez votre façon de voir vers ce schéma et vous aurez compris la POO -- vous pourrez ensuite vous attaquer à ses limitations (cf les ECS qui ont le vent en poupe)

bacelar a écrit:

hérésie

hérésie ou juste les pratiques qui ont changée ?

Stroustrup a écrit:

Père, pardonne-leur car ils ne savaient pas ce qu'ils faisaient !

-
Edité par gbdivers 16 septembre 2014 à 19:35:16

>hérésie ou juste les pratiques qui ont changée ?

Pas faux, mais lui, il a fini sur une croix (l'auteur original, pas Bjarn).

Les pratiques changent, ou les utilisateurs commencent à réfléchir à ce que l'on cherchait à les premiers leur enseignaient ? (Avant qu'une vague intermédiaire ne débarquent avec les méthodes qu'ils appliquaient dans le passé ?)