Où mettre des méthodes communes partagées


9

J'ai un tas de méthodes qui sont couramment utilisées partout. À l'heure actuelle, le fichier de code est nommé globaux, pour représenter le fait qu'ils sont ... en fait ... mondiaux.

Cependant, je n'aime pas ça.

Je veux les regrouper en classe et faire passer une interface. Je ne ferai qu'une seule instance, mais je ne tombe pas dans le piège singleton ici.

Tout d'abord, que dois-je nommer la classe. Je veux éviter le nom de globals parce que je crains que les responsables ne se trompent.

Aussi, comment devrais-je envisager de fractionner un tel ensemble de méthodes afin que le comportement puisse changer et s'adapter?

L'ensemble de méthodes contient des choses comme:

  • Tables de conversion
  • Interaction du presse-papiers
  • Gestion des polices construites
  • Méthodes de dessin courantes
  • Fournir une interface avec accès aux ressources souvent utilisées

S'agit-il de méthodes pure Util qui ne sauvegardent pas l'état ou sauvegardent-elles l'état?
TheLQ

+1 pour ne pas tomber dans le piège singleton.
Caleb

@TheLQ Ils n'enregistreront pas nécessairement l'état, mais ils contiendront des données const (comme les tableaux de conversion) pour plus de commodité.
Lee Louviere

Réponses:


4

L'espace de noms pourrait être [application].Common.Shared

Les classes peuvent être nommées:

ConversionLookup
ClipboardCommunication
FontManager
DrawingUtility

Je séparerais les cours parce qu'il semble qu'ils font des choses différentes.


1

Si vous allez créer une instance, vous avez à peu près un singleton. De plus, la chose à laquelle les gens font normalement référence s'ils parlent d'un piège singleton est que les singletons sont globaux, et la plupart des classes ont intérêt à ne pas être globales. Donc, vous pourriez aussi bien avoir un singleton. Si vous pouvez raisonnablement transmettre une interface à des objets qui pourraient vouloir l'appeler, elle n'est pas vraiment globale.

En outre, le fait de mettre tout cela dans un sac à main de méthodes globales rend difficile le changement de comportement et l'adaptation car non seulement chaque changement vers une méthode nécessite une nouvelle sous-classe, mais chaque combinaison de changements nécessiterait sa propre sous-classe.

Je recommanderais d'avoir des singletons pour chacun qui est vraiment global (je vous prie de croire qu'ils le sont tous) et une sorte de registre ou de fabrique qui vous donne une instance (ce qui signifie que vous pouvez l'implémenter en tant que singleton ou non, puisque l'interface ne faites aucune promesse). Je les nommerais en fonction de ce qu'ils font du point de vue de l'appelant.


1

Normalement, je mets ces types de choses dans leurs propres noms d'assembly quelque chose comme "foo.Common" sous un espace de noms comme "foo.Common.Collections" ou "foo.common.UI" etc., puis, je peux référencer l'assembly dans n'importe quel projet J'en ai besoin.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.