Architecture logicielle & Développement

This ticket is the first in my Design Pattern series. This series (in English, sorry for those who don't speak this language) focuses on business-oriented design patterns. The intended audience is the game development community, although I hope that others will also find some useful information. Be aware that it's a Work in Progress - some patterns may need refinement before being usable.

Lire la suite

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

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.

Lire la suite

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

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

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

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

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.

Lire la suite

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

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é.

Lire la suite

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

Intuitivement, on a tendance à considérer un objet et ses méthodes comme un tout. Ainsi, si on considère l'objet Image on pense immédiatement à sa représentation en mémoire (son modèle mathématique) mais aussi à l'affichage de cette image à l'écran et à la sauvegarde de celle-ci dans un fichier. Ce faisant, on introduit dans la classe Image plusieurs responsabilité qui vont plus tard nous porter préjudice.

Lire la suite