Αντικειμενοστρεφής Προγραμματισμός: Σε όρους απλούς, ποια είναι η διαφορά μεταξύ αφαίρεσης, εγκλεισμού και κρυπτογράφησης πληροφοριών;


Απάντηση 1:

Είναι δύσκολο να παράσχετε μια εξήγηση απλού ανθρώπου με τον κώδικα. ;-)

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

Το ίδιο το κιβώτιο αντιπροσωπεύει μια καψυλίωση, αλλά δεν απαιτεί την ετικέτα.

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


Απάντηση 2:

Σε όρους OOP, η αφαίρεση λαμβάνει χώρα στα μηνύματα που μεταφέρονται μεταξύ αντικειμένων. Πιο συγκεκριμένα, αυτό δημιουργείται μέσω της δημιουργίας διεπαφών. Αυτό που βρίσκω με κάποιες από τις άλλες απαντήσεις είναι ότι συνδυάζουν μια διεπαφή με την εγκαψούλωση. Νομίζω ότι αυτός είναι ο λανθασμένος τρόπος να το εξετάσουμε. Μια διεπαφή αντιπροσωπεύει ένα σταθερό σύστημα συμπεριφοράς, αλλά δεν πηγαίνει με ένα συγκεκριμένο είδος αντικειμένου. Η ισχυρή ιδέα του OO είναι να σκεφτόμαστε αντικείμενα όπως είναι οι υπολογιστές, με την αρχή ότι οποιοσδήποτε υπολογιστής μπορεί να μιμηθεί οποιοδήποτε άλλο υπολογιστή. Οι διεπαφές είναι σαν πρωτόκολλα επικοινωνίας μεταξύ των υπολογιστών, με την προσδοκία ότι αν το αντικείμενο Α χρησιμοποιεί μια διεπαφή για επικοινωνία με το αντικείμενο B, το οποίο χρησιμοποιεί τη διασύνδεση C, το αντικείμενο Α θα πρέπει να μπορεί να αναμένει την ίδια συμπεριφορά, στο μέτρο που αυτό αφορά, με το Β καθώς θα χρησιμοποιούσε τη διασύνδεση C με ένα άλλο αντικείμενο D (υποθέτοντας ότι το D εφαρμόζει και το C).

Για να χρησιμοποιήσετε το παράδειγμα του Jack Menendez, εάν διαθέτετε μια διεπαφή που περιέχει μεθόδους για το Open and Close, θα μπορούσαμε να γενικεύσουμε την έννοια στο "Portal" ή κάτι τέτοιο. Με αυτόν τον τρόπο ένα αντικείμενο πόρτας θα μπορούσε να υλοποιήσει την πύλη, αλλά θα μπορούσε να φτιάξει ένα ψυγείο, ένα CarDoor ή ακόμα και ένα φρεάτιο, αλλά η πύλη θεωρείται ότι είναι μια διεπαφή, που αντιπροσωπεύει ένα σταθερό σύστημα συμπεριφοράς στο οποίο μπορούν να εγγραφούν οι κλάσεις. Κάθε κλάση παρέχει τη δική της εφαρμογή αυτής της διασύνδεσης.

Σχετικά με. ενθυλάκωση και κρυπτογράφηση πληροφοριών

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

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

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

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

Εάν εκτεθεί η διεπαφή, σε μια κλάση, ή μια αλλαγή κατάστασης αλλάζει τη συμπεριφορά ενός αντικειμένου, ο συνολικός σκοπός της αφαίρεσης είναι αποτυχημένος. Η συνέπεια αυτού είναι ότι τα αντικείμενα που χρησιμοποιούν τη διεπαφή για να επικοινωνούν με άλλα αντικείμενα δεν μπορούν να υπολογίζουν σε συνεπή συμπεριφορά με αυτό και έτσι τα αντικείμενα θα πρέπει να ελέγξουν για τους τύπους των αντικειμένων που κρατούν και θα πρέπει είτε να δοκιμάσουν ένα αντικείμενο πριν προχωρήσουν, ή θα πρέπει να κάνουν υποθέσεις, βάσει του τύπου ενός αντικειμένου, αν η συμπεριφορά ενός αντικειμένου πρόκειται να αλλάξει. Θα πρέπει να πουν: "Παρόλο που ξέρω ότι αυτό το αντικείμενο έχει interface X, πρέπει να ξέρω αν είναι πραγματικά ένα αντικείμενο Α ή ένα αντικείμενο Β". Αυτό θέλεις να αποφύγεις.

Μπορεί να προχωράω από αυτό που ζητούσατε, αλλά στο OOP υπάρχει αυτή η σημαντική ιδέα του "προγραμματισμού σε μια διεπαφή". Μια βέλτιστη πρακτική που έχω ακούσει για την επιβολή αυτού σε δημοφιλείς γλώσσες είναι η χρήση της λεγόμενης "στατικής μεθόδου εργοστασίου" σε συνδυασμό με αυτό που ονομάζεται "ιδιωτικός κατασκευαστής" σε μια τάξη. Σκέφτομαι C ++, C # και Java γι 'αυτό. Οι προγραμματιστές Ruby μπορεί να έχουν διαφορετικό τρόπο να το κάνουν αυτό. Η εργοστασιακή μέθοδος είναι μια δημόσια στατική μέθοδος που επιστρέφει έναν κατάλληλο τύπο διεπαφής και καλεί έναν κατασκευαστή στην ίδια κλάση που είναι ιδιωτικός, για να δημιουργήσει ένα στιγμιότυπο του εαυτού του. Με αυτόν τον τρόπο, κάθε προγραμματιστής που χρησιμοποιεί την κλάση αναγκάζεται να χρησιμοποιήσει τον κατάλληλο τύπο διεπαφής, αντί για τον τύπο της κλάσης, όταν δηλώνει μια αναφορά / δείκτη σε μια νέα παρουσία.


