Principe de dévelloppement

Question

Bonjour,

J'ai une Classe A (Public) qui sert d'aiguillage vers une classe Serveur ou une classe Client (les 2 classes en Friend)
Et un certains nombres d'interface et méthode

Avec une propriété Serveur qui permet de savoir si je suis Serveur ou Client
Qui crée un classe Serveur ou Client suivant cette propriété

Je voudrait écrire Une Classe Serveur et Une Classe Client qui hérite de la Classe A.

Es la bonne méthode ?

Suite à quelque test je suis capable de d'accéder à mes méthodes et mes propriétés de la classe A via une redéclaration de celle-ci dans les classes serveur et client en utilisant Mybase.

Malheureusement pour les interfaces de la classe A je ne sait pas comment faire ?

Merci.

Mayzz · Answer

Salut,

C'est pas très précis :

Si j'ai bien compris t'as une classe A qui a une propriété qui définis si une autre propriété de cette classe A sera de Type classe Client ou classe Serveur. Et tu souaiterais que cette classe hérite des méthodes et propriétés de la classe A ???

Classe A
 => Propriété Server (Boolean)
 => Propriété QueSuisJe (Classe inherits A)

je comprend pas trop le but, ou alors tu as mal détaillé ta question...

++ Mayzz.

Si le déboguage est l'art d'enlever les bogues, la programmation doit être l'art de les créer.

jlg42 · Answer

Je vais essayé d'être plus claire
Classe A 
  une propriété ObjServeur as boolean
  une méthode start
    If ObjServeur Then
          If MyServeur Is Nothing Then MyServeur = New Serveur(Me)
          If MyClient IsNot Nothing Then MyClient = Nothing
        Else
          If MyClient Is Nothing Then MyClient = New Client(Me)
          If MyServeur IsNot Nothing Then MyServeur = Nothing
        End If
donc la Classe A est soit serveur soit client suivant la valeur de la propriété ObjServeur (cette philosophie a été mise en oeuvre car pour le superviseur qui utilise cette objet c'est la même application que l'on soit serveur ou client) d'où l'utilisation d'une classe fourretout (A) qui est identique vis à vis de l'extérieur. De plus, ce superviseur ne comprends que le vba d'où l'utilisation d'interface pour mettre à dispo des structures complexe.

Vu la complexité croissante des parties serveur et cliente il a été décidé de créer deux classe séparées.

Mais pour ne pas répéter les mêmes propriétés et les mêmes méthodes dans les 2 classes je veux quel hérite de la classe A.

Exemple : 
Avant 
propriété NiveauSonore de la classe A était utilisé par les deux classes
dans la classe serveur on utilisait parent.NiveauSonore avec parent=Classe A

Après
propriété NiveauSonore toujours dans la classe A
Mais dans Serveur 
Public Overloads Property NiveauSonore() As String
      Get
        Return MyBase.NiveauSonore
      End Get

La philosophie est qu'au niveau de l'utilisateur final de la classe il y es que très peu de modification de code à faire.

Mais peut-être que se que l'on veut mettre en place en trop éloigné des pratiques de programmation en .NET (objet, héritage, ...)

C'est peu le genre de gestion que je me pose.

Si je suis vraiment trop incompréhensible je me propose de faire un schéma.

Merci

Mayzz · Answer

Non je pense avoir compris, et je pense aussi que tu as tout a fait saisi le principe de l'héritage... 

Si tes deux classes auront un certain nombre de propriétés et de méthodes en commun alors il convient en effet de créer une classe (MustInherit dans ton cas) Qui servira de modèle (pour le développeur). Mais tout ceci reste transparent pour l'utilisateur de la classe, si procède ainsi, c'est simplement pour t'éviter de saisir 2 fois le même code pour chaque classe.

L'utilisateur aura quant a lui, deux classes qui auront un certain nombre de méthodes et propriétés en commun (qu'elles soit hérités ou non). 

Par contre la ou je ne comprend toujours pas ta strucure :

Je vais essayé d'être plus claire 
Classe A 
une propriété ObjServeur as boolean 
une méthode start 
If ObjServeur Then 
If MyServeur Is Nothing Then MyServeur = New Serveur(Me) 
If MyClient IsNot Nothing Then MyClient = Nothing 
Else 
If MyClient Is Nothing Then MyClient = New Client(Me) 
If MyServeur IsNot Nothing Then MyServeur = Nothing 
End If 

Est ce qu'ici, les objets MyClient et MyServer sont des membres de A ?

Car dans ces cas la si MyServer hérite de A on poura alors avoir 

A.MyServer.ObjServer ...
A.MyServer.MyServer ...

Ce qui n'est pas très logique, donc si je ne me trompe pas, ton schéma devrait ressembler à quelque chose dans le genre :

