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.

[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,