Allen Holub a écrit "Vous ne devez jamais utiliser get/set fonctions", est-il correct?

Question

Allen Holub a écrit ce qui suit,

Vous ne pouvez pas avoir un programme sans couplage. Néanmoins, vous pouvez réduire le couplage considérablement par servilement la suite OO (orienté objet), les préceptes, dont le plus important est que la mise en œuvre d'un objet doit être complètement caché par les objets qui l'utilisent). Par exemple, une instance de l'objet de variables (champs des membres qui ne sont pas constantes), doit toujours être privé. Période. Pas d'exceptions. Jamais. Je veux dire, c'. (Vous pouvez parfois utiliser les méthodes protected efficacement, mais protégé les variables d'instance sont une abomination.)

Ce qui semble raisonnable, mais il va ensuite à dire,

Vous devriez ne jamais les utiliser get/fonctions de jeu pour la même raison, ils sont juste trop compliqués, les façons de faire d'un domaine public (bien que l'accès des fonctions qui renvoient pleine crise d'objets plutôt que sur la base d'un type de valeur sont raisonnables dans les situations où l'objet retourné est une clé de l'abstraction dans la conception).

Qui, franchement, juste des sons de fou pour moi.

J'ai compris le principe de se cacher de l'information, mais sans les accesseurs et des mutateurs vous ne pouviez pas utiliser Java beans à tous. Je ne sais pas comment vous suivez un MVC conception sans accesseurs dans le modèle, puisque le modèle ne peut pas être responsable pour le rendu de la vue.

Cependant, je suis un jeune programmeur et je en savoir plus sur la Conception Orientée Objet de tous les jours. Peut-être quelqu'un avec plus d'expérience peut peser sur cette question.

Allen Holub, des articles pour la référence

• Pourquoi S'Étend Est Le Mal
• Pourquoi Les Méthodes Getter Et Setter Sont Mal

---

Questions Connexes:

• Java: Sont des Getters et Setters mal?
• Est-ce vraiment mal de ne pas utiliser les setters et getters?
• Sont des fonctions get et set populaire avec les programmeurs en C++?
• Devriez-vous utiliser des propriétés d'accesseur de l'intérieur de la classe, ou tout simplement de l'extérieur de la classe?

Answer 1

Je n'ai pas de problème avec Holub vous dire que vous devriez généralement éviter de modifier l' état d'un objet, mais plutôt recourir à des méthodes intégrées (exécution de comportements) pour parvenir à cette fin. Comme Corletk le souligne, il y a de la sagesse dans le fait de penser à long et dur sur le plus haut niveau d'abstraction, et pas seulement de la programmation à la légère avec des getters/setters qui vient de vous permettre de faire une fin de course autour de l'encapsulation.

Cependant, j'ai beaucoup de mal avec quelqu'un qui vous dit que vous devriez "jamais" utiliser les incubateurs ou doit "jamais" accès de type primitif. En effet, l'effort nécessaire pour maintenir ce niveau de pureté dans tous les cas, peut et finira par causer plus de complexité dans votre code à l'aide de mise en œuvre adéquate des propriétés. Vous avez juste à avoir assez de bon sens pour savoir quand vous êtes en contournant les règles pour des gains à court terme au détriment de la douleur à long terme.

Holub n'a pas confiance en vous connaître la différence. Je pense que le fait de connaître la différence est ce qui fait de vous un professionnel.

Answer 2

Lire cet article attentivement. Holub est poussée au point que les getters et les setters sont un mal "par défaut antipattern", une mauvaise habitude que nous glisser dans lors de la conception d'un système; parce que nous le pouvons.

Le processus de pensée devrait être le long des lignes; Quel est cet objet n'? Quelles sont ses responsabilités? Quels sont ses comportements? Que faut-il savoir? Penser à long et dur sur ces questions vous mène tout naturellement vers la conception de classes qui exposent le plus haut niveau de l'interface possible.

Une voiture est un bon exemple. Il expose une bien défini, standardisé interface de haut niveau. Je n'ai pas à me préoccuper de setSpeed(60)... est-ce que MPH ou en km/h? Je viens d'accélérer, de croisière, de décélérer. Je n'ai pas à penser aux détails en setSteeringWheelAngle(getSteeringWheelAngle()+Math.rad(-1.5)), je viens turn(-1.5), et les détails sont pris en charge sous le capot.

