Εαν για παραδειγμα εχουμε μια κλαση με 10 private variables, θα πρεπει να φτιαξουμε αντιστοιχα 10 getters & 10 setters για καθε variable? δεν ειναι λιγο υπερβολικο κατι τετοιο απο αποψη ογκου του κωδικα;
getters/setters
Απάντηση: getters/setters
Όχι δεν είναι. Υπάρχει άλλος τρόπος να αλλάξεις ή να διαβάσεις την τιμή κάποιας μεταβλητής μέλους αφού έχεις δημιουργήσει και αρχικοποιήσει το αντικείμενο;
ΝΠ
ΝΠ
Απάντηση: getters/setters
για να διαβασεις οχι αλλα για να θεσεις δεν αρκει ενας μονο constructor; φτιαχνεις το αντικειμενο σου και ...αχμφ εκτος και αν θελουμε να αλλαξουμε κατι..οκ οκ θεμιτο :-P
Απάντηση: getters/setters
Νομίζω ήμουν σαφής, αφότου έχεις φτιάξει το αντικείμενο. Αν δεν έχεις setters δε μπορείς να αλλάξεις τις τιμές των μεταβλητών και αν δεν έχεις setters δε μπορείς να επιστρέψεις τις τιμές τους, period!
Οι περιπτώσεις που μπορεί να μη χρειάζεται να γράψεις getters/setters για κάποια μεταβλητή μέλος είναι ελάχιστες.
ΝΠ
Οι περιπτώσεις που μπορεί να μη χρειάζεται να γράψεις getters/setters για κάποια μεταβλητή μέλος είναι ελάχιστες.
ΝΠ
Απάντηση: getters/setters
Η όλη ιστορία με τους getters/setters μου φαίνεται λίγο τσάμπα κόπος, σαν να κάνουμε κύκλο. Δηλαδή πρώτα κρύβουμε τις μεταβλητές με την private και μετά τις ξανααποκαλύπτουμε με τους getters/setters. Τι δεν κατάλαβα καλά; 
Γιατί τότε να μην πούμε τις μεταβλητές ως public εξαρχής και να τελειώνουμε;
Γιατί τότε να μην πούμε τις μεταβλητές ως public εξαρχής και να τελειώνουμε;
Απάντηση: getters/setters
Γεια σου Παναγιώτη,
δεν είσαι ο πρώτος που εκφράζει αυτή την απορία. Οι getters/setters είναι εξαιρετικά χρήσιμες γιατί μας δίνουν τη δυνατότητα να δίνουμε ελεγχόμενη πρόσβαση στις μεταβλητές μέλη.
Σκέψου για παράδειγμα πως σε μία κλάση Vehicle έχεις μια μεταβλητή μέλος τύπου int που καταγράφει την ταχύτητα και ονομάζεται velocity και έστω πως η μεταβλητή αυτή δε μπορεί να πάρει αρνητικές τιμές. Αν την είχες δηλώσει public τότε ο οποιοσδήποτε χρησιμοποιήσει την κλάση αυτή μπορεί να πειράξει την τιμή της με το χέρι και να θέσει ακόμη και αρνητικές τιμές. Κάνοντάς την private και υλοποιώντας την αντίστοιχη setter να ελέγχει την τιμή πριν την εκχωρήσει αποφεύγεις τέτοιου είδους προβλήματα.
Θα μου πεις πως θα μπορούσε ο προγραμματιστής να κάνει τον έλεγχο αυτόν και πριν εκχωρήσει την τιμή με το χέρι αλλά στην περίπτωση αυτή θα πρέπει να κάνει την ίδια διαδικασία κάθε φορά που θέλει να αλλάξει την τιμή της velocity, πράγμα όχι και τόσο αποδοτικό αφού επαναλαμβάνεται ο κώδικας.
Με την αντίστοιχη setter απλά περνάει ως παράμετρο τη νέα τιμή και αν αυτή περάσει τον έλεγχο εγκυρότητας θα εκχωρηθεί κανονικά, διαφορετικά θα προβληθεί κάποιο μήνυμα που θα ενημερώνει για το σφάλμα, που είναι σαφώς καλύτερος χειρισμός. Στα παραδείγματα των σημειώσεων καθώς και στις εργασίες για λόγους απότητας έχει παραλειφθεί ο κώδικας ελέγχου εγκυρότητας τιμών, σε ένα πραγματικό όμως project στις περισσότερες κλάσεις ο κώδικας αυτός υπάρχει.
Σε γενικές γραμμές, στον αντικειμενοστρεφή προγραμματισμό επιθυμούμε να παρέχουμε ελεγχόμενη πρόσβαση στις τιμές των μεταβλητών μελών και όχι ανεξέλεγκτη που μπορεί να οδηγήσει σε κάθε λογής λάθη. Στο επόμενο κεφάλαιο που θα μιλήσουμε και για κληρονομικότητα θα δεις πως όταν έχουμε μια μεγάλη ιεραρχία κλάσεων, η σωστή υλοποίηση των getters/setters και των constructors είναι η καλύτερη λύση για να αρχικοποιούμε τα αντικείμενά μας με σωστές τιμές.
ΝΠ
δεν είσαι ο πρώτος που εκφράζει αυτή την απορία. Οι getters/setters είναι εξαιρετικά χρήσιμες γιατί μας δίνουν τη δυνατότητα να δίνουμε ελεγχόμενη πρόσβαση στις μεταβλητές μέλη.
Σκέψου για παράδειγμα πως σε μία κλάση Vehicle έχεις μια μεταβλητή μέλος τύπου int που καταγράφει την ταχύτητα και ονομάζεται velocity και έστω πως η μεταβλητή αυτή δε μπορεί να πάρει αρνητικές τιμές. Αν την είχες δηλώσει public τότε ο οποιοσδήποτε χρησιμοποιήσει την κλάση αυτή μπορεί να πειράξει την τιμή της με το χέρι και να θέσει ακόμη και αρνητικές τιμές. Κάνοντάς την private και υλοποιώντας την αντίστοιχη setter να ελέγχει την τιμή πριν την εκχωρήσει αποφεύγεις τέτοιου είδους προβλήματα.
Θα μου πεις πως θα μπορούσε ο προγραμματιστής να κάνει τον έλεγχο αυτόν και πριν εκχωρήσει την τιμή με το χέρι αλλά στην περίπτωση αυτή θα πρέπει να κάνει την ίδια διαδικασία κάθε φορά που θέλει να αλλάξει την τιμή της velocity, πράγμα όχι και τόσο αποδοτικό αφού επαναλαμβάνεται ο κώδικας.
Με την αντίστοιχη setter απλά περνάει ως παράμετρο τη νέα τιμή και αν αυτή περάσει τον έλεγχο εγκυρότητας θα εκχωρηθεί κανονικά, διαφορετικά θα προβληθεί κάποιο μήνυμα που θα ενημερώνει για το σφάλμα, που είναι σαφώς καλύτερος χειρισμός. Στα παραδείγματα των σημειώσεων καθώς και στις εργασίες για λόγους απότητας έχει παραλειφθεί ο κώδικας ελέγχου εγκυρότητας τιμών, σε ένα πραγματικό όμως project στις περισσότερες κλάσεις ο κώδικας αυτός υπάρχει.
Σε γενικές γραμμές, στον αντικειμενοστρεφή προγραμματισμό επιθυμούμε να παρέχουμε ελεγχόμενη πρόσβαση στις τιμές των μεταβλητών μελών και όχι ανεξέλεγκτη που μπορεί να οδηγήσει σε κάθε λογής λάθη. Στο επόμενο κεφάλαιο που θα μιλήσουμε και για κληρονομικότητα θα δεις πως όταν έχουμε μια μεγάλη ιεραρχία κλάσεων, η σωστή υλοποίηση των getters/setters και των constructors είναι η καλύτερη λύση για να αρχικοποιούμε τα αντικείμενά μας με σωστές τιμές.
ΝΠ
Απάντηση: getters/setters
Αν κατάλαβα καλά, στο παράδειγμα με τη vehicle και τη velocity που ανέφερες, το θέμα είναι να βάζαμε στον setter ένα "if(velocity<0) τότε μην της αλλάξεις την τιμή" (σε ελεύθερη απόδοση). Είδα στο βιβλίο στο 3ο κεφάλαιο το παράδειγμα "Account" που έχει συνθήκη ο αρχικός τραπεζικός λογαριασμός (initialBalance) να είναι θετικός, αλλιώς να μην αλλάξει η μεταβλητή μέλος balance. Φαντάζομαι αυτό εννοείς, αυτός όμως βάζει τη συνθήκη στον constructor.
Απάντηση: getters/setters
Σωστά, o κώδικας ελέγχου εγκυρότητας τιμών μπαίνει και στους constructors και στις setters, οπουδήποτε δηλαδή γίνεται εκχώρηση τιμών στις μεταβλητές μέλη.
Στο βιβλίο για κάποιον λόγο (κακώς) οι getters/setters αναλύονται ελάχιστα, βέβαια υπάρχει ένα σχόλιο που λέει πως θα πρέπει να τις δημιουργούμε σε κάθε κλάση.
ΝΠ
Στο βιβλίο για κάποιον λόγο (κακώς) οι getters/setters αναλύονται ελάχιστα, βέβαια υπάρχει ένα σχόλιο που λέει πως θα πρέπει να τις δημιουργούμε σε κάθε κλάση.
ΝΠ