Πώς θα αποκτήσετε πρόσβαση σε ιδιότητες αντικειμένου μέσα από μια μέθοδο αντικειμένου;

ψήφοι
81

Τι είναι η «καθαρεύουσα» ή «σωστό» τρόπο για να αποκτήσετε πρόσβαση σε ιδιότητες ενός αντικειμένου μέσα από μια μέθοδο αντικείμενο που δεν είναι μια μέθοδος κτήτορας / setter;

Ξέρω ότι εκτός του αντικειμένου θα πρέπει να χρησιμοποιήσετε ένα συλλέκτη / setter, αλλά από μέσα θα κάνετε ακριβώς:

Ιάβα:

String property = this.property;

PHP:

$property = $this->property;

ή θα το κάνετε:

Ιάβα:

String property = this.getProperty();

PHP:

$property = $this->getProperty();

Συγχωρήστε με αν Java μου είναι λίγο μακριά, είναι ήδη ένας χρόνος από τότε που έχει προγραμματιστεί σε Java ...

ΕΠΕΞΕΡΓΑΣΙΑ:

Φαίνεται ότι οι άνθρωποι αναλαμβάνουν μιλάω για ιδιωτική ή προστατευόμενη μεταβλητές / μόνο ιδιότητες. Όταν έμαθα OO διδάχτηκα να χρησιμοποιήσετε κτήτορες / setters για κάθε ακίνητο, ακόμη και αν ήταν δημόσια (και μάλιστα μου είπαν να μην κάνει καμία μεταβλητή / δημόσια περιουσία). Έτσι, μπορεί να ξεκινάμε από μια εσφαλμένη υπόθεση από το να πάει. Φαίνεται ότι οι άνθρωποι απάντηση στο ερώτημα αυτό είναι ίσως λέγοντας ότι θα πρέπει να έχετε δημοσίων ακινήτων και ότι εκείνες δεν χρειάζονται getters και setters, η οποία έρχεται σε αντίθεση με αυτό που δίδαξε, και τι μιλούσα για, αν και ίσως αυτό θα πρέπει να συζητηθεί ως Καλά. Αυτό είναι πιθανώς ένα καλό θέμα για ένα άλλο ζήτημα αν ...

Δημοσιεύθηκε 01/08/2008 στις 17:10
πηγή χρήστη
Σε άλλες γλώσσες...                            


18 απαντήσεις

ψήφοι
58

Αυτό έχει θρησκευτικό πόλεμο δυναμικό, αλλά μου φαίνεται ότι αν χρησιμοποιείτε μια κτήτορας / setter, θα πρέπει να το χρησιμοποιήσετε στο εσωτερικό, καθώς και - χρησιμοποιώντας τόσο θα οδηγήσει σε προβλήματα συντήρησης κάτω από το δρόμο (π.χ. κάποιος προσθέτει κώδικα σε ένα setter που χρειάζεται να εκτελείται κάθε φορά που ιδιότητα έχει οριστεί, και η ιδιότητα, η οποία προβλέπεται εσωτερικώς w / o εν λόγω setter που καλείται).

Απαντήθηκε 01/08/2008 στις 17:13
πηγή χρήστη

ψήφοι
41

Προσωπικά, νιώθω σαν να είναι σημαντικό να διατηρηθεί η συνοχή. Αν έχετε getters και setters, τα χρησιμοποιούν. Η μόνη φορά που θα έχετε άμεση πρόσβαση σε πεδίο είναι όταν η accessor έχει πολύ γενικά. Μπορεί να νιώθετε σαν να είστε φούσκωμα κωδικό σας άσκοπα, αλλά σίγουρα μπορεί να σώσει ένα σωρό πονοκέφαλο στο μέλλον. Το κλασικό παράδειγμα:

Αργότερα, μπορείτε να επιθυμήσετε να αλλάξετε τον τρόπο που δουλεύει το πεδίο. Ίσως θα πρέπει να υπολογίζεται on-the-fly ή ίσως θέλετε να χρησιμοποιήσετε ένα διαφορετικό τύπο για το κατάστημα υποστήριξη. Αν έχετε άμεση πρόσβαση ιδιότητες, μια αλλαγή όπως αυτή μπορεί να σπάσει ένα φοβερό μέρος του κώδικα σε ένα φούσκωμα foop.

