Quel est l'intérêt des propriétés?

Voici quelques arguments pour les propriétés et mes contre-arguments:

Plus facile à utiliser que d'écrire des méthodes getter et setter

Les paires de méthodes getter et setter sont une odeur de code. Les rendre plus faciles à écrire, c'est comme faciliter l'échec d'un test de mathématiques en utilisant un formulaire Scantron et en remplissant tous les «C». Les objets qui contiennent uniquement un état, pour la persistance, ne doivent pas utiliser de getters / setters et doivent créer des objets immuables au moment de la persistance.

Ce qui est important pour un consommateur d'un objet, c'est ce qu'il fait, pas comment il le fait. Son comportement est ce qu'il fait; son état est de savoir comment il le fait. Si vous vous souciez de l'état d'un objet (sauf pour la persistance, bien que cela casse également OO), vous ne faites tout simplement pas de POO et ne perdez pas ses avantages.

Ils donnent une indication approximative des performances aux consommateurs

C'est quelque chose qui pourrait changer à l'avenir, pour n'importe quelle propriété donnée. Supposons que dans la version 1.0, l'accès à PropertyX renvoie simplement un champ. Dans la version 1.5, si le champ est null, PropertyX utilise le modèle Null Object pour créer un nouvel objet null. Dans la version 2.0, le champ est encore validé par la méthode getter dans PropertyX.

Comme la propriété devient de plus en plus complexe, l'indication de performance d'utilisation d'une propriété semble de moins en moins véridique.

Ils sont meilleurs que les champs publics

C'est vrai. Mais les méthodes aussi.

Ils représentent un aspect fondamentalement différent d'un objet qu'une méthode, et tous les consommateurs de l'objet devraient s'en soucier

Êtes-vous sûr que les deux affirmations ci-dessus sont vraies?

Ils sont plus faciles à taper, mec

Bien sûr, la frappe myObject.Lengthest plus facile que la frappe myObject.Length(), mais cela ne pourrait-il pas être corrigé avec un peu de sucre syntaxique?

Pourquoi utiliser des méthodes plutôt que des propriétés?

• Aucune garantie de performance. L'API restera véridique même si la méthode devient plus complexe. Le consommateur devra profiler son code s'il rencontre des problèmes de performances et ne pas s'appuyer sur Word-of-API.

• Moins de réflexion pour le consommateur. Cette propriété a-t-elle un setter? Une méthode, bien sûr.

• Le consommateur pense d'un état d'esprit approprié. En tant que consommateur d'une API, je souhaite interagir avec le comportement d'un objet. Quand je vois des propriétés dans l'API, cela ressemble beaucoup à l'état. En fait, si les propriétés en font trop, elles ne devraient même pas être des propriétés, donc vraiment, les propriétés dans un état API ARE telles qu'elles apparaissent aux consommateurs.

• Le programmeur de l'API réfléchira plus profondément aux méthodes avec des valeurs de retour et évitera si possible de modifier l'état de l'objet dans de telles méthodes. La séparation des commandes des requêtes doit être appliquée dans la mesure du possible.

Je vous demande donc pourquoi utiliser des propriétés plutôt que des méthodes? La plupart des points sur MSDN sont des odeurs de code en soi et n'appartiennent ni aux propriétés ni aux méthodes.

(Ces pensées me sont venues après avoir pensé au CQS.)

Pourquoi s'agit-il de "méthodes contre propriétés"? Une méthode fait quelque chose. Une propriété est, bien, un membre d'un objet. Ce sont des choses totalement différentes, bien que deux types de méthodes couramment écrites - les getters et les setters - correspondent aux propriétés. Étant donné que la comparaison des propriétés avec les méthodes en général n'a pas de sens, je suppose que vous vouliez parler des getters / setters.

Les paires de méthodes getter et setter sont une odeur de code.

Pas nécessairement, je dirais, mais de toute façon ce n'est pas une question de getters / setters vs propriétés, mais une question de savoir si l'un doit être utilisé. Notez également que vous pouvez par exemple omettre la setXpièce comme vous pouvez créer des propriétés en lecture seule.

