L'Extreme Programming

L'Extreme Programming (XP) est un processus de développement logiciel, c'est-à-dire un ensemble de pratiques destinées à organiser le travail d'une équipe de développement. Ces pratiques se focalisent sur la construction proprement dite du logiciel, en aval des phases préparatoires d'études d'opportunité ou de faisabilité.

XP propose une réponse originale à ces questions, avec un ensemble de pratiques organisées autour des principes suivants :

• Le client (maîtrise d'ouvrage) pilote lui-même le projet, et ce de très près grâce à des cycles itératifs extrêmement courts (1 ou 2 semaines).
• L'équipe livre très tôt dans le projet une première version du logiciel, et les livraisons de nouvelles versions s'enchaînent ensuite à un rythme soutenu pour obtenir un feedback maximal sur l'avancement des développements.
• L'équipe s'organise elle-même pour atteindre ses objectifs, en favorisant une collaboration maximale entre ses membres.
• L'équipe met en place des tests automatiques pour toutes les fonctionnalités qu'elle développe, ce qui garantit au produit un niveau de robustesse très élevé.
• Les développeurs améliorent sans cesse la structure interne du logiciel pour que les évolutions y restent faciles et rapides.

L'objectif de ce dossier est de donner une vision d'ensemble des principes et des pratiques d'XP, en commençant par ce qui fait son agilité : l'ouverture au changement.

Atelier :Bonnes pratiques objet en .net : Introduction aux principes SOLID

I. Introduction

SOLID est l'acronyme de cinq principes de base (Single Responsibility Principle, Open/Closed Principle, Liskov Substitution Principle, Interface Segregation Principle et Dependency Inversion Principle) que l'on peut appliquer au développement objet.

I - B. Couplage=--------
Le couplage est une métrique qui mesure l'interconnexion des modules. Deux modules sont dit couplés si une modification d'un de ces modules demande une modification dans l'autre.

I - C. Encapsulation :+++++++
L'idée derrière l'encapsulation est d'intégrer à un objet tous les éléments nécessaires à son fonctionnement, que ce soit des fonctions ou des données.
Le corolaire est qu'un objet devrait (et non pas doit, comme c'est souvent expliqué) masquer la cuisine interne de la classe, pour exposer une interface propre, de façon à ce que ses clients puissent manipuler l'objet et ses données sans avoir à connaitre le fonctionnement interne de l'objet.

II. Responsabilité unique (SRP: Single Responsibility Principle)

Le principe de responsabilité unique, est qu'une classe donnée ne doit avoir qu'une seule responsabilité, et, par conséquent, qu'elle ne doit avoir qu'une seule raison de changer.

Les avantages de cette approche sont les suivants:

-Diminution de la complexité du code

-Augmentation de la lisibilité de la classe

-Meilleure encapsulation, et meilleure cohésion, les responsabilités étant regroupées

pour l’appliquer il faut Analyser et regrouper des méthodes du code puis en sortir des classes

II. Ouvert/fermé (OCP: Open/closed Principle)

-Les modules qui se conforment au principe ouvert/ferme ont deux attributs principaux. 1 - Ils sont "ouverts pour l'extension". Cela signifie que le comportement du module peut être étendu, que l'on peut faire se comporter ce module de façons nouvelles et différentes si les exigences de l'application sont modifiées, (hériter de la classe d'origine)

2 - Ils sont "Fermés à la modification". Le code source d'un tel module ne peut pas être modifié. Personne n'est autorisé à y apporter des modifications.«

Voir Exemple

III. Substitution de Liskov (LSP: Liskov Substitution Principle)

-Les sous-types doivent être remplaçables par leur type de base SANS CAST.

Principe de Polymorphisme on POO.

Voir Exemple

IV. Séparation des Interfaces (ISP: Interface Segregation Principle)

-Les clients ne doivent pas être forcés de dépendre d'interfaces qu'ils n'utilisent pas.

Les interfaces doit être le moins compliquée.

Modèle ISP

V.Inversion des dépendances (DIP: Dependency Inversion Principle)

Les architectures classiques ne permettent pas la réutilisation des modules "métier"

Dans la plupart des applications, les modules de haut niveau (ceux qui portent la logique fonctionnelle de l'application ou les aspects "métier") sont construits directement sur les modules de bas niveau (par exemple les librairies graphiques ou de communication)

Les modules de haut niveau doivent être modifiés lorsque les modules de bas niveau sont modifiés.

Selon le principe d'inversion des dépendances

, la relation de dépendance doit être inversée : les modules de bas niveau doivent se conformer à des interfaces définies et utilisées par les modules de haut niveau.

Vers des Framework métier ?

Ce principe conduit à des applications dans lesquelles la logique "métier" est parfaitement réutilisable. Cette partie métier forme une sorte de "framework", qui permet de développer une même application dans des contextes techniques différents.(sfeir Tools bon exemple, edition EML )

http://www.regismedina.com/articles/fr/principesoo/dip