Κυριακή 10 Απριλίου 2011

Αντικειμενοστραφή πρότυπα.


Έχουμε κάναν java-άνθρωπο, ή C++άνθρωπο στο ακροατήριο; Θέλω να πω κάτι προγραμματιστικά τώρα. Όπου δηλαδή εγκαταλείψτε κάθε ελπίδα οι μή καλωδιωμένοι, ή για να το πω αλλοιώς (αφού την πάτησε ο καϋμένος ο aizen):

Ουδείς ακαλωδίωτος εισήτω!


(όπως λέμε spoiler alert αλλλά από την ανάποδη!)

Λοιπόν, πολύ σύντομη ανακεφαλαίωση, τα ξέρεις αυτά. Τα αντικειμενοστραφή πρότυπα, τα design patterns της Gang of Four, είναι το εξής. Έχεις μια δομή που υποτίθεται οτι είναι ιδανική για το πρόγραμμά σου, στο πλαίσιο μιας άλφα λειτουργικότητας που θες να έχει. Και δεν υποτίθεται απλώς, είναι. Και τη χρησιμοποιείς ως πρότυπο για συστήματα που έχουνε παρόμοιες λειτουργίες.

Παρατηρώ λοιπόν πως αν έχεις μια δομή κώδικά κι απλώς αλλάζεις κάθε φορά τα στοιχεία που την αποτελούν, στην πράξη ξαναχρησιμοποιείς τον παλιό σου κώδικα. Αν έχεις δηλαδή ένα pattern και απλά του αλλάζεις τα αντικείμενα, κι αν έχεις ένα παλιό σου πρόγραμμα και το κάνεις copy-paste και του αλλάξεις όνομα στις τάξεις, ε, το ίδιο πράγμα είναι. Κι εδώ που τα λέμε αν έχεις μια εφαρμογή, πχ, του Abstract Factory, δε θα κάτσεις να το ξαναγράψεις από την αρχή... θα το κάνεις copy-paste στην καινούργια εφαρμογή. Και υποτίθεται πως όλη η ιστορία με τον αντικειμενοστραφή προγραμματισμό (εντάξει, όχι όλη- ένα μεγάλο μέρος όμως) είναι οτι αποφεύγεις την επαναχρησιμοποίηση του κώδικα, το code reuse, κακώς εννοούμενο.

Λοιπόν, εφ' όσον έχεις μια δομή που κάνει τη δουλειά που θες, γιατί δεν την γενικεύεις, να την κάνεις γλώσσα και να ξεμπερδεύεις; Αυτό που θέλω να πω είναι, πιάνουμε τα patterns, πόσα είναι; Τόσα. Να τ' αφήσω. Τα εκφράζουμε ως σύνταξη. Και γίνονται τα στοιχεία της καινούργιας μας γλώσσας, της, πχ, Pattern Oriented Language. Και μετά για να προγραμματίσουμε σ' αυτήν, διαλέγουμε ένα pattern, εκφράζουμε τη δομή του στη γλώσσα μας και προσθέτουμε τη δική μας ντάτα- και ασχολείται το pattern με την χαμηλού επιπέδου λειτουργικότητα και πώς να τη διεκπεραιώσει.

Παράδειγμα (εντελώς άψαχτο, σόρυ):

pattern(Abstract_factory, Concrete_factories, Abstract_products, Concrete_products).

Όπου Abstract_factory είναι μια λίστα με τα χαρακτηριστικά του προτύπου, και Concrete_factories, Abstract_products, Concrete_products είναι λίστες (ή άλλες δομές) με την πληροφορία που χρειάζεται το abstract_factory πρότυπο για να λειτουργήσει. Αυτό δηλαδή που θα είχες ως τάξη στην γλώσσα σου, java, C++ κλπ. Αντί να τα εκφράσεις ως μέθοδους και τάξεις, του τα περνάς ως παράμετρους και σου μένει χρόνος να σερφάρεις στο ίντερνετ. Αυτό λέω. Αφήνεις τον υπολογιστή να κάνει τη χαμαλοδουλειά- γι' αυτό δεν τους έχουμε;

