Discussion :

[Arthis]

Bonjour,

Je developpe depuis quelques temps dans une nouvelle societe ou ils ont la folie de la fonction static , ils veulent en mettre partout. Moi je suis plutot de l'ecole pas de fonctions static ou alors simplement pour des cas extremement precis.

Ce que je leur reproche, c'est que leurs fonctions static, on les retrouve un peu partout et que par consequent il n 'y a plus vraiment d'unicité des interface entre les objets. Cela rend la maintenance assez eprouvante.

Par contre il est vrai que c'est tres pratique pour realiser rapidement des petites applications jetables.

Et vous qu en pensez vous? Utilisez vous des fonctions statiques ? Ai je raison de m'emporter ainsi contre cette facon de programmer ?

Merci,



PS: Bon je ne m'emporte pas tant que ca non plus, je n'ai encore tapé personne

[Gold Bug]

par consequent il n 'y a plus vraiment d'unicité des interface entre les objets.

Je ne comprends pas ce que tu veux dire par là...

Par contre il est vrai que c'est tres pratique pour realiser rapidement des petites applications jetables.

Heu... non, je ne suis pas d'accord. Cela n'a rien à voir!!

En deux mots, une méthode doit être statique si elle n'accède à aucun champ d'instance de la classe.

[Arthis]

Un petit exemple alors:

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
public class A
{
    methode static GetA() {....}
}
 
 
public class B
{
    methode static GetB() 
         {
            ....
            A.GetA();
            ....
          }
}

Et la poum d'un coup tu as , une fonction statique qui sort dans ta classe B. Ce qui fait que chaque changement de GetA sera directement impacté sdans B et ce sans même qu il y ait un interfacage quelquonque...
Avec une methode et deux classes le probleme est gerable mais quand tu as 150 fonctions qui s'entortillent les unes aux autres , le problem devient plus evident.

[Edit]

moi je prefererais :

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
public class A
{
    methode int GetA() {....}
}
 
 
public class B
{
    methode int GetB( int A) 
         {
 
          }
}
 
 
public class C
{
    Methode void CalculateC(ObjetA,ObjetB)
     {
         return ObjetB.GetB(Objet.GetA)+1;
      }
 
}

[Gold Bug]

Est-il possible que cela soit du code plus ancien (genre de C) qui ait été porté vers du C# sans qu'aucun redesign n'ait été fait ?

[Gold Bug]

A mon avis tu as 2 possibilités:
- Proposer un redesign complet : ce sera refusé.
- Te démerder avec ça. Bon courage.

[Arthis]

desolé j ai edité mon precedent message un peu trop tardivement..

Et pour repondre a ta question non. C'est leur facon de proceder. J avoue avoir du mal a faire valoir ma facon de penser car elle implique plus de travail dans un premier temps et le resultat peut sembler plus compliqué, meme si amon avis il est plus facilement maintenable ensuite..

Mais me trompe-je?

[Guulh]

Avec l'expérience, je me rends compte que les méthodes statiques doivent être utilisées avec parcimonie. Des petites fonctions utilitaires "hors contexte" (mais qui dans ce cas là sont le plus souvent privées) peuvent l'être ; mais entre une classe statique (dont toutes les méthodes sont statiques, donc) et un singleton, je préfère le singleton car il peut au moins implémenter une interface... Alors qu'avec une classe statique, tous les appelants doivent connaître son nom, ce qui d'un point de vue modularité est pas top.
Sans compter que faire des tests unitaires est compliqué, que le mock up est difficile, etc.
Donc dans une optique de découpage, de séparation des responsabilités, bref de développement objet sur des projets qui ont un minimum d'ampleur, je te soutiens à 100% : or d'un cadre bien précis (fonctions mathématiques, classe / méthode auxiliaire), il vaut mieux à mon avis préférer les méthodes non statiques.

[ppphil]

Si t'as une caisse à outils statique, la clef à molette peut aussi être statique. Elle servira à reserrer n'importe quel boulon.
Si dans ta caisse à outils t'as une fonction statique Conduire(), ça ne veut plus rien dire du tout. Par contre si cette fonction fait partie de la classe Automobile, là ça prend du sens... En plus elle peut être virtuelle, ce qui te permettra de conduire tant une 2CV que la dernière F1...

[freerider74]

Etant en plein dans le problème actuellement dans mon projet, je vais donc poster une petite question à mon tour.

