Discussion :

[progfou]

Bonjour tout le monde !

Dans un code, je viens de trouver une structure de l'algorithme qui me semble assez peu efficace...
Qu'en pensez-vous ?

Code :

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

1
2
3
4
5
6
do
{
  if(!ma_fonction1(arg1)) break;
  if(!ma_fonction2(arg2)) break;
  //etc...
}while(0)

ma_fonction1 et ma_fonction2 vont mettre en forme arg1 dans une classe par exemple, et retourner un false en cas d'erreur.

Je trouve cela commode, mais inefficace...
Qu'en est-il ?

Merci d'avance !

[millie]

Bonjour tout le monde !

Dans un code, je viens de trouver une structure de l'algorithme qui me semble assez peu efficace...
Qu'en pensez-vous ?

Code :

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

1
2
3
4
5
6
do
{
  if(!ma_fonction1(arg1)) break;
  if(!ma_fonction2(arg2)) break;
  //etc...
}while(0)

ma_fonction1 et ma_fonction2 vont mettre en forme arg1 dans une classe par exemple, et retourner un false en cas d'erreur.

Je trouve cela commode, mais inefficace...
Qu'en est-il ?

Merci d'avance !

Code :

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

1
2
 
while(mafonction1(arg1) && mafonction2(arg2));

avec évaluation paresseuse des booléens ?

[progfou]

Et dans le cas où ce ne sont pas deux mais 20 ou 30 fonctions (ce qui est le cas) ?

[pseudocode]

Encore plus sale:

Code C :

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

1
2
 
ma_fonction1(arg1) && ma_fonction2(arg2) && ma_fonction3(arg3);

[progfou]

Oui, ok pour quelques fonctions, mais est-ce que c'est bien de faire cela quand on a des dizaines de fonctions ?

[pseudocode]

Et dans le cas où ce ne sont pas deux mais 20 ou 30 fonctions (ce qui est le cas) ?

Code C :

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

1
2
3
4
5
6
 
if(!ma_fonction1(arg1));
else if(!ma_fonction2(arg2));
else if(!ma_fonction1(arg3));
/* ... */
else if(!ma_fonction20(arg20));

sinon il y a les pointeurs sur fonctions...

[progfou]

Qu'est-ce qui est le mieux ?
Ce qui sera bien optimisé par le compilo, facile à lire, etc. ?

[Lowelace]

Bonjour,

Pour reprendre l'idée de pseudocode, pourquoi ne pas construire une liste chainée de "fonctions" (une implémentation possible du design pattern "chaine de responsabilité") :
Plus :
- code compact (sauf l'initialisation de la liste)
- code évolutif

Moins :
- pas très lisible, ou du moins compréhensible

[pseudocode]

Pour reprendre l'idée de pseudocode, pourquoi ne pas construire une liste chainée de "fonctions" (une implémentation possible du design pattern "chaine de responsabilité")

Si le langage utilisé est le C, l'idée de vouloir construire un DP objet me parrait étrange. Si c'est du C++, autant utiliser un bloc try/catch

[Lowelace]

Si le langage utilisé est le C, l'idée de vouloir construire un DP objet me parrait étrange. Si c'est du C++, autant utiliser un bloc try/catch

Un design pattern est certes fortement basé sur des concepts objet mais rien n'empêche d'utiliser le concept sous-jacent avec des langages non objets, ou d'en avoir une implémentation non-objet.

Une liste de fonctions que l'on parcourt est une façon de faire qui reprend le concept de la chaine de responsabilité mais qui n'a rien d'objet dans son implémentation.

Ce n'est peut-être pas non plus la solution optimale (en terme de performances), c'est une question de compromis.

[pseudocode]

Une liste de fonctions que l'on parcourt est une facon de faire qui reprend le concept de la chaine de responsabilité mais qui n'a rien d'objet dans son implémentation.

Parcourir une liste de fonctions et le DP chaine de responsabilité ce n'est quand meme pas pareil.

De toutes facons, la contrainte d'utiliser des arguments identiques pour chaque appel de fonction ne semble pas être possible ici.

[Lowelace]

Repris de la Wikipédia :

En génie logiciel, le patron de conception Chaîne de responsabilité permet à un nombre quelconque de classes d'essayer de répondre à une requête sans connaître les possibilités des autres classes sur cette requête. Cela permet de diminuer le couplage entre objets. Le seul lien commun entre ces objets étant cette requête qui passe d'un objet à l'autre jusqu'à ce que l'un des objets puisse répondre.

Pour moi, une liste de fonctions que l'on parcourt répond à cette définition, même si je te l'accorde, c'est une implémentation "préhistorique".

Par contre, je suis aussi d'accord sur le fait que si les paramètres sont différents, çà complique les choses

[pseudocode]

Pour moi, une liste de fonctions que l'on parcourt répond à cette définition, même si je te l'accorde, c'est une implémentation "préhistorique".

Dans l'implémentation de référence du GoF, chaque handler ne connait que son successeur => implémentation en liste chainée (d'où le nom du pattern ).

Utiliser une liste et un itérateur n'est pas pour moi une implémentation du pattern CoR.

Par contre, je suis aussi d'accord sur le fait que si les paramètres sont différents, çà complique les choses

Comme tu l'as dit toi même:

En génie logiciel, le patron de conception Chaîne de responsabilité permet à un nombre quelconque de classes d'essayer de répondre à une requête sans connaître les possibilités des autres classes sur cette requête. Cela permet de diminuer le couplage entre objets. Le seul lien commun entre ces objets étant cette requête qui passe d'un objet à l'autre jusqu'à ce que l'un des objets puisse répondre.

Si chaque handler doit gérer une requête différente, ca n'a plus rien a voir avec l'objectif du pattern.

[Lowelace]

On n'est pas dans une implémentation stricto sensu du pattern, mais l'idée sous-jacente reste la même.

C'est ce qui, à mon avis, est le plus important.

progfou : quelles têtes ont les paramètres des fonctions ?

[progfou]

C'est très variable.

[pseudocode]

je pense que ton approche de départ est la plus simple. Peut-etre en utilisant un autre type de bloc que le do/while, comme par exemple le switch.

Code C :

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

1
2
3
4
5
6
7
 
switch(0) { 
case 0:
	if(!ma_fonction1(arg1))  break;
	if(!ma_fonction2(arg2))  break;
	if(!ma_fonction3(arg3)) break;
}

Peut-etre également utiliser des #define pour simplifier la relecture...

Code C :

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

1
2
3
4
 
#define TRY_BEGIN  switch(0) {case 0:
#define TRY(f) if (!f) break;
#define TRY_END  }

Code C :

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

1
2
3
4
5
6
 
TRY_BEGIN {
	TRY( ma_fonction1(arg1) );
	TRY( ma_fonction2(arg2) );
	TRY( ma_fonction3(arg3) );
} TRY_END;