Απαντήθηκε 01/08/2008 στις 19:23
πηγή χρήστη

ψήφοι
25

Είμαι αρκετά έκπληκτος με το πόσο ομόφωνη το συναίσθημα είναι ότι gettersκαι setters είναι ωραία και καλά. Προτείνω το εμπρηστικό άρθρο του Allen Holub « κτήτορες και ρυθμιστές είναι κακό ». Σύμφωνοι, ο τίτλος είναι για την αξία σοκ, αλλά ο συγγραφέας κάνει έγκυρα σημεία.

Ουσιαστικά, αν έχετε gettersκαι settersγια κάθε ιδιωτικό τομέα, που κάνουν αυτά τα πεδία τόσο καλή όσο κοινού. Θα ήθελα να είναι πολύ πιεσμένοι για να αλλάξετε τον τύπο του ιδιωτικού τομέα, χωρίς παράπλευρες συνέπειες σε κάθε κατηγορία που απαιτεί ότι getter.

Επιπλέον, από αυστηρά OO άποψη, τα αντικείμενα θα πρέπει να ανταποκρίνεται στα μηνύματα (μεθόδους) που αντιστοιχούν σε τους (ελπίζουμε) και μόνο ευθύνη. Η συντριπτική πλειοψηφία των gettersκαι settersδεν έχουν νόημα για τα συστατικά αντικειμένων τους? Pen.dispenseInkOnto(Surface)έχει περισσότερο νόημα για μένα από ό, τι Pen.getColor().

Getters και setters ενθαρρύνει επίσης τους χρήστες της τάξης να ζητήσει από το αντικείμενο για ορισμένα δεδομένα, εκτελούν έναν υπολογισμό, και στη συνέχεια, ορίστε κάποια άλλη τιμή στο αντικείμενο, περισσότερο γνωστή ως διαδικαστικό προγραμματισμό. Θα ήθελα να εξυπηρετούνται καλύτερα να πω απλά το αντικείμενο για να κάνει ό, τι επρόκειτο να στην πρώτη θέση? Επίσης γνωστό ως πληροφορίες εμπειρογνωμόνων ιδίωμα.

Getters και setters, όμως, είναι αναγκαία κακά, στα όρια των στρωμάτων - UI, επιμονή, και ούτω καθεξής. Περιορισμένη πρόσβαση σε εσωτερικά μιας τάξης, όπως ο φίλος λέξη-κλειδί C ++ 's, προστατεύονται δέσμη πρόσβασης της Java, εσωτερική πρόσβαση .NET, καθώς και το μοτίβο φίλο Class μπορεί να σας βοηθήσει να μειώσετε την προβολή της gettersκαι setters μόνο σε εκείνους που τα έχουν ανάγκη.

Απαντήθηκε 19/09/2008 στις 01:13
πηγή χρήστη

ψήφοι
18

Εξαρτάται από το πώς χρησιμοποιείται το ακίνητο. Για παράδειγμα, ας υποθέσουμε ότι έχετε ένα αντικείμενο μαθητή που έχει το ακίνητο. Μπορείτε να χρησιμοποιήσετε τη μέθοδο GET για να τραβήξει το όνομα από τη βάση δεδομένων, αν δεν έχει ανακτηθεί ήδη. Με αυτό τον τρόπο θα έχετε την μείωση των περιττών κλήσεις στη βάση δεδομένων.

Τώρα ας υποθέσουμε ότι έχετε μια ιδιωτική ακέραιο μετρητή στο αντικείμενό σας που μετρά τον αριθμό των φορών που το όνομα έχει κληθεί. Μπορεί να θέλετε να μην χρησιμοποιούν τη μέθοδο GET από το εσωτερικό του αντικειμένου, διότι θα παράγουν μια μη έγκυρη μέτρηση.

Απαντήθηκε 01/08/2008 στις 17:19
πηγή χρήστη

ψήφοι
13

