Discussion :

[topolino]

Bonjour,

Quelle est l'avantage de mettre comme type de methode une interface ?

Merci

[Arthis]

Donner une interface plutot qu'une classe. C'est simplement donner la notion de mouvement, d'action comme notion de communication entre deux entites.

Prenons un exemple:

la classe cheval a quatre pattes et sait courir.
l'homme a deux apttes et sait courir.

Tu as besoin pour ta carriole d'un animal qui sait courir, tu vas donc creer l'interface animal avec la fonction courir et les classes homme et cheval rempliront son contrat.

Ainsi, peu importe que ce soit un cheval ou un homme (peu importe les proprietes de la classe) qui tire la carriole elle sait que quelqu un va courir pour la tirer.
Toi tu ainsi pouvoir jouer avec cette interface pour selon le poids de la carriole la faire tirer par un homme ou par un cheval.

[topolino]

Si je mets comme type l'interface, à quel moment je fais lui dire c'est le cheval ou l'homme que je prefere utiliser ? car les 2 class font implementer la method courir de l'interface

[Immobilis]

Code :

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

1
2
3
4
5
6
 
IAnimal moteur = new Homme();
IAnimal moteur2 = new Cheval();
 
moteur.Avance();
moteur2.Avance();

A+

[topolino]

Ca revient au meme que

Code :

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

1
2
3
4
5
Homme moteur = new Homme();
Cheval moteur2 = new Cheval();
 
moteur.Avance();
moteur2.Avance();

Alors je ne vois pas trop l'interet ? excusez moi mais j'essaye de comprendre

[Arthis]

Avec Carriole .moteur de type IAnimal:

Code :

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

1
2
3
4
5
6
7
8
 
if (Carrriole.Lourde)
  Carrriole.moteur = new Cheval();
else
  Carrriole.moteur = new Homme();
 
 
Carriole.moteur.avancer()

[Immobilis]

Pour aller plus loin (fabrique) tu fais:

Code :

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

1
2
3
 
IAnimal animal = Fabrique.CreateAnimal("Homme");
animal.Avance();

Tu evites ainsi

Code :

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

1
2
3
4
5
6
7
8
9
10
string nomanimal = "Homme";
switch (nomanimal.ToUpperInvariant())
{
    case "CHEVAL":
        break;
    case "HOMME":
        break;
    default:
        break;
}

Exemple avec la recurcivité

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
public static IAnimal CreateAnimal(string animal)
{
    Object obj = null;
 
    if (!string.IsNullOrEmpty(animal))
    {
        Assembly assembly = Assembly.GetExecutingAssembly();
 
        Type[] mytypes = assembly.GetTypes();
        foreach (Type t in mytypes)
        {
            if (t.IsClass)
            {
                IList<CustomAttributeData> lstAttributs = CustomAttributeData.GetCustomAttributes(t);
                foreach (CustomAttributeData atr in lstAttributs)
                {
                    if ((atr.ConstructorArguments.Count > 0)
                        && atr.ConstructorArguments[0].ToString().Replace("\"", "") == animal.ToUpperInvariant())
                    {
                        try
                        {
                            obj = Activator.CreateInstance(t);
                            break;
                        }
                        catch (ArgumentNullException ex) { throw(ex); }
                        catch (ArgumentException ex) { throw(ex); }
                        catch (NotSupportedException ex) { throw(ex); }
                        catch (TargetInvocationException ex) { throw(ex); }
                        catch (MethodAccessException ex) { throw(ex); }
                        catch (MemberAccessException ex) { throw(ex); }
                        catch (TypeLoadException ex) { throw(ex); }
                    }
                }
 
            }
        }
    }
    else
    { }
 
    return (IAnimal)obj;
 
}

A+

[Arthis]

Code :

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

public static IAnimal CreateAnimal(string animal)

je ne suis pas un grand fan de type d'ecriture peut etre a tort.
Personnellement, je prefere penser que ma fabrique sait ce qu'elle doit fabriquer et quelle connait les differentes classes.

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
  public class AnimalFactory
    {
 
        /// <summary>
        /// Candidate type available
        /// </summary>
        public enum E_AnimalType
        {
            Homme,
            Cheval
        }
 
       public static IAnimal GetInstance()
        {
            return AnimalFactory.GetInstance( E_AnimalType.Homme);
        }
 
        public static IAnimal GetInstance(E_AnimalType animaltype)
        {
            IAnimal Instance = null;
            switch (animaltype)
            {
                case E_AnimalType.Homme:
                    Instance = new ConcreteProviders.Homme();
                    break;
                case E_AnimalType.Cheval:
                    Instance = new ConcreteProviders.Cheval();
                    break;
            }
 
            return Instance;
        }
}

[SaumonAgile]

Une petite question au passage :

Code :

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

1
2
3
4
5
6
7
8
 
catch (ArgumentNullException ex) { throw(ex); }
catch (ArgumentException ex) { throw(ex); }
catch (NotSupportedException ex) { throw(ex); }
catch (TargetInvocationException ex) { throw(ex); }
catch (MethodAccessException ex) { throw(ex); }
catch (MemberAccessException ex) { throw(ex); }
catch (TypeLoadException ex) { throw(ex); }

Elle servent à quoi ces horreurs ?

Et je plusine la remarque d'Arthis, je préférerais l'utilisation d'une enum, à mon sens c'est bien plus propre dans ce cas précis.

