Discussion :

[Baptiste Wicht]

Bonjour,

Je suis en train de réfléchir à une architecture pour une application. J'ai commmencé par réfléchir aux différents modules que je pourrais avoir et je me suis vite rendu compte que j'aurais deux types de modules. J'ai des modules complètement indépendant des autres modules et des modules qui viennent ajouter des fonctionnalités à un autre module.

C'est une application permettant de gérer une collection de films (pour l'instant seulement de films, mais je compte aller plus loin). Pour modulariser un max, je compte faire un module de la gestion des films/acteurs/réalisateurs pour que je puisse ensuite ajouter facilement par exemple un module de gestion des livres/auteurs par exemple. J'ai aussi par exemple un module qui rajoute juste une fonction permettant de gérer une liste de films à acheter.

Mais ensuite, j'ai des modules venant ajouter des fonctions à la gestion des films, comme par exemple les prêts ou alors les statistiques.

Ces modules sont donc fortement dépendant du module "Films".

Je ne sais donc pas trop comment faire avec eux. Est-ce qu'il faut que je crée ces modules en les rendant dépendant de "Films", mais alors il sera impossible de les utiliser si on désinstalle ou désactive le module films. Ou alors je dois créer une architecture de dépendance. C'est à dire un lien entre les deux modules qui indique que si "Films" est désactivé, il faut automatiquement désactiver "Prets".

En plus, un module du genre prêts serait utiles autant dans le cas des films que dans le cas des livres. Donc est-ce qu'il faudrait ensuite que je crée un autre module pour gérer les prêts des livres ou est-ce qu'il faudra que je change mon module de prets pour qu'il accepte les livres, mais dans ce cas, il sera dépendant de deux modules et je ne pense pas que ce soit idéal.

Ou alors dernière solution, est-ce qu'il faut que je laisse la gestion des films et des livres (par exemple) dans le coeur de l'application et ensuite les modules auront directement accès à cette partie. Par contre, j'aimerais laisser la solution de choisir entre "Films", "Films et Livres" et "Livres", ce qui serait plus difficile avec cette solution.

Bref, je ne sais pas vraiment quelle solution serait la bonne.

Qu'en pensez-vous ? Y a t'il d'autres solutions ? Y a t-il de bonnes ressources sur le net (j'ai cherché, mais j'ai pas trouvé grand chose de convaincant, mise à part de toutes petites mises en oeuvre) ?

Merci d'avance de supporter cette longue lecture

[souviron34]

