Python class προτάσεις βελτίωσης

[Dr.Fuzzy]

@iceblade

Όπως έγραψα πριν ο κώδικας όπως τον έκανα αρχικά port σε Python από το MATLAB ήταν pure modules με functions χωρίς OOP, με βάση τη λογική που λες. Αποφάσισα να το γράψω OOP επειδή πρόκειται να επεκταθεί αρκετά και να συνδεθεί και με άλλα frameworks.

 

Σίγουρα γίνεται code reuse, maintenance και library adaptation χωρίς OOP αλλά γιατί όχι αν τελικά βοηθάει να είναι πιο οργανωμένος ο κώδικας; Δε βλέπω κάτι κακό, ούτε γιατί πρέπει να αποκλειστεί από το scientific programming. Ναι αν μιλάμε για έναν πχ, Kalman filter προφανώς και θα το έφτιαχνα σε ένα single function, ίσως ούτε καν function. Αν όμως μιλάμε για πολλά διαφορετικά φίλτρα, controllers, benchmarks, κλπ, κλπ που συνθέτουν ένα μεγάλο framework όπως στην περίπτωση του project που αναφέρω, τότε το OOP νομίζω βοηθάει.

 

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

[M2000]

Dr.Fuzzy

Φτιαχνουμε κάτι σε oop αν θέλουμε να χειριστούμε πολλά αντικείμενα. Με αυτή την έννοια η δουλειά σου με την ιδέα του αντικειμένου θα αποδώσει! Σε ένα άλλο πρόγραμμα που θα θέλει να φτιάξει κανείς δυο ή περισσότερες παραστάσεις, με τα αντικείμενα θα γίνεται εύκολα!

καλή συνέχεια!

[pmav99]

@Dr.Fuzzy

Τις απαντήσεις για το βέλτιστο design δεν μπορούμε να τις δώσουμε εμείς. Εσύ ξέρεις το project και τις ανάγκες του. Υλοποιώντας και έτσι και αλλιώς θα αποκτήσεις και εμπειρία και έτσι στο μέλλον θα μπορείς να κρίνεις πιο εύκολα τι ταιριάζει που.

 

Τα programming paradigms δεν είναι πανάκεια. Είναι απλά δρόμοι για ένα σκοπό (ο οποίος είναι να κάνεις τη δουλειά σου). That being said, υπάρχουν συγκεκριμένα προβλήματα τα οποία ταιριάζουν εξαιρετικά καλά με συγκεκριμένα programming paradigms. Πχ η δημιουργία μιας βιβλιοθήκης για GUI ταιριάζει με OOP. Εγώ όταν έπαιξα με Qt κατάλαβα τι θα πει OOP

 

O iceblade έχει δίκιο ότι συχνά στο scientific computing ο ΟΟP δεν είναι απαραίτητος (αν και πάλι εξαρτάται από το πρόβλημα, πχ τα Finite Elements είναι πολύ Object Oriented· οι solvers τους πάλι, όχι και τόσο ), αλλά μία περίπτωση που εγώ χρησιμοποιώ κλάσεις χωρίς OOP, χωρίς δηλαδή inheritance κτλ, είναι όταν έχω πολλές μεταβλητές. Βρίσκω πιο εύκολο να κάνω "self. + <tab>" από το να περνάω 10+ μεταβλητές στον ορισμό της function (σε αυτό βέβαια οφείλεται και η δυναμική φύση της python που δεν επιτρέπει να έχεις καλό automatic refactoring).

[groot]

Η Python είναι (κατά προσωπική άποψη) ταμάμ για scientific computing.

 

Το παπιο-σύστημα σου δίνει την ευκαιρία για τρελό re-usability, π.χ. απλά functionalities υλοποιημένα με mixins ή decorators (ειδικά το τελευταίο είναι πολύ ωραίο για input argument checking/handling), αλλά και η φαινομενικά spaghetti φάση της python σου επιτρέπει να έχεις αντικείμενα και "χύμα" functions.

 