PHP προσφέρει μια πληθώρα τρόπων για να χειριστεί αυτό, συμπεριλαμβανομένων μαγεία μεθόδους __getκαι __set, αλλά εγώ προτιμώ ρητή getters και setters. Εδώ είναι γιατί:

  1. Η επικύρωση μπορεί να τοποθετηθεί σε ρυθμιστές (και κτήτορες για εκείνο το θέμα)
  2. Intellisense λειτουργεί με σαφείς μεθόδους
  3. Δεν τίθεται θέμα αν μια ιδιότητα είναι μόνο για ανάγνωση, γράφουν μόνο ή ανάγνωσης-γραφής
  4. Ανάκτηση εικονικές ιδιότητες (π.χ., υπολογιζόμενες τιμές) φαίνεται το ίδιο με το κανονικό ιδιότητες
  5. Μπορείτε εύκολα να ρυθμίσετε ένα ακίνητο αντικείμενο που στην πραγματικότητα ποτέ δεν ορίζεται πουθενά, το οποίο στη συνέχεια πηγαίνει χωρίς χαρτιά
Απαντήθηκε 24/09/2008 στις 18:24
πηγή χρήστη

ψήφοι
12

Είμαι ακριβώς πρόκειται θάλασσα εδώ;

Ισως ;)

Μια άλλη προσέγγιση θα ήταν να χρησιμοποιήσει ένα ιδιωτικό / προστατευμένη μέθοδος για να γίνει πραγματικότητα το πάρει (caching / db / κλπ), και ένα δημόσιο περιτύλιγμα για αυτό που αυξάνει την καταμέτρηση:

PHP:

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

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

και στη συνέχεια μέσα από το ίδιο το αντικείμενο:

PHP:

$name = $this->_getName();

Με αυτό τον τρόπο μπορείτε ακόμα να χρησιμοποιήσετε αυτό το πρώτο επιχείρημα για κάτι άλλο (όπως η αποστολή της σημαίας για το αν πρέπει ή όχι να χρησιμοποιηθεί προσωρινά αποθηκευμένα δεδομένα εδώ ίσως).

Απαντήθηκε 01/08/2008 στις 17:43
πηγή χρήστη

ψήφοι
11

Θα πρέπει να λείπει το σημείο εδώ, γιατί θα χρησιμοποιήσετε ένα συλλέκτη μέσα σε ένα αντικείμενο για να αποκτήσετε πρόσβαση σε μια ιδιότητα του αντικειμένου;

Λαμβάνοντας αυτό να ολοκληρωθεί ο κτήτορας θα πρέπει να καλέσετε έναν συλλέκτη, η οποία θα πρέπει να καλέσετε έναν συλλέκτη.

Έτσι θα έλεγα ότι μέσα σε μια μέθοδο αντικειμένου πρόσβασης ένα ακίνητο άμεσα, ειδικά βλέποντας και καλεί μια άλλη μέθοδο σε αυτό το αντικείμενο (το οποίο θα έχουν πρόσβαση μόνο απευθείας με το ξενοδοχείο ούτως ή άλλως στη συνέχεια επιστρέφουν αυτό) είναι απλά μια άσκοπη, περιττή η άσκηση (ή έχω παρανοήσει την ερώτηση ).

Απαντήθηκε 04/06/2011 στις 16:42
πηγή χρήστη

ψήφοι
7

θα έλεγα καλύτερα να χρησιμοποιήσετε τις μεθόδων πρόσβασης, ακόμη και εντός του αντικειμένου. Εδώ είναι τα σημεία που έρχονται στο μυαλό μου αμέσως:

1) Θα πρέπει να γίνει προς το συμφέρον της διατήρησης συνοχή με προσβάσεων έξω από το αντικείμενο.

2) Σε ορισμένες περιπτώσεις, οι εν λόγω μεθόδων πρόσβασης θα μπορούσε να κάνει κάτι περισσότερο από την πρόσβαση στο χώρο? θα μπορούσε να κάνει κάποια επιπλέον επεξεργασία (σπάνια του όμως). Αν αυτή είναι η περίπτωση, από την πρόσβαση στο πεδίο άμεσα θα χάσει ότι η πρόσθετη επεξεργασία και το πρόγραμμά σας θα μπορούσε να πάει στραβά, αν η επεξεργασία αυτή είναι πάντα πρέπει να γίνει κατά τη διάρκεια αυτών των προσβάσεων

Απαντήθηκε 20/01/2010 στις 09:32
πηγή χρήστη

ψήφοι
7