je ne sais pas en quel (enfin je suppose d'après ton titre si) langage tu programmes.

En C, j'aurais fait des modules indépendants, avec simplement des "callbacks" a enregistrer;

Vraisemblablement, ta structure "livre" ou "film" contient un certain nombre de sections, dont prêt, contenant les informations nécessaires , non ?

Dans "film", un moment donné, tu aurais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
if ( ExisteFonctionEnregistree ( PRET_FILM ) )
       AppelleFonctionEnregistree ( PRET_FILM, (void *)&Ce_Film_Structure );

tu as des define pour tes actions (PRET_FILM, PRET_LIVRE, etc..), et ça peut être les mêmes routines...

[Baptiste Wicht]

Je suis pas sûr de te suivre...

Le projet est en Java.

Le problème que je vois avec ta façon de faire, c'est que le module "Films" est obligé de connaître le module prêts. Donc si je veux ensuite rajouter un autre module, je suis obligé de modifier le module Films pour lui faire savoir qu'il y a un nouveau module.

J'aimerais bien éviter ça. J'aimerais bien avoir des modules que je peux ajouter sans modifier aucun des autres modules.

Sinon, je pourrais éventuellement partir sur deux sortes de modules. Car il faut avouer que si on désactive le module Films et le module Livres, l'application en devient inutile. On pourrait donc imaginer des modules principaux qui pourront être désactivés, mais il devra automatiquement en rester un et des modules secondaires, éventuellement dépendant d'un module principal, qui pourront être désactivés sans problèmes.

[souviron34]

Je suis pas sûr de te suivre...

Le projet est en Java.

ok je ne connais pas le Java..

Le problème que je vois avec ta façon de faire, c'est que le module "Films" est obligé de connaître le module prêts.

Non, le module films ne connaitrait que la liste des actons possibles., en aucun cas les fonctions ou modules éventuels.

C'est l'avantage de ce mécanisme.

Si tu veux, pour te faire prendre conscience, si ce vocabulaire t'es inconnu, c'est ce qui se passe dans un moteur graphique (et dans une interface, y compris en Java ) :

Chaque objet graphique a un type. En fonction de ce type, les concepteurs ont décidé qu'il pouvait y avoir un certain nombre d'actions ( exemple : un bouton-poussoir, tu as "armer" (passer dessus et y rester), désarmer (en sortir sans avoir cliqué), activer (appuyer dessus)).

Ils ne savent pas quelle méthode tu vas faire en créant l'interface , mais ils savent qu'elle sera de ce type.

Quand tu "drag and drop" un bouton dans une forme, avant que tu vois le module ouvert avec le nom de ta méthode toute prête et qui attend ton code, il y a eu un

"RegisterFunction ( boution, ACTIVATE, adresse de cette fonction)".

Ce qui leur permet, dans la bibliothèque, et sans savoir quelle est la fonction ou son nom, de l'appeller (par adresse uniquement).

Tu fais donc une bibliothèque qui simplement peut avoir des actions qui sont enregistrées par des modules que tu ne connais pas.

Voila ce que je voulais dire.

[Baptiste Wicht]

Oki, j'ai compris ce que tu voulais dire, mais je vois toujours le même inconvénient.

Le module "Films" gère les modules en quelque sorte, alors que pour moi, il ne devrait même pas se préoccupper du fait qu'il puisse y avoir des modules ou non. C'est la tâche du core de s'occupper des modules.

De plus si je veux ajouter un nouveau module (XXX_FILM) par exemple, il faudra que je modifie le module FILM pour ajouter un code permettant d'intégrer ce module alors que j'aimerais pouvoir ne rien modifier et juste ajouter ce module dans le dossier de mon application et qu'il soit pris en compte par le core.

Je pense vraiment que la solution la plus simple est de faire deux types de modules, les modules de bas niveau (Films et Livres) et ensuite les modules de plus haut niveau qui viennent rajouter des fonctionnalités aux modules de bas niveau (comme les statistiques), mais ça aurait été plus esthétique de faire une seule sorte de module.

[souviron34]

Oki, j'ai compris ce que tu voulais dire, mais je vois toujours le même inconvénient.

Le module "Films" gère les modules en quelque sorte, alors que pour moi, il ne devrait même pas se préoccupper du fait qu'il puisse y avoir des modules ou non. C'est la tâche du core de s'occupper des modules.

De plus si je veux ajouter un nouveau module (XXX_FILM) par exemple, il faudra que je modifie le module FILM pour ajouter un code permettant d'intégrer ce module alors que j'aimerais pouvoir ne rien modifier et juste ajouter ce module dans le dossier de mon application et qu'il soit pris en compte par le core.

Je pense vraiment que la solution la plus simple est de faire deux types de modules, les modules de bas niveau (Films et Livres) et ensuite les modules de plus haut niveau qui viennent rajouter des fonctionnalités aux modules de bas niveau (comme les statistiques), mais ça aurait été plus esthétique de faire une seule sorte de module.

peut-etre, mais je crois que tu n'as pas compris le fond de ce que je disais..

Le module "Films" gère les modules en quelque sorte, alors que pour moi, il ne devrait même pas se préoccupper du fait qu'il puisse y avoir des modules ou non. C'est la tâche du core de s'occupper des modules.

De plus si je veux ajouter un nouveau module (XXX_FILM) par exemple, il faudra que je modifie le module FILM pour ajouter un code permettant

non.. Encore une fois, il s'agit juste de connaitre les actions possibles, c'est tout...

Je te donne un exemple :

Film.h

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
typedef struct pPret {
       char Nom[500] ;
       char DateDebut[20] ;
       char DateFin[20] ;
 } Pret ;

typedef struct pFilm {
    char Titre[500] ;
    char Realisateur[500] ;
    int   Nb_Copies ;
    int   N_Prets ;
    Pret *Prets ;
} Film ;

#define ADD_PRET      0
#define MODIFY_PRET 1
#define DELETE_PRET  2

Film.c

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
.....

Film_Pret ( Film *MonFilm )   /* Routine appellee par l'IHM */
{
if ( RegisteredFunction ( ADD_PRET ) )
   CallRegisteredFunction ( ADD_PRET, (void *)MonFilm ) ;
...
}

Cette routine ne SAIT PAS quelle fonction elle appelle, donc quel module...
Il peut y en avoir une, plusieurs, ou zero.

Tu as juste besoin d'un module de gestions de fonctions independant ET d'avoir identifie toutes les actions que tu peux faire sur Film et ses sous-structures.

Dans ce cas, tes modules de gestion de pret, par exemple, sont independants,, et ton module film aussi.

Ton module Fct.c est un truc du style :

Fct.c

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
typedef struct pFct {
      int Type ;
      int *Fct ;
      void *data ;
} Fct ;

Fct *TableFct ;
int    NFcts =0;

RegisterFunction ( int Type, int *Fct, void *data )
{
   /* Fait l'allocation ou pointe au bon endroit */
   ..
   TableFct[i].Fct = Fct ;
   TableFct[i].data = data ;
   TableFct[i].Type = Type ;
   NFcts = NFcts + 1 ;
}

Boolean RegisteredFunction ( int Type )
{
  int i ;

  for ( i = 0 ; i < NFcts ; i++ )
    {
       if ( TableFct[i].Type == Type )
          return True ;
    }
   return False ;
}

void CallRegisteredFunction ( int Type, void *clientdata )
{
  int i, j ;

  for ( i = 0 ; i < NFcts ; i++ )
    {
       if ( TableFct[i].Type == Type )
         {
             j = TableFct[i].Fct ( TableFct[i].data, clientdata );   
         }
    }   
}

et dans ton module Pret.c tu aurais :


Pret.c

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
....
int EnregistrePret ( void *data, void *Clientdata )
{
   Film *Film = (Film *)ClientData ;

   /* Fait tes operations pour le pret */
   ....
}

/* Et quelque part dans une routine d'intialisation */
..

RegisterFunction ( ADD_PRET , &EnregistrePret, (void *)Whatever );
...

Mais maintenant si tu ne sais pas qu'est-ce que tu pourrais avoir comme fonctionalites, la, il faut faire plus ruse si tu veux etre completement independant..

[souviron34]

sinon encore une autre idee :

tu fais une "classe" ou ce que tu veux d'objet gere , dont Film (et/ou livre) est une instance.

Cette classe, elle, a les methodes adaptees. Et du coup, les 2 film ou livre, en profitent..

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
typedef struct pObjetGere {

   int Type ;
   Pret *Prets
   ...
} ObjetGere ;

ObjetGere Film ;
ObjetGere Livre ;

.....

et la-dessus tu fais juste un module central GereObjet, avec les methodes pour gerer les prets etc, et tu as ensuite un module GereFilm ou GereLivre.

[Baptiste Wicht]

Merci beaucoup pour l'exemple

Mais maintenant si tu ne sais pas qu'est-ce que tu pourrais avoir comme fonctionalites, la, il faut faire plus ruse si tu veux etre completement independant..

J'avais bien compris, mais je partais effectivement du principe que je ne sais pas quelles seront les fonctionnalités finales.

sinon encore une autre idee :

tu fais une "classe" ou ce que tu veux d'objet gere , dont Film (et/ou livre) est une instance.

Cette classe, elle, a les methodes adaptees. Et du coup, les 2 film ou livre, en profitent..

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
typedef struct pObjetGere {

   int Type ;
   Pret *Prets
   ...
} ObjetGere ;

ObjetGere Film ;
ObjetGere Livre ;

.....

et la-dessus tu fais juste un module central GereObjet, avec les methodes pour gerer les prets etc, et tu as ensuite un module GereFilm ou GereLivre.

Effectivement, c'est une idée à laquelle je n'avais pas pensé

Je vais encore réfléchir à tout ça et explorer les différentes pistes.

Merci beaucoup souviron

[eclesia]

J'ajoute une piste pour la réalisation :
lookup

J'ai découvert ca dans NetBeans RCP, c'est plutot pas mal quand on veut justement faire une appli extensible.

bref c'est une piste