Ce qui est important pour un consommateur d'un objet, c'est ce qu'il fait, pas comment il le fait. Son comportement est ce qu'il fait; son état est de savoir comment il le fait. Si vous vous souciez de l'état d'un objet (sauf pour la persistance, bien que cela casse également OO), vous ne faites tout simplement pas de POO et ne perdez pas ses avantages.

Une attitude très discutable. Si l'interface graphique veut sortir des données détenues par un DataStuffManagerImpl, elle doit en obtenir ce numéro d'une certaine manière (et non, entasser la moitié de l'application dans la classe de widget n'est pas une option).

Comme la propriété devient de plus en plus complexe, l'indication de performance d'utilisation d'une propriété semble de moins en moins véridique.

[Les méthodes ont] Aucune garantie de performance. L'API restera véridique même si la méthode devient plus complexe. Le consommateur devra profiler son code s'il rencontre des problèmes de performances et ne pas s'appuyer sur Word-of-API.

Dans presque tous les cas, toute la logique de validation, etc. est toujours effectivement O (1), ou autrement négative en termes de coût. Sinon, vous êtes peut-être allé trop loin et il est temps de changer. Et une getX()méthode est généralement considérée comme aussi bon marché!

Bien sûr, taper myObject.Length est plus facile que taper myObject.Length (), mais cela ne pourrait-il pas être corrigé avec un peu de sucre syntaxique?

Les propriétés sont ce sucre syntaxique.

Moins de réflexion pour le consommateur. Cette propriété a-t-elle un setter? Une méthode, bien sûr.

"Y a-t-il un passeur pour ce getter?" Même différence.

Le programmeur de l'API réfléchira plus profondément aux méthodes avec des valeurs de retour et évitera si possible de modifier l'état de l'objet dans de telles méthodes. La séparation des commandes des requêtes doit être appliquée dans la mesure du possible.

Je ne sais pas ce que vous essayez de nous dire ici. Pour les propriétés, il existe une loi non écrite encore plus forte pour ne pas provoquer d'effets secondaires.

Les paires de méthodes getter et setter sont une odeur de code.

C'est une hypothèse erronée et complètement incorrecte. Les méthodes Get / Set sont un moyen d'encapsuler un membre de données et ne sont en aucun cas une "odeur de code". Je déteste vraiment la façon dont certaines personnes utilisent le terme "odeur de code", mais de toute façon ...

C'est quelque chose qui pourrait changer à l'avenir, pour n'importe quelle propriété donnée. Supposons que dans la version 1.0, l'accès à PropertyX renvoie simplement un champ. Dans la version 1.5, si le champ est null, PropertyX utilise le modèle Null Object pour créer un nouvel objet null. Dans la version 2.0, le champ est encore validé par la méthode getter dans PropertyX.

Comme la propriété devient de plus en plus complexe, l'indication de performance d'utilisation d'une propriété semble de moins en moins véridique.

Cela ressemble à une API mal conçue, je ne vois pas comment c'est la faute de la syntaxe des propriétés.

Les propriétés en C # étaient simplement du sucre syntaxique pour un modèle très courant qui nous facilitait un peu la vie en tant que programmeurs. Cependant, de nos jours, si vous souhaitez utiliser la liaison de données, vous "devez" utiliser des propriétés, elles sont donc un peu plus que du sucre syntaxique. Je suppose que je ne suis vraiment pas d'accord avec aucun de vos points et je ne comprends pas pourquoi vous n'aimez pas une fonctionnalité de langue qui prend directement en charge un modèle commun.

Votre prémisse est fausse.

Les propriétés ne sont en aucun cas un contrat de performance ou d'implémentation interne ou autre.
Les propriétés sont des paires de méthodes spéciales, qui représentent sémantiquement un attribut, si vous voulez. Et donc le seul contrat est qu'une propriété se comporte comme vous vous attendez à ce qu'un attribut se comporte.
Si je demande la couleur d'un objet, je ne fais pas d'hypothèse si elle est obtenue par un simple accès au champ, ou si elle est calculée juste à temps.
Le tout est d'avoir la possibilité d'exposer le comportement d'un attribut à l'aide de méthodes, tout en étant transparent pour le consommateur de l'interface, que vous utilisiez un champ ou des accesseurs.