Αυτό είναι που κάνουμε και με τις μέθoδους και τις τάξεις. Η μέθοδος είναι μια δομή για τη ντάτα σου, η τάξη είναι μια δομή για τις μεθόδους σου. Κι έτσι προχωράμε προς τις γλώσσες προγραμματισμού υψηλότερου επιπέδου, διαρκώς οργανώνοντας και αφαιρώντας. Οργανώνουμε την πληροφορία μας σε όλο και γενικότερα σχήματα και κάποτε θα φτάσουμε και στην πλήρη φυσική γλώσσα. Για να πετύχουμε τον απώτερο σκοπό, το φωτεινό όραμα, τη μεγάλη υπόσχεση της πληροφορικής, να λες στο πρόγραμμά σου "φτιάξε ένα φραπέ" και να σου απαντάει "Τί χρώμα καλαμάκι και με πόσες ρίγες;".

(Αυτό αν γουστάρει- αν δεν γουστάρει θα σου πετάει το βάζο με το νεσκαφέ στο κεφάλι).

6 σχόλια:

Ο χρήστης Blogger stassa είπε...

Αυτό, άκου να δεις πώς μου ήρθε τώρα, διάβαζα αυτό το γνωστό αρθράκι:

http://www.paulgraham.com/icad.html

... και προς το τέλος, μετά από ένα μεγαλειώδες λογύδριο του ίντερνετς για το πώς οι Lispers την έχουνε μεγαλύτερη απ' όλους, βρήκα το εξής ψήγμα ουσιαστικής ενόρασης:

This practice is not only common, but institutionalized. For example, in the OO world you hear a good deal about "patterns". I wonder if these patterns are not sometimes evidence of case (c), the human compiler, at work. When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough-- often that I'm generating by hand the expansions of some macro that I need to write.

Κυριακή 10 Απριλίου 2011 στις 2:22:00 μ.μ. EEST  
Ο χρήστης Blogger aizen999 είπε...

λοιπον στασσα!
δε καταλαβα απολυτως τιποτα.

Κυριακή 10 Απριλίου 2011 στις 6:01:00 μ.μ. EEST  
Ο χρήστης Blogger stassa είπε...

Συγνώμη, aizen. Προειδοποίησα όμως, ε; :ο)

Κυριακή 10 Απριλίου 2011 στις 8:21:00 μ.μ. EEST  
Ο χρήστης Anonymous plagal είπε...

You're on to something, πλην ομως νομιζω οτι το βλεπεις απο χαμηλο λεβελ οβ αμπστραξιον. Τι εννοω: τα πατερνς ειναι παρα πολυ χρησιμα αλλα παραμενουν στο επιπεδο του ιμπλεμεντεσιον. Αυτο που πραγματικα θελεις με τις "γλωσσες υψηλοτερου επιπεδου" ειναι το code generation (οπως καποτε ξεφυγαμε απο τα 01 με τους κομπαιλερς, οπως ξεφυγαμε απο το platform dependence με τους bytecode interpreters, παμε ακομα παραπερα: ποιος νοιαζεται τον κωδικα ενιγουει?).

Τσεκαρε τις ιδεες στο πεδιο του Model Driven Software Engineering (γοογλε ιτ), οπου ο κωδικας παραγεται στο τελος και ολη η διαδικασια γινεται χρησιμοποιωντας μοντελα (φαση UML ή πιο domain specific γλωσσες). Για πιο πρακτικο παραδειγμα, τσεκαρε πώς δουλευει το πραμα στο Eclipse οικοσυστημα. Συγκεκριμενα, δες το workflow του EMF (Eclipse Modeling Framework): http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclipse.emf.doc/references/overview/EMF.html

Το γαματο μεταξυ αλλων ειναι το με το MDE φαινεται να εχουμε ενα τροπο να συνδυασουμε ΚΑΙ το φλεξιμπιλιτι και εξπρεσιβνες γλωσσων οπως η UML ΚΑΙ τη μαθηματικη αυστηροτητα των formal methods, μιας και το λεβελ οβ αμπστραξιον ειναι τετοιο που μπορουμε να κανουμε automated reasoning, model checking, formal refinement και αλλα ομορφα τετοια πραματα.

It's not there yet (αν και δουλευει καλα για συγκεκριμενες εφαρμογες), αλλα αυτο ειναι το ωραιο: το διδακτορικο μου σε αυτα το κανω :)

Κυριακή 10 Απριλίου 2011 στις 10:00:00 μ.μ. EEST  
Ο χρήστης Blogger Constantine είπε...

Java-άνθρωπος εδώ. Ένα μέρος από αυτά που θέλεις τα κάνει και το Spring Framework.

Κυριακή 10 Απριλίου 2011 στις 10:23:00 μ.μ. EEST  
Ο χρήστης Blogger stassa είπε...

Plagal,
γειά, νομίζω πρώτη φορά σε βλέπω εδώ. Ευχαριστώ πολύ για τα λινκς και τις ιδέες για ψάξιμο. Έχεις δίκιο φυσικά οτι το βλέπω σε χαμηλό επίπεδο, αλλά σταματάω εκεί επειδή τα patterns είναι προς το παρόν ένα βοήθημα, ας πούμε, παραγωγικότητας. Το βλέπω δηλαδή καθαρά από τη σκοπιά της πρακτικής ανάγκης για μεγαλύτερη αφαίρεση και γενίκευση, θεωρώντας οτι στο παρόν στάδιο κι ο απλός κώδικας χρειάζεται να είναι αρκετά γενικός αλλοιώς αρχίζει να χάνει σε χρησιμότητα. "citation needed" βέβαια, ή μάλλον "original research?".

Ποιός νοιάζεται τον κώδικα; Χαχά! Εμείς οι ταπεινοί και ταπεινές coders! :) ΟΚ, ισχύει αυτό που είπα παραπάνω, βασικά ο τρόπος (και η αιτία) που γράφουμε κώδικα είναι κληρονομιά της αρχιτεκτονικής Von Neumann και νομίζω όλοι θα ωφεληθούν (και ωφελούνται) από ό,τι μπορεί να μετατρέψει τον προγραμματισμό από χαμαλίκι σε ...λιγότερο χαμαλίκι, για αρχή και βλέπουμε.

Πάντως, εξαρτάται και πώς εννοείς το "κώδικας". Μέχρι να φτάσουμε όντως να μπορούμε να επικοινωνήσουμε με τις μηχανές μας σε φυσική γλώσσα (είτε μετακινόντας τις δικές τους προς τις δικές μας είτε -γιατί όχι- το ανάποδο), αναγκαστικά οποιαδήποτε σύνταξη θα είναι "κώδικας". Οπότε το θέμα είναι να εξελίξουμε τη σύνταξη. Οι διάφορες γλώσσες μοντέλων είναι απλά πιο εξελιγμένη/ ανώτερου επιπέδου σύνταξη, όχι; Και τελικά όπως λες κι εσύ και ένας compiler, κώδικα παράγει. Απλά δεν χρειάζεται να είναι κώδικας που διαβάζουν άνθρωποι.

Σε τί φάση είναι το διδακτορικό σου; Αν έχεις κάνα λινκ, κάνα μπλογκοπόστ, στείλτο, θα το διαβάσω ευχάριστα.

Κωνσταντίνε,
Αγαπητέ java-άνθρωπε (που μου δάνεισες και τον ορισμό ;) καλώς τονε! Έριξα μια ματιά στο Spring που λες, ίσα το δαχτυλάκι μου έβρεξα. Ναι, έχεις δίκιο- ε, το φανταζόμουνα οτι θα υπάρχει κάτι σχετικό, να είμαι ειλικρινής. Περίμενα οτι θα φάω και κάνα κράξιμο, "αυτά τά 'χουμε πει εδώ και χρόοονια" :)

Δευτέρα 11 Απριλίου 2011 στις 6:37:00 μ.μ. EEST  

Δημοσίευση σχολίου

Εγγραφή σε Σχόλια ανάρτησης [Atom]

<< Αρχική σελίδα