J'ai récemment formulé une recommandation à l'un de mes collègues indiquant que sur notre projet actuel (C #) "Les services devraient être apatrides et donc statiques".
Mon collègue a accepté et a indiqué que dans notre projet, les services sont (et devraient être) en effet apatrides. Cependant, mon collègue n'était pas d'aperçu que statique n'implique aucun État et que l'apatride signifierait statique.
Mes questions est "une méthode marquée comme statique implique qu'elle ne nécessite aucun état et que, dans la majorité des cas, des méthodes apatrides soient statiques".
13 Réponses :
Statique signifie presque global. Il y a encore une instance, et il y a toujours de l'état dans ce cas, mais c'est l'instance statique , ce qui signifie qu'il n'y a qu'un seul et tous les appelants font toujours référence à celui-là.
@Rex, je ne crois pas qu'il soit techniquement précis d'appeler la définition de la classe comme une "instance" de la classe. Il n'y a pas de structure de données sur le tas pour la classe elle-même. Les variables statiques sont stockées dans la définition de la classe elle-même, qui n'est pas une "instance" de la classe. Lorsque vous codez un singleton, il existe une seule et unique instance créée ... la définition de la classe (où les champs statiques sont stockés, ce n'est pas une autre instance ... et quand aucune instance n'a été "nouvelle" D 'D. classe, que la classe a une ou plusieurs variables statiques ne signifie pas qu'il a une "instance" ...
@CHARLES Je pense que c'est plus d'une discussion philosophique que lorsque les octets sont stockés.
@Rex, je suppose que je pourrais être d'accord avec cette caractérisation, mais si vous voulez impliquer que ce n'est pas important, je demanderais poliment que vous reconsidérez. La distinction a certainement plus de conséquences que les octets sont stockés. Les instances peuvent disparaître, (lorsqu'elles sont collectées aux ordures) et leurs valeurs de niveau d'instance vont avec eux. Les champs statiques sont stockés avec la définition de la classe, qui n'est pas une instance et, car elle ne disparaît jamais, a une durée de vie permanente (jusqu'à décharge de l'AppDomain)
Vous avez tous deux raison (j'ai appris qu'en Californie): C'est toujours un cas, et il y a toujours un état dans ce cas. Mais l'instance n'est pas de classe foo mais plutôt de classe de classe (selon la langue). Ou quelque chose comme ça...
@Chals je ne pense pas que ce soit injuste de le caractériser comme une instance. Un type et tous les membres statiques sur un type sont initialisés et stockés sur le tas lorsque le type est d'abord accessible, et même s'ils ne reçoivent pas GC'D ne veulent rien dire.
@Chalarles, sauf si je lisais Rex faux, il est correct, mais je pense que vous le lisez différemment. J'ai lu son "il y a toujours une instance" comme faisant référence aux variables statiques dans la classe. Considérer classe A {statique string b = "boo"; } - ici b est une instance de chaîne, même si aucune instance de A n'est jamais créée.
@Nvram je veux vraiment dire qu'il y a une instance statique. Il existe une seule instance du type qui vit pour la vie de l'AppDomain, et tous les membres statiques sont initialisés et stockés avec celui-ci sur le tas.
S'il n'y avait vraiment pas une instance du type, il ne pouvait pas y avoir de constructeur statique ( cctor ), appelé quand (ou avant) la première méthode ou propriété statique est invoquée et < Je peux être utilisé pour initialiser les membres de données statiques - MSDN. ERGO: Il y a un CCTOR , qui attribue l'instance statique ", qui est une instance du type .
Pour tous: le constructeur statique est plus correctement appelé un indicateur. Il ne construit pas d'instance, il initialise le type. Et une instance du "type" n'est pas une instance de la "classe". Je cite des cases Don "Essential .NET" La plupart des membres d'une classe peuvent être définis comme "par instance" ou "par type" (instance ou statique). "Un membre par instance nécessite une instance du type afin d'y accéder. Un membre par type n'a pas cette exigence. En C # TheDefault est par exemple. ... Changez ceci à par type à l'aide de la statique mot-clé.
Lorsqu'une instance réelle est créée, une variable est créée qui contient une référence (pointeur d'adresse) sur un objet sur le tas, qui contient un pointeur (appelé htype) à une autre structure de mémoire appelée corinfo_class_tructeur. Cette structure est la reprémentation du type et contient toutes les définitions du type et (probablement) où tous les champs statiques sont stockés. Chaque type utilisé dans votre code obtient un corinfo_class_truct_truct, une fois et une seule fois, avant la première utilisation du type. Ce n'est pas une «instance» du type, c'est une structure de données représentant le type.
Donc, pour résumer, cette corinfo_class_truct_truct a créé la première fois qu'un type est utilisé est une représentation du type, et non une instance du type. Ce n'est pas seulement une sémantique, car corinfo_class_truct_truct est totalement différent de, dans la structure et la fonction, de ce qui est créé sur le tas comme exemple d'un type. En fait, si vous écrivez type mytyp = typeof (myClass) ;, le nouvel objet sur le tas est de type "type", pas "myClass", et deux corinfo_class_tructs sont créés, (s'il s'agit d'une première référence pour Tapez 'Type', et un pour le type 'myclass'.
@Rex, si toute cette discussion est uniquement parce que vous utilisez le mot "instance" pour faire référence à la société CORINFO_CLASS_Structure créée pour chaque type lors de la première utilisation du type, veuillez relire un peu plus sur cette structure de données et ce qu'elle fait. Il est très différent de toutes les autres "instances" construites du type. IMHO, l'utilisation du mot "instance" pour faire référence à cette structure de données communique à la moyenne des utilisateurs de .NET qui n'est pas vrai, et donc, je conseillerais contre cela.
Une autre fridue intéressante ici, est que vous obtenez une corinfo_class_truct_tructeur pour chaque type que vous référence ... Donc, si votre code a une classe définie comme chien, qui hérite d'un mammifère, qui hérite de l'animal, qui hérite d'un objet, la première fois Vous utilisez votre chien dans votre code, vous obtiendrez quatre (4) structures de données corinf_class_struct_structure, une pour chaque type que vous avez mentionné - même si la référence était d'un champ statique chez le chien. Voulez-vous vraiment dire que vous avez maintenant 4 cas de chien?
Une méthode statique, en C #, peut accéder aux variables statiques de sa classe contenant, et si elle le fait, ce n'est pas apatride. J'ai vu des exemples douloureuses de méthodes statiques "apatrides" non réentrantes qui déclenchent des conditions de course amusantes.
Une méthode vraiment apatride peut en effet être faite statique et devrait généralement.
est une méthode marquée comme statique impliquée que cela ne nécessite aucun état
1) Non. Vous ne pouvez pas dire que les méthodes statiques impliquent qu'il ne nécessite aucun état car les méthodes statiques peuvent accéder aux ressources statiques / singletons.
Une majorité de cas devraient être apatrides méthodes sont faites statique
2) oui. Les méthodes nécessitant aucun état ne nécessitent donc pas instance doivent être généralement statiques.
Marquer le "généralement". Je suis d'accord, mais trop souvent, lorsque les gens découvrent qu'une méthode particulière ne nécessite pas d'état, ils le modifient à statique . Mais si l'action est liée à l'objet sotculier, et si son utilisation est considérée comme étant prise à partir d'une instance (c'est-à-dire «sentir» de la méthode), la méthode ne doit pas être rendue statique.
c'est généralement correct. Cependant, vous pouvez avoir des variables statiques, qui permettent à vos méthodes statiques d'avoir un état. Par exemple, prenez cette classe foobarfactory: Dans ce cas, votre méthode statique a un minimum d'état, mais c'est (probablement) Neccessaire.
Avez-vous peut-être voulu dire «c'est (probablement) inutile»?
statique peut être énorme. Vous devez juste définir des conteneurs statiques pour ledit état. et les conteneurs sont partagés entre tous les appels de vos méthodes statiques.
Si vous voulez une seule instance avec état, utilisez un motif singleton; Il fait clairement l'intention que vous travaillez avec un objet d'événement unique.
De cela, je traiterais ensuite toutes les classes et méthodes statiques aussi apatrides. Cela aide simplement à garder la santé mentale.
Je trouve cela plutôt effrayant de dire que apatride est le même que statique comme il s'agit de deux mondes différents. Staffess signifie qu'il n'y a pas d'état gardé, c'est-à-dire un exemple parfait est une connexion HTTP (une fois que les données sont envoyées, la connexion est fermée et il n'y a pas de mémoire conservée), où nous essayons réellement de faire de notre mieux pour maintenir l'état indépendamment (connexion Etat pour un).
statique d'autre part est un terme utilisé pour décrire une manière qu'une méthode soit invoquée. En C #, cela signifie qu'une méthode peut être invoquée sans instance de classe, mais une instance d'une classe n'est pas la même que l'état. Il y a toujours l'instance statique et qui est parfaitement capable de maintenir l'état: toute variable de membre statique, champ ou propriété peut maintenir l'état. Une méthode ou une classe statique est également parfaitement capable de maintenir l'état à l'aide de fichiers mappés en mémoire, d'une base de données ou autre. Statique est une convention appelante, rien de plus et n'est pas liée à être apatride ou non.
Chaque classe a une structure de définition de classe, où les champs statiques sont représentés et stockés. Chaque "instance" de la classe a accès aux champs statiques stockés dans la définition de la classe (une structure de données caleld Étant donné que les valeurs stockées dans ces champs de niveau de classe statique sont persistées, elles sont définitivement statistiques. En fait, ils sont partagés de l'État par non seulement tous les cas de la classe pouvant exister, ils sont partagés tout au long de l'Assemblée, que tout cas ait été créé ou non.
encore plus significatif, car une fois un Pour plus d'informations, consultez corinfo_class_tructeur ). Même lorsque aucun instance n'a été créé, le code nulle part dans votre assembly peut accéder à ces champs de niveau de classe statiques à l'aide de la syntaxe classname.staticfieldname , sans aucune instance du tout.
corinfo_class_truct_tructeur La définition de la classe a été chargée, contrairement à une instance vraie de la classe, il est jamais non chargé jusqu'à ce que l'assemblage (ou l'appdomain) soit déchargé, il est donc sans doute plus d'état que tout champ d'instance défini dans une classe, car un champ d'instance disparaît lorsque l'instance se décheve collecté.
corinfo_class_tructeur Lien vers Don Boxes 'Super livre, Essential .Net < / p>
statique est un mot clé de langue et état est un concept de conception. Il y a une relation évidente entre ces deux choses, mais c'est une relation entre le béton de la métaphysique et non une relation de cause et d'effet. Il est possible que les méthodes statiques avancent certaines sortes d'informations de l'état.
En ce qui concerne les méthodes apatrides, nous parlons ici de méthode qui ne font pas référence à une instance de classe, c'est-à-dire un ce pointeur. Marquage de ces méthodes en tant que statique améliore la clarté du code et est cohérente avec les meilleures pratiques. Notez que dans ce cas, nous parlons un type spécifique d'apatridie »et nous ne faisant pas de commentaire général sur l'utilisation de contextes standard.
Je pense que sa déclaration fait autant de sens que «les démocraties devraient utiliser des bulletins de papier jaune».
Il mélange de concepts de conception de haut niveau "Services apatrides" avec un détail de mise en œuvre technique de bas niveau "Utilisation de classes statiques".
Les services apatrides peuvent (et ont été) mis en œuvre dans des langues qui ne supporte que les variables statiques (par exemple COBOL, RPG) et les langues qui ne permettent même pas même de variables statiques (Erlang, etc.).
Je pourrais facilement imaginer un cas où le service apatride a été mis en œuvre largement en utilisant des classes statiques, car ils étaient là et ont déjà mis en œuvre la logique commerciale correcte, bien que sa bonne programmation de la bonne pratique de Java ne pratiquait pas à ne pas utiliser de classes statiques.
Serioulsy mal comprendre ce que "statique" est tout à propos de: une variable statique est un moyen de stocker l'état entre des invocations - et semblerait donc une meilleure correspondance avec un service "état".
La réponse courte à votre question est "non", En référence à vos autres commentaires, statique n'implique pas "aucun état".
statique peut être utilisé pour vous aider à mettre en œuvre un service apatride, mais statique seul n'est pas suffisant. Un autre outil / technique pour aider à rendre quelque chose d'apatride est d'utiliser des structures de données immuables. Ceci (actuellement) n'est pas l'un des buteurs de C #, surtout par rapport à F #.
au-delà de la réhabation de toutes les définitions de "statiques" que l'on peut courir, J'espère que ce n'était pas trop déroutant :)
Une classe statique n'est pas apatride. Il peut encore avoir des variables qui, bien que statiques, ont un état.
Une classe statique sans aucune variables de niveau de classe est apatride. Il ne contient aucune donnée.