Public MustInherit Class ObjBase
    'Classe représentant la base du client/serveur
    Private _NiveauSonore As String
    Public Overloads Property NiveauSonore() As String
        Get
            Return _NiveauSonore
        End Get
        Set(ByVal value As String)
            _NiveauSonore = value
        End Set
    End Property

End Class

Public Class A
    'Classe conteneur de l'objet, servant à définir de quel objet il s'agit
    Public Enum ObjectTypeConstant
        CLIENT
        SERVEUR
    End Enum

    Private _Obj As ObjBase
    Private _ObjectType As ObjectTypeConstant

    Public ReadOnly Property Obj() As ObjBase
        Get
            Return _Obj
        End Get
    End Property

    Public Property ObjectType() As ObjectTypeConstant
        Get
            Return _ObjectType
        End Get
        Set(ByVal value As ObjectTypeConstant)
            _ObjectType = value
            If value = ObjectTypeConstant.CLIENT Then
                _Obj = New Client
            Else
                _Obj = New Serveur
            End If
        End Set
    End Property

    'Un constructeur au quel on doit spécifier quel objet il s'agit lors de la création
    Sub New(ByVal t As ObjectTypeConstant)
        'Lors d'un affectation à la propriété, celle-ci modifie la propriété Obj pour
        'que celle-ci corresponde au type d'objet attendue.
        ObjectType = t
    End Sub

End Class

Public Class Serveur
    'Classe serveur héritante de ObjBase
    Inherits ObjBase
    Public _TestPropriete As String
    Public Property ProprieteDeClassServer() As String
        Get
            Return _TestPropriete
        End Get
        Set(ByVal value As String)
            _TestPropriete = value
        End Set
    End Property
End Class

Public Class Client
    'Classe client héritante de ObjBase
    Inherits ObjBase
    Public _TestPropriete As String
    Public Property ProprieteDeClassClient() As String
        Get
            Return _TestPropriete
        End Get
        Set(ByVal value As String)
            _TestPropriete = value
        End Set
    End Property
End Class

Si le déboguage est l'art d'enlever les bogues, la programmation doit être l'art de les créer.

jlg42 · Answer

Anciennement

Public Class CSonorisation
  Private MyServeur As Serveur
  Private MyClient As Client
  property NiveauSonore

Sub Start
  If ObjServeur Then
    If MyServeur Is Nothing Then MyServeur = New Serveur(Me)
    If MyClient IsNot Nothing Then MyClient = Nothing
  Else
    If MyClient Is Nothing Then MyClient = New Client(Me)
    If MyServeur IsNot Nothing Then MyServeur = Nothing
  End If
End Sub

End Class

Friend Class Serveur
Private CSono As CSonorisation

Sub New(ByVal sender As Object)
  CSono = CType(sender, CSonorisation)
End Sub

Sub LitSon
 Msgbox Csono.
End Sub

End Class

idem classe client et serveur

Nouveau design
Public Class Serveur
   Inherits CSonorisation
  Public Overloads Property NiveauSonore() As String
    Get
     Return MyBase.NiveauSonore
    End Get
  End Property
End Class

idem pour le client

Bien entendu la classe CSonorisation est à reprendre

De plus le MustInherit de peut pas s'appliquer sur les classes Client et Serveur car les classes sont des classe COMs (Pour une utilisation en VBA)

Mayzz · Answer

C'est que tu compte utiliser ces classes en COM, ah oué... c'est pas la même effectivement..

mais je ne vois pas l'intérêt :

Nouveau design
Public Class Serveur
Inherits CSonorisation
Public Overloads Property NiveauSonore() As String
Get
Return MyBase.NiveauSonore
End Get
End Property
End Class 

Pourquoi recréer la propriété NiveauSonore qui existe justement grâce à l'héritage, étant donnée que tu l'overload sans lui apporter de mise à jour l'héritage ne sert strictement a rien...


Si le déboguage est l'art d'enlever les bogues, la programmation doit être l'art de les créer.

jlg42 · Answer

je te remercie mais je ne vois pas comment accéder à la propriété NiveauSonore à partir de la classe de base

En .NET si pas d'overloads pas de problème j'accède aux méthodes et propriétés de la classe héritée
    Dim toto As ControlSonorisation.Serveur
    toto.NiveauSonore = 15

ATTENTION utilisation de la dll en vba
si pas d'overloads la classe hérité n'est pas visible
Dim toto As ControlSonorisation.Serveur
toto.NiveauSonore 15> existe pas

Peut-être un problème de portée de variables mais plus certainement un problème lié à l'utilisation de VBA (Obligation !!!!).

Si tu as une solution, remarque, astuce je suis preneur.

Merci

Mayzz · Answer

Oui donc c'est exactement ce que je te disait : écrire une classe de base ne sert strictement a rien (mise à part te faire coder double) si tu dois réécrire ces propriétés dans tes classes enfant (sans avoir à les modifier) ou est l'intérêt ?

