Les Property Lists

Avez-vous lu le post de Steve Yegge appelé "The Universal Design Pattern"? Allez-y. C'est du touffu, mais comme d'habitude, c'est très intéressant. Steve y présente une structure de données qui correspond à une liste de propriétés, et un système d'héritage permettant à une liste de dériver d'une autre.

Cette structure est probablement réinventée par tout programmeur un jour ou l'autre, bien que Steve l'étende bien plus loin.

C'est donc sur ce type de structures qu'une partie importante de la persistence et de la communication client-serveur se base. L'idée étant que l'on ne connaît pas par avance l'ensemble des paramètres qui affectent un objet du jeu, mais également que certains paramètres n'ont de sens que pour le client (par exemple, les informations relatives au modèle 3D à charger). Dans ce cas là, pourquoi est-ce que le serveur devrait comprendre ces données? Non, il les passe directement au client.

Voilà ma structure de données en SQL:

create table PropertyListDescriptions(
       listId int primary key,
       parentId int null references PropertyListDescriptions(listId));

create table PropertyListTypes(
 valueType varchar(255) primary key);
insert into PropertyListTypes values('int'), ('double'), ('string');

create table PropertyListAccess(
 accessType varchar(255) primary key);
insert into PropertyListAccess values('restricted'), ('private'), ('public');

create table PropertyListItems(
 listId int not null references PropertyListDescriptions(listId),
 key varchar(255) not null,
 valueType varchar(255) not null references PropertyListTypes(valueType),
 accessType varchar(255) not null references PropertyListAccess(accessType),
 intValue int null,
 doubleValue double precision null,
 stringValue text null);

Une liste est simplement définie par un numéro, et peut avoir une liste parente.
Un élément de liste est associé au numéro de la liste, et possède une clé (le nom de la propriété), et une valeur typée (pour l'instant, une chaîne, un entier ou un double). L'accès me sert à déterminer qui a le droit de voir la propriété:
- une propriété publique (par exemple, la couleur de mes cheveux) est envoyée à tous les clients
- une propriété privée (par exemple, le contenu de mon sac) n'est envoyée qu'au client qui possède la liste
- une propriété restreinte (par exemple, le nombre de charges magiques dans mon poignard) ne sort jamais du serveur, car même son possesseur n'est pas sensé connaître l'information.

C'est simple et efficace, la seule chose manquante étant pour une liste de contenir une autre liste (par exemple, la liste associée à un personnage contient une sous-liste correspondant à son inventaire). Autant descendre à ce niveau rend la structure beaucoup plus dynamique, autant je suis un peu inquiet de ne pas m'y retrouver! Pour l'instant, j'ai donc l'intention d'avoir mes objets principaux (un personnage, par exemple) codés en dur, et composé de plusieurs listes, par exemple la liste d'inventaire, la liste de caractéristiques, etc. Et si j'ai du courage, je passerai aux listes dans les listes!