[C++] Άσκηση 5 - 2015/2016 Προθεσμία 14/11/2015 11:00 μμ

[Thmmy.gr portal]

  Thmmy.gr portal
   Forum
   Downloads
   Ενεργ. Λογαριασμού
   Επικοινωνία
  
  Χρήσιμα links
   Σελίδα τμήματος
   Βιβλιοθήκη Τμήματος
   Elearning
   Φοιτητικά fora
   Πρόγραμμα Λέσχης
   Πρακτική Άσκηση
   Ηλεκτρονική Εξυπηρέτηση Φοιτητών
   Διανομή Συγγραμμάτων
   Ψηφιακό Καταθετήριο Διπλωματικών
   Πληροφορίες Καθηγητών
   Instagram @thmmy.gr
   mTHMMY
  
  Φοιτητικές Ομάδες
   ACM
   Aristurtle
   ART
   ASAT
   BEAM
   BEST Thessaloniki
   EESTEC LC Thessaloniki
   EΜΒ Auth
   IAESTE Thessaloniki
   IEEE φοιτητικό παράρτημα ΑΠΘ
   SpaceDot
   VROOM
   Panther
  

THMMY.gr Web

Helios_MultiScribbles2SMF Default ThemeSMFone_Blue

[Ανεβάζετε τα θέματα των εξετάσεων στον τομέα Downloads]

Είσαι πρωτοετής;... Καλώς ήρθες! Μπορείς να βρεις πληροφορίες εδώ. Βοήθεια για τους καινούργιους μέσω χάρτη.

Κατεβάστε εδώ το Android Application για εύκολη πρόσβαση στο forum.

Ανεβάζετε τα θέματα των εξετάσεων στον τομέα Downloads με προσοχή στα ονόματα των αρχείων!

[Αντιστοίχηση Μαθημάτων ΝΠΣ με ΠΠΣ]

Επίσημη ενημέρωση για Αντιστοίχηση Μαθημάτων ΝΠΣ με ΠΠΣ και η συζήτηση στο forum.

[Apostolof]

γενικά είναι καλό να βάζω στο πρόγραμμα όλες τις συναρτήσεις get και set;

Κατά τη γνώμη μου όχι. Όταν έχεις ένα μέλος κλάσης private και συναρτήσεις set και get ψιλό-χάνεις το νόημα του private σκέλους, καλύτερα δήλωσε το μέλος public και γλύτωσε ένα τόνο κώδικα από setters και getters. Ούτως ή άλλως τα private μέλη αποσκοπούν στη περιορισμένη πρόσβαση, γιατί να έχεις συναρτήσεις set;

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

Public πεδία είναι γενικά ΑΠΑΓΟΡΕΥΤΙΚΑ στην C++ και γενικά στον αντικειμενοστραφή προγραμματισμό , δεν είναι θέμα γνώμης , είναι θέμα design (βλ αρχή του encapsulation). Οπότε, αν θες να είσαι τυπικά σωστός βάζε getters setters όπου χρειάζεται. Επίσης που είδες ότι οι απόψεις διίστανται ??

Δεν λέω ότι τα public πεδία είναι καλός προγραμματισμός. Λέω ότι η μέθοδος private member-setter + getter είναι εξίσου κακός για εμένα. Πάνω σε αυτό διίστανται οι απόψεις. Πως προστατεύεις τα private members σου αν έχεις setters;
Για το που το είδα δε μπορώ να απαντήσω τώρα είμαι από κινητό και βράζουμε τσίπουρα  

[LordOdy]

γενικά είναι καλό να βάζω στο πρόγραμμα όλες τις συναρτήσεις get και set;

Κατά τη γνώμη μου όχι. Όταν έχεις ένα μέλος κλάσης private και συναρτήσεις set και get ψιλό-χάνεις το νόημα του private σκέλους, καλύτερα δήλωσε το μέλος public και γλύτωσε ένα τόνο κώδικα από setters και getters. Ούτως ή άλλως τα private μέλη αποσκοπούν στη περιορισμένη πρόσβαση, γιατί να έχεις συναρτήσεις set;

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