Απάντηση 3:

Σε όρους OOP, η αφαίρεση λαμβάνει χώρα στα μηνύματα που μεταφέρονται μεταξύ αντικειμένων. Πιο συγκεκριμένα, αυτό δημιουργείται μέσω της δημιουργίας διεπαφών. Αυτό που βρίσκω με κάποιες από τις άλλες απαντήσεις είναι ότι συνδυάζουν μια διεπαφή με την εγκαψούλωση. Νομίζω ότι αυτός είναι ο λανθασμένος τρόπος να το εξετάσουμε. Μια διεπαφή αντιπροσωπεύει ένα σταθερό σύστημα συμπεριφοράς, αλλά δεν πηγαίνει με ένα συγκεκριμένο είδος αντικειμένου. Η ισχυρή ιδέα του OO είναι να σκεφτόμαστε αντικείμενα όπως είναι οι υπολογιστές, με την αρχή ότι οποιοσδήποτε υπολογιστής μπορεί να μιμηθεί οποιοδήποτε άλλο υπολογιστή. Οι διεπαφές είναι σαν πρωτόκολλα επικοινωνίας μεταξύ των υπολογιστών, με την προσδοκία ότι αν το αντικείμενο Α χρησιμοποιεί μια διεπαφή για επικοινωνία με το αντικείμενο B, το οποίο χρησιμοποιεί τη διασύνδεση C, το αντικείμενο Α θα πρέπει να μπορεί να αναμένει την ίδια συμπεριφορά, στο μέτρο που αυτό αφορά, με το Β καθώς θα χρησιμοποιούσε τη διασύνδεση C με ένα άλλο αντικείμενο D (υποθέτοντας ότι το D εφαρμόζει και το C).

Για να χρησιμοποιήσετε το παράδειγμα του Jack Menendez, εάν διαθέτετε μια διεπαφή που περιέχει μεθόδους για το Open and Close, θα μπορούσαμε να γενικεύσουμε την έννοια στο "Portal" ή κάτι τέτοιο. Με αυτόν τον τρόπο ένα αντικείμενο πόρτας θα μπορούσε να υλοποιήσει την πύλη, αλλά θα μπορούσε να φτιάξει ένα ψυγείο, ένα CarDoor ή ακόμα και ένα φρεάτιο, αλλά η πύλη θεωρείται ότι είναι μια διεπαφή, που αντιπροσωπεύει ένα σταθερό σύστημα συμπεριφοράς στο οποίο μπορούν να εγγραφούν οι κλάσεις. Κάθε κλάση παρέχει τη δική της εφαρμογή αυτής της διασύνδεσης.

Σχετικά με. ενθυλάκωση και κρυπτογράφηση πληροφοριών

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

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

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

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

Εάν εκτεθεί η διεπαφή, σε μια κλάση, ή μια αλλαγή κατάστασης αλλάζει τη συμπεριφορά ενός αντικειμένου, ο συνολικός σκοπός της αφαίρεσης είναι αποτυχημένος. Η συνέπεια αυτού είναι ότι τα αντικείμενα που χρησιμοποιούν τη διεπαφή για να επικοινωνούν με άλλα αντικείμενα δεν μπορούν να υπολογίζουν σε συνεπή συμπεριφορά με αυτό και έτσι τα αντικείμενα θα πρέπει να ελέγξουν για τους τύπους των αντικειμένων που κρατούν και θα πρέπει είτε να δοκιμάσουν ένα αντικείμενο πριν προχωρήσουν, ή θα πρέπει να κάνουν υποθέσεις, βάσει του τύπου ενός αντικειμένου, αν η συμπεριφορά ενός αντικειμένου πρόκειται να αλλάξει. Θα πρέπει να πουν: "Παρόλο που ξέρω ότι αυτό το αντικείμενο έχει interface X, πρέπει να ξέρω αν είναι πραγματικά ένα αντικείμενο Α ή ένα αντικείμενο Β". Αυτό θέλεις να αποφύγεις.

Μπορεί να προχωράω από αυτό που ζητούσατε, αλλά στο OOP υπάρχει αυτή η σημαντική ιδέα του "προγραμματισμού σε μια διεπαφή". Μια βέλτιστη πρακτική που έχω ακούσει για την επιβολή αυτού σε δημοφιλείς γλώσσες είναι η χρήση της λεγόμενης "στατικής μεθόδου εργοστασίου" σε συνδυασμό με αυτό που ονομάζεται "ιδιωτικός κατασκευαστής" σε μια τάξη. Σκέφτομαι C ++, C # και Java γι 'αυτό. Οι προγραμματιστές Ruby μπορεί να έχουν διαφορετικό τρόπο να το κάνουν αυτό. Η εργοστασιακή μέθοδος είναι μια δημόσια στατική μέθοδος που επιστρέφει έναν κατάλληλο τύπο διεπαφής και καλεί έναν κατασκευαστή στην ίδια κλάση που είναι ιδιωτικός, για να δημιουργήσει ένα στιγμιότυπο του εαυτού του. Με αυτόν τον τρόπο, κάθε προγραμματιστής που χρησιμοποιεί την κλάση αναγκάζεται να χρησιμοποιήσει τον κατάλληλο τύπο διεπαφής, αντί για τον τύπο της κλάσης, όταν δηλώνει μια αναφορά / δείκτη σε μια νέα παρουσία.