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

20 juin 2012

Valeurs et entités : les deux grandes classes d'objets

Mise à jour : les commentaires de ce billet ont mis en évidence un problème plus que certain dans la relation illogique que j'ai établi entre sémantique de mouvement (notamment telle qu'elle est implémentée en C++11) et entité. Du coup, ce billet a été corrigé. Je le publie de nouveau en tête de page afin de permettre aux personnes l'ayant lu au moment de sa sortie de voir ces corrections.

En programmation objet, on manipule différents types d'objets. Certains obtiennent naturellement un constructeur par copie, d'autres non. Certains sont utilisés via des pointeurs, tandis que d'autres sont simplement copiés ici et là au gré des besoins. En bref, et même si vous ne vous en êtes pas encore rendu compte, certains de vos objets ont une sémantique de valeur, tandis que d'autres ont une sémantique d'entité.

Le but de cette article n'est pas de vous apprendre aujourd'hui à différencier une valeur d'une entité, mais de vous faire toucher du doigt ces deux grandes classes d'objets que tout oppose.

Lire la suite...

10 oct. 2011

Dangers et pièges des systèmes de suivi des références

On conçoit aisément qu'il est très difficile de bien concevoir une application ou une libraire : cela demande des connaissances pointues en design ainsi qu'une imagination débordante. Par contre, il est très facile de mal faire : il suffit de se laisser appeler par les sirènes des différents pièges qui, nonchalamment, s'installent sur notre route.

Ce billet traite de l'un de ces pièges : la notion de propriété des objets dans un programme.

Je sais, vous avez déjà lu cette introduction récemment...

Lire la suite...

18 août 2011

De la gestion des gestionnaires

On conçoit aisément qu'il est très difficile de bien concevoir une application ou une libraire : cela demande des connaissances pointues en design ainsi qu'une imagination débordante. Par contre, il est très facile de mal faire : il suffit de se laisser appeler par les sirènes des différents pièges qui, nonchalamment, s'installent sur notre route.

Ce billet traite de l'un de ces pièges : l'omniprésent gestionnaire, qu'on retrouve à peu prêt partout, et dont on sait peu de choses.

Lire la suite...

11 août 2010

Proposition de mise à jour du standard UML

Bien évidemment, une telle proposition est principalement destinée à mes lecteurs, car il et peu probable qu'un membre du comité de normalisation passe par là et se l'approprie (sait-on jamais).

UML est un bon langage de modélisation. Il a toutefois un défaut : l'approche purement objet qu'il utilise rends complexe la modélisation de code dans des langages autres que Java ou C#. On peut modéliser une partie d'un projet écrit en C++, mais il est impossible d'en modéliser la totalité. Cette limitation vient du fait que UML ne permet pas de modéliser une fonction qui n'est pas attachée à une classe. Hors une telle fonction peut avoir une importance capitale dans la conception - la librairie <algorithm> du C++ ne serait que modérément utile si elle n'était pas composée que de fonctions libres ; en fait on peut argumenter que toute autre approche aurait été une erreur de conception.

Cette proposition élimine cette limitation.

Lire la suite...

30 juil. 2010

Les ORM sont-ils une bonne chose ?

Axiom Database LogoCes dernières années, avec l'explosion du web dynamique et les avancées liées à la programmation objet, on a vu se développer des systèmes permettant de faire des liens plus ou moins directs entre le monde objet et le monde relationnel. Ces ORM (pour Object/Relational Mapping) proposent de créer une couche entre votre application et les données sous-jacente. En somme, ils gèrent ce qu'on appelle la persistance des données, en tentant de répondre à une question toute simple : comment faire pour les utiliser simplement tout en gardant une architecture claire, concise et efficace ?

Bien évidemment, ils échouent à apporter la bonne réponse à cette question.

Lire la suite...

06 déc. 2009

Implémentation d'un système de règle pour un jeu de rôle - Retour à nos problèmes

Après avoir bien étudié les possibilités qui s'offrent à nous pour éviter de tomber dans le piège terrible des références circulaires, nous pouvons reprendre notre petit bonhomme de chemin et étudier un peu plus les besoin liés à l'implémentation d'un système de règle pour un jeu de rôle, et même commencer à proposer des solutions.

Mise à jour : le code source qui met en oeuvre la technique présentée dans ce billet est disponible. Gardez en mémoire qu'il ne s'agit pour l'instant que d'un début - il est fort possible que l'ensemble évolue très rapidement. Le code source est compilable sous linux (./configure && make && make check) et sous Windows avec Visual Studio 2008 (au moins ; quelques warnings subsistent). Bien évidemment, il s'agit de C++, et l'ensemble du système de gestion de message est basé sur des classes template - de manière à maximiser sa réutilisation future. Amusez vous bien avec ce code source !

Update : contrairement à ce que je dis dans le paragraphe ci-dessus, le code source N'EST PAS compilable sous Windows. Les évolutions que j'ai apporté à celui-ci ne sont pas reportées dans la configuration VS2008, si bien que le projet n'est pas compilable dans cet EDI. Désolé pour ce manque incroyable de tact (je vais tenter de remédier à ce problème le plus vite possible).

Lire la suite...

23 nov. 2009

Implémentation d'un système de règle pour un jeu de rôle - Cassons la circularité !

Dans l'article précédent, on a vu que l'implémentation d'un système fermé ayant pour put la gestion d'un personnage dans un jeu de rôle modérément complexe avant des conséquences pour le moins inattendues, et notamment le fait que de nombreuses entités se retrouvait dans un état d'interdépendance complexe. Cet article, plus général que le titre ne le montre, essaie de donner quelques pistes pour casser ces dépendances circulaire dans le but de nous permettre la création d'une architecture simple, ouverte et efficace.

Lire la suite...

26 oct. 2009

Implémentation d'un système de règle pour un jeu de rôle - Analyse des besoins

L'article précédent ne donne guère de solution - il se contente de présenter une problématique qui se résume à : pour transformer un système de règle complexe en code, de nombreux problèmes liés à l'architecture logicielle doivent être résolus. Si j'ai pris l'exemple de Dungeons & Dragons (4ème édition), c'est que ce système est un exemple typique représentatif d'un système de règle complexe. Et nous allons voir dans ce billet dans quelle mesure il peut être complexe.

Lire la suite...

19 oct. 2009

Implémentation d'un système de règle pour un jeu de rôle - Introduction

Même si ça peut paraître relativement simple, l'implémentation d'un système de règle pour un jeu de rôle est une tâche complexe. Il existe de nombreuses raisons à ça :

  • les règles elles même ne sont pas hiérarchisées : dans un système parfait, une règle particulière ne fait pas référence à une règle plus générale ; au mieux, elle se substitue à la règle générale. Dans le cas des jeux de rôle, ça n'est pas le cas. Les règles particulières peuvent non seulement se substituer aux règles générales, mais elle peuvent aussi les étendre ou les modifier de manière plus fine.
  • le nombre de cas à gérer n'est pa connu par avance : un jeu de rôle est un produit vivant. Un supplément va nécessairement étendre le système de jeu pour ajouter de nouvelles options. Avant sa parution, il est impossible de savoir quelle modification va avoir un impact sur l'architecture du code. Il convient donc d'ouvrir l'architecture au maximum, sans pourtant tomber dans le travers de la sur-ingénierie qui serait contre-productive.

Lire la suite...

07 mai 2008

Design Pattern - Function Layer

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

- page 1 de 3