Public πεδία είναι γενικά ΑΠΑΓΟΡΕΥΤΙΚΑ στην C++ και γενικά στον αντικειμενοστραφή προγραμματισμό , δεν είναι θέμα γνώμης , είναι θέμα design (βλ αρχή του encapsulation). Οπότε, αν θες να είσαι τυπικά σωστός βάζε getters setters όπου χρειάζεται. Επίσης που είδες ότι οι απόψεις διίστανται ??

Δεν λέω ότι τα public πεδία είναι καλός προγραμματισμός. Λέω ότι η μέθοδος private member-setter + getter είναι εξίσου κακός για εμένα. Πάνω σε αυτό διίστανται οι απόψεις. Πως προστατεύεις τα private members σου αν έχεις setters;
Για το που το είδα δε μπορώ να απαντήσω τώρα είμαι από κινητό και βάζουμε τσίπουρα 

Σε αυτή την trivial περίπτωση φαίνεται ανούσιο , το καταλαβαίνω. Πες όμως πως θες να βάλεις έναν έλεγχο στην set (πχ μην δέχεσαι τιμές πάνω απο 100 κλπ) . Εκεί αρχίζει και φαίνεται η αναγκαιότητα του encapsulation. Οπότε , από το να λες καθε φορά "Βρε λες να το βάλω Public , το ίδιο είναι",απλά ακολουθείς το design choice και έχεις το κεφάλι σου ήσυχο. Η λογική είναι ότι μια κλάση (και κατ'επεκταση ένα αντικείμενο αυτής) είναι η μόνη υπεύθυνη για τον χειρισμό της μεταβλητής , για να γλυτώνεις περρίσιο κώδικα κλπ κλπ. Καλα τσίπουρα 

[Apostolof]

Σε αυτή την trivial περίπτωση φαίνεται ανούσιο , το καταλαβαίνω. Πες όμως πως θες να βάλεις έναν έλεγχο στην set (πχ μην δέχεσαι τιμές πάνω απο 100 κλπ) . Εκεί αρχίζει και φαίνεται η αναγκαιότητα του encapsulation. Οπότε , από το να λες καθε φορά "Βρε λες να το βάλω Public , το ίδιο είναι",απλά ακολουθείς το design choice και έχεις το κεφάλι σου ήσυχο. Η λογική είναι ότι μια κλάση (και κατ'επεκταση ένα αντικείμενο αυτής) είναι η μόνη υπεύθυνη για τον χειρισμό της μεταβλητής , για να γλυτώνεις περρίσιο κώδικα κλπ κλπ. Καλα τσίπουρα  

Ξαναλέω δε τίθεται θέμα αν τα public πεδία είναι καλός προγραμματισμός, γιατί απλά συμφωνώ ότι δεν είναι. Το θέμα είναι αν θα πρέπει κάθε μεταβλητή να έχει μια setter και μια getter συνάρτηση. Ειδικά setter πιστεύω ότι δε πρέπει να έχει και μάλιστα καλό θα είναι να αποφεύγεται όπου είναι δυνατόν.

http://www.artima.com/intv/goldilocks2.html
Bjarne Stroustrup: "Going to the big class hierarchy is again, you write more code than you need to, and you get too much connection between different parts. I particularly dislike classes with a lot of get and set functions. That is often an indication that it shouldn't have been a class in the first place. It's just a data structure. And if it really is a data structure, make it a data structure."

http://typicalprogrammer.com/doing-it-wrong-getters-and-setters/
“Python is not Java” Phillip J. Eby: "Getters and setters are evil. Evil, evil, I say! Python objects are not Java beans. Do not write getters and setters. This is what the ‘property’ built-in is for. And do not take that to mean that you should write getters and setters, and then wrap them in ‘property’. That means that until you prove that you need anything more than a simple attribute access, don’t write getters and setters."

Επίσης ούτε η c++ είναι η java.

Καλά ήταν τα τσίπουρα!!