Il ne faut pas confondre Interface : Schéma obligeant une classe a suivre une structure bien définie dans le but d'être utilisé par une méthode externe (Sorte de guide pour développeur, si j'ose dire).

et héritage : Coder une classe de base que l'on peut modifier à souhait pour lui apporter de nouvelles fonctionnalités sans avoir à réécrire ces fonctions de base (Donc sorte d'évolution, de mise à jour).

Pour la solution je n'en vois pas vraiment, surtout que je ne travaille pas en vba, je pense que si ta classe est faite pour être utilisé comme un ActiveX , alors code la simplement comme telle.

Si le déboguage est l'art d'enlever les bogues, la programmation doit être l'art de les créer.

jlg42 · Answer

Le gros problème vient à la base de son utilisation final qui est VBA

Ma classe CSonorisation (parent) dont hérite la classe serveur Implement déjà des interfaces qui permettent d'accéder aux structures complexes de celle-ci; car encore en vba les seuls types reconnu sont integer, string, boolean, .. qui sont des types simples.

J'aurais pu développer en VB6 et alors plus aucun problème; mais le choix s'est porté sur un environnement qui est encore supporté par MS d'où le bric à brac.

Quant j'ai développé l'objet au début c'était en .NET avec un programme de Test en .NET lors du passage en vba j'ai pleuré. Et j'ai pas réussi à trouver comment développer un active X en .NET, je suis même pas sure que sa soit possible.

Je te remercie de toutes tes explications.

Mayzz · Answer

Effectivement c'est pas simple...

Bref, je te dirais simplement qu'il ne faut pas utiliser d'héritage si celui-ci n'est pas reconnu en vba, Biensur, l'instruction MustInherits n'est pas reconnue, je m'en doute bien, mais je parle de l'objet COM (ActiveX) donc la librairie de classe qui sera généré par VB.Net, Il y a une différence entre la source et le produit fini.

Pour ce qui est des interfaces c'est idem, aucun besoin en vba par contre dans ton code à toi, pour t'organiser oui, pourquoi pas...

Si tu crée cette classe je suppose que le but n'est pas de garder une syntaxe vba pour en faire un pale copié/collé dans vbe, sinon la encore aucun intérêt au .Net. Par contre si tu utilise des strucures complexes, la oui en revanche, tu peux organiser ton code. Pense par contre à bien rendre tes classes, interfaces et autres visibles par COM, de cette façon l' IDE de vb.Net t'indiquera je pense, si un objet ne peut être définis comme tel dans la liste des erreurs.

Si le déboguage est l'art d'enlever les bogues, la programmation doit être l'art de les créer.

jlg42 · Answer

Les interfaces de l'objet hérité sont visibles et accessible en VBA mais pas les méthodes et les propriétés si qui est assez fabuleux. (les interfaces sont vuent comme des classes déjà instancié en VBA).

N'ayant pas forcément une vue très claire des principes d'héritages, ... je pense que je me suis fait des nœuds au cerveau à cause de l'utilisation de l'objet en VBA.

Donc je pense que la redéclaration des propriétés en Overload est un moindre mal et que le jour ou le superviseur sera container .NET je pourrais les supprimer et avoir un objet qui sera plus en adéquation avec les bonnes pratiques de développement .NET

Mayzz · Answer

Oui effectivement.

Mais que ce soit un héritage ou une interface, tu dois toujours redéfinir les propriétés de la classe finale (celle qui sera utilisé en vba). Donc l'héritage et les interfaces ne servent à rien, sauf, à mettre au propre ton code sous l'IDE .Net si celui-ci est complexe. Comme tu le dis, il est bien que ces interfaces soient présentes dans la source de la classe .Net, car si celle-ci migre un jour dans un programme .Net, tu pourras utiliser pleinement ses fonctionnalités.

Maintenant, ton superviseur à fait un mauvais choix en alliant une technologie .Net vers vba, certes MS ont conservés une compatibilité vers les composant COM, mais ce n'est pas le but du .Net, je dirais même l'inverse .Net a pour but de faire disparaitre ces objets COM (et la plupart des API).

VBA est une technologie d'autrefois, totalement dépassé, comme l'est vb6, quoi que, vb6 permettait pas mal de choses. Perso j'ai abandonné le vb6 pour suivre l'évolution, je n'ai pas eu le choix, j'ai résisté le plus longtemps possible car l'apprentissage du .Net demande pas mal de temps, mais offre beaucoup de possibilités, surtout au niveau des données et des interfaces graphiques, sans compter les fonctionnalités du Framework qui font que l'on peut aujourd'hui économiser 80% de temps par rapport à vb6 sur des applications (bureautiques surtout).

Si le déboguage est l'art d'enlever les bogues, la programmation doit être l'art de les créer.

Principe de dévelloppement

11 réponses

Votre réponse

Discussions similaires