Discussion :

[zax-tfh]

Bonjour à tous,

Je suis bloqué sur un truc et je cherche à trouver une solution "élégante" :
J'ai une classe métier avec un point d'entrée DoWork qui attend un parametre typé as IInterfaceBase.
Dans cette classe j'ai deux fonctions privées : DoWorkA(arg as IInterfaceA) et DoWorkB(arg as IInterfaceB)
InterfaceA et InterfaceB héritent de IInterfaceBase.
J'aimerai que quand j'envoie un objet implémentant IInterfaceA dans DoWork, cela puisse router vers DoWorkA et quand j'envoie un objet implémentant IInterfaceB dans DoWork, j'aimerai qu'il aille dans DoWorkB.
Malheureusement, ça n'a pas l'air de fonctionner comme ça dans la vraie vie.
Voici le bout de code qui illustre mes propos :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
 
    Public Function DoWork(argument As IBaseInterface) As String
        Return Consume(argument)
    End Function
 
    Private Function Consume(int As IBaseInterface) As String
        Return "work for Base Interface Object"
    End Function
 
    Private Function Consume(int As IInheritedInterface) As String
        Return "work for inherited Interface Object"
    End Function

Quand j'appelle DoWork, quel que soit le type de l'argument, je passerai toujours dans la fonction Consume typée (IBaseInterface).
La façon moins élégante de coder cela serait de modifier DoWork comme ceci :

Code :

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

1
2
3
4
5
6
7
8
9
 
 Public Function DoWork(argument As IBaseInterface) As String
        Select Case True
            Case TypeOf argument Is IInheritedInterface
                Return Consume(DirectCast(argument, IInheritedInterface))
            Case TypeOf argument Is IBaseInterface
                Return Consume(DirectCast(argument, IBaseInterface))
        End Select
    End Function

Le problème est que cet exemple est très simpliste. Quand on a plusieurs arguments typés "interface de base" ça peut vite devenir très moche. Et puis bon, j'ai bon espoir qu'il y ait une solution bien plus lisible que ça !
Si vous avez une idée... je suis preneur
Merci d'avance

[mermich]

Salut,

le probleme vient de la conception: c'est a l'implementation de tes interfaces d'effectuer le code, pas a ta classe appellante. en d'autres tu essaies de changer de comportement en fonction du type d'objet passe en parametre, mais c'est le 'type' d'objet lui meme qui devrait implementer le code.

Donc a part un switch case, ecrit d'une maniere ou d'une autre je ne vois pas commente realiser ce que tu veux faire.

[zax-tfh]

Salut Mermich,

Niveau conception, tout dépend ce que tu recherches. Pour le coup, ces interfaces sont des contrats permettant le transport de données (DTO) donc dénués de toute logique fonctionnelle. La conception est donc correcte.
Cela dit, nous avons fait le choix d'opter pour les surcharges.
Plutot que d'avoir un seul point d'entrée public et un dispatch derriere, nous avons plusieurs points d'entrée (autant qu'il y a de dérivées) et ensuite on fait la sauce à partir de là.
Ce qui donne grosso modo :

Code :

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

1
2
3
4
5
6
7
8
 
public Function DoWork(int As IInheritedInterface1) As String
        Return "work for inherited Interface1 Object"
    End Function
 
    public Function DoWork(int As IInheritedInterface2) As String
        Return "work for inherited Interface2 Object"
    End Function

[mermich]

Ouais, j'imaginais un truc du genre.

Donc tu pourras pas te passer d'un switch ecrit d'une maniere ou d'une autre:

• getType().GetInterfaces()
• test via le 'is'
• crado via try cast /try catch

[zax-tfh]

au temps pour moi, j'avais oublié de modifier les interfaces des arguments (que je viens de corriger dans mon message précédent).
A partir du moment où tu types avec les interfaces dérivées, ça roule, pas besoin de reflection