Ο τρόπος καθαρεύουσα OO είναι να αποφύγει τα δύο και ακολουθούν το νόμο της Δήμητρας , χρησιμοποιώντας το Στείλτε Μην Ρωτήστε προσέγγιση.

Αντί να πάρει την αξία της περιουσίας του αντικειμένου, το οποίο σφιχτά ζευγάρια των δύο τάξη, χρησιμοποιήστε το αντικείμενο ως παράμετρο π.χ.

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

Σε περίπτωση που το ακίνητο ήταν ένα εγγενές είδος, π.χ. int, χρησιμοποιήστε μια μέθοδο πρόσβασης, το όνομα αυτό για το πρόβλημα χώρου που δεν τον τομέα του προγραμματισμού.

  doSomethingWithProperty( this.daysPerWeek() ) ;

Αυτά θα σας επιτρέψει να διατηρήσει την ενθυλάκωση και οποιαδήποτε μετα-συνθήκες ή εξαρτώνται από σταθερές. Μπορείτε επίσης να χρησιμοποιήσετε τη μέθοδο setter να διατηρήσει οποιαδήποτε προϋποθέσεις ή εξαρτώνται από σταθερές, ωστόσο δεν εμπίπτουν στην παγίδα της ονομασίας τους ρυθμιστές, πηγαίνετε πίσω στο Χόλιγουντ Αρχή για την ονομασία κατά τη χρήση του ιδίωμα.

Απαντήθηκε 24/09/2008 στις 18:04
πηγή χρήστη

ψήφοι
7

Αν η «καθαρεύουσα» που σημαίνει «πιο ενθυλάκωση», τότε συνήθως δηλώνουν όλους τους τομείς μου ως ιδιωτική και στη συνέχεια χρησιμοποιήστε this.field μέσα από την ίδια την τάξη, αλλά όλες οι άλλες κατηγορίες, συμπεριλαμβανομένης υποκατηγορίες, πρόσβαση κράτους παράδειγμα, χρησιμοποιώντας τα κτήτορες.

Απαντήθηκε 22/08/2008 στις 12:15
πηγή χρήστη

ψήφοι
6

Εξαρτάται. Είναι περισσότερο ένα θέμα στυλ από οτιδήποτε άλλο, και δεν υπάρχει κανένας αυστηρός κανόνας.

Απαντήθηκε 01/10/2008 στις 11:51
πηγή χρήστη

ψήφοι
6

Αν δεν θα επεξεργαστείτε το ακίνητο θα χρησιμοποιήσω μια get_property()δημόσια μέθοδο, εκτός αν πρόκειται για μια ειδική περίσταση, όπως ένα mysqli αντικείμενο μέσα σε ένα άλλο αντικείμενο σε αυτή την περίπτωση απλά θα δημόσιας ιδιοκτησία και αναφέρονται σε αυτήν ως $obj->object_property.

Στο εσωτερικό του αντικειμένου είναι πάντα $ this-> ιδιοκτησίας για μένα.

Απαντήθηκε 22/08/2008 στις 12:34
πηγή χρήστη

ψήφοι
6

Ιδιωτική πεδία με δημόσιο ή προστατευμένο ιδιότητες. Η πρόσβαση στις τιμές θα πρέπει να περάσουν από τις ιδιότητες, και να αντιγραφούν σε μια τοπική μεταβλητή αν θα χρησιμοποιηθεί περισσότερο από μία φορά σε μια μέθοδο. Αν και μόνο αν έχετε το υπόλοιπο της εφαρμογής σας, έτσι εντελώς πειραγμένο, συγκλόνισε έξω, και άλλα βελτιστοποιημένη για το πού πρόσβαση σε τιμές που διέρχεται από συσχετιστεί ιδιότητές τους έχει γίνει ένα εμπόδιο (Και αυτό δεν θα συμβεί ποτέ, σας εγγυώμαι) θα πρέπει να αρχίσετε ακόμη να εξετάσει το ενδεχόμενο να αφήσει οτιδήποτε άλλο εκτός από τα ακίνητα που αγγίζουν άμεσα τις μεταβλητές υποστήριξή τους.

.NET προγραμματιστές μπορούν να χρησιμοποιήσουν την αυτόματη ιδιότητες για την επιβολή αυτό επειδή δεν μπορείτε να δείτε ακόμη και τις μεταβλητές υποστήριξη κατά τη σχεδίαση.