Έτσι, μπορείς να έχεις την λογική των data σου σε κλάσεις και επεξεργασία δεδομένων σε functions. Με τα callables μπορείς και να ορίζεις on-the-fly τι functions θα χρησιμοποιήσεις για διαφορετικές διαδικασίες. Π.χ., για ένα απλό code book building να μπορείς να περάσεις εσύ τι functions θα χρησιμοποιήσει περαιτέρω ο κώδικας με τρόπο που είναι πολύ απλός (και τον έχουν εκμεταλλευτεί στο έπακρο στην κοινότητα του enthought/scipy).

[pmav99]

> Old-style, new style classes...Ι'd never would have known, if you haven't mentioned it!

 

Όταν βλέπω class που δεν κληρονομεί από object, είναι το πρώτο πράγμα που έρχεται στο μυαλό.

 

> Αρχικά το είχα self.time (όπως το έγραψε ο pmav99 τώρα) μετά κάπου διάβασα ότι 1 _ είναι semi-private και 2 __ private και το άλλαξα (συγκεριμένα δες #62 εδώ http://stackoverflow...ame-in-python).

 

Στην python, τα, κατά συνθήκη, private attributes/methods έχουν νόημα σε μια library που θα ανεβεί pypi και θα χρησιμοποιεί πολύς κόσμος. Εκεί το κάνεις γιατί έχεις high level API και για να αποφύγεις να γράψεις εκτενές documentation για το internal implementation.

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

 

> Έχει νόημα τελικά να έχω separate classes Metrics και PlotMetrics (ή MetricsPlot...;;; ) όπως προτάθηκε από τον mad-professor;

 

Κάντο για να δεις

[groot]

> Έχει νόημα τελικά να έχω separate classes Metrics και PlotMetrics (ή MetricsPlot...;;; )

Σχετικά με αυτό....

 

@Fuzzy

Εάν κάνεις plot συγκεκριμένα μετρικά ή μπορείς να οργανώσεις τα μετρικά σου (π.χ. και πολύ απλά, στο όριο του λάθους, βάζοντας κάτι ως αναγνωριστικό: plottable_my_metric) μπορείς να χρησιμοποιήσεις mixins και να κάνεις μία class (από την οποία θα κληρονομεί το Metrics).

 

Η κλάση αυτή θα έχει την δυνατότητα να βρει τα plottables (π.χ. ακόμα και με getattribute) και να τα σχεδιάσει βάσει ενός κοινού template.

 

Αλλά, συμφωνώντας με τον pmav99, too much work για κάτι που θα το κάνεις σε συγκεκριμένο task. Εάν σκοπεύεις να το κάνεις και αργότερα ή να δώσεις κώδικα σε colleagues, τότε ίσως αξίζει.

[Dr.Fuzzy]

Σας ευχαριστώ όλους όσους βοηθήσατε με τις προτάσεις σας και τα σχόλια σας.

 

Αναφορικά με το OOP ή όχι ένας από τους λόγους που στράφηκα εκει είναι κάτι αντίστοιχο με αυτό που είπε ο pmav99,

 

 

αλλά μία περίπτωση που εγώ χρησιμοποιώ κλάσεις χωρίς OOP, χωρίς δηλαδή inheritance κτλ, είναι όταν έχω πολλές μεταβλητές. Βρίσκω πιο εύκολο να κάνω "self. + <tab>" από το να περνάω 10+ μεταβλητές στον ορισμό της function.

Θέματα inheritance κλπ όχι δε μου πολύ χρειάζονται, ισχύει. Φυσικά και γνωρίζω ότι το OOP είναι πολύ περισσότερα από τους λόγους που αρχικά το επέλεξα.

 

Γενικά και για να μη δημιουργώ τη λάθος εικόνα, διευκρινίζω ότι δεν είμαι sw engineer, ούτε prof. developer. Η δουλειά μου είναι καθαρά ακαδημαϊκή-ερευνητική. Οι (όποιες) γνώσεις μου πάνω σε OOP προέρχονται λόγω της συμμετοχής μου σε επιστημονικές εργασίες (ή και της προσωπικής μου ενασχόλησης, όπως αυτό το post άλλωστε), όπου όπως είναι γνωστό πολλές φορές "αναγκαζόμαστε" (τραβάτε με και ας κλαίω...) να μπαίνουμε και σε ξένα χωράφια πέραν από το αντικείμενο μας (το ξέρω δεν είναι ότι καλύτερο, αλλά χρειάζεται αν κάποιος θέλει να εμπλακεί και σε πρακτικό επίπεδο εκτός από το θεωρητικό μόνο).

 

Moral of the story...Ο κώδικας υπάρχει στο bitbucket σε pure module/functions μορφή (όπου θα μπει σίγουρα το dictionary όπως προτάθηκε απο groot). Θα τελειώσω όμως και την έκδοση με classes βάσει των σχολίων σας και θα ανεβάσω ένα δεύτερο branch. Ο συγκεκριμένος κώδικας τελικά προορίζεται να δοθεί σε φοιτητή μου που θα κάνει τη διπλωματική του και θα τον επεκτείνει. Ποιον από τις δύο εκδόσεις θα του δώσω...θα πρέπει να το σκεφτώ!

 

@pmav99

"ο μουσάτος τύπος που ακούει όλη μέρα Motorhead και κάθεται στο δίπλα γραφείο, δεν..."

Εντάξει...κλαίω, γελάω μόνος μου...μου θύμισες πριν λίγα χρόνια στο lab όταν έκανα PhD, υπήρχε ακριβώς τέτοια μορφή...

Επεξ/σία 24 Μαρτίου 2016 από Dr.Fuzzy

[groot]

Would you mind telling me your field of study in pm?

[pmav99]

Γενικά και για να μη δημιουργώ τη λάθος εικόνα, διευκρινίζω ότι δεν είμαι sw engineer, ούτε prof. developer. Η δουλειά μου είναι καθαρά ακαδημαϊκή-ερευνητική. Οι (όποιες) γνώσεις μου πάνω σε OOP προέρχονται λόγω της συμμετοχής μου σε επιστημονικές εργασίες (ή και της προσωπικής μου ενασχόλησης, όπως αυτό το post άλλωστε), όπου όπως είναι γνωστό πολλές φορές "αναγκαζόμαστε" (τραβάτε με και ας κλαίω...) να μπαίνουμε και σε ξένα χωράφια πέραν από το αντικείμενο μας (το ξέρω δεν είναι ότι καλύτερο, αλλά χρειάζεται αν κάποιος θέλει να εμπλακεί και σε πρακτικό επίπεδο εκτός από το θεωρητικό μόνο).

Ναι, το ιδανικό είναι αφού τελειώσεις τον κώδικά σου να του κάνει refactroring κάποιος SW Eng. Παρόλα αυτά μην ψαρώνεις. To scientific computing καλώς ή κακώς δεν μπορούν να το κάνουν οι SW Engs μόνοι τους γιατί δεν έχουν γνώση του εκάστοτε domain. Στην πράξη νομίζω ότι είναι πιο εύκολο να μάθεις εσύ αυτά που σου χρειάζονται από Computer Science παρά να μάθει ένας computer scientist αυτά που εσύ κάνεις. Επίσης ο συνδυασμός science και προγραμματισμού είναι καλή επαγγελματική προοπτική...

[Dr.Fuzzy]

Ναι, το ιδανικό είναι αφού τελειώσεις τον κώδικά σου να του κάνει refactroring κάποιος SW Eng. Παρόλα αυτά μην ψαρώνεις. To scientific computing καλώς ή κακώς δεν μπορούν να το κάνουν οι SW Engs μόνοι τους γιατί δεν έχουν γνώση του εκάστοτε domain. Στην πράξη νομίζω ότι είναι πιο εύκολο να μάθεις εσύ αυτά που σου χρειάζονται από Computer Science παρά να μάθει ένας computer scientist αυτά που εσύ κάνεις. Επίσης ο συνδυασμός science και προγραμματισμού είναι καλή επαγγελματική προοπτική...

 

Very well said! 

 

@groot

u've been pm'd!