IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C# Discussion :

"Overrider" les classes du namespace System


Sujet :

C#

  1. #1
    Rédacteur
    Avatar de Arnaud F.
    Homme Profil pro
    Développeur COBOL
    Inscrit en
    août 2005
    Messages
    5 183
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France

    Informations professionnelles :
    Activité : Développeur COBOL
    Secteur : Finance

    Informations forums :
    Inscription : août 2005
    Messages : 5 183
    Points : 8 870
    Points
    8 870
    Par défaut "Overrider" les classes du namespace System
    Bonjour,

    j'ai un projet une librairie compilé en Compact Framework 3.5 et .NET Framework 3.5 (donc deux projets, juste des options de compilations qui changent).

    Dans le CF il manque quelques classes qui me sont bien utiles (genre FTP, Network, PowerStatus) je les ai donc recréée à l'identique pour le projet CF et ne les ai compilées que dans ce projet là :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    #if CFNET35 // Si on est en CF .NET 3.5 uniquement
    namespace MaLib.Net
    {
        public class FtpWebRequest : WebRequest {}
        public class FtpWebResponse : WebResponse {}
    }
    #endif

    Je voulais juste savoir si je pouvais remplacer le namespace par System.Net ?


    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    #if CFNET35 // Si on est en CF .NET 3.5 uniquement
    namespace System.Net
    {
        public class FtpWebRequest : WebRequest {}
        public class FtpWebResponse : WebResponse {}
    }
    #endif
    Cela me simplifierait énormément la vie pour les projets utilisant cette librairie afin qu'elle n'aient pas plusieurs using a gérer selon le cas.

    Je peux me permettre de le faire parce que je sais qu'en CF 3.5 ces classes ne seront jamais implémentées (et moi je l'ai fait à l'identique du .NET3.5), d'autant plus qu'il n'y a plus de nouveau CF.NET ...

    Vos avis là dessus?

    C'est par l'adresse que vaut le bûcheron, bien plus que par la force. Homère

    Installation de Code::Blocks sous Debian à partir de Nightly Builds

  2. #2
    Membre émérite Avatar de Guulh
    Homme Profil pro
    Inscrit en
    septembre 2007
    Messages
    2 160
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : septembre 2007
    Messages : 2 160
    Points : 2 924
    Points
    2 924
    Par défaut
    Tu peux mettre tes classes dans le namespace que tu veux. Par exemple, récemment, voulant utiliser Linq tout en restant en .Net 2, j'ai utilisé LinqBridge, qui définit des classes dans le namespace System.Linq.

    Donc tu peux très bien avoir un truc du style
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    #if COMPACT_FRAMEWORK
    namespace System.Net
    {
      public class FtpWebRequest : WebRequest {}
      ...
    }
    #endif
    Tu pourrais peut être te passer du précompileur, en mettant le code spécifique à chaque version du framework dans une assembly (du style core.cf.dll, core.standard.dll), choper d'une façon ou d'une autre une implémentation d'une interface IFtpWebRequest dans l'une ou l'autre de ces assemblies selon le framework dispo. Ca serait plus POO dans l'esprit, mais perso je retiendrai la solution du pré-compilo.
    ಠ_ಠ

  3. #3
    Rédacteur
    Avatar de Arnaud F.
    Homme Profil pro
    Développeur COBOL
    Inscrit en
    août 2005
    Messages
    5 183
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France

    Informations professionnelles :
    Activité : Développeur COBOL
    Secteur : Finance

    Informations forums :
    Inscription : août 2005
    Messages : 5 183
    Points : 8 870
    Points
    8 870
    Par défaut
    Citation Envoyé par Guulh Voir le message
    Tu peux mettre tes classes dans le namespace que tu veux.
    Je sais que je peux, je veux juste savoir si c'est une (très) mauvaise pratique / idée de procéder de la sorte où non.

    Citation Envoyé par Guulh Voir le message
    Tu pourrais peut être te passer du précompileur, en mettant le code spécifique à chaque version du framework dans une assembly (du style core.cf.dll, core.standard.dll), choper d'une façon ou d'une autre une implémentation d'une interface IFtpWebRequest dans l'une ou l'autre de ces assemblies selon le framework dispo.
    En fait je veux justement éviter de faire une assembly séparée car la librairie sera toujours intégralement déployée, donc si je peux m'affranchir de faire encore une distinction CF de ce qui ne l'est pas, ça m'arrangerait

    Puis je me vois réinterfacer le tout à chaque fois que je veux rajouter une classe manquante dans le CF

    Citation Envoyé par Guulh Voir le message
    Ca serait plus POO dans l'esprit, mais perso je retiendrai la solution du pré-compilo.
    Merci
    C'est par l'adresse que vaut le bûcheron, bien plus que par la force. Homère

    Installation de Code::Blocks sous Debian à partir de Nightly Builds

  4. #4
    Membre émérite Avatar de Guulh
    Homme Profil pro
    Inscrit en
    septembre 2007
    Messages
    2 160
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : septembre 2007
    Messages : 2 160
    Points : 2 924
    Points
    2 924
    Par défaut
    Citation Envoyé par Arnaud F. Voir le message
    En fait je veux justement éviter de faire une assembly séparée car la librairie sera toujours intégralement déployée, donc si je peux m'affranchir de faire encore une distinction CF de ce qui ne l'est pas, ça m'arrangerait
    A la limite il y aurait ILMerge pour tout mettre dans une même dll, mais ça me parait too much

    A la limite, avec une seule dll, tu pourrais avoir une factory, qui te fournirait un IFtpBidule, dont l'implémentation serait un MaLib.Net.FtpBidule en CF, ou une classe héritée de System.Net.FtpWebRequest et implémentant IFtpBidule dans l'autre, le switch entre les deux étant fait par le précompilo.

    Mais non, je vois pas ce que ta solution initiale a comme inconvénient. A part peut être si quelque en reprenant le projet (ou toi-même dans 6 mois ) tombe sur un bug de ta version custom et fouille la MSDN, croyant que c'est la version du framework qui est utilisée, mais bon si tu documentes bien...
    ಠ_ಠ

  5. #5
    Rédacteur
    Avatar de Arnaud F.
    Homme Profil pro
    Développeur COBOL
    Inscrit en
    août 2005
    Messages
    5 183
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France

    Informations professionnelles :
    Activité : Développeur COBOL
    Secteur : Finance

    Informations forums :
    Inscription : août 2005
    Messages : 5 183
    Points : 8 870
    Points
    8 870
    Par défaut
    Citation Envoyé par Guulh Voir le message
    A la limite il y aurait ILMerge pour tout mettre dans une même dll, mais ça me parait too much

    A la limite, avec une seule dll, tu pourrais avoir une factory, qui te fournirait un IFtpBidule, dont l'implémentation serait un MaLib.Net.FtpBidule en CF, ou une classe héritée de System.Net.FtpWebRequest et implémentant IFtpBidule dans l'autre, le switch entre les deux étant fait par le précompilo.
    Mal de crane assuré :p

    Citation Envoyé par Guulh Voir le message
    Mais non, je vois pas ce que ta solution initiale a comme inconvénient. A part peut être si quelque en reprenant le projet (ou toi-même dans 6 mois ) tombe sur un bug de ta version custom et fouille la MSDN, croyant que c'est la version du framework qui est utilisée, mais bon si tu documentes bien...
    On m'a déjà remonté ça, mais étant donné que si bug il y a, je saurais tout de suite si c'est une appli CF.NET ou .NET et donc dans ce cas, ayant explicité dans la documentation quelles classes j'ai pu rajouter, je pense pas que ça pose problème.

    Surtout qu'on est dans la top priorité c'est d'abord CF.NET (et donc implémentations persos) et ensuite .NET

    J'ai tout bien documenté, donc ça "devrait" bien se passer
    C'est par l'adresse que vaut le bûcheron, bien plus que par la force. Homère

    Installation de Code::Blocks sous Debian à partir de Nightly Builds

+ Répondre à la discussion
Cette discussion est résolue.

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo