Θέματα ΟΕΦΕ 2022

[evry]

Συμφωνώ ότι σαν πρώτη σκέψη είναι λάθος.

Αλλά έχω την εξής δεύτερη σκέψη:
Το ότι δεν αναγράφονται οι ιδιότητες της κλάσης Α στην κλάση Β δεν σημαίνει ότι δεν είναι ιδιότητες της κλάσης Β (προφανώς δεν αναγράφονται στην κλάση Β γιατί κληρονομούνται).
Μήπως θα έπρεπε η πρόταση να είναι «Ένα αντικείμενο της κλάσης Β θα έχει μόνο τις ιδιότητες και τις μεθόδους που αναγράφονται στην κλάση Β»;

Εξάλλου αν δεχτούμε την 8η πρόταση ως σωστή, γιατί η 6η να είναι λάθος;

Πολύ σωστή παρατήρηση. Το συγκεκριμένο ΣΛ είναι απαράδεκτο, αφού η Β κληρονομεί από την Α και προφανώς θα έχει και όλα όσα έχει η Α. Αν μιλάγαμε για Private και Protected ίσως να είχε κάποιο νόημα αλλά και πάλι ελέγχεται.
Ήθελε άλλη διατύπωση.
Το έσωσαν με την λέξη μόνο, ώστε όλοι να καταλάβουν τι εννοούν αλλά και πάλι δεν είναι σωστό.

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

[gthal]

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

Στο παράδειγμα σου με τη λίστα η μία Εισαγωγή πολυμορφίζει την άλλη.
Δες στον παρακάτω κώδικα (μη υπαρκτής αλλά pythonοειδούς γλώσσας προγραμματισμού) τι πλεονέκτημα έχει αυτό:

Από το παράδειγμά σου κατάλαβα αμέσως δύο πράγματα.

• είναι ζήτημα ορισμού (δηλ αν θα ονομάσω την επίμαχη περίπτωση πολυμορφισμό ή όχι - και εν τέλει είναι απλά θεωρητικό ζήτημα, γιατί αν ο προγραμματιστής "θέλει" την ευκολία τού να έχει δύο μεθόδους με το ίδιο όνομα σε ασυσχέτιστες κλάσεις και αν αυτό μπορεί να το κάνει αφ' ενός και δουλεύει αφ' ετέρου, ποσώς τον ενδιαφέρει αν είναι πολυμορφισμός ή όχι)
• ανήκουμε σε διαφορετικές "σχολές": εγώ είμαι επηρεασμένος κατά βάση από την Java, ενώ εσύ μάλλον από την python. Και είναι γεγονός ότι το παράδειγμά σου θα δούλευε στην python αλλά όχι στην Java. 

Η λίστα των δύο Λιστών που φτιάχνεις (παρακάτω τη λέω "μεγάλη" λίστα) θα ήταν αποδεκτή στην python, νομίζω χάρη στην χαλαρότητά της με τους τύπους.
Η Java δεν θα άφηνε να φτιάξουμε μια τέτοια λίστα, με αντικείμενα διαφορετικού τύπου. Θα μας "ανάγκαζε" λοιπόν να δούμε τις δύο λίστες μας (ταξινομημένη και αταξινόμητη) ως υποκλάσεις ενός κοινού τους προγόνου (το οποίο κάνει και πολύ νόημα, μιας και οι Λίστες μας δεν είναι άσχετα πράγματα αλλά έχουν ειδοποιούς ομοιότητες). Ο κοινός αυτός πρόγονος θα όριζε πως κάθε μέλος του θα διαθέτει μια μέθοδο εισαγωγή (την οποία κάθε μέλος μπορεί να πολυμορφίσει αν θέλει) και για αυτό και μόνο το λόγο θα μπορούσε να κληθεί η εισαγωγή σε κάθε αντικείμενο της "μεγάλης" μας λίστας. Αν δεν ορίσουμε έναν κοινό τους πρόγονο με αυτό το χαρακτηριστικό, και ο άμεσος κοινός τους πρόγονος θεωρηθεί το Object (δηλαδή προστεθούν οι δύο λίστες στην "μεγάλη" λίστα ως Objects), δεν θα είναι δυνατή η κλήση στην εισαγωγή, παρότι την διαθέτουν και οι δύο, γιατί δεν είναι ορατή αν τα βλέπουμε ως απλά Objects.
Ανέτρεξα τελικά στη βιβλιογραφία 
Πώς ορίζεται τελικά ο πολυμορφισμός;; Πρέπει να σου πω ότι τα πρώτα 7-8 άρθρα που διάβασα έλεγαν αυτό που λέω εγώ (είναι πάντα μια προγονική μέθοδος η οποία υπερκαλύπτεται) κι ετοιμαζόμουν να σου πω ότι κάνεις λάθος. Αυτά τα άρθρα είχαν αναφορές σε java, c++, c# και 1-2 άλλες γλώσσες που δεν θυμάμαι τώρα και έχασα τα tabs. Τελικά αναζήτησα συγκεκριμένα για τον πολυμορφισμό στην python και βρήκα όντως άρθρο που αναφέρει και την περίπτωση που λες κι εσύ. Σωστά και τα δύο λοιπόν! Αναλόγως σε ποια "σχολή" είσαι.
Δεν θα αποφύγω να πω όμως δυο λόγια υπέρ της "αυστηρής" σχολής 
Έχω βλαστημήσει τη java άπειρες φορές που δε με άφηνε να κάνω αυτό που διαισθητικά ήθελα! Τελικά την ευγνωμονώ γιατί με ανάγκασε να καταλάβω καλύτερα τι κάνω. Και τελικά πάντα υπήρχε ένας τρόπος να το κάνω. Πιο σωστός και πιο δομημένος. Όπως ακριβώς βλαστημούσα τον δομημένο προγραμματισμό όταν τον πρωτοδιδάχτηκα, μαθημένος-αυτοδίδακτος στην "ελευθερία" της BASIC και της GOTO. Κάποια στιγμή αντιλήφθηκα τη μαγεία του και πόσο νόημα έχει να υποχρεωθείς να μείνεις στη δομή. Και πάντα υπήρχε ο τρόπος να γίνει αυτό που ήθελα. Και σωστότερα!
Από την άλλη, η python μου έχει λύσει προβλήματα "γρήγορα και βρώμικα" (δόξα τω Θεώ), πολλές φορές μάλιστα χωρίς να καταλαβαίνω ακριβώς τι κάνω, και δε με νοιάζει γιατί δεν σκοπεύω να επανέλθω. Με νοιάζει που δούλεψε χωρίς να με ταλαιπωρήσει. Δε μπορώ όμως να διανοηθώ πώς θα μπορούσα να βρω άκρη στον ίδιο τον δικό μου κώδικα αν έγραφα ένα μεγάλο πρόγραμμα και συνέχιζα να εκμεταλλεύομαι τις ελευθερίες που παρέχει. (γιαυτό και έχω δεύτερες σκέψεις αν είναι καλή γλώσσα για τον αρχάριο που δομεί τη γνώση του σε όλα αυτά- κλείνει η παρένθεση)
Θέλω να καταλήξω στο ότι υπάρχει καλή και "λιγότερο καλή" αντικειμενοστραφής σχεδίαση. Μια καλή σχεδίαση προκύπτει από καλή κατανόηση των σχέσεων των κλάσεών μας, των αλληλεξαρτήσεων και φυσικά των συνεργασιών τους. Διαφορετικά μπορεί να καταλήξει το πρόγραμμά μας να είναι ένας σωρός από κλάσεις και αντικείμενα σκόρπια και "ξέμπαρκα" που με κάποιον τρόπο προσπαθούν να συνεργαστούν μεταξύ τους.
Η 1η υλοποίηση στο σχήμα που είχα στείλει είναι καλύτερη από τη 2η και ακόμα καλύτερη από κάποια 3η στην οποία δεν θα είχαμε καν κοινό πρόγονο στα δύο είδη Λιστών μας. Ο 1ος προγραμματιστής έχει καταλάβει καλύτερα από τους άλλους δύο (και έχει αξιοποιήσει) τις σχέσεις και την ειδοποιό ομοιότητα των αντικειμένων του. Έχει καταλάβει πως υπάρχει αιτίαση για τις κοινές μεθόδους και τα ονόματά τους (και δεν τα αντιμετώπισε ως "συμπτώσεις", που επιμένω να το λέω για να γίνει κατανοητό τι εννοώ). Ο κώδικας του 1ου, θα είναι πολύ πιο εύκολος στο να αλλαχθεί, να διορθωθεί και να επεκταθεί χωρίς να προκύψουν bugs, σε αντίθεση με των άλλων δύο, που σε κάθε αλλαγή θα τρέμει το φυλλοκάρδι τους, μην τυχόν ξεχάσουν να ενημερώσουν κατάλληλα και τις άλλες υποκλάσεις.
Δε θα μπορούσα να συμφωνώ περισσότερο με αυτό που λες εδώ, γιαυτό και λέω όσα λέω

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

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

[bagelis]

 Απολαυστική η κουβέντα σας, σε συζητήσεις με ανθρώπους που ξέρουν τον αντικειμενοστραφή καλύτερα από εμένα άκουσα τις ίδιες απόψεις, το πιο καθαρό και δομημένο είναι ότι όντως ο πολυμορφισμός προϋποθέτει κληρονομικότητα,
 στο παράδειγμα με τις λίστες

Α=νέα ΜηΤαξινομένηΛιστα()
Β=νέα ΤαξινομημένηΛιστα()
Για χ σε [Α,Β]
   Για υ σε [9,8,7,6,5]
      χ.Εισαγωγη(υ)

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

[isle]

Γεια σας.
Θα ήθελα να ρωτήσω αν και πού μπορούμε να βρούμε τις λυσεις γι τα θέματα ΟΕΦΕ 2022.
Ευχαριστώ

[Νίκος Αδαμόπουλος]

Μπορούμε να έχουμε πολυμορφισμό χωρίς κληρονομικότητα.
Πχ. με interfaces όπως στη Java αλλά και με overloading όπως κάνει πχ. η Python στους τελεστές.

H C++ έχει πολυμορφισμό ακόμα και σε επίπεδο απλών functions, δηλαδή χωρίς κατ' ανάγκη να γίνεται λόγος για κλάσεις, κληρονομικότητες κλπ. Π.χ. μπορούμε να έχουμε με το ίδιο όνομα:

int megalyteros(int a, int b);
int megalyteros(int a, int b, int c);
double megalyteros(double a, double b);

κλπ, στο ίδιο πρόγραμμα.

Γενικά συμφωνώ με τον pgrontas...