Il se résume à "vous pouvez et Vous devez comprendre ce que chaque classe sera utilisée, ce qu'elle fait, ce qu'il représente, et d'exposer le plus haut niveau de l'interface possible qui répond à toutes ces exigences. Les accesseurs et mutateurs sont généralement un cop-out, quand le programmeur est juste trop paresseux pour faire l'analyse nécessaire pour déterminer exactement ce que chaque classe est et n'est-ce pas, et donc, nous descendons le chemin de la "il ne peut rien faire". Les accesseurs et mutateurs sont le mal!

Parfois, les exigences réelles de classe sont impossibles à connaître à l'avance. C'est cool, juste cop-out et l'utilisation getter/setter antipattern pour l'instant, mais quand on sait, par expérience, ce que la classe est utilisé pour, vous aurez probablement envie de revenir et de nettoyage de la sale faible niveau de l'interface. Refactoring basé sur des "choses" que vous souhaitez vous saviez quand vous écrivez le meunier, en premier lieu" est par pour le cours. Vous n'avez pas tout savoir dans le but de faire un début, c'est juste que le plus vous le faire savoir, le moins de retouches est susceptible d'être requise sur le chemin.

C'est la mentalité qu'il est promotion de. Les accesseurs et mutateurs sont un simple piège tomber dans.

Oui, les haricots, fondamentalement, exigent des getters et setters, mais pour moi un bean est un cas spécial. Haricots représentent des noms, des choses tangibles identifiables (si ce n'est physique) des objets. Pas beaucoup d'objets ont des comportements automatiques; la plupart du temps les choses sont manipulés par des forces externes, y compris les humains, afin de les rendre productives.

daisy.setColor(Color.PINK) tout à fait logique. Quoi d'autre pouvez-vous faire? Peut-être un Vulcan esprit-fondre, pour faire la fleur voulez être rose? Hmmm?

Getters et setters ont leur ?le mal? place. C'est juste, comme tous vraiment bon OO choses, nous avons tendance à en abuser, parce qu'ils sont sûrs et familier, pour ne pas mentionner simple, et par conséquent, il pourrait être mieux si les noobs ne pas voir ou entendre parler d'eux, au moins jusqu'à ce qu'ils avaient maîtrisé l'esprit-fondre chose.

Answer 3

Je pense que ce Allen Holub essayé de dire, reformulé dans cet article, est la suivante.

Les accesseurs et mutateurs peut être utile pour les variables que vous souhaitez pour encapsuler, mais vous n'avez pas à les utiliser pour toutes les variables. En fait, leur utilisation pour toutes les variables est désagréable odeur de code.

Le problème des programmeurs, et Allen Holub a raison de souligner c'est que, parfois, ils utilisent des getters/setters pour toutes les variables. Et le but de l'encapsulation est perdu.

Answer 4

(remarque, je viens à ce à partir d'un .NET "propriété" de l'angle)

Eh bien, tout simplement - je ne suis pas d'accord avec lui; il a fait un grand tapage sur le type de retour de propriétés d'être une mauvaise chose, car il peut briser votre code d'appel - mais exactement le même argument s'appliquerait à des arguments de méthode. Et si vous ne pouvez pas utiliser les méthodes?

OK, des arguments de méthode qui pourrait être modifié, que l'aggravation des conversions, mais.... juste pourquoi... il est Également à noter qu'en C# le var mot-clé pourrait atténuer beaucoup de cette perception de la douleur.

Les accesseurs sont pas un détail de l'implémentation; ils sont le public de l'API ou du contrat. Yup, si vous cassez la contracft vous avez des problèmes. Quand est-ce devenu une surprise? De même, il n'est pas rare pour les accesseurs pour être non négligeable - c'est à dire qu'ils font plus que juste envelopper les champs; ils procèdent à des calculs, la logique des contrôles, notifications, etc. Et ils permettent à l'interface en fonction des abstractions de l'etat. Oh, et le polymorphisme - etc.

Re détaillé de la nature des accesseurs (p3?4?) - en C#: public int Foo {get; private set;} - travail.

En fin de compte, tout le code est un moyen d'exprimer notre intention de le compilateur. Propriétés de me laisser faire que dans un type-safe, contrat, vérifiables, extensible, polymorphe moyen - grâce. Pourquoi ai-je besoin de "réparer" ce?

Answer 5

Les accesseurs et mutateurs sont utilisés comme un peu plus qu'un masque pour faire une variable privée publique.

Il n'y a pas de point de répéter ce que Holub déjà dit mais l'essentiel, c'est que les classes à représenter le comportement et non pas seulement de l'état.