[Immobilis]

Une petite question au passage :
Elle servent à quoi ces horreurs ?

En fait, à la place du throw, il y a un appel à une fonction qui envoi un mail indiquant une erreur.

J'ai pris le parti de systematiquement (ou presque) capturer les erreurs des méthodes auxquelles je fais appel pour décider si oui ou non l'erreur en question doit remonter (jetée) ou etre signalée ou ignorée. Cela me permet de réellement gérer les erreurs. Sans quoi pas de gestion fine. C'est un peu lourd, mais à mon sens indispensable. Exemple dans le code ci-dessous.

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
using System;
using System.Collections.Generic;
using System.Text;
 
namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            try
            {
                MaFonction(args[0].ToString());
            }
            catch (Exception ex)
            {
                throw ex;
            }
        }
 
        private static void MaFonction(string p)
        {
            try
            {
                Console.WriteLine(p);
            }
            catch (FormatException ex)
            {
                throw ex;
            }
            catch (System.IO.IOException ex)
            {
                // Do nothing
            }
            catch (ArgumentNullException ex)
            {
                // Log into windows application log
            }
        }
    }
}

Mon programme console est lancé sous DOS. Il attend une chaine, mais la chaine peut etre "null". Si c'est le cas mais que je ne veux pas que mon programme plante, je suis obligé de capturer et gérer l'erreur. Pour éviter de ne capturer que des exceptions de type "Exception", je gère tous les types d'erreur. FXCop d'ailleurs recommande de ne gérer que les erreurs attendues. Au début, je n'ai fait que respecter cette recommendantion. Mais je me rend compte de son utilité. Ca m'a sauvé plusieurs fois.

je ne suis pas un grand fan de type d'ecriture peut etre a tort.

L'utilisation d'une enum pose pb quand la classe est générée en fonction d'un parametre dans une URL par exemple. La chaine est un peu moins stricte. Contrairement à ce que tu penses la factory "sait" très bien ce qu'elle doit créer.

Et je plusine la remarque d'Arthis, je préférerais l'utilisation d'une enum, à mon sens c'est bien plus propre dans ce cas précis.

Ca se discute... Dans mon cas j'ai préféré ajouter un attribu personnel afin d'identifier ma classe et d'utiliser la reflection pour la retrouver. Cela élimine la maintenance d'une enum.

A+

[SaumonAgile]

En fait, à la place du throw, il y a un appel à une fonction qui envoi un mail indiquant une erreur.

Oui mais c'est le throw ex; qui m'a dérangé. Dans ce cas, utilise plutôt throw; tout simplement.

Ca se discute... Dans mon cas j'ai préféré ajouter un attribu personnel afin d'identifier ma classe et d'utiliser la reflection pour la retrouver. Cela élimine la maintenance d'une enum.

Je plusine ça aussi. C'est un peu plus lourd mais plus facile à faire évoluer ensuite.

[Immobilis]

Dans ce cas, utilise plutôt throw; tout simplement.

Quelles différences entre "throw ex" et "throw"?

[Arthis]

puis je me permettre une question Immobilis ? (bon en fait je me permets.. )

Si j ai bien compris ton code, lorsque tu declares ta factory tu realises un foreach sur tous les tapes contenus dans ton assembly :

Code :

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

1
2
3
Assembly assembly = Assembly.GetExecutingAssembly();
 
Type[] mytypes = assembly.GetTypes();

Et ensuite, tu instancies un objet :

Code :

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

1
2
3
4
5
try
{
   obj = Activator.CreateInstance(t);
   break;
}

Cela signifie donc que tu crees une factory par assembly? En fait je ne suis pas sur de tout comprendre dans ton code..

[Immobilis]

puis je me permettre une question Immobilis ? (bon en fait je me permets.. )

Super, j'aime bien expliquer ce que je fais.

Cela signifie donc que tu crees une factory par assembly?

Non, juste une pour ma BLL dans un projet précis. Je traaille sur un systeme de passerelle. Comme je suis une grosse feignasse, j'ai pas eu envie de trop dupliquer de code donc je me suis dit pourquoi pas une interface et une fabrique.
Exemple: J'ai une collection de robots qui vont aller me chercher des infos. Chaque robot est programmé pour réaliser un travail précis (aller chercher des infos) mais chacun d'une façon différente et dans des lieux différents. Je me suis dit qu'ils devaient obéir tous au même ordre: "Va chercher!". Grace aux interface je dis:

Code :

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

1
2
3
4
5
6
7
 
IRobot robot = Fabrique.CreateRobot("R2D2");
robot.VaChercher();
IRobot robot = Fabrique.CreateRobot("6PO");
robot.VaChercher();
IRobot robot = Fabrique.CreateRobot("RADAR");
robot.VaChercher();

Le nom du robot est passé par parametre. R2D2 m'apporte le pain, 6PO mes chaussons, RADAR mon journal. Pour "S1m0ne" c'est une autre méthode ...

A+

[Arthis]

ok merci de ton explication.

J'y réfléchirais pour la prochaine fois.

Bon week end,
a+

[SaumonAgile]

Quelles différences entre "throw ex" et "throw"?

throw ex declenche une nouvelle exception qui ressemble à l'exception de départ (même message) alors que throw laisse remonter l'exception en elle-même. Dans le premier cas, tu perds la stacktrace, dans le 2e non. Top critique comme info quand tu débogues.