Comment voulez-vous accéder aux propriétés d'objets à partir d'une méthode d'objet?

voix
81

Quel est le « puristes » ou « bonne » pour accéder aux propriétés d'un objet à partir d'une méthode d'objet qui n'est pas une méthode getter / setter?

Je sais que de l'extérieur de l'objet, vous devez utiliser un getter / setter, mais à l'intérieur feriez-vous simplement:

Java:

String property = this.property;

PHP:

$property = $this->property;

ou vous faire:

Java:

String property = this.getProperty();

PHP:

$property = $this->getProperty();

Pardonnez-moi si mon Java est un peu loin, il a été une année depuis que je Programmé en Java ...

MODIFIER:

Il semble que les gens sont en supposant que je parle des variables privées ou protégées / propriétés seulement. Quand j'appris OO On m'a appris à utiliser getters / setters pour chaque propriété unique, même si elle était publique (et en fait, on m'a dit de ne jamais faire une variable / propriété public). Donc, je peux être partant d'une hypothèse fausse dès le départ. Il semble que les gens ont répondu à cette question sont peut-être dire que vous devriez avoir des propriétés publiques et que ceux-ci ne ont pas besoin accesseurs, qui va à l'encontre ce qu'on m'a appris, et ce que je parle, mais peut-être qui doit être discuté en bien. C'est probablement un bon sujet pour une autre question bien ...

Créé 01/08/2008 à 17:10
source utilisateur
Dans d'autres langues...                            


18 réponses

voix
58

Cela a le potentiel de guerre de religion, mais il me semble que si vous utilisez un getter / setter, vous devez l' utiliser en interne et - utilisant à la fois conduira à des problèmes d'entretien sur la route (par exemple quelqu'un ajoute code à un compositeur qui a besoin de fonctionner à chaque fois que la propriété est définie, et la propriété est définie à l' intérieur w / o que setter appelé).

Créé 01/08/2008 à 17:13
source utilisateur

voix
41

Personnellement, je me sens comme il est important de rester cohérent. Si vous avez des accesseurs, les utiliser. La seule fois où j'accéder à un champ est directement lorsque l'accesseur a beaucoup de frais généraux. Il peut se sentir comme vous ballonnements votre code inutilement, mais il peut certainement économiser beaucoup de maux de tête à l'avenir. L'exemple classique:

Par la suite, vous pouvez vouloir changer la façon dont fonctionne ce domaine. Peut-être qu'il devrait être calculé sur la volée ou peut-être vous souhaitez utiliser un autre type pour le magasin de support. Si vous l'accès aux propriétés directement, comme un changement qui peut briser énormément de code dans une foop de houle.

Créé 01/08/2008 à 19:23
source utilisateur

voix
25

Je suis assez surpris de voir combien le sentiment unanime est que getterset setters sont très bien et bon. Je suggère l'article incendiaire par Allen Holub « accesseurs sont mauvaises ». Certes, le titre est pour la valeur de choc, mais l'auteur fait valoir des points valides.

Essentiellement, si vous avez getterset setterspour chaque domaine privé, vous faites ces domaines aussi bien que public. Vous seriez très mal à changer le type d'un champ privé sans effets d' entraînement à chaque classe qui appelle cela getter.

De plus, d'un point de vue strictement OO, les objets doivent être répondre aux messages (méthodes) qui correspondent à leur (je l' espère) la responsabilité unique. La grande majorité des getterset settersne font pas de sens pour leurs objets constitutifs; Pen.dispenseInkOnto(Surface)plus de sens pour moi que Pen.getColor().

Accesseurs encouragent également les utilisateurs de la classe pour demander l'objet de certaines données, effectuer un calcul, puis définissez une autre valeur dans l'objet, mieux connu sous le nom de programmation procédurale. Vous seriez mieux servis pour dire simplement l'objet de faire ce que vous allez en premier lieu; également connu sous le nom d' experts de l' information idiome.

Accesseurs, cependant, sont des maux nécessaires à la limite de couches - UI, la persistance, et ainsi de suite. Accès restreint à un internals de classe, comme mot - clé d'amis de C ++, package Java accès protégé, un accès interne de .NET et le modèle de classe ami peut vous aider à réduire la visibilité getterset setters seulement ceux qui en ont besoin.

Créé 19/09/2008 à 01:13
source utilisateur

