[7] Classes et objets

Le bloc de base d'un logiciel OO.

Une class définit un type de données, tout comme un struct en C. Informatique parlant, un type se compose d'un ensemble d'états et d'un ensemble d'opérations qui correspondent aux transitions entre ces états. Ainsi int est un type parce qu'il a un ensemble d'états et il a des opérations comme i + j ou i++, etc... Exactement de la même façon, une classe fournit un ensemble d'opérations (habituellement public:), et un ensemble de bits de donnée (habituellement non public:) représentant les valeurs abstraites que les instances du type en question peuvent avoir.

Pensez à un int comme à une classe possédant des fonctions membre appelées operator++, etc...

Note: un programmeur de C peut voir une class comme un struct dont les membres sont private par défaut. Mais si c'est là tout ce que vous évoque une class, vous avez probablement besoin de changer votre paradygme.

Une zone mémoire et la sémantique associée.

Après la déclaration int i; on dit que "i est un objet de type int". En OO/C++, "objet" désigne habituellement "une instance d'une classe". Ainsi une classe définit éventuellement le comportement de plusieurs objets (instances).

Quand elle fournit une vue simplifiée d'un bout de logiciel, et qu'elle est exprimée dans le vocabulaire de l'utilisateur(un "bout" est normalement une classe ou un groupe de classes, et un "utilisateur" est un autre développeur plutôt que le client final).

• "Une vue simplifiée" signifie que les détails inutiles sont intentionnellement cachés. Ceci réduit le risque de mauvaise utilisation de la classe.
• Le "vocabulaire de l'utilisateur" signifie que l'utilisateur n'a pas besoin d'apprendre un nouvel ensemble de mots et de concepts. Ceci améliore la vitesse d'apprentissage de l'utilisateur.

Empêcher l'accès non autorisé à certaines informations ou fonctionnalités.

L'aspect clé (qui permet d'économiser temps et argent) est de séparer la partie volatile d'un bout de logiciel donné de la partie stable. L'encapsulation met un mur de feu autour du bout de logiciel en question, qui empêche les autres morceaux d'accéder aux pièces volatiles; les autres morceaux accédent seulement aux pièces stables. Ceci réduit les dépendances entre morceaux et empêche les autres morceaux de se casser si (quand!) des parties volatiles sont changées. Dans le contexte du logiciel OO, un "gros morceau" est normalement une classe ou un module .

"Les pièces volatiles" sont les détails d'implémentation. Si le bout de logiciel se limite à une classe simple, la partie volatile est normalement encapsulée dans les parties private: et/ou protected:. Si le bout de logiciel est un groupe de classes, l'encapsulation peut être employée pour empêcher l'accès à des classes entières dans ce groupe. L'héritage peut également être utilisée comme forme d'encapsulation .

"Les pièces stables" sont les interfaces. Une bonne interface fournit une vue simplifiée dans le vocabulaire de l'utilisateur, et est conçue de l'extérieur vers l'intérieur (ici un "utilisateur" signifie un autre développeur, pas l'utilisateur qui achète l'application finale). Si le bout de logiciel est une classe simple, l'interface est simplement l'ensemble des membres (données et méthodes) déclarées public: et des fonctions amies. Si le bout de logiciel est un groupe de classes , l'interface peut inclure plusieurs de ces classes.

Concevoir une interface propre en organisant la séparation de cette interface de son implémentation permet simplement à des utilisateurs d'utiliser l'interface. Mais l'encapsulation (mettre "dans une capsule") de l'implémentaion force les utilisateurs à utiliser l'interface.

En C, l'encapsulation était accomplie en déclarant des éléments staticdans une unité ou un module de compilation. Ceci empêchait les autres modules d'accéder à ces éléments static. Cette technique est maintenant dépréciée : ne faites pas cela en C++.

Malheureusement cette approche ne fonctionne plus dans un environement où les données peuvent être instanciées de manière multiple, puisqu'il n'y a aucun soutien direct permettant de créer plusieurs instances des données static dans un module. Lorsque des instances multiples étaient nécessaires en C, les programmeurs avait typiquement recours au struct. Malheureusement les C structs ne supportent pas l'encapsulation. Ceci dégrade le compromis fiabilité (en dissimulant l'information interne à l'utilisateur) contre la rentabilité (instances multiples).

En C++, vous pouvez avoir deux instances et l'encapsulation multiple par l'intermédiaire d'une classe. Une partie dite public: de la classe contient l'interface de la classe : données et fonctions membre et fonctions friend (amies). Et une partie private: (privée) et/ou protected: (protégée) qui contient typiquement l'implantation des routines de la classe, ainsi que ses données.

Le résultat est d'une certaine manière un "struct encapsulé". Ceci aide à améliorer le compromis fiabilité (l'accès à l'information est interdit)/facilité d'utilisation (instances multiples).

Ca ne vaut pas l'effort - l'encapsulation est un outil pour le code, pas pour les personnes.

Ca n'est pas violer l'encapulsation pour un programmeur, que de voire les memebres déclarés private: et/ou protected:, pour autant qu'il n'écrive pas de code dépendant de ce qu'ils ont vu. En d'autres termes, l'encapsulation n'empêche pas les personnes connaître l'intérieur d'une classe; elle empêche le code qu'ils écrivent de devenir dépendants des parties de la classe qui n'appartiennent pas à l'interface. La société n'a pas de "coût d'entretien" pour entretenir votre matière grise (implantation de la classe); mais elle doit par contre payer la mise à jour du code écrit (l'interface). Ce que vous en tant que personne n'augmente pas le coût d'entretien si le code qu'ils écrivent dépend de l'interface plutôt que de l'implantation.

En outre, c'est rarement un problème, pour autant que ça puisse l'être. Je ne connais pas de programmeur qui ont intentionnellement essayé d'accéder aux parties privées d'une classe. "Ma recommandation dans ce cas est de changer le programmeur, pas le code " [ James Kanze; avec la permission de l'auteur].

Non.

Encapsulation != sécurité.

L'encapsulation protège contre les erreurs, pas contre l'espionnage.

Les membres et classes de base d'un structsont publiques par défaut, alors que pour une classe (class), ils sont par défaut privés (private). Note: vous devriez toujours déclarer explicitementvos classes de base publique (public), privées (private), ou protégé (protected), plutôt que de compter sur les valeur par défaut.

Pour le reste, struct et class sont fonctionnellement équivalent.

OK, assez avec ce discours propre grinçant de technique. Avec émotion, la plupart des développeurs font une distinction forte entre une classe et un struct. Un struct est ressenti simplement comme un ensemble de bits avec très peu de d'encapsulation ou de fonctionnalité. Une classe en revanche est ressentie comme quelque chose de plus évolué avec des services intelligents, une barrière forte d'encapsulation, et une interface bien définie. Puisque c'est le sentiment que la plupart des personnes ont déjà, vous devriez probablement utiliser le mot-clé struct si vous avez une classe qui a très peu de méthodes (voir pas du tout) et des données publiques (de telles choses existent dans les systèmes bien conçu!), mais autrement je vous conseille d'utiliser le mot-clé class.