Interface en tant que type

Version imprimable

04/03/2009, 16h22
topolino

Interface en tant que type

Bonjour,

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

Merci
04/03/2009, 16h44
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.
04/03/2009, 16h57
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

Code:

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

A+

04/03/2009, 17h12
topolino
Ca revient au meme que
Code:

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

Avec Carriole .moteur de type IAnimal:

Code:

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

Pour aller plus loin (fabrique) tu fais:

Code:

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

Tu evites ainsi

Code:

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:

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+

Code:

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:

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;
        }
}

Une petite question au passage :
Citation:
Envoyé par Immobilis
Code:

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.

Citation:

Envoyé par SaumonAgile

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:

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.

Citation:

Envoyé par Arthis

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.

Citation:

Envoyé par SaumonAgile

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+

06/03/2009, 08h32
SaumonAgile

Citation:

Envoyé par Immobilis

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

Citation:

Envoyé par Immobilis

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. :king:
06/03/2009, 09h39
Immobilis

Citation:

Envoyé par SaumonAgile

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

Quelles différences entre "throw ex" et "throw"?
06/03/2009, 15h52
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:

1 2 3 Assembly assembly = Assembly.GetExecutingAssembly(); Type[] mytypes = assembly.GetTypes();
Et ensuite, tu instancies un objet :
Code:

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

Citation:

Envoyé par Arthis

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

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

Citation:

Envoyé par Arthis

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:

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 :P ;)...

A+

06/03/2009, 16h42
Arthis

ok merci de ton explication.

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

Bon week end,
a+
06/03/2009, 23h04
SaumonAgile

Citation:

Envoyé par Immobilis

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.