voix
18

Cela dépend de la façon dont la propriété est utilisée. Par exemple, supposons que vous avez un objet étudiant qui a une propriété de nom. Vous pouvez utiliser votre méthode Get pour tirer le nom de la base de données, si elle n'a pas été récupéré déjà. De cette façon, vous réduisez les appels inutiles à la base de données.

Maintenant que vous avez un compteur entier privé dans votre objet qui compte le nombre de fois que le nom a été appelé. Vous voudrez peut-être de ne pas utiliser la méthode Get à l'intérieur de l'objet, car il produirait un nombre non valide.

Créé 01/08/2008 à 17:19
source utilisateur

voix
13

PHP offre une myriade de façons de gérer cela, y compris les méthodes magiques __getet __set, mais je préfère des accesseurs explicites. Voici pourquoi:

  1. La validation peut être placé dans setters (et apporteurs d'ailleurs)
  2. IntelliSense fonctionne avec des méthodes explicites
  3. Aucune question de savoir si une propriété est en lecture seule, écriture seule ou lecture-écriture
  4. Récupération des propriétés virtuelles (valeurs calculées) semble même que les propriétés régulières
  5. Vous pouvez facilement définir une propriété d'objet qui est jamais réellement défini nulle part, qui va alors sans papier
Créé 24/09/2008 à 18:24
source utilisateur

voix
12

Est-ce que je viens ici aller trop loin?

Peut-être;)

Une autre approche serait d'utiliser une méthode privée / protégée pour faire réellement le faire (cache / db / etc), et une enveloppe publique pour ce qui incrémente le compteur:

PHP:

public function getName() {
    $this->incrementNameCalled();
    return $this->_getName();
}

protected function _getName() {
    return $this->name;
}

puis à partir de l'objet lui-même:

PHP:

$name = $this->_getName();

De cette façon, vous pouvez toujours utiliser que le premier argument pour quelque chose d'autre (comme l'envoi d'un drapeau pour que ce soit ou non utilisé des données mises en cache ici peut-être).

Créé 01/08/2008 à 17:43
source utilisateur

voix
11

Je dois manquer le point ici, pourquoi voudriez-vous utiliser un getter à l'intérieur d'un objet pour accéder à une propriété de cet objet?

Prenant cela à sa conclusion, le getter doit appeler un getter, qui devrait appeler un getter.

Je dirais donc que l'intérieur d'un accès de la méthode d'objet directement une propriété, voir en particulier comme appeler une autre méthode dans cet objet (qui vient accéder à la propriété retourner directement de toute façon il) est juste un exercice inutile, un gaspillage inutile (ou ai-je mal compris la question ).

Créé 04/06/2011 à 16:42
source utilisateur

voix
7

Je dirais que ce mieux d'utiliser les méthodes d'accès même à l'intérieur de l'objet. Voici les points qui me viennent à l'esprit immédiatement:

1) Il doit être fait dans l'intérêt de maintenir la cohérence avec accès en dehors de l'objet.

2) Dans certains cas, ces méthodes accesseurs pourraient faire plus que l'accès au terrain; ils pourraient faire un certain traitement supplémentaire (son rare cependant). Si tel est le cas, en accédant directement sur le terrain vous manque que le traitement supplémentaire et votre programme pourrait déraper si ce traitement est toujours à faire au cours de ces accès

Créé 20/01/2010 à 09:32
source utilisateur

voix
7

La façon OO puriste est d'éviter à la fois et suivre la loi de Déméter en utilisant le Tell Do not Ask approche.

Au lieu d'obtenir la valeur de la propriété de l' objet, qui bien des couples les deux classes, utilisez l'objet comme paramètre par exemple

  doSomethingWithProperty() {
     doSomethingWith( this.property ) ;
  }

Lorsque la propriété était un type natif, par exemple int, utiliser une méthode d'accès, le nom de domaine pour des problèmes pas le domaine de la programmation.

  doSomethingWithProperty( this.daysPerWeek() ) ;

Ceux-ci vous permettront de maintenir l'encapsulation et les post-conditions ou dépendantes invariants. Vous pouvez également utiliser la méthode setter pour maintenir toutes les conditions préalables ou dépendantes invariants, mais ne pas tomber dans le piège de les nommer setters, retournez au principe de Hollywood pour nommer lors de l'utilisation du langage.

