Architecture logicielle & Développement

Le billet précédent avait pour but de vous aider à mieux structurer votre code. Avant de rebondir sur d'autres points importants du framework XNA, j'aimerais poursuivre un peu dans cette direction, et vous présenter des éléments de micro-architecture qui, je le pense, vous faciliterons la vie lors du développement de votre produit : les calques de fonctionnalités.

Note: cet article, bien que basé sur des notions XNA, présente un concept qu'il est possible d'adapter à tous les autres langages (C++, Java, etc). Ne vous sentez pas limités par le titre du billet ou par les paramètres des méthodes décrites.

Lire la suite

Dans un billet précédent, je faisais référence à la gestion d’états dans le cadre du développement d’un jeu vidéo. Une machine à états a des avantages intéressants dès lors qu’il s’agit de contrôler le flux des actions de l’utilisateur du jeu et de le séquencer en écrans multiples.

Avant d’aller plus loin dans cette analyse, ile nous faut définir ce qu’est une machine à état et à quoi elle peut bien servir.

Note: cet article, bien que basé sur des notions XNA, présente un concept qu'il est possible d'adapter à tous les autres langages (C++, Java, etc). NE vous sentez pas limités par le titre du billet ou par les paramètres des méthodes décrites.

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

Récemment, je suis tombé sur le site de Jason Gorman, consultant reconnu pour son expertise de l'architecture logicielle et des méthodes agiles^[1]. Et sur son blog, j'ai découvert un test d'architecture logicielle qu'il utilise pour s'assurer de la qualité des aspirant architectes qui souhaitent travailler avec lui.

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

En architecture objet, l'encapsulation est ce qui semble être le plus simple à comprendre. En C++, on apprend que mettre des variables membres en accès public, c'est "sale"; qu'il faut absolument mettre les variables en accès privé ou protégé, et qu'ensuite, tout ira pour le mieux. Bien évidemment, cette vision de l'encapsulation est très réductrice. Le but de l'encapsulation est plus large que juste cacher des variables: il s'agit de découpler une interface (par essence, c'est une abstraction) de l'implémentation sous-jacente.

Lire la suite

Mes lectures et mes interventions sur divers forums techniques (tel gamedev.net) m'ont appris que la notion de programmation orientée objet est floue dans l'esprit de beaucoup de programmeurs, y compris des programmeurs expérimentés. Tout au plus, ils imaginent que cela a trait aux classes et à l'héritage, certains y ajoutant le polymorphisme pour faire bonne figure.

Lire la suite

YAGNI par ci, YAGNI par là, YAGNI, YAGNI, YAGNI.

Parmi la multitude de conseils pouvant être donnés en réponse à une question concernant l'architecture logicielle, YAGNI est probablement le plus courant des résultats obtenus. Souvent, sans aucune forme d'explication, la réponse se résout même à cette simple interjection : YAGNI !

Lire la suite