Sommaire: Formation C++
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++ ?
Extrait du formation C++
Chapitre 1 La conception objet
1.1 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 évoluer. 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é.
1.2 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.
1.2.1 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…
Les deux méthodes ne sont pas automatiquement à opposer, et sont souvent utilisées en même temps lors de la conception d’un logiciel. On peut cependant noter que l’approche descendante ne favorise pas toujours la réutilisabilité des modules produits.
1.2.2 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.
……..
Si le lien ne fonctionne pas correctement, veuillez nous contacter (mentionner le lien dans votre message)Formation C++ Format des entrées-sorties et carte de référence STL (458 KO) (Cours PDF)