Créé 24/09/2008 à 18:04
source utilisateur

voix
7

Si par « puristes » vous voulez dire « plus encapsulation », je déclare généralement tous mes champs comme privés et ensuite utiliser this.field à partir de la classe elle-même, mais toutes les autres classes, y compris les sous-classes, l'état d'exemple l'accès à l'aide des apporteurs.

Créé 22/08/2008 à 12:15
source utilisateur

voix
6

Ça dépend. Il est plus une question de style que toute autre chose, et il n'y a pas de règle.

Créé 01/10/2008 à 11:51
source utilisateur

voix
6

Si je ne vais pas modifier la propriété que je vais utiliser une get_property()méthode publique à moins d'une occasion spéciale, comme un objet MySQLi dans un autre objet auquel cas je vais juste la propriété publique et parler comme $obj->object_property.

A l'intérieur de l'objet, il est toujours $ this-> propriété pour moi.

Créé 22/08/2008 à 12:34
source utilisateur

voix
6

champs privés avec des propriétés publiques ou protégées. L'accès aux valeurs doit passer par les propriétés, et être copié à une variable locale si elles seront utilisées plus d'une fois dans une méthode. Si et seulement si vous avez le reste de votre application de façon totalement retouché, bercé sur, et par ailleurs optimisé où l'accès aux valeurs en passant par leurs propriétés assosciated est devenu un goulot d'étranglement (Et cela ne jamais arriver, je vous garantis) si vous commencer même à envisager de laisser quoi que ce soit autre que les propriétés touchent leurs variables d'accompagnement directement.

Les développeurs .NET peuvent utiliser les propriétés automatiques pour appliquer cette puisque vous ne pouvez même pas voir les variables d'accompagnement au moment de la conception.

Créé 18/08/2008 à 18:43
source utilisateur

voix
6

Je l'ai trouvé à l'aide setters / getters fait mon code plus facile à lire. J'aime aussi le contrôle qu'il donne quand d'autres classes utilisent les méthodes et si je change les données de la propriété stockeront.

Créé 18/08/2008 à 18:37
source utilisateur

voix
6

Je peux me tromper parce que je suis autodidacte, mais je ne les propriétés publiques de l'utilisateur dans mes classes Java, ils sont toujours privés ou protégés, de sorte que le code extérieur doit accéder par getters / setters. Il est préférable à des fins d'entretien / de modification. Et pour le code à l'intérieur de la classe ... Si getter est trivial que j'utilise la propriété directement, mais je l'utilise toujours les méthodes setter parce que je pourrais facilement ajouter du code pour déclencher des événements si je veux.

Créé 06/08/2008 à 15:43
source utilisateur

voix
5

J'aime la réponse par cmcculloh , mais il semble que le plus correct est la réponse par Greg Hurlman . Utilisez getter / setters tout le temps si vous avez commencé à les utiliser de la getgo et / ou l' habitude de travailler avec eux.

En aparté, je trouve que l'utilisation getter / setters rend le code plus facile à lire et à déboguer plus tard.

Créé 15/09/2008 à 10:46
source utilisateur

voix
5

Eh bien, il semble à la mise en œuvre par défaut C # 3.0 propriétés, la décision est prise pour vous; vous devez définir la propriété en utilisant le (éventuellement privé) setter de propriété.

Personnellement, j'utilise uniquement l'élément derrière privé quand ne pas le faire provoquerait l'objet de tomber dans un état moins souhaitable, par exemple lors de l'initialisation ou lorsque la mise en cache / chargement paresseux est impliqué.

Créé 01/08/2008 à 17:56
source utilisateur

voix
4

Comme il est indiqué dans certains des commentaires: Parfois, vous devriez, parfois vous ne devriez pas. La grande partie sur des variables privées est que vous êtes en mesure de voir tous les endroits où ils sont utilisés lorsque vous changez quelque chose. Si votre getter / setter fait quelque chose dont vous avez besoin, utiliser. Si cela ne vous importe de décider.

Le cas contraire pourrait être fait que si vous utilisez le getter / setter et quelqu'un change le getter / setter ils doivent analyser tous les endroits du getter et setter est utilisé en interne pour voir si elle salit quelque chose.

Créé 01/08/2008 à 18:01
source utilisateur

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more