Avoir des attributs (et masquer leur implémentation, comme les propriétés s'opposent aux champs) est une puissante fonctionnalité déclarative , qui est la base pour avoir des inspecteurs d'objets visuels et d'autres génération de vues automatiques, pour la liaison de données et bien d'autres choses utiles. Et surtout, il transporte également clairement ces informations pour vos collègues programmeurs.

Le consommateur pense d'un état d'esprit approprié. En tant que consommateur d'une API, je souhaite interagir avec le comportement d'un objet. Quand je vois des propriétés dans l'API, cela ressemble beaucoup à l'état. En fait, si les propriétés en font trop, elles ne devraient même pas être des propriétés, donc vraiment, les propriétés dans un état API ARE telles qu'elles apparaissent aux consommateurs.

Une propriété est censée être un état. Si le code setter ou getter changements sous - jacents à ajouter de manière significative au traitement requis pour définir ou obtenir l'état alors vraiment il n'est plus une propriété et vous devrait le remplacer par des méthodes. Cela dépend de vous en tant que développeur du code.

Mettre trop (combien coûte trop dépend) du code dans un setter ou un getter est faux, mais ce n'est pas parce que c'est possible de jeter le motif dans tous les cas.

Une chose qui vous manque, et je ne sais pas si cela est dû à l'ignorance ou si vous négligez intentionnellement ce détail, c'est que les propriétés SONT des méthodes.

Lorsque vous utilisez la syntaxe de propriété de C #, le compilateur crée silencieusement des méthodes getter et setter avec des métadonnées qui indiquent aux langages qui comprennent les propriétés comme une fonctionnalité syntaxique de première classe de les traiter comme telles. C'est en fait le sucre syntaxique que vous demandez. Quelques langages qui peuvent être exécutés sur le CLR ne vous cachent pas complètement ce détail (Boo, si la mémoire me sert, et certaines implémentations Lisp), et vous pouvez appeler explicitement les getters et setters.

Les propriétés ont parfois des effets secondaires, comme déclencher des événements de notification de changement (INotifyPropertyChanged, par exemple) ou marquer une instance d'une classe comme sale. C'est là qu'ils ont leur vraie valeur, bien que les créer soit un peu plus de travail (sauf dans Boo, qui a des macros syntaxiques).

Maintenant, la question plus large est de savoir si les méthodes getter et setter sont, en fait, une bonne chose. Il y a clairement des compromis; si vous avez des méthodes de mutation, votre code est intrinsèquement moins parallélisable, car vous devez maintenant faire face aux problèmes de synchronisation des threads. Et il est tout à fait possible que vous risquiez de violer la loi de Demeter en utilisant des méthodes de mutation (qu'elles soient appelées propriétés ou méthodes getter / setter; elles sont équivalentes), car c'est tellement pratique de le faire.

Mais parfois, c'est la bonne chose à faire. Parfois, votre problème consiste à récupérer des données d'une source, à les modifier un peu, à présenter les données mises à jour à l'utilisateur et à enregistrer les modifications. Cet idiome est bien servi par les propriétés. Comme le dit l' article d'Allen Holub , ce n'est pas parce que les getters et les setters ont des problèmes que vous ne devriez jamais les utiliser. (Guruspeak abstrait perroquet considéré comme nuisible). Même lorsque vous suivez l'approche Classe / Responsabilités / Collaborateurs, vous finissez toujours par exposer des informations ou des présentations d'informations à quelqu'un; il s'agit de minimiser la surface d'enchevêtrement.

L'avantage des propriétés est qu'il est très facile de faire en sorte qu'un autre objet en profite. L'inconvénient des propriétés est qu'il est très facile qu'un autre objet en profite, et vous ne pouvez pas facilement empêcher cela.

La mutation d'objet est logique au niveau de la couche contrôleur, dans, par exemple, une architecture MVC. Voilà votre collaborateur. Votre point de vue est également un collaborateur, mais il ne doit pas directement muter vos objets, car il a des responsabilités différentes. Rouler le code de présentation dans vos objets métier n'est pas nécessairement la bonne façon d'éviter les getters / setters.

L'équation change un peu si vous utilisez des abstractions fonctionnelles plutôt que des OO pures, ce qui rend généralement la copie d'un objet "record" avec quelques changements assez banale, mais pas gratuite. Et bon, si vous essayez d'obtenir des garanties de performances, les propriétés sont généralement plus prévisibles que la reconstruction paresseuse d'une collection immuable.

Une autre raison importante de l'utilisation de propriétés dans mon livre est qu'elles peuvent augmenter considérablement la lisibilité.

account.setBalance(Account.getBalance()+deposit);

est nettement moins lisible que

account.Balance += deposit;

Vous avez presque le point de vue religieux opposé à moi :)

Quand j'ai déménagé de Delphi à Java, le manque de propriétés a été un énorme affront pour moi. J'avais l'habitude de déclarer une propriété et de la pointer directement vers une variable privée ou d'écrire un getter & setter (protégé), puis de les "raccorder" à la propriété. Cela a encapsulé la propriété et contrôlé la façon dont elle devrait être accessible de manière claire et sans ambiguïté. Vous pouvez avoir une propriété en lecture seule qui calcule le total lors de l'accès et l'appeler "Total" et non "_getTotal ()" ou des ballochs similaires. Cela signifiait également que vous pouviez restreindre l'accès aux propriétés en les rendant protégées dans la classe de base abstraite, puis en les déplaçant vers le public ou publiées dans des sous-classes.

Pour moi, les propriétés sont un moyen plus naturel et expressif de définir et d'obtenir l'état de l'objet. S'appuyer sur des conventions de codage non appliquées est plus une "odeur de code" que tout ce dont vous critiquez les propriétés. En outre, comme d'autres l'ont dit, proposer une utilisation mal conçue des propriétés et utiliser ses échecs pour essayer de rejeter le concept de propriétés en général est une forme extrêmement mauvaise. Il est possible que vous n'ayez vu que la mauvaise utilisation des propriétés et supposez que c'est comme ça, je suppose, mais vous devriez faire plus de recherches avant de devenir trop dogmatique.

L'une des raisons pour lesquelles les propriétés ont été introduites dans Java Beans Framework était de permettre l'intégration avec un IDE - vous pouvez faire glisser ces composants vers l'IDE et modifier les propriétés à l'aide des éditeurs de propriétés.

(à l'époque, ils n'étaient que des getters et des setters réguliers - et n'étaient définis que par la convention de dénomination - et cela sentait effectivement)

Aujourd'hui, il y a encore plus de cas où les propriétés sont accessibles et modifiées non pas par le biais du code normal - comme lors du débogage.

Un autre angle - ils venaient vraiment de VB. Rappelez-vous que dans les jours sombres du 20e siècle, lorsque .NET a été conçu, l'accent était mis sur le remplacement facile et rapide de VB afin que vos programmeurs VB puissent simplement glisser-déposer des éléments sur des formulaires Web. VB avait des propriétés, vous devez donc conserver cette fonctionnalité pour que les choses se traduisent correctement.

Les propriétés ont au moins deux objectifs:

• Ils sont conceptuellement identiques aux champs même s'ils sont implémentés différemment. Un getter ne devrait pas changer l'état de l'objet et ne devrait avoir aucun effet secondaire. Un setter ne devrait changer l'état que de manière conceptuellement similaire à la modification d'un champ et ne pas avoir d'autres effets secondaires.

• Ils sont syntaxiquement identiques aux champs publics (éventuellement en lecture seule). Cela signifie qu'un champ public peut être modifié en une propriété sans interrompre les appelants au niveau source.