Introduction au langage C++ (Les classes), tutoriel & guide de travaux pratiques en pdf.

1 La conception objet
1.1 Introduction
1.2 La modularité
1.2.1 Deux méthodes de conception de modules
1.2.2 Quelques critères de qualités
1.2.3 Les principes de définition
1.3 La réutilisabilité
1.3.1 Les principes de la réutilisabilité
1.3.2 De nouvelles techniques
1.4 Principes de conception objet
1.4.1 Introduction
1.4.2 La conception par objets
1.4.3 Détermination des objets
1.4.4 Conclusion
1.5 Résumé et terminologie
2 Introduction au langage C++
2.1 Historique
2.2 Implantation de modules en C++
2.3 Types de base
2.4 Commentaires
2.5 Structure d’un programme C++
2.6 Les fonctions
2.7 Définition des variables
2.8 Les références
2.9 Les constantes
2.10 Allocation dynamique de mémoire
2.11 La surcharge
2.12 Les entrées-sorties en C++
2.13 Les fonctions template
3 Les classes
3.1 Définition
3.2 Utilisation
3.3 Les méthodes inline
3.4 Les constructeurs
3.5 Le destructeur
3.6 Méthodes constantes
3.7 Le mot-clé this
3.8 La surcharge
3.9 Les classes template
3.10 Les amis
3.11 Membres statiques
4 L’héritage
4.1 Introduction
4.2 La dérivation
4.3 Redéfinition de méthodes
4.4 Le polymorphisme
4.5 La liaison dynamique
4.6 Les classes abstraites
5 La bibliothèque STL
5.1 Introduction
5.2 Les containers
5.3 Les itérateurs
5.4 Les algorithmes
Annexes
A Format des entrées-sorties
A.1 La classe ios
A.2 La classe ostream
A.3 La classe istream
A.4 Les fichiers
B Carte de référence STL
B.1 Les containers
B.2 Les itérateurs
B.3 Les algorithmes
C Compléments
C.1 Les namespaces
C.2 Les nouveaux casts
C.3 Où trouver un compilateur C++ ?

La conception objet

Introduction

Le but de ce premier chapitre est d’introduire la notion même de conception objet, d’un point de vue théorique. Ce chapitre n’a pas la prétention d’expliquer en détail ce type de conception, mais se propose d’en rappeler les idées maîtresses en préambule à l’étude du langage C++. Le chapitre est très largement inspiré de [Mey 91] et [Gau 96] auquel le lecteur pourra se reporter pour plus de précisions. La philosophie du langage C++, comme celle des autres langages à objets, est en effet directement inspirée de ce type de conception.
La conception par objet trouve ses fondements dans une réflexion menée autour de la vie du logiciel. D’une part, le développement de logiciels de plus en plus importants nécessite l’utilisation de règles permettant d’assurer une certaine qualité de réalisation. D’autre part, la réalisation même de logiciel est composée de plusieurs phases, dont le développement ne constitue que la première partie. Elle est suivie dans la plupart des cas d’une phase dite de maintenance qui consiste à corriger le logiciel et à le faire évolue r. On estime que cette dernière phase représente 70 % du coût total d’un logiciel [Mey 91], ce qui exige plus encore que la phase de développement de produire du logiciel de qualité.

La modularité

Les critères énoncés au paragraphe précédent influent sur la façon de concevoir un logiciel, et en particulier sur l’architecture logicielle. En effet, beaucoup de ces critères ne sont pas respectés lorsque l’architecture d’un logicielle est obscure, monolithique. Dans ces conditions, le moindre changement de spécification peut avoir des répercutions très importantes sur le logiciel, imposant une lourde charge de travail pour effectuer les mises à jour.
On adopte généralement une architecture assez flexible pour parer ce genre de problèmes, basée sur les modules. Ceux-ci sont des entités indépendantes intégrées dans une architecture pour produire un logiciel. L’ensemble des modules utilisés, ainsi que les relations qu’ils  entretiennent entre eux, sont dénominés système. L’intérêt de ce type de conception est de concentrer les connaissances liées à une entité logique à l’intérieur d’un module qui est seul habilité à exploiter ces connaissances. L’une des conséquences immédiates est que lorsqu’une maintenance est à effectuer sur une entité logique, celle-ci ne doit concerner qu’un seul module, ce qui confine la maintenance.

Deux méthodes de conception de modules

Si la définition de modules est une approche communément admise, il faut également une méthode de construction de systèmes qui permette de déduire quels sont les bons modules. Il existe deux grandes familles de méthodes modulaires :
– Les méthodes descendantes qui procèdent par décomposition de problème. Un problème est ainsi divisé en un certain nombre de sous-problèmes, chacun de complexité moindre. Cette division est ensuite appliquée aux sous-problèmes générés, et ainsi de suite, jusqu’à ce que chacun des sous problèmes soit trivial.
– Les méthodes ascendantes qui procèdent par composition de briques logicielles simples, pour obtenir des systèmes complets. C’est en particulier le cas des bibliothèques de sous-programmes disponibles avec tous les systèmes, langages, environnements…

Quelques critères de qualités

En dehors de la démarche même menant aux modules, il est bon de préciser quelques critères de qualité à respecter lors de la définition des modules :
– Compréhensibilité modulaire : les modules doivent être clairs et organisés de manière compréhensible dans le système. Ceci implique que les modules doivent communiquer avec peu de modules, ce qui permet de les « situer » plus facilement. De même, l’enchaînement des différents modules doit être logique, et on ne doit pas avoir par exemple à utiliser plusieurs fois de suite un module pour produire une action atomique.
– Continuité modulaire : ce critère est respecté si une petite modification des spécifications n’entraîne qu’un nombre limité de modifications au sein d’un petit nombre de modules, sans remettre en cause les relations qui les lient.

Les principes de définition

À partir des critères exposés ci-dessus, quelques principes de conception ont été retenus pour la réalisation de modules :
– Interface limitée : le but n’est pas de borner les actions associées à un module, mais de se restreindre à un nombre limité d’actions bien définies, ce qui supprime une part des erreurs liées à l’utilisation de modules.
– Communications limitées : les communications entre modules, réalisées via leur interface, doivent être limitées de façon quantitative. Ceci est une conséquence du principe de modularité, qui est d’autant mieux respecté que les modules jouent leur rôle. Si les échanges sont trop importants, la notion même de module devient floue, limitant l’intérêt de cette technique.
– Interface explicites : les communications entre modules doivent ressortir explicitement.
– Masquage de l’information : toutes les informations contenues dans un module doivent être privées au module, à l’exception de celles explicitement définies publiques. Les communications autorisées sont ainsi celles explicitement définies dans l’interface du module, via les services qu’il propose.

……..

Si le lien ne fonctionne pas correctement, veuillez nous contacter (mentionner le lien dans votre message)
Introduction a la conception objet et à C++ (376 KO) (Cours PDF)