police étant une détresse immuable à la fois du programmeur et du GC, car vous devez créer une nouvelle instance à chaque fois.
Pourquoi la police est-elle un type de référence immuable alors?
6 Réponses :
Il simplifie l'utilisation du système de rendu.
Si le cadre devait permettre que la police soit mutable, il aurait besoin de détecter des modifications et de retravailler la manière dont il se produit régulièrement. Puisque la police crée une ressource native, la conservation de cette immuable empêche le système de se préoccuper de devoir recréer des poignées interne à une base répétée.
En outre, je suis en désaccord en termes de "détresse au programmeur". En rendant la police immuable, cela rend plus évident ce qui se passe lorsque l'utilisateur crée un objet de police. Si vous voulez une nouvelle police, vous devez créer un nouvel objet de la police, ce qui crée à son tour de nouvelles ressources de police indigènes. Faire une police immuable rend plus clair ce qui se passe - vous êtes moins susceptible de créer un problème de performance accidentellement.
Les polices mutables, il serait moins évident que vous créiez des poignées à plusieurs reprises lorsque vous avez modifié vos propriétés de police.
Sans parler de ce objet (par exemple une fenêtre) qui utilise l'objet de police géré aurait à détecter lorsque la poignée native avait modifié et associer la nouvelle poignée avec son propre objet natif (par exemple le HWND).
J'ai toujours pensé que la copie et la modification légèrement d'un objet de police existant était inutilement douloureuse. Je n'ai jamais envisagé qu'ils créent des ressources indigènes, donc +1 pour la réponse perspicace.
Dommage, même si elles ne faisaient aucune méthode ASBOLD () qui renvoie la nouvelle instance uniquement en gras.
@Aitay: Avez-vous remarqué le constructeur qui modifie le style de police ?
Ils ne sont pas des structures car ils doivent avoir des finaliseurs à envelopper les objets sous-jacents et à fournir une implémentation isolable . Que se passe-t-il si vous Ce n'est pas vraiment beaucoup de stress sur le gc ...
Il permet également à la police DISPOSE () Votre propre copie d'un struct ? Faites-vous cloner la poignée à chaque fois?
à réutiliser en toute sécurité sans vous soucier de changer à mi-chemin à travers une opération ;-p
Ce qui aurait été utile aurait été d'avoir une structure de Fontinfo mutable et une classe ReadyFont immuable; Seuls les derniers auraient besoin de disposer. Des choses comme les propriétés de la police sur les commandes seraient exposées comme une structure Fontinfo plutôt que comme une fois-ci.
Je suis en désaccord que cela détresse le programmeur. Il existe de nombreux types immuables dans la BCL qui sont utilisés quotidiennement par les programmeurs et ne provoquent aucun problème. Système.string par exemple.
L'un des avantages d'être immuable est que vous n'avez pas à créer une nouvelle instance à chaque fois. Vous pouvez réutiliser le même type de polices aussi souvent que vous le souhaitez car cela ne va pas changer. D'autre part, s'il était mutable, vous devriez effectuer une copie à chaque fois pour vous aider à garantir que personne ne l'a changé de dessous de vous.
Enfin, la police n'est pas en fait une classe immuable dans le sens le plus strict du mot. Il implémente Idisposable et dans la méthode d'élimination déchire l'objet natif sous-jacent.
Cela me rappelle quelque chose que je me suis demandé: qui "possède" des polices, des images et d'autres objets utilisés dans des contrôles? Si je crée une police et attribuez-la à la propriété de la police de contrôle, copie-t-il la police transbordée afin que je puisse disposer de la police une fois que je n'en ai plus besoin, ou dois-je conserver une référence à la police jusqu'à ce que je dispose du contrôle? Ou attribuez-lui une police différente afin que je puisse disposer correctement la police? Mon approche normale consiste simplement à abandonner simplement des objets que j'ignais dans un contrôle et que je laisse les giquer les manipuler, mais cela ressemble à Icky.
@supercat, je n'ai jamais compris la réponse à qui possède polices non plus et je ne crois pas qu'il y ait une bonne réponse. J'ai la même approche d'abandon et laissez le gc les chercher.
J'oublie si je l'ai déjà dit, mais la propriété de polices d'un contrôle semble échantillonner les propriétés de la police sans tenir compte de savoir si la police est disposée. On peut disposer d'un objet de police et définir une propriété Control.font sur la police disposée.
Je voulais dire détresse dans la syntaxe
Eh bien, posez-vous quelques questions.
Premier, est une police logiquement une chose mutable, comme une liste d'épicerie, ou une chose immuable, comme un nombre? Si vous modélisez une liste d'épicerie dans un programme, il est logique de le rendre mutable car vous pensez généralement à avoir une liste d'épicerie dont le contenu change au fur et à mesure de votre épuisement ou de l'achat d'éléments particuliers. Mais les chiffres que vous modélisez généralement comme étant immuables - le numéro 12 est le numéro 12, maintenant et pour toujours.
Je pense à "Helvetica 12 points audacieux" comme étant une chose fixe et immuable, comme un nombre, pas quelque chose que je peux changer.
Deuxièmement, est une police logiquement plus comme une valeur que vous pouvez faire des copies, ou s'agit-il d'une seule chose à laquelle vous pouvez vous référer? Je ne pense pas avoir "deux copies" d'Helvetica; Je pense faire référence à Helvetica. Tandis que je pense que je pense comme ayant des copies différentes de différentes fins - lorsque j'ai 12 articles sur ma liste d'épicerie et 12 clés sur mon porte-clés, je ne pense pas à ces deux éléments de "faire référence à 12".
Depuis que je pense aux polices comme étant immuables et référencées, plutôt que comme étant mutable et copiée par la valeur, je manquerait personnellement des polices comme des types de référence immuables. Peut-être que vos intuitions sur les polices sont différentes que les miennes.
Votre philosophie de traitement des choses me semble irrituellement incompatible. Mais j'aurais peut-être manqué quelque chose ... Tout d'abord, vous mettez en vedette une liste d'épicerie générale à un numéro spécifique. Vous pouvez aussi bien dire que "la pastèque, le fromage, le pain" sera toujours "de la melon d'eau, du fromage et du pain", tandis qu'un nombre tel que le prix, peut être très variable ... un nombre peut sembler plus atomique pour nous Les humains, mais une liste d'épicerie est une entité comme un nombre est une entité, elles sont à la fois mutable et immuables en fonction du contexte. Tout comme True sera toujours vrai, mais une lampe peut être sur ou éteinte ...... [suite]
[Part2] est maintenant booléen logiquement immutable? cette question juste sans réponse. Les seules choses qui comptent sont des considérations pratiques ............. maintenant "Helvetica 12 points audacieux" est vraiment aussi correct. Tout comme le vrai, et le numéro 12. Mais la police de mon titre est variable, comme un prix d'une voiture ou de l'état d'agneau ... Deuxièmement, en fait, vous pouvez avoir dans C # deux copies de " Helvetica 12 points Bold "et vous référez des chiffres en Java ........ La logique devrait être une considération qui aide à se rendre à des résultats esthétiques, mais à la fin, vous devriez être guidé par une considération pratique.
@Aitay: Lorsque ma femme me demande d'ajouter du lait à la liste d'épicerie, je ne détruisez pas l'ancienne liste et ne produisez pas une nouvelle liste avec du lait ajouté. La liste est mutable et il est donc logique de modéliser une liste d'épicerie avec un type mutable. Il y a bien sûr des contextes dans lesquels la modélisation des listes de modélisation est logique.
@ERIC - Je pense que c'est une question philosophique sans réponse. Si nous prenons une vue "en dehors du temps", toutes les versions de la liste peuvent coexister, indexées par le temps, et votre changement de liste aujourd'hui ne modifie pas la liste d'hier. Pour moi, la question pertinente est "ce modèle du monde simplifie la solution au problème à la main?", Qui dépendra du contexte.
@KVB: Vous achetez votre épicerie dans le monde éternel platonique des formes idéales, en dehors du temps? Cela résoudrait certainement le problème de laitue fanée.
mettre les choses dans un contexte de tous les jours à un tel niveau est simplement bizarre ... Vos comparaisons, pour moi, ne sont tout simplement pas sensibles, je peux autant dire que lorsque je répare une faute d'orthographe dans mon essai écrit, je ne détruisez pas l'ancien un a créé un nouveau fixé, mais en fait que ce soit exactement quel corder.replace fait ... IMO Ces comparaisons n'ont rien à voir avec la façon dont vous devriez concevoir des cours ... Je veux dire, parfois je t'aime aussi penser à penser à Qu'est-ce que ma classe représente et quel est le moyen le plus raisonnable de le concevoir et non seulement des considérations pratiques ... mais vous le prenez à un tout nouveau niveau ..
@ERIC: Quand j'écris un titre, puis j'ai décidé d'ajouter un soulignement, puis-je détruire l'ancien titre et créer un nouveau? Maintenant c'est juste une question stupide qui dérivée de votre chemin
@Aitay: Je pense que ces choses sont très importantes lors de la conception de cours. Je ne tente pas que tu sois d'accord avec moi. Si ces comparaisons vous sont inutiles pour vous, ne les utilisez pas. Votre exemple de système d'édition de documents est bon; Si j'écris un tel système, je pourrais modéliser un document comme un objet mutable, car c'est la manière dont les utilisateurs pensent des documents. Cependant, je pourrais également le modeler comme un objet immuable, car cela me permettrait de construire plus facilement un riche système d'annulation. C'est une décision d'ingénierie que je considérerais avec soin; Il y a beaucoup de pros et de contre des deux côtés.
Vous pouvez faire valoir que cela détresse le développeur. Mais vous pouvez également faire le même argument dans le cas opposé.
Par exemple: P>
// Let me just set the button to the same font as the textbox... button.Font = textBox.Font; // ...except that I want the button's font to be bold. button.Font.Bold = true;
police est un objet mal conçu, qui viole le principe de responsabilité unique et les difficultés que vous citez de la tige de ceci. Le problème de la police est qu'il englobe deux choses: (1) une description de la manière dont une police doit être dessinée, et (2) un objet de police GDI pour une police avec ces propriétés. Le type précédent pourrait être mutable sans conséquence, tout en rendant ce dernier type mutable poserait toutes sortes de problèmes.
Entre autres choses, envisagez la question de savoir comment il faut suivre la propriété d'un contrôle de contrôle typique (bouton E.G)? Si on modifiera parfois les polices associées aux contrôles, il faut créer un objet de police séparé pour chaque contrôle et en disposer lors de la modification de la police d'une commande en quelque chose d'autre ou de conserver une liste de toutes les polices différentes utilisées Pour éviter de créer un nombre excessif d'objets de police identiques, ou quoi?
S'il existait une structure de fontscription (qui a été mutable, et non isisposable) et des choses comme Control.font étaient de type FonteDescription (ou mieux encore, contrôlez une méthode Setfont avec le paramètre de police de police), la question ci-dessus pourrait être répondu jolie simplement. Comme c'est le cas, l'approche la plus efficace pour définir la police d'un contrôle consiste à créer un nouvel objet de la police (si on ne dispose pas déjà d'un), en le disposera immédiatement, puis effectuez l'affectation. La partie "Police Description" de la police reste quasi-valide même après la disposition, et c'est tout ce qui est vraiment nécessaire pour la propriété Control.font.
Je suis d'accord que quelque chose comme
label1.font = nouvelle police (label1.font.name, label1.font.size + 2.0f, label1.font.style, label1.font.unit); semble un peu sur le dessus d'un "juste faire ce que je veux" perspective.Permet de faire des numéros de carte de crédit immuables afin que tout le monde puisse changer son nombre à tout moment !!! Quel plaisir cela causerait. Et pendant que vous l'ajoutez - permet de faire immuable le nom de chacun afin que nous puissions les changer tous les 5 minutes si nous voulons.