web-dev-qa-db-fra.com

Est-il considéré comme une mauvaise pratique en génie logiciel de toujours utiliser des méthodes "publiques"?

J'ai toujours utilisé des méthodes publiques et récemment, un de mes amis m'a conseillé d'éviter de définir les méthodes comme publiques, dans la mesure du possible, bien que j'aie travaillé dans une entreprise commerciale, je n'ai jamais "vraiment" compris le concept de pourquoi public ne sont pas "sûres à utiliser par moments".

J'ai beaucoup travaillé avec c # et ne vous méprenez pas, j'ai utilisé d'autres types d'accès tels que internal, private et protected et je sais comment ils "fonctionnent" mais je n'ai jamais vraiment compris pourquoi vous devez définir des méthodes avec ces niveaux d'accès, en particulier dans la production.

programming-practicesprogramming-languagesmethodsjunior-programmer
22
Sid Khanye

Les méthodes, propriétés et constructeurs (c'est-à-dire les membres d'une classe) que vous définissez à l'aide d'un accesseur public déterminent la surface avec laquelle les utilisateurs de votre classe seront autorisés à interagir. Toute méthode dont vous ne voulez pas faire partie de cette surface ne doit pas être faite public.

Raisons pour lesquelles certains membres peuvent ne pas être publics:

  1. Ce sont des détails de mise en œuvre; ils implémentent le comportement requis par les membres publics, mais ne sont pas destinés à être appelés directement de l'extérieur (c'est-à-dire private).
  2. Ils sont censés être accessibles dans une classe dérivée, mais pas appelés directement. (c'est-à-dire protected).

Pensez-y en termes de maison. Vous ne laissez pas le fisc entrer dans votre maison, trouver votre chéquier et vous faire un chèque. Le fisc vous envoie plutôt une facture, vous l'examinez, vous écrivez un chèque et vous l'envoyez. L'envoi de la facture et du chèque sont tous deux des actes publics. Les actes de révision de la facture et de rédaction du chèque sont des détails de mise en œuvre effectués dans l'intimité de votre propre maison dont le contribuable n'a besoin de rien savoir.

Lectures complémentaires
Encapsulation

59
Robert Harvey

Réponse courte:

Déclarer une méthode ou un champ "public" se traduit par une promesse:

Chers collègues,

Je vous invite à utiliser cette méthode ou ce champ partout où vous le jugez approprié.

J'ai documenté tout ce que vous devez savoir sur son utilisation, et tant que vous ne violez pas cette documentation, je prends la responsabilité de chaque bogue dans ce contexte.

Je promets que je ne changerai jamais le comportement de cette méthode/interprétation des données dans ce champ, ou que j'analyserai tout votre code en utilisant ma méthode et que je le modifierai de manière appropriée.

Êtes-vous sûr de vouloir cela (en particulier la partie "documentation")?

38
Ralf Kleberhoff

Si j'ai une classe:

class SomeThing
{
    public DoSomething()
    {
        DoThing1();
        DoThing2();
    }

    public DoThing1() ...
    public DoThing2() ...
}

Maintenant, je pourrais avoir l'intention que tout le monde appelle uniquement DoSomething. Mais j'ai fait DoThing1 et DoThing2 public aussi, afin que les utilisateurs puissent toujours les utiliser. Par conséquent, lorsque je réécrirai plus tard DoSomething pour utiliser DoThing3 seulement, je suis coincé: je ne peux pas me débarrasser de DoThing1 et DoThing2, même si je ne les utilise plus.

Si je les avais marqués comme private, aucun problème de ce type ne se poserait. Je peux les supprimer en toute sécurité sans casser le code externe.

Donc, une bonne règle de base est de tout marquer private à moins qu'il ne soit absolument nécessaire d'y accéder en dehors de la classe. Si vous devez y accéder, marquez-le internal si possible car il reste "privé" à ce projet et peut être modifié sans interrompre d'autres projets. Ce n'est que s'il est nécessaire dans le cadre de l'API publique du projet que vous devez le marquer public. Cela s'applique autant aux classes, énumérations, etc. qu'aux membres de ces classes, etc.

10
David Arno

Les classes exposent une interface (le mot anglais, pas le mot clé c #), à travers laquelle vous les utilisez.

Rendre les interfaces faciles à utiliser correctement et difficiles à utiliser incorrectement.

Si votre classe possède une fonction qui ne doit pas être appelée à partir d'autres classes, mais que vous autorisez d'autres classes à le faire, vous simplifiez l'utilisation incorrecte de la classe. Cela introduit des bogues, des coûts de maintenance et des coûts de formation. Ce n'est pas aussi mauvais si vous êtes le seul développeur - vous connaissez déjà le code et savez quelles fonctions vous pouvez ou ne pouvez pas appeler. À moins que vous ne deviez revoir votre code 6 mois plus tard, vous ne vous en souviendrez plus.

7
Peter

Si vous écrivez des logiciels "à grande échelle" (c'est-à-dire que vous travaillez avec plusieurs équipes, que vous publiez de nouvelles versions au fil du temps, que vous avez suffisamment de code pour qu'il soit difficile de tout garder en tête à la fois), alors oui, c'est une mauvaise pratique d'ingénierie (voir les autres bonnes réponses).

Si vous écrivez simplement du code unique (par exemple, un script à fichier unique pour pousser les données avec seulement 3 méthodes), c'est exagéré.

1
Carl Walsh

Les spécificateurs d'accès agissent également comme une sorte de documentation/commentaire/description. Lorsque vous lisez du code source, si vous voyez quelque chose de privé, vous savez immédiatement que la chose n'est utilisée qu'en interne. Cela permet d'améliorer la lisibilité du code.

0
cshu