Architecture Orientée Objet

Les billets de cette catégorie parlent d'architecture logicielle orientée objet, de patrons de conception et autres principes d'architecture.

Fil des billets - Fil des commentaires

Sous-catégories

29 fév. 2008

Valider et corriger une architecture objet, seconde partie

Dans la première partie, nous avons vu comment vérifier qu'une architecture validait les principes d'encapsulation, SRP et OCP. Dans cet article, nous allons étudier l'incidence des trois autres principes principaux - LSP, ISP et DIP - sur une architecture orientée objet.

Lire la suite...

01 fév. 2008

Valider et corriger une architecture objet, première partie

La validation d'une architecture orientée objet est une étape importante dans le cadre de la mise en route d'un projet. Il s'agit de vérifier si l'architecture imaginée "tient debout", c'est à dire si d'une part elle réponds au besoin et si d'autre part elle est, disons, "suffisamment correcte". J'emploie à dessein une expression vague car la plupart du temps nous n'avons qu'une idée confuse de ce qui pourrait être une architecture "suffisamment bien" - nous n'avons pas vraiment de métrique à nous raccrocher[1].

Cet article est en deux parties. La seconde partie sera publiée la semaine prochaine.

Notes

[1] Il existe bien des métriques quantitatives (nombre de classes, nombres de méthodes par classes, nombre de liens entre les classes, etc) mais ces métriques ne nous donne que peu d'indications quand à la qualité de l'architecture objet réalisée.

Lire la suite...

01 juin 2007

The Law of Demeter, part 1/2

Contrary to the French version of this post, I decided to break the English version in two parts. The first part deals with the law formulation, and the second part deals with the application of the law. The reason for that is that it gives me a good reason to continue the translation. I know, that's a strange reason.

In addition to the multiple object oriented software design principles that have been discussed in previous blog tickets, the tool box of the software architect contains many other tools, including a set of "laws".

Of course, these are not law in the juridic meaning of the word. They must be seen as guides whose clever use allows us to simplify the code or the software design. Actually, most of these laws are not fully applied, and they often feature logical restrictions when it comes to their application. As we'll see it later, this is the case of the Law of Demeter.

Lire la suite...

15 fév. 2007

La Loi de Demeter

En plus des différents principes d'architecture orienté objet qui ont déjà été discutés dans des billets antérieurs, la boite à outil de l'architecte logiciel contient bien d'autres choses, et en particulier un certain nombre de "lois".

Bien évidemment, ces lois ne sont pas des lois au sens strict. Il faut les voir comme des guides dont l'utilisation intelligente permet de simplifier le code ou l'architecture du logiciel en cours de construction. Pour la plupart, ces lois ne peuvent même pas être appliquées à 100%, et énoncent souvent des restrictions logiques en ce qui concerne leur application. C'est le cas, comme nous le verrons plus tard, de la Loi de Demeter.

Lire la suite...

08 fév. 2007

RAII !

Un cri de guerre, dirait-on - tout comme on l'aurait dit de YAGNI. Bien évidemment, il n'en est rien, car sous ce vocable barbare se cache tout simplement un acronyme décrivant une technique de gestion des ressources adaptée aux langages objets ou orientés objets.

Lire la suite...

14 déc. 2006

Héritage et composition

Lorsque nous souhaitons réutiliser du code déjà écrit, trois possibilités s’offrent à nous : soit nous recopions le code que nous voulons réutiliser, soit nous héritons d’une classe offrant les fonctionnalités souhaitées, soit nous composons notre nouvelle classe en utilisant les différents modules à notre disposition.

Lire la suite...

30 nov. 2006

Le principe d'inversion de dépendance

Après avoir discuté des LSP, ISP, SRP et autres OCP, il ne nous reste qu’un seul principe de programmation orienté objet important à considérer – le principe d’inversion de dépendance (Dependency Inversion Principle selon R. C. Martin[1], ou DIP pour faire court). Si ils existent d’autre principes, ils touchent surtout à la notion de package. Bien qu’ils aient leur intérêt et qu’ils feront peut être plus tard l’objet d’études similaires, les cinq grand principes présentés résument à eux seuls un grand nombre de bonnes pratiques à utiliser lors de la conception d’un programme.

Note

[1] Object Oriented Design Quality Metrics: An Analysis of dependencies , Robert C. Martin, ROAD, Vol. 2, No. 3, Sep-Oct, 1995

Lire la suite...

19 oct. 2006

Le Principe de Ségrégation des Interfaces

Il reste encore certains principes de conception orientée objet que nous n’avons pas approché – le principe de ségrégation des interfaces (ISP, interface segregation principle) est l’un d’eux.

Lire la suite...

12 oct. 2006

Le principe de substitution de Liskov

Après avoir eu un bref aperçu du principe d'encapsulation, du principe de responsabilité unique (SRP, pour single responsability principle) et du principe "ouvert/fermé" (OCP, pour open/closed principle), il ne nous reste que peu de principes à étudier. Parmi eux se trouve le principe de substitution de Liskov (LSP, pour Liskov substitution principle), un principe souvent décrit comme corolaire de OCP et énoncé par deux femmes - Barbara Liskov et Jeannette Wing[1] - fait assez rare dans une communauté fortement dominée par les hommes pour être noté.

Notes

[1] le rapport technique qui énonce ce principe est disponible en téléchargement sur citeseerx.ist.psu.edu

Lire la suite...

21 sept. 2006

Le principe "ouvert/fermé"

Le principe "ouvert-fermé" (Open Closed Principle, ou OCP) est probablement l'un des principe de programmation les plus important. L'expérience montre qu'une simple entorse à ce principe introduit dans une architecture un point de faiblesse par lequel l'architecture peut se corroder lentement.

Lire la suite...

- page 2 de 3 -