Απαντήθηκε 18/08/2008 στις 18:43
πηγή χρήστη

ψήφοι
6

Έχω βρεθεί χρησιμοποιώντας setters / κτήτορες έκανε τον κωδικό μου πιο ευανάγνωστο. Μου αρέσει επίσης ο έλεγχος δίνει όταν άλλες τάξεις χρησιμοποιούν τις μεθόδους και αν μπορώ να αλλάξω τα στοιχεία του ακινήτου θα αποθηκεύσει.

Απαντήθηκε 18/08/2008 στις 18:37
πηγή χρήστη

ψήφοι
6

Μπορώ να είμαι λάθος, γιατί είμαι αυτοδίδακτος, αλλά ποτέ δεν το χρήστη δημοσίων ακινήτων στις τάξεις Java μου, είναι πάντα ιδιωτικές ή προστατεύονται, έτσι ώστε εκτός κώδικας θα πρέπει να έχει πρόσβαση από κτήτορες / setters. Είναι καλύτερα για λόγους συντήρησης / τροποποίηση. Και για εσωτερικό κωδικό τάξη ... Αν η μέθοδος κτήτορας είναι ασήμαντο μπορώ να χρησιμοποιήσω απευθείας με το ξενοδοχείο, αλλά μπορώ να χρησιμοποιήσω πάντα τις μεθόδους setter, γιατί θα μπορούσε εύκολα να προσθέσετε κώδικα στη φωτιά γεγονότα, αν θέλω.

Απαντήθηκε 06/08/2008 στις 15:43
πηγή χρήστη

ψήφοι
5

Μου αρέσει η απάντηση από cmcculloh , αλλά φαίνεται ότι η πιο σωστή είναι η απάντηση από τον Greg Hurlman . Χρησιμοποιήστε κτήτορας / setters όλο το χρόνο, αν ξεκινήσετε τη χρήση τους από την getgo και / ή χρησιμοποιούνται για να συνεργαστώ μαζί τους.

Παρεμπιπτόντως, εγώ προσωπικά βρίσκω ότι η χρήση κτήτορας / setters κάνει ο κώδικας πιο εύκολο να διαβάσει και να διορθώσετε αργότερα.

Απαντήθηκε 15/09/2008 στις 10:46
πηγή χρήστη

ψήφοι
5

Λοιπόν, φαίνεται ότι με την προεπιλεγμένη εφαρμογή C # 3.0 ιδιότητες, η απόφαση λαμβάνεται για σας? Θα πρέπει να ορίσετε την ιδιότητα χρησιμοποιώντας την (ενδεχομένως ιδιωτικών) setter ιδιοκτησίας.

Χρησιμοποιώ προσωπικά μόνο τον ιδιωτικό μέλος-πίσω, όταν δεν το πράττει, θα προκαλέσει το αντικείμενο να πέσει σε λιγότερο από επιθυμητή κατάσταση, όπως κατά την αρχική ρύθμιση ή όταν η προσωρινή αποθήκευση / τεμπέληδες φόρτωση εμπλέκεται.

Απαντήθηκε 01/08/2008 στις 17:56
πηγή χρήστη

ψήφοι
4

Όπως αναφέρεται σε ορισμένα από τα σχόλια: Μερικές φορές θα πρέπει, μερικές φορές δεν πρέπει. Το μεγάλο μέρος για ιδιωτικές μεταβλητές είναι ότι είστε σε θέση να δείτε όλες τις θέσεις αυτές χρησιμοποιούνται όταν αλλάξει κάτι. Αν κτήτορας σας / ρυθμιστής κάνει κάτι που χρειάζεστε, να το χρησιμοποιήσετε. Εάν δεν έχει σημασία αν αποφασίσετε.

Η αντίθετη περίπτωση θα μπορούσε να προβλεφθεί ότι, αν χρησιμοποιείτε το συλλέκτη / setter και κάποιος αλλάζει το συλλέκτη / setter πρέπει να αναλύσει όλα τα μέρη του κτήτορας και ρυθμιστής χρησιμοποιείται εσωτερικά για να δούμε αν βρωμίζει κάτι επάνω.

Απαντήθηκε 01/08/2008 στις 18:01
πηγή χρήστη

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