Question

Disons que j'ai une classe simple appelée WebsterDictionary qui a une fonction qui peut prendre un mot et renvoyer sa définition. Peut-être une autre fonction peut-elle prendre une définition et renvoyer un mot. La classe est utilisée tout le temps par de nombreux clients.

Pour faciliter les recherches, la classe contient une variable membre qui est un dictionnaire en mémoire qui stocke les mots et leurs définitions associées. Supposons que le dictionnaire ne puisse jamais changer une fois qu'il est initialisé - il est constant et ne varie pas d'une instance à l'autre.

Est-ce un bon candidat pour les cours statiques? J'ai lu que les classes statiques devraient être sans état ... mais cette classe a l'état (le dictionnaire en mémoire), n'est-ce pas?

EDIT: Par ailleurs, si cela devient une classe statique, quand dois-je initialiser le dictionnaire, car il n'y aurait plus de constructeur? Est-ce que je vérifie si la référence au dictionnaire est nulle chaque fois qu'une des méthodes statiques est appelée?

Merci.

Était-ce utile?

La solution

Une classe statique convient lorsque la fonctionnalité n'a pas besoin d'être remplaçable (par exemple, pour des tests). Si vous souhaitez utiliser un talon ou une maquette, vous devez créer une interface appropriée, puis l'implémenter avec un singleton.

Autres conseils

Pour développer les réponses des autres, une classe statique ou un singleton est utile lorsque vous n'avez besoin que d'une instance de la classe. Cela est beaucoup plus facile à accomplir lorsque les données sont immuables. Ainsi, il est possible qu'une classe statique soit ce que vous voulez utiliser pour cela. Mais ce n’est pas nécessairement le cas, c’est automatiquement ce que vous voulez utiliser.

Mon conseil est de vous poser une question: le monde s'effondrera-t-il si j'instancie plus d'un de ces objets? Si c'est le cas, utilisez un singleton ou une classe statique. Sinon, utilisez une classe régulière.

Une classe statique peut être ce que vous voulez ici (voir les autres réponses). Mais ne faites pas l'erreur d'appeler votre dictionnaire "immuable".

Immuable ne signifie pas que "ne peut jamais changer au moment de l'exécution". dans le sens où vous avez utilisé l'expression , parce que votre dictionnaire change au moment de l'exécution; Une fois que vous devez le créer, vous devez également ajouter les éléments. Même à ce stade, vous pouvez vouloir que cela ne change plus jamais, mais il est possible de le changer. Votre intention n'est appliquée nulle part.

Un véritable objet immuable ne peut pas changer après la création, quel que soit le nombre d'essais. Au lieu de cela, lorsque vous avez besoin d'une variante de l'objet, vous devez créer une nouvelle instance avec les attributs souhaités.

Vous pouvez considérer une classe statique dans un sens comme ayant exactement une instance. Ce n'est probablement pas le meilleur choix pour un modèle dans lequel vous dépendez de la création de nouvelles instances pour chaque changement d'état.

Vous pouvez choisir Singleton ou une classe statique. J'irais probablement avec un Singleton mais je pense que c'est surtout une question de préférence dans cette situation particulière.

Une classe statique est appropriée quand une seule instance " devrait toujours exister, auquel cas le motif Singleton peut ou peut ne pas être plus approprié (en fonction des détails). Pour un objet immuable pour lequel vous aurez besoin de plusieurs instances, bien sûr, une classe statique est inappropriée.

Ce que vous recherchez pourrait être Singleton?

Il n'est pas nécessaire que la classe statique n'ait pas nécessairement d'état (elle peut comporter des membres statiques, qui peuvent faire partie de son état).

Comme vous l'avez dit, la classe détient une forme d'état global, même s'il est en lecture seule. L'approche Singleton montre clairement qu'il contient des données.

Si vous utilisez l'injection de dépendance, vous pouvez le faire injecter des instances singleton, au lieu de faire en sorte que toutes les classes aient un code qui récupère l'instance. Cela signifie que les autres classes ne seront pas liées à l'approche Singleton, et si vous pouvez plus facilement la remplacer lors des tests (combinée à une interface pour permettre le remplacement par des simulations de test).

scroll top