Discussion :

[rems14]

Bonjour à tous !

Voilà j'ai lu un livre entier pour apprendre le C++, je connais donc pas mal de choses. Mais j'ai un gros problème, c'est que je ne sais pas "bien programmer".
J'entends par là, savoir comment bien séparer le code source (avec les classes et calculs) de l'interface graphique (ou flux d'entrée/sortie), le tout pour que ça soit portable et facile à mettre à jour.
En effet dans les livres que j'ai pu voir, on en parle presque pas, on apprends juste à programmer. Moi je veux programmer "intelligent". Je pourrais vous faire un programme mais bonjour les dégats si je veux qu'il soit portable ou changer d'interface graphique, donc ça ne m'intéresse pas.

J'ai vu sur le net qu'il fallait que son programme soit codé en plusieurs couches (fonctions de bases / flux d'entrée et sortie / interfaces graphique), ou qu'il soit modulable, mais je n'ai pas trouvé comment le faire.

Ma question : Pouvez-vous me conseiller un cours sur internet ou un livre qui m'apprenne ces concepts de programmation ?

Merci d'avance

[zais_ethael]

Pour commencer, tu as toute la partie Conception du site. Il s'agit principalement de design patterns ou de méthodologies applicables à l'orienté objet et donc difficilement transposables au C++ mais c'est mieux que rien.
Plus précisément pour le C++, il est fort présomptueux de dire qu'on connait beaucoup de choses après avoir lu un bouquin . C'est un langage excessivement complexe et même ceux qui l'utilisent depuis 10 ans te diront qu'ils apprenent de nouveaux trucs tous les jours.

[ZaaN]

Bien que le rapport ne semble pas etre forcement evident,
le modèle des couches OSI est la théorie universelle dans l'architecture informatique (du hard au soft). Si tu comprend et intègre ce principe ce sera un grand pas dans la structure de tes composants logiciels.

[koala01]

Salut,

De manière générale, il ne faut pas se "jeter directement" sur le clavier pour "vomir du code" qui ne serait pas murement réfléchi.

Avant d'en arriver à l'écriture du code, il est important de passer par des étapes d'analyse, de conception et de création d'algorithmes.

L'analyse des besoin te permettra de "dégrossir" les choses, de manière à avoir en tete ce que doit faire l'application, afin entre autre, qu'elle fasse ce qu'elle doit.

La conception te permettra d'avoir une idée précise de la manière dont tu va organiser l'application afin, justement, de satisfaire aux besoins que tu a déterminé.

Les algorithmes te permettront enfin d'être sur(e) de la logique à mettre en oeuvre pout qu'une - ayant en gros pour but de satisfaire ne serait ce qu'en partie un besoin, ou de fournir les outils qui permettront de le faire - puisse dans les meilleures conditions de sécurité arriver au résultat escompté.

Il existe plusieurs méthodes d'analyse des besoins, de conception et d'algorithmie, et chacune ayant - comme d'habitude - ses avantage, ses inconvéniants, ses adeptes et ses détracteurs...

Si tu veux améliorer ta manière de programmer, il semble cohérent de t'intéresser aux différentes méthodes, d'en choisir une dans chaque catégorie qui te plaise le plus ou qui présente le plus d'avantages à ton gout, et de t'y initier tres largement...

Une fois que tu auras atteint une certaine maturité dans ces méthodes, tu considérera - peut etre - l'écriture du code elle-même comme un *simple* travail de traduction et de dactylographie

[rems14]

Merci pour vos réponses.

C'est vrai je n'avais pas vu la partie conception, je vais regarder ça.
Sinon pour la norme OSI c'est vrai qu'à première vu on dirait qu'il n'y a aucun rapport, je dirais même que ça me fait peur tellement c'est abstrait ! Si j'ai la motive je m'y intéresserais.
Enfin je sais que l'analyse d'un programme c'est hyper important pour en faire un bien structuré, et je n'en fais pas. Le pb c'est que je ne sais pas en faire. Ce que j'ai pu lire dessus était très vague, donc passez détailler pour apprendre. Aussi un sujet sur lequel il faudrait que je m'intéresse.

Encore merci, et si d'autres personnes peuvent me donner des conseils je suis prenant !

edit : je ne trouve aucun cours qui traitent de la programmation en couches en C++, je commence à désespérer. Comment l'avez-vous appris ???

[zais_ethael]

La conception orientée objet s'apprend, la programmation en couche ou plus généralement l'abstraction pas vraiment. C'est basé sur l'expérience et la logique.
Par exemple, prenons un programme de comptabilité permettant d'encoder des factures. En général on voudra créer au moins deux couches: d'une part une couche "données" contenant des fonctions pour ajouter/supprimer/modifier des factures dans le fichier et d'autre part une couche "interface" pour tout ce qui compose l'interface graphique. La couche interface va utiliser la couche données mais surtout pas l'inverse (c'est d'ailleurs un très bon truc à apprendre dés le début: rendre le programme indépendant de l'interface graphique).
Pour le cas du modèle OSI c'est moins compliqué qu'il n'y parait et en dehors des couches 1, 5 et 6 il est justement très concret, bien sur il faut connaitre un minimum le fonctionnement des réseaux pour piger le fonctionnement

[Mat007]

Salut,

Juste je me demandais ce que signifiait :

Il s'agit principalement de design patterns ou de méthodologies applicables à l'orienté objet et donc difficilement transposables au C++ mais c'est mieux que rien.

??

Personnellement j'ai l'impression de faire de l'orienté objet de la même façon en C++ qu'en Java par exemple.
Ok y'a quelques petites différences mais au final on y retrouve les mêmes mécanismes globaux d'organisation d'une application.
Tu veux dire que tu n'as (ou ne vois émerger) aucun 'design pattern' en C++ ? J'avoue que je ne comprends pas bien, mes applications sont truffées de proxies et de factories

MAT.

[koala01]

J'avoue ne pas non plus avoir parfaitement saisi ce qu'il voulait dire:

Les Desing patterns permettent de modéliser des problèmes de conceptions récurents dont on a déterminer une bonne fois pour toute la solution qui semble la moins mauvaise...

Comme la modélisation reste fort indépendante du langage - meme si on *peut* décider de se rapprocher de certaines contraintes de langages, en évitant, par exemple, de modéliser un héritage multiple - il n'est pas plus difficile d'implémenter un modèle (a fortiori de DP) en C++ qu'en n'importe quel autre langage orienté objet...

Le paradigme "orienté objet" a été envisagé différemment en java, en VB ou en C++, soit, mais... Au final, tous les langages disposent d'une meme base, et les desing patterns ne s'intéressent, justement, qu'à cette base

[rems14]

Encore merci des réponses.
Connaissez-vous un petit programme open source qui sépare la couche "interface" de la couche "données" pour que je puisse voir quelles techniques C++ ils utilisent ?

[zais_ethael]

Diable non, moultes langages ont une approche similaire de l'orienté objet (Java, C#, perl, python, ruby, php, javascript, smalltalk pour ceux qui me viennent à l'esprit) mais le C++ est radicalement à part (le Delphi aussi, mais en moins bien). C'est avant tout un langage multi-paradigmes et l'orienté-objet est juste l'un de ces paradigmes, si on le compare avec le C, il permet juste une syntaxe plus agréable (à la rigueur l'identification des types ne serait pas évident à simuler en C).
Pour ce qui est d'implémenter un programme à partir d'un modèle objet pensé indépendamment du langage de destination, c'est bien sur possible mais c'est une vrai saleté. Bien trop de choses accessoires dans la plupart des langages mais essentielles en C++ n'apparaissent pas sur un diagramme, avec en tête de liste la gestion du cycle de vie des objets. Que fait on alors? On met des smarts pointers par ci, de simples pointeurs par la (avec le risque d'erreur de manip que cela implique),... Et quand on a réussi à trouver l'agencement correct on se rend compte qu'il faut modifier le diagramme, et bien evidemment l'ancien code n'est pas adaptable au nouveau modèle. Alors que faire? => limiter l'orienté objet au strict minimum et profiter des autres fonctionnalités du C++ qui n'ont rien à voir avec ça.
Comme le dit si bien Alan Kay: "I invented the term Object-Oriented, and I can tell you I did not have C++ in mind."