J'ai entendu deux de mes collègues qui affirment que de créer ou non une nouvelle classe de modèle de données qui contient uniquement un champ de chaîne et un setter et un getter pour cela. Un programme créera ensuite quelques objets de la classe et les mettre dans une liste de matrices. Le gars qui les stocke affirme qu'il devrait y avoir un nouveau type pendant que le gars qui obtient les données a déclaré qu'il n'y a pas de point à travers tout ce trouble pendant que vous pouvez simplifier la chaîne de stockage.
Personnellement, je préfère créer un nouveau type afin que nous sachions ce qui est stocké dans la liste des matrices, mais je n'ai pas de fortes arguments pour persuader le type de données "Obtenir". Est-ce que tu?
sarah
8 Réponses :
Cela dépend s'il existe une possibilité réelle d'ajouter un comportement au type plus tard. Même si les getters et les pigments sont triviaux maintenant, un type a du sens s'il y a une chance réelle, ils pouvaient faire quelque chose plus tard. Sinon, les noms de variables clairs devraient suffire.
Enveloppez-le dans une classe, s'il correspond au reste de la conception de votre modèle de données.
Cela dit, la clé est si elle correspond au reste de la conception de votre modèle de données ... Soyez cohérent avec ce que vous avez déjà.
Dans le temps passé à discuter de savoir s'il faut envelopper dans une classe, il pourrait être enveloppé et fait avec. Ne fait jamais mal à la conception de la conception, surtout quand cela ne prend qu'un effort minimal.
Je conviens qu'ils ont probablement passé plus de temps à discuter de temps que cela ne prendrait à faire dans les deux sens, mais je ne suis pas d'accord sur le fait que cela "ne fait jamais mal" d'ajouter plus de code (qui correspond à ce que cela revient). La taille est que Yegge dit, le pire ennemi du code. Un système passe à 100k, 1m, 10m, 100m Loc une ligne à la fois, et avant chaque personne, le développeur a pensé qu'il ne pouvait pas faire mal.
contrepoint à la réponse de Mschaef:
Gardez-le comme une chaîne, s'il correspond au reste de la conception de votre modèle de données. (Voyez comment l'ouverture sonne si importante, même si je traîne avec une phrase qui dit essentiellement que nous ne connaissons pas la réponse?)
comme YEGGE dit , "le pire chose qui peut arriver à une base de code est la taille ". Ajouter une déclaration de classe, un getter, un setter, appelez-les maintenant ceux de partout qui le touche et vous avez ajouté une taille à votre code SANS FOIS . / P>
"Si vous avez besoin d'une étiquette disant ce qu'il est, ajoutez un commentaire." Ce n'est qu'une étiquette de compilation. Le bénéfice du type est que si j'ai une référence à x pendant que je suis dans un débogueur, le type formellement déclaré me permet de savoir ce qu'il est à l'exécution (via l'inspecteur). Cela peut être une chose utile. Vous pouvez également utiliser quelque chose comme le reflettostringbuilder pour obtenir une totring contenant le nom de type. Cela peut être utile lors de la journalisation. @Ken: "(voyez comment l'ouverture sonne si importante" mener avec votre "phrase de sujet". C'est l'une des premières choses que je me souviens d'avoir appris à écrire.
+1 pour soutenir votre argument avec des liens. Bien que (n'ayant pas lu l'article mais la planification de), je dois être en désaccord qu'une base de code importante est mauvaise, sans parler de la pire chose que le code se produise. En tant que codeurs, nous construisons aujourd'hui sur des structures composées de millions de lignes de code et que nous n'avons jamais eu si bonne.
RideauDog: Je ne suis pas surpris de trouver un désaccord avec ça. La phrase avant celle que j'ai citée est "Je tiens à occuper une opinion minoritaire durement gagné sur les bases de code". :-)
Mschaef: C'est un point juste. Je suppose que je suis habitué à des langues à ce niveau ayant des debuggotes relativement médiocres (c'est-à-dire que des langages de niveau supérieur, et en particulier des langues à base d'images), donc je commente et connectez-vous abondamment, de toute façon, ce qui rend la classe moins importante.
MSCHAEF: Je n'utilisais pas d'abord de mettre la phrase du sujet. Je remarquais que la seconde moitié de votre sujets condamnée a complètement nié la première. :-) Il semble donc que vous préconisiez une chose (une nouvelle classe), lorsque vous finissez par défendre quelque chose de complètement orthogonal (correspondez au code existant).
... une nouvelle classe de modèle de données qui contient uniquement un champ de chaîne et un setter et un getter pour cela.
Si c'était juste un getter, il n'est pas possible de dire en général si une chaîne ou une classe personnalisée est meilleure. Cela dépend des choses comme:
- Cohérence avec le reste de votre modèle de données,
- Anticiper si vous voudrez peut-être changer la représentation,
- Anticipant si vous souhaitez implémenter la validation lors de la création d'une instance, ajoutez des méthodes d'assistance, etc.,
- implications pour l'utilisation de la mémoire ou la persistance (si elles sont même pertinentes).
(Personnellement, je serais enclin à utiliser une chaîne simple par défaut et utilise uniquement une classe personnalisée si, par exemple, je savait qu'il était probable que le changement / raffinement de la représentation future serait nécessaire. Dans la plupart des situations, ce n'est pas un problème énorme de changer de chaîne en classe personnalisée plus tard ... si le besoin se pose.)
Cependant, le fait qu'il soit proposé d'être un setter pour le champ change de manière significative. Les instances de la classe seront mutables, où ne sont pas des cas de chaîne. D'une part, cela pourrait éventuellement être utile; par exemple. où vous avez réellement besoin d'une mutabilité. D'autre part, la mutabilité rendrait la classe quelque peu risquée d'être utilisée dans certains contextes; par exemple. dans des ensembles et des clés dans les cartes. Et dans d'autres contextes, vous devrez peut-être copier les instances. (Cela serait inutile pour une classe d'enveloppe immuable ou une chaîne nue.)
(la réponse simple est de se débarrasser du setter, sauf si vous en avez vraiment besoin.)
Il y a aussi le problème que la sémantique du
est égale à sera différente pour une chaîne et une enveloppe personnalisée. Vous pouvez donc avoir besoin de remplacerégale ethashcode pour obtenir une sémantique plus intuitive dans le boîtier de wrapper personnalisé. (Et cela se rapporte à la question d'un setter et d'utilisation de la classe dans les collections.)
Merci Stephen pour la perspective sur la mutabilité.
Oups..Je voulait voter votre publication, mais en fait l'a voté. Je vais essayer à nouveau dans 3 heures!
Je ne vois aucune raison pour laquelle la chaîne doit être enveloppée dans une classe. La perception de base de la discussion est que la nécessité du temps est un objet de chaîne. Si cela devient augmenté plus tard, faites-le refactored alors. Pourquoi ajouter un code inutile au nom d'une future épreuve.
L'enveloppement dans une classe vous fournit plus de sécurité de type - dans votre modèle, vous ne pouvez alors utiliser que des instances de la classe wrapper et vous ne pouvez pas facilement faire une erreur où vous mettez une chaîne contenant quelque chose de différent dans le modèle. .
Cependant, il ajoute des frais généraux, une complexité supplémentaire et une verbosité à votre code.
Je suis en désaccord avec les autres réponses:
Cela dépend s'il y a une possibilité réelle d'ajouter un comportement au type ultérieurement [ Matthew Flaschen ]
Non, ça ne le fait pas. ...
Ne fait jamais mal à l'épreuve future de la conception [ Alex ]
vrai, mais pas pertinent ici ...
Personnellement, je serais enclin à utiliser une chaîne simple par défaut [ Stephen C ]
Mais ce n'est pas une question d'opinion. Il s'agit de décisions de conception:
est l'entité que vous stockez logiquement une chaîne, une pièce de texte? si oui, puis stockez une chaîne (ignorant le problème de l'installation).
sinon - alors faites
pas stocker une chaîne. Ces données peuvent être stockées comme une chaîne correspondent à un détail de mise en œuvre , il ne doit pas être reflété dans votre code. Pour le deuxième point, il n'est pas pertinent que vous souhaitiez ajouter un comportement plus tard. Tout ce qui compte, c'est que dans une langue fortement dactylographiée, le type de données doit décrire l'entité logique. Si vous traitez des choses qui ne sont pas du texte (mais peuvent être représentées par texte, peuvent contenir du texte ...) puis utilisez une classe qui stocke en interne ledit texte. Ne stockez pas le texte directement.
Il s'agit de tout le point d'abstraction et de dactylographie forte: laissez les types représenter la sémantique de votre code.
et enfin:
Comme Yegge dit: "La pire chose qui peut arriver à une base de code est la taille". [ Ken ]
Eh bien, c'est so ironique. Avez-vous lu des poteaux de blog de Steve Yegge? Je ne less pas, ils sont juste trop damn long .
Konrad - Tout sur les limites d'abstraction. Évidemment, nous avons besoin d'eux, Mais ce n'est souvent pas une question simple où ils devraient aller et à quel point ils devraient cacher les détails de la mise en œuvre. Si vous n'en avez pas assez, vous vous retrouvez avec des abstractions qui fuient ou pire. Si vous allez à la mer avec la mise en place des limites d'abstraction, vous vous retrouvez avec beaucoup de code inutile et une gamme de problèmes de performance. Enfin, si vous ne voyez pas que les décisions de conception sont (souvent) une question d'opinion, vous devez probablement travailler sur des projets plus difficiles techniquement difficiles :-)
@Stephenc, ils sont une question d'opinion que dans la mesure où l'ingénierie logicielle est aujourd'hui en largement vaudou. Si nous en savions plus sur des systèmes complexes, nous pourrions prendre de meilleures décisions. SE est toujours à ses balbutiements, une proto-science. Mais cela ne signifie pas que les décisions sont une question d'opinion, simplement qu'elles sont mal informées.
Je pense que vous devez avoir une idée étrange de la "question d'opinion" et "mal informée". En outre, je pense que vous avez une attente irréaliste de ce que SE pratique devrait être capable de réaliser; C'est-à-dire que là-bas pourrait être une solution simple de manière objective correcte à chaque problème de conception . (Aucune des disciplines de génie classique ne peut faire cette réclamation non plus.)
@Stephenc dès qu'il y a plusieurs des solutions qualitativement différentes à un problème, l'un d'entre eux est par définition supérieure aux autres. Même si nous ne pourrions peut-être jamais déterminer la solution optimale analytiquement, en passant de là pour dire que "c'est une question d'opinion" est fallacieuse. Vous ne pouvez pas choisir vos faits, vous pouvez simplement reconnaître que vous n'avez pas tous les faits et de prendre des décisions imparfaites (mais acceptables) basées sur une contribution imparfaite. C'est tout à fait légitime, mais c'est
@Stephenc au fait, je conviens que dans de nombreux cas, Yagni. C'est-à-dire que la chaîne ordinaire est souvent le choix approprié (code de code, et tout cela). Dans la plupart des cas, lorsque des langues n'offrent pas de moyens concis d'exprimer cette encapsulation, je vais également aller avec une chaîne. Mais envisagez des langues comme Haskell que fait vous donne les moyens. Ici la question ne se pose même pas même; Vous utilisez une chaîne pour le texte, des alias ou des constructeurs fortement typés pour tout le reste.
"dès qu'il existe plusieurs solutions qualitativement différentes à un problème, l'un d'entre eux est par définition supérieure aux autres." - qui suppose qu'il existe un système objectif d'évaluation qui est supérieur et que tout le monde accepte d'utiliser ce système. Il suppose également que le schéma est garanti de classer deux solutions de sorte que l'une est meilleure que l'autre. Aucun de ceux-ci n'est vrai dans le monde réel.
@Stephenc ça ne suppose pas que. Cela suppose simplement qu'il existe une vérité objective que nous nous efforçons de se rapprocher, même si nous ne l'atteignons peut-être jamais. Vous faites la distinction entre théorie et «monde réel» pourtant de reconnaître que même pendant que nous travaillons dans un monde réel imparfait, nous pouvons toujours être au courant de l'imperfection de nos métriques. Dire "c'est une question de préférence" est une affirmation que nous peut faire des évaluations parfaites et trouver deux méthodes pour être vraiment équivalentes. C'est, comme vous l'avez dit vous-même, tout simplement pas le cas.
Désolé, mais vous supposez qu'il existe une vérité objective et que différentes solutions peuvent être classées objectivement. Vous supposez également que le «monde parfait» est encore possible.
"Mais vous supposez qu'il y ait une vérité objective" - bien sûr. Je suis un scientifique. "Que différentes solutions peuvent être classées objectivement" en principe, oui. Encore une fois, bien sûr.
"Dire" c'est une question de préférence ", c'est une affirmation que nous pouvons faire des évaluations parfaites" - au contraire, il dit que nous ne pouvons pas faire une évaluation parfaite. Au lieu de cela, nous devons faire des évaluations fondées sur des informations imparfaites et une théorie imparfaite (ou inexistante), et que ces évaluations sont nécessairement subjectives. Et aucune quantité d'hypothèse de mondes parfaite ne va aider les vrais ingénieurs logiciels. (Et je pourrais ajouter ... à nouveau ... ce génie logiciel n'est pas différent des autres disciplines d'ingénieur à cet égard, sauf dans la mesure où il est possible de modéliser les inconnues.)
Ok comme un scientifique, je vous conteste de prouver ces hypothèses. Ou au moins fournir des preuves plausibles pour eux. Parce que si vous ne pouvez pas alors votre argument selon lequel la bonne conception est «pas une question d'opinion» n'a pas de fondement logique.
@Stephen Notre désaccord semble provenir de différentes usages du mot "préférence". Pour moi, une préférence est le choix entre rouge et bleu, ou de chocolat et de glace. Choix qualitativement identiques. Vous, par contre, vous l'attribuez exactement à ce que j'ai dit, faisant de meilleurs choix possibles en l'absence de données exactes. Si tel est le cas, le seul point que nous sommes en désaccord est ce que le mot signifie. Depuis pour moi, cela implique le choix rouge-vs-bleu plutôt qu'une décision d'ingénierie basée sur des données (imparfaites), je n'aime pas le mot.
@Stephenc (et je suis d'accord, dans le recul, que j'étais celui qui a apporté une "question d'opinion", votre formulation originale est neutre à cet égard. Je suis toujours en désaccord avec l'utilisation de la programmation dactylographiée à terme lors de la conception d'une API, à moins que Yagni s'applique.)
Si vous n'aimez pas le mot «préférence», ne l'utilisez pas. Lire les réponses et les commentaires. Vous étiez celui qui l'a introduit dans la conversation ... comme une paraphrase (incorrecte) de ce que je disais. Notez que «question d'opinion» et «matière de préférence» ne signifie pas la même chose.
@Stephenc j'ai reconnu que.
Merci pour le montage Robusto.
Si l'alternative est une chaîne , je vous recommande vivement de rendre la classe immuable avec un champ final et aucun setter.
Le type de données valide-t-il la chaîne ou effectue-t-elle une manipulation autre que la tâche droite? La valeur est-elle censée être mutable? Les valeurs valides sont-elles connues au moment de la compilation?