usercontrol : obliger une propriété à être d'un type qui hérite d'un type de base bien précis

**Kropernic** · 12/09/2013, 13h51

Bonjour,

Je m'amuse actuellement à créer un contrôle pour afficher un diagramme de Gantt (ceux que l'on peut trouver sur le net en libre/payant ne correspondent pas bien à mon besoin).

Dans le code de mon usercontrol, j'ai donc une propriété que j'ai nommée DataSource qui sera chargée de recevoir les données à afficher dans le diagramme (aussi bien dans le DataGridView de gauche que la PictureBox de droite (cf. image en pièce jointe).

Le hic, c'est que pour afficher les barres dans ma PictoreBox, j'ai besoin d'informations spécifiques.

Pour donner un exemple concret, voici un modèle simple de 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
34
35
36
37
Public Class Employee
    Public Property Name As String
    Public Property Ranges As List(Of Range)
    Public Sub New(name As String)
        Me.Name = name
        Ranges = New List(Of Range)
    End Sub
    Public Sub AddRange(debut As Decimal, fin As Decimal, type As Range.TypeRange)
        ...
    End Sub
    Public Function GetRangeSurrounding(time As Decimal) As Range
        ...
    End Function
    Private Sub AddSimplifiedRange(debut As Decimal, fin As Decimal, type As Range.TypeRange)
        ...
    End Sub
    Private Sub SimplifyRange()
        ...
    End Sub
    Private Function GetRangeById(id As Integer) As Range
        ...
    End Function
End Class
Public Class Range
    Public Property Id As Integer
    Public Property Debut As Decimal
    Public Property Fin As Decimal
    Public Property Type As TypeRange
    Public Property Text As String
 
    Public Sub New(id As Integer, debut As Decimal, fin As Decimal, type As TypeRange)
        Me.Id = id
        Me.Debut = debut
        Me.Fin = fin
        Me.Type = type
    End Sub
End Class

Bon, là j'avais le test avec des employés donc la classe s'appelle Employee mais l'idée est là. Pour que mon contrôle fonctionne, il faut que l'objet passé à ma propriété DataSource hérite de cette classe Employee (qui sera bien sûr renommée de manière appropriée).

Ma question est donc : Comment définir que, pour une propriété d'une classe, son type DOIT hériter d'un type précis ?

**Kikuts** · 12/09/2013, 14h04

Peut être comme avec les génériques et le where.

Exemple pour une méthode :

Code :

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

1
2
3
4
public void SetDateSource(T dataSource) where T : ITypeObjetCommun, new()
{
 
}

Je te montre un exemple de code que j'ai :

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
 
public IEnumerable<T> GetAll<T>() where T : ICategorie, new()
		{
			IEnumerable<T> resultat = null;
 
			using (var edmx = new EDMXContainer())
			{
				var listeObj = edmx.CATEGORIES;
				var liste = new List<T>();
 
				if (listeObj.Count() > 0)
				{
					foreach (var element in listeObj)
					{
						liste.Add(new T() { Id = element.Id, Code = element.Code, Libelle = element.Libelle, Description = element.Description, Image = element.Image });
					}
				}
				if (liste.Count() > 0) resultat = liste;
 
			}
 
			return resultat;
		}
 
//appel :
 
var all = (List<CategorieDTO>)bll.GetAll<CategorieDTO>();

Le new permet d'utiliser le type passé dans la fonction en type de retour.

Tu peux définir une interface ITypeObjetCommun qui regroupe les infos obligatoires puis étendre les models qui l'implémente en fonction des besoins de chacun.

(ps : ce n'est qu'une piste je n'ai pas beaucoup réfléchi au problème car je suis en pleine digestion et sur un dév un peu casse bonbon ^^)

**DotNetMatt** · 12/09/2013, 14h09

Tu peux mettre Employee comme étant le type de la propriété.

Ainsi si tu as une classe EmployeeExtended qui hérite de Employee, tu pourras la passer à ta propriété...

**Kropernic** · 12/09/2013, 14h20

@Kikuts : Merci pour l'exemple. Je ne parle pas le C#. Du coup, je l'ai passé dans un traducteur et j'ai pas tout compris ^^.

@DotNetMatt (encore toi ? :p) : J'y avais songé. Ca se fait ce genre de choses ? J'ai pas osé car j'me suis dit que c'était une méthode de bourrin

.

Question corollaire :
Disons que j'applique la solution de DotNetMatt et que je renomme Employee en Source histoire d'être plus générique. Toujours pour être plus générique, je retire la propriété Name. Quand dans le programme qui utilisera mon contrôle, le dev affectera à DataSource un objet qui hérite de Source, comment dois-je faire pour connaître les propriétés qui existe en plus de Ranges ? Le mot réflexion me vient à l'esprit mais je ne l'ai encore jamais utilisée. Suis-je sur la bonne voie ?

**DotNetMatt** · 12/09/2013, 14h35

Envoyé par Kropernic

@DotNetMatt (encore toi ? :p) : J'y avais songé. Ca se fait ce genre de choses ? J'ai pas osé car j'me suis dit que c'était une méthode de bourrin

.

Oui encore moi

Et oui ça se fait, c'est le principe de l'héritage

Il y a d'autres moyens comme l'a dit Kikuts, comme par exemple en utilisant une interface, ou encore en passant par une classe abstraite.

Envoyé par Kropernic

Question corollaire :
Disons que j'applique la solution de DotNetMatt et que je renomme Employee en Source histoire d'être plus générique. Toujours pour être plus générique, je retire la propriété Name. Quand dans le programme qui utilisera mon contrôle, le dev affectera à DataSource un objet qui hérite de Source, comment dois-je faire pour connaître les propriétés qui existe en plus de Ranges ? Le mot réflexion me vient à l'esprit mais je ne l'ai encore jamais utilisée. Suis-je sur la bonne voie ?

La réflexion peut être utilisée dans ce cas, mais c'est surtout par un cast que tu pourras retrouver l'objet original. Un exemple :

Code VB.NET :

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

1
2
3
4
5
Dim sourceExt = New SourceExtended()    ' SourceExtended hérite de Source
Dim dc = New DummyClass()    ' DummyClass est une classe "bidon"...
dc.Source = sourceExt    ' La propriété Source est de type Source...
 
sourceExt = DirectCast(dc.Source, SourceExtended)    ' Avec un cast, on retrouve notre type initial (SourceExtended)

**Kropernic** · 12/09/2013, 14h44

Euh oui mais dans mon contrôle, je n'ai aucune idée de que le dev qui l'utilisera me donnera comme type (qui devra donc hériter de Source).

L'idée est de pouvoir passer toutes les propriétés de l'objet au DGV et de garder la propriété Range pour la partie d'affichage des barres du diagramme.

N.B. : En fait, la propriété DataSource doit être de type List(Of Source). Sinon, il n'y aura jamais qu'une seule ligne ^^

**Kikuts** · 12/09/2013, 14h57

Envoyé par Kropernic

@DotNetMatt (encore toi ? :p)

Il est partout ! En tout cas, il répond souvent présent quand j'ai un problème ! Mathieu est un mec en or

Si jamais tu veux je te mettrais le code en VB (à la base je l'avais fait en VB puis en c# pour un projet perso)

**Kropernic** · 12/09/2013, 15h07

Envoyé par Kikuts

Il est partout ! En tout cas, il répond souvent présent quand j'ai un problème ! Mathieu est un mec en or

Si jamais tu veux je te mettrais le code en VB (à la base je l'avais fait en VB puis en c# pour un projet perso)

Oui, il est souvent là pour moi aussi. On a déjà quelques conversations sur des sujets forts intéressants.

Pour le code, pas la peine. Je l'avais fait traduire sur developperfusion.com et je comprenais quand même pas ^^. Il y a plein de notion avec lesquelles je ne suis pas encore à l'aise et les génériques en font partie.

**Kikuts** · 12/09/2013, 15h13

Je ne suis toujours pas à l'aise avec alors que j'ai utilisé ce principe sur tout un projet xD

Donc je te comprend

faudrait que je trouve un livre bien complet là dessus un de ces 4 car depuis que je code, je crois que c'est un des trucs qui m'a fait le plus halluciner tant c'est puissant et permet de faire des choses incroyables !

**DotNetMatt** · 12/09/2013, 15h30

Merci les gars

J'essaie de faire du mieux possible

Envoyé par Kropernic

Euh oui mais dans mon contrôle, je n'ai aucune idée de que le dev qui l'utilisera me donnera comme type (qui devra donc hériter de Source).

C'est justement le principe : peu importe ce que le dev va te passer, l'important c'est qu'il hérite de Source. Je pense qu'il faut poser clairement le code...

La classe Source, qui est la classe de base dont les autres vont hériter :

Code VB.NET :

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

1
2
3
4
5
6
7
8
9
10
11
Public Class Source
	Public Property Id() As Integer
		Get
			Return m_Id
		End Get
		Set
			m_Id = Value
		End Set
	End Property
	Private m_Id As Integer
End Class

La classe SourceExtended, qui hérite de Source :

Code VB.NET :

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

1
2
3
4
5
6
7
8
9
10
11
12
Public Class SourceExtended
	Inherits Source
	Public Property ExtendedObject() As Object
		Get
			Return m_ExtendedObject
		End Get
		Set
			m_ExtendedObject = Value
		End Set
	End Property
	Private m_ExtendedObject As Object
End Class

La classe SourceFiltered, qui hérite aussi de Source :

Code VB.NET :

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

1
2
3
4
5
6
7
8
9
10
11
12
Public Class SourceFiltered
	Inherits Source
	Public Property FilteredObject() As Object
		Get
			Return m_FilteredObject
		End Get
		Set
			m_FilteredObject = Value
		End Set
	End Property
	Private m_FilteredObject As Object
End Class

Ok, maintenant on va supposer que le développeur initialise un objet de type SourceFiltered :

Code VB.NET :

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

1
2
3
Dim sf = New SourceFiltered()
sf.Id = 1
sf.FilteredObject = New Object() {1, 2, 3}

Pour le recevoir, j'ai deux options. La première c'est de recevoir on objet de type SourceFiltered :

Code VB.NET :

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

1
2
3
4
5
6
7
8
9
10
11
Public Class Control
	Public Property DataSource() As SourceFiltered
		Get
			Return m_DataSource
		End Get
		Set
			m_DataSource = Value
		End Set
	End Property
	Private m_DataSource As SourceFiltered
End Class

La seconde, c'est de recevoir un objet de type Source :

Code VB.NET :

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

1
2
3
4
5
6
7
8
9
10
11
Public Class Control
	Public Property DataSource() As Source
		Get
			Return m_DataSource
		End Get
		Set
			m_DataSource = Value
		End Set
	End Property
	Private m_DataSource As Source
End Class

Les deux fonctionnent (sf étant la variable qu'on a utilisé un peu plus haut) :

Code VB.NET :

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

1
2
Dim ctrl = New Control()
ctrl.DataSource = sf

L'avantage de la seconde, c'est que si le développeur veut m'envoyer un objet typé en SourceExtended, il pourra aussi... On va donc rester sur ça, ce qui est apparemment ce que tu souhaites faire.

Ensuite, au sein de mon Control, je peux tester le type de la DataSource et effectuer un traitement en conséquence :

Code VB.NET :

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
Public Sub ProcessDataSource()
	If TypeOf Me.DataSource Is SourceExtended Then
		Me.ProcessSourceExtended()
	ElseIf TypeOf Me.DataSource Is SourceFiltered Then
		Me.ProcessSourceFiltered()
	End If
End Sub
 
Private Sub ProcessSourceExtended()
	Dim se As SourceExtended = TryCast(Me.DataSource, SourceExtended)
	If se IsNot Nothing Then
		' Le traitement pour un objet de type SourceExtended...
	End If
End Sub
 
Private Sub ProcessSourceFiltered()
	Dim sf As SourceFiltered = TryCast(Me.DataSource, SourceFiltered)
	If sf IsNot Nothing Then
		' Le traitement pour un objet de type SourceFiltered...
	End If
End Sub

Bon, ça c'est un exemple assez simple. Est-ce que c'est ce que tu veux faire ?

On peut aussi complexifier en rajoutant des Generics, on peut aussi passer par une interface ou encore une classe abstraite mais il faut en avoir l'utilité.

**Kropernic** · 12/09/2013, 15h46

Oui oui, ça j'avais bien compris

Le souci c'est que le dev lui va faire :

Code :

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

control.DataSource = sourceMachinTrucMuche

où sourceMachinTrucMuche est de type SourceMachinTrucMuche qui hérite de Source.

Bref, je n'ai aucune idée de la classe dérivée que je vais recevoir. Je sais juste que ce sera une classe dérivée. Rien d'autre.

C'est là dessus que je bloque...

Si les possibilités étaient en nombre fini, pas de souci. Mais ce n'est pas le cas me semble-t-il.

**Sehnsucht** · 12/09/2013, 15h59

Je me trompe peut-être mais pour devoir recourir à un test de Type + cast ; va totalement à l'encontre des principes OO (le polymorphisme dans ce cas)

A priori la classe Source doit rendre des services, et tous ses dérivés doivent rendre au moins les mêmes services (pas forcément de la même manière d'où la surcharge). Par conséquent les "consommateurs" de cette classe (Source ou un dérivé qui reste un Source) ne devraient utiliser que l'interface (au sens prototype d'API) de Source (et c'est le polymorphisme qui délèguera le boulot, l'action concrète étant réalisant par le bon type)

Bon c'est pas très clair tout ça

Un exemple (très schématique) de ce que je veux dire:

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
Class SourceBase
 
    Public Overridable Function Foo() As String
        Return "SourceBase.Foo"
    End Function
End Class
 
Class SourceDerived
    Inherits SourceBase
 
    Public Overrides Function Foo() As String
        Return "SourceDerived.Foo"
    End Function
End Class
 
Class Consumer
    Public Property Source As SourceBase
End Class

Si maintenant je fais une boucle sur différents consommateurs, en affichant le Foo de leur Source respectifs, le consommateur ne saura jamais quel type réel de Source il a (et il s'en fout, après tout ce qu'il veut c'est que le boulot soit fait, pas savoir qui le fait), malgré tout ; chaque Source effectuera bien son protocole spécifique, ainsi :

Code :

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

1
2
Array.ForEach({New Consumer With {.Source = New SourceBase}, New Consumer With {.Source = New SourceDerived}},
              Sub(cons) Console.WriteLine(cons.Source.Foo))

Affichera bien

SourceBase.Foo
SourceDerived.Foo

Pour résumer (d'une manière générale) pour moi, un "consommateur" n'a jamais besoin de savoir QUI il utilise, juste savoir de QUOI il est capable

Cordialement !

**Kropernic** · 12/09/2013, 16h09

Autant je suis d'accord avec ce que tu expliques, autant je ne vois pas comment l'appliquer à mon problème.

Je crois que c'est une autre problématique (problématique que j'avais abordé dans un autre sujet il y a quelques temps que voici)

Ici, j'ai un usercontrol C avec une propriété P de type S.

Dans une application, un developer va ajouter C à son interface. Il va ensuite affecter à P un objet de type S1 (où S1 hérite de S).

Dans C, je veux pouvoir récupérer les propriétés de S1 qui ne viennent pas de S afin de les afficher dans le DataGridView qui se trouve dans C.

Or le developer pourrait tout aussi bien affecter à P un objet de type S2, S3, S4, ..., SN (où tous héritent de S). Je ne sais donc pas quoi faire dans C.

**DotNetMatt** · 12/09/2013, 16h09

Tu as raison pour le cas que tu décris, avec juste des méthodes overridées

Si on considère mes 3 classes (plus haut) : Source, SourceExtended et SourceFiltered.

La propriété DataSource étant de type Source, on n'aura jamais accès aux propriétés ExtendedObject et FilteredObject sans faire de cast...

**Sehnsucht** · 12/09/2013, 16h24

J'ai peut-être une vision trop rigoriste de l'OO mais si Source ne présente pas de propriétés ExtendedObject et FilteredObject c'est que du point de vue consommateur il n'en a pas besoin; et si on en a besoin c'est qu'il y a un souci de conception ; recourir à une solution à base de cast va à l'encontre des principes OO (après techniquement c'est faisable je ne dis pas le contraire

)

**DotNetMatt** · 12/09/2013, 16h43

Tu es en fait un intégriste de l'OO

Plus sérieusement, je ne pense pas que ça enfreigne les principes OO. Pour rester sur mon exemple, si je met les propriétés FilteredObject et ExtendedObject dans la classe Source directement --> plus besoin d'héritage. Ou alors si on conserve l'héritage, cela voudrait dire qu'on a omi de prendre en compte le principe d'encapsulation, puisque les propriétés seraient accessibles indifféremment par une classe ou l'autre.

Je ne vois pas comment est-ce que tu peux faire sans cast, il y a bien un moment où il faut que tu saches à quel objet tu as à faire.

Au boulot, je bosse sur une appli avec pas mal de niveaux d'héritage, sur certains modules on atteint la trentaine de niveaux. On est obligés de faire des casts et de tester le type à certains moments afin de pouvoir aiguiller correctement le traitement.

**Kropernic** · 12/09/2013, 16h56

Quoi qu'il en soit (à vrai dire, je ne sais même pas si vous êtes lancé sur une discussion "philosophique" à propos de l'OO ou si vous discutez toujours de mon problème

), ça ne marche pas.

Dans un projet de test, j'ai mis le contrôle dans une winform et voici un p'tit bout de code on ne peut plus simple :

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
Public Class Form1
    Dim tst As List(Of test)
    Private Sub Form1_Load(sender As System.Object, e As System.EventArgs) Handles MyBase.Load
        tst = New List(Of test)
        tst.Add(New test("arnaud"))
        tst.Add(New test("ruben"))
        tst.Add(New test("luk"))
        Me.GanttHourDiagram1.DataSource = tst
    End Sub
End Class
Public Class test
    Inherits GanttDiagram.GanttHourDiagram.Source
    Public Property Name As String
    Public Sub New(name As String)
        Me.Name = name
    End Sub
End Class

VS râle sur la ligne en gras en me disant qu'il ne peut pas convertir une liste de test en une liste de source... Pourtant test est dérivé de source. Je croyais qu'on pouvait faire ça. Où est-ce que je me plante ?

**ebastien** · 12/09/2013, 17h02

Grand débat sur l'OO !

C'est un débat sans fin, d'autant que vous avez (à mon sens) tous les deux raison.
Maintenant concernant la problématique de Kropernic, je pense qu'il veut juste afficher les propriétés d'un objets dans un Grid sans même savoir de quelle classe il s'agit car son UserControl ne connait que la classe de base, façon éditeur de propriété si j'ai bien compris. Et là, il me semble que sa première idée concernant la réflexion sera la plus efficace.

**Kropernic** · 12/09/2013, 17h13

Envoyé par ebastien

Grand débat sur l'OO !

C'est un débat sans fin, d'autant que vous avez (à mon sens) tous les deux raison.
Maintenant concernant la problématique de Kropernic, je pense qu'il veut juste afficher les propriétés d'un objets dans un Grid sans même savoir de quelle classe il s'agit car son UserControl ne connait que la classe de base, façon éditeur de propriété si j'ai bien compris. Et là, il me semble que sa première idée concernant la réflexion sera la plus efficace.

Je crois bien que tu y es.

Histoire d'être sûr, dans le premier message j'ai mis une image en pièce jointe. C'est une image du contrôle lorsque je run son projet. On y voit clairement deux parties. Une toute grise à gauche et une grille horaire avec des radiobuttons en dessous.

La partie grise est un DataGridView.

Ce que je veux faire, c'est afficher dans ce DGV les propriétés de Source qui ne sont pas une liste de Range.