Accueil > Le centre d'expertise Agile de Pyxis > Programmation orientée objet

Programmation orientée objet

La programmation orientée objet (POO), ou programmation par objet, est un paradigme de programmation informatique qui consiste en la définition et l'interaction de briques logicielles appelées objets; un objet représente un concept, une idée ou toute entité du monde physique, comme une voiture, une personne ou encore une page d'un livre. Il possède une structure interne et un comportement, et il sait communiquer avec ses pairs. Il s'agit donc de représenter ces objets et leurs relations ; la communication entre les objets via leur relation permet de réaliser les fonctionnalités attendues, de résoudre le ou les problèmes.

Sommaire

1. Les concepts coeurs
2. Les principes de programmation orienté objet
    2.1 Les principes S.O.L.I.D
    2.2 Les principes de programmation UNIX
    2.3 La loi de Demeter (Tell don't ask)
    2.4 Le principe de non répétition (Don't Repeat Yourself - DRY)
    2.5 La séparation requête-commande
    2.6 La conception par contrat
    2.7 Le principe de robustesse
    2.8 L'immutabilité
    2.9 L'inversion de contrôle
3. Les patrons de conception du "Gang of four"
4. Des références sur la programmation orienté objet
    4.1 Livres
    4.2 Blogues et comptes Twitter
    4.3 Articles

1. Les concepts coeurs

Principes coeur

Objectifs de conception

Orthogonalité : l'orthogonalité est une propriété de conception d'un système facilitant la faisabilité et la compacité des conceptions complexes. L'orthogonalité garantit qu'une modification d'un composant d'un système ne crée ni ne propage aucun effet de bord sur les autres composants du système.
Faible couplage : le niveau d'interaction entre deux ou plusieurs composants logiciels.
Forte cohésion : mesure l'application des principes d'encapsulation des données et de masquage de l'information ainsi que la cohésion sémantique des interfaces des modules et des classes.

2. Les principes de programmation orienté objet

2.1 Les Principes S.O.L.I.D

Ces principes ont été inventés par oncle Bob (Uncle Bob's Principles Of Ood).

Conception de classe (S.O.L.I.D)

Single Responsibility Principle : une classe devrait avoir une, et une seule raison de changer.
Open Closed Principle : vous devriez être capable d'étendre le comportement d'une classe, sans la modifier.
Liskov Substitution Principle : les classes dérivées doivent être substituables par leur classe de base.
Interface Segregation Principle : faire des interfaces fines qui sont spécifiques au client.
Dependency Inversion Principle : dépendre des abstractions, et non des concrétions.

Cohésion de package

The Release Reuse Equivalency Principle : La granularité de réutilisation est la granularité de la relâche (release).
The Common Closure Principle : Les classes qui changent ensemble sont packagées ensemble.
The Common Reuse Principle : Les classes qui sont utilisées ensemble sont packagées ensemble.

Couplage entre packages

The Acyclic Dependencies Principle : Le graphe de dépendences des packages ne doit pas avoir de cycles.
The Stable Dependencies Principle : Dépendre en direction de la stabilité.
The Stable Abstractions Principle : L'Abstraction augmente avec la stabilité.

2.2 Les principes de programmation UNIX

Ces principes ont été inventés par Eric Steven Raymond (The Art of UNIX Programming)

Modularité : Ecrivez des parties simples connectées par des interfaces claires.
Clarté : La clarté est meilleure que l'habileté.
Composition : Concevez des programmes à connecter aux autres programmes.
Séparation : Séparez la policy du mécanisme; séparer les interfaces des moteurs.
Simplicité : Concevez pour la simplicité; ajoutez la complexité seulement si nécessaire.
Parsimonie : Ecrivez un gros programme seulement quand il est clairement démontré que rien d'autre ne ferait l'affaire.
Transparence : Concevez pour la visibilité pour faciliter l'inspection et le debogage.
Robustesse : La robustesse est l'enfant de la transparence et de la simplicité.
Représentation : Concentrez la connaissance dans les données de manière à ce que la logique soit stupide et robuste.
Moindre surprise : En conception d'interfaces, toujours choisir l'option qui réserve le moins de surprises.
Silence : Quand un programme n'a rien de surprenant à dire, il ne devrait rien dire.
Réparation : Quand vous devez échouer, échouez le plus bruyamment et le plus rapidement possible.
Économie : Le temps du développeur coûte cher; conservez le en priorité par rapport au temps de calcul.
Génération : Eviter le bidouillage; écrivez des programmes qui écrivent des programmes quand vous le pouvez.
Optimisation : Prototypez avant de fignoler. Faites fonctionner avant d'optimiser.
Diversité : Ne croyez jamais les revendications du type "la seule bonne façon de faire".
Extensibilité : Concevez pour le futur, car il sera là plus tôt que vous le pensez.

2.3 La Loi de Demeter (Tell don't ask)

Vous devez demander aux objects ce que vous voulez qu'ils fassent, et non leur poser des questions sur leur état pour prendre ensuite des décisions qui mènent à des actions de leur part (+ d'information).

2.4 Le principe de non répétition(Don't Repeat Yourself - DRY)

Ne vous répétez pas (Don’t Repeat Yourself en anglais, aussi désigné par l’acronyme DRY) est une philosophie en programmation informatique consistant à éviter la redondance de code au travers de l’ensemble d’une application afin de faciliter la maintenance, le test, le débogage et les évolutions de cette dernière. (voir l'article interressant de Steve Smith sur le sujet).

2.5 La séparation requête-commande

La séparation requête commande (Command-query separation, CQS) est un principe de programmation impérative. Le terme a été initié par Bertrand Meyer lors de l'élaboration du langage Eiffel. Le principe annonce que chaque méthode devrait être soit une commande qui effectue une action, ou une requête qui retourne des données à l'appelant, mais pas les deux. En d'autres mots, poser une question ne devrait pas changer la réponse. Plus formellement, les méthodes devraient retourner une valeur seulement si elles ont une transparence référentielle et ainsi ne possèdent pas d'effets de bord (voir l'article de Martin Fowler pour plus d'information).

2.6 La conception par contrat

La programmation par contrat est un paradigme de programmation dans lequel le déroulement des traitements est régi par des règles. Ces règles, appelées des assertions, forment un contrat qui précise les responsabilités entre le client et le fournisseur d'un morceau de code logiciel. C'est une méthode de programmation semi-formelle dont le but principal est de réduire le nombre de bugs dans les programmes ( voir + d'information ). Le langage Eiffel est basé sur ce paradigme.

2.7 Le principe de robustesse

Le principe de robustesse est une recommendation pour la conception de logiciel : Soyez conservateur dans ce que vous envoyez; soyez libéraux dans ce que vous acceptez.

En d'autres mots, le code qui envoit des commandes ou des données à d'autres machines (ou à d'autres programmes sur la même machine) devrait se conformer complètement aux spécifications, mais le code qui reçoit des entrées devrait accepter des entrées non conformes aussi longtemps que l'intention est claire ( voir + d'information).

2.8 L'immutabilité

Un objet non mutable, en programmation orientée objet et fonctionnelle, est un objet dont l'état ne peut pas être modifié après sa création. Ce concept est à contraster avec celui d'objet mutable :

2.9 L'inversion de contrôle

L'inversion de contrôle est un patron d'architecture commun à tous les frameworks (ou cadre de développement et d'exécution). Il fonctionne selon le principe que le flot d'exécution d'un logiciel n'est plus sous le contrôle direct de l'application elle-même mais du framework ou de la couche logicielle sous-jacente.

L'inversion de contrôle est un terme générique. Selon la problématique, il existe différentes formes, ou représentation d'IoC. Le plus connu étant l'injection de dépendances (dependency injection) qui est un patron de conception permettant, en programmation orientée objet, de découpler les dépendances entre objets.

Articles