Je suis en train de coder une DLL pour mon projet, celle-ci me sert en fait (dans 75% des cas) à faire de la lecture écriture dans une base de données. Dans celle ci j'ai une connexion est ma base qui est une propriété static. Dans mes classes ou je dois juste faire de la lecture ou écriture, j'ai déclaré toutes mes méthodes static (elles utilisent ma connexion partagée)

Ai-je raison de faire cela? Est-ce que je dois plutot créer des classes non static?

[Gold Bug]

Etant en plein dans le problème actuellement dans mon projet, je vais donc poster une petite question à mon tour.

Je suis en train de coder une DLL pour mon projet, celle-ci me sert en fait (dans 75% des cas) à faire de la lecture écriture dans une base de données. Dans celle ci j'ai une connexion est ma base qui est une propriété static. Dans mes classes ou je dois juste faire de la lecture ou écriture, j'ai déclaré toutes mes méthodes static (elles utilisent ma connexion partagée)

Ai-je raison de faire cela? Est-ce que je dois plutot créer des classes non static?

Je préfère utiliser un Singleton pour accéder à la base de données.

[freerider74]

Je préfère utiliser un Singleton pour accéder à la base de données.

Oui mais puisque ma connexion à ma base est unique (sur à 100 pourcent) doit-je vraiment utiliser le singleton

[Gold Bug]

Oui mais puisque ma connexion à ma base est unique (sur à 100 pourcent) doit-je vraiment utiliser le singleton

Lorsque je conçois une application, je pars du principe suivant : une classe ne peut être statique que si toutes ses méthodes peuvent être appelées indépendamment les unes des autres et sans initialisation préalable de contexte.
J'ai par exemple une classe statique Zip :

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
    /// <summary>
    /// Provides ZIP archives access.
    /// </summary>
    public static class Zip
    {
        /// <summary>
        /// Creates a ZIP archive containing a specified file.
        /// </summary>
        /// <param name="archiveName">Full path name of the ZIP archive to create.</param>
        /// <param name="fileName">Full path name of the file to archive.</param>
        public static void CreateArchive(string archiveName, string fileName)
        {
        }
 
        /// <summary>
        /// Extract Stream of specified file from a ZIP archive.
        /// </summary>
        /// <param name="archiveName">Full path name of the ZIP archive to open.</param>
        /// <param name="fileName">Full path name of the file into archive.</param>
        public static Stream ExtractFile(string archiveName, string fileName)
        {
        }

Dans le cas d'une classe d'accès à une base de données, une méthode Select() ne peut pas être utilisée tant que la connexion à la base n'a pas été ouverte. Donc, je n'utiliserai pas de classe statique pour ça.

[freerider74]

Lorsque je conçois une application, je pars du principe suivant : une classe ne peut être statique que si toutes ses méthodes peuvent être appelées indépendamment les unes des autres et sans initialisation préalable de contexte.
J'ai par exemple une classe statique Zip :

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
    /// <summary>
    /// Provides ZIP archives access.
    /// </summary>
    public static class Zip
    {
        /// <summary>
        /// Creates a ZIP archive containing a specified file.
        /// </summary>
        /// <param name="archiveName">Full path name of the ZIP archive to create.</param>
        /// <param name="fileName">Full path name of the file to archive.</param>
        public static void CreateArchive(string archiveName, string fileName)
        {
        }
 
        /// <summary>
        /// Extract Stream of specified file from a ZIP archive.
        /// </summary>
        /// <param name="archiveName">Full path name of the ZIP archive to open.</param>
        /// <param name="fileName">Full path name of the file into archive.</param>
        public static Stream ExtractFile(string archiveName, string fileName)
        {
        }

Dans le cas d'une classe d'accès à une base de données, une méthode Select() ne peut pas être utilisée tant que la connexion à la base n'a pas été ouverte. Donc, je n'utiliserai pas de classe statique pour ça.

Entièrement d'accord avec toi sur le principe. Je vais faire mon que tu vas me dire mais je cherche réelement la meilleur solution. Dans le cas ou je travail en mode connécter. Et que cette connexion est initialisé au Load de l'appli et fermer dans le closing.

[Arthis]

Ok je vous remercie pour ces échanges et vos retours d'experiences.

Ils confirment ma vision initiale.

@freerider74 : pense à l'evolution de ton appli. Qui te dit que dans 6 mois, un an, il n'y aura pas un besoin sur un interfacage web, ou une réelle transformation en aplli serveur-client. Cela impliquerait d'avoir plus d'un utilisateur. Auquel cas il est toujours preferable d'avoir commencer tot la separation des couches.

bon code à vous tous,