.NET Framework

Απ: Μια υλοποίηση του FilterChain pattern ...

PALLADIN — Sun, 06 May 2007 03:00:40 GMT

Φιλε anjelinio

Χάρηκα πολύ που διάβασα το post σου, καθώς μου θύμισε και τις δικες μου όμορφες στιγμές που έζησα πριν από πολλά χρονια που συναντήθηκα με την Scheme.

Το functional programming paradigm έχει βαθιές μαθηματικές ρίζες και θα σε ταξιδέψει πολύ μακρύτερα από όσο μπόρεσε το OOP ή οποιοδήποτε άλλο programming paradigm.

Τσέκαρε το blog μου και ελπίζω να σε βοηθήσει στο ταξίδι σου.

"Recursion is beautiful and lambdas are the ultimate abstraction"

Απ: Μια υλοποίηση του FilterChain pattern ...

KelMan — Sun, 06 May 2007 01:45:39 GMT

Αυτά τα πράγματα ακριβώς κουβεντιάζαμε στο τελευταίο community event! Κρίμα που δεν ήρθες, θα το είχες διασκεδάσει

Απ: Μια υλοποίηση του FilterChain pattern ...

anjelinio — Sat, 05 May 2007 22:58:44 GMT

Και μετά απο τόόόόόόσο περισσότερο καιρό, και λίγο διάβασμα πρόσφατα, και ξαναδιαβάζοντας τα posts εδώ αρχίζω να το "πιάνω" καλύτερα thaanos. Καταλαβαίνω πλεον where you're coming from που λένε.

Μάλλον απλώς είχα "κολλήσει" στη Java 1.4 / C# 1.1, και κυρίως στο deserialization απο xml - έκανα focus πιο πολύ στο configurability μέσα απο XmlSerialization, και στο object tree που αυτό μου παράγει, παρά στην κυρίως λειτουργικότητα / υλοποίηση του pattern. Και, αν και όντως εξακολουθεί αυτή η αρχική υλοποίηση να μου λύνει τα χέρια, πλέον με το VPC του Orcas και τη μαγική λεξούλα Func, υπόσχομαι να επανέλθω πιο functional απο πρίν :D

Χρειάστηκε να περάσει βέβαια καιρός, να καταφέρω να βρώ χρόνο να διαβάσω λίγο σχετικά με functional programming ( ας είναι καλά το LINQ - αλλά κυρίως τα "side-effects" του, expression trees, lamdas κτλ κτλ ) και να δώ ένα - δύο intro to Haskell για να "ανοίξει" λίγο ο ορίζοντας στο μισο-καμμένο μυαλό μου, και να πιάσω κάποιες έννοιες :D

Sidenote: Πρίν καμμιά εβδομάδα, πήρα άδεια. Θυμόμουν αυτή τη συζήτηση με το thaanos, και είχα στο μυαλό μου οτι πρέπει να ψάξω λίγο τον functional κόσμο. Το πρώτο βράδυ που άρχισα να διαβάζω, δεν κοιμήθηκα. Και για 2 μέρες περπατούσα, μιλούσα, έπινα καφέ, αλλά ... το μισό μυαλό μου ήταν κολλημένο σε αυτά που διάβασα, ήταν απίστευτο !!! Είχα να αισθανθώ έτσι απο το παν/μιο, τη στιγμή που "έπιασα" το OO - φαντάζομαι την ξέρετε πολλοί αυτή τη μαγική στιγμή που ξαφνικά .. καταλαβαίνεις το object orientation ε; Άντε να δούμε, πόσο θα πάρει η αντίστοιχη functιonal στιγμή :D

[ thaanos, σ' ευχαριστώ πολύ φίλε μου. Για το ερέθισμα να ψαχτώ. Ο καφές που χρωστάω με τους τόκους πρέπει να έχει γίνει πλέον ολόκληρο κατάστημα του Floca, αλλά επιφυλλάσομαι :) ]

Απ: Μια υλοποίηση του FilterChain pattern ...

anjelinio — Tue, 24 Oct 2006 04:49:09 GMT

... μετά απο τόσον καιρό συνειδητοποίησα οτι ποτέ δεν έκανα attach τα sources ...

Απ: Μια υλοποίηση του FilterChain pattern ...

thAAAnos — Fri, 29 Sep 2006 16:58:38 GMT

Sorry που άργησα (off net)... μεσα για τον cafe... οπουδηποτε... :P

αλλα είμαι λίγο ντροπαλός... :) για μεγάλο κοινο...

Απ: Μια υλοποίηση του FilterChain pattern ...

anjelinio — Thu, 28 Sep 2006 00:20:41 GMT

[ ... τί, δεν έχει ... java ??? :D ]

Απ: Μια υλοποίηση του FilterChain pattern ...

KelMan — Wed, 27 Sep 2006 22:00:05 GMT

Blue Mountain! Σου κάνει;

Απ: Μια υλοποίηση του FilterChain pattern ...

anjelinio — Wed, 27 Sep 2006 21:51:45 GMT

... αν έχει και καφέ ... :D ... lol !!! :D

Σοβαρά τώρα, αν θέλει κι ο thAAAnos νομίζω θα ήταν πολύ ενδιαφέρουσα συζήτηση.

Απ: Μια υλοποίηση του FilterChain pattern ...

KelMan — Wed, 27 Sep 2006 19:44:28 GMT

Ή μπορείτε να τα κουβεντιάσετε μπροστά σε κοινό, στα events του community που λέμε να οργανώσουμε

Απ: Μια υλοποίηση του FilterChain pattern ...

anjelinio — Wed, 27 Sep 2006 19:27:00 GMT

Η αλήθεια είναι οτι η αρχική παρότρυνση για το συγκεκριμένο implementation ήταν το αντίστοιχο chain που δίνει ο εκάστοτε J2EE container ( π.χ. το filter chain του tomcat, όπου δηλώνεις κάπως αντίστοιχα στο config αρχείο σε xml τα φίλτρα απ'τα οποία θα περάσει το request ), αλλά στην πορεία το έχω χρησιμοποιήσει για χίλιους-δύο λόγους, και όντως λύνει χέρια.

Αλλά απ'την άλλη, σκέφτομαι κι εγώ τώρα οτι ίσως πρέπει να δώ και τις άλλες απόψεις / οπτικές .. ποιός ξέρει τι μπορεί να προκύψει ;;; Γι'αυτό σίγουρα κάποια στιγμή θα κεράσω καφέ αν θές, να δούμε και την άλλη πλευρά, άλλες ιδέες ... τί geeks είμαστε στην τελική αν δεν μιλήσουμε και λίγο πιο φιλοσοφικά με τετραδιάκια και laptops στην καφετέρια ;;; :D ( χαχαχχαα ... χριστέ μου, τι καμένος είμαι !!! :D )

Άντε, καλημέρα μας :D

Απ: Μια υλοποίηση του FilterChain pattern ...

thAAAnos — Wed, 27 Sep 2006 17:21:44 GMT

Χμμ...

Απλά ξέρεις τι; Μάλλον αυτό που τελικα με παραξένεψε είναι όχι πως υλοποιείς το pattern. Αλλα ή χρήση του στην συγκεκριμένη περιπτωση... Έχω την εντύπωση πως το filter chain (αν έχω σωστά την αναλογία στο μυαλό μου με το chail of responsibility ) δέν είναι για να στέλνεις data από μέσα του αλλα events (requests,interupts,errors)... -Και υπό αυτήν την έννοια το πιο γνωστο παραδειγμα ειναι τα διαδοχικά catch blocks μετά το try ( χωρις το δυναμισμό κλπ (αν και με reflection... χμ να μια ιδέα! ) ).- Επιχειρώντας να στείλεις ένα dataset ( για validation/transformation ) εχω την εντυπωση οτι επιχειρείς να στήσεις ενα dataflow γράφο, εξου και η παρότρυνση μου για functional orientation του προβληματός σου...

Αλλά από την άλλη σε βλέπω πολύ ζεστό και αυτό σημαίνει οτι σου έχει λύσει τα χέρια, τόσο που έκατσες και να το μοιραστείς μαζί μας... :) όποτε σημφωνα με την design-comandment "Never fix what ain' broken" το αφήνω εδώ.

PS μήπως έχεις ανακαλύψει στην τελική ενα νέο pattern?

Απ: Μια υλοποίηση του FilterChain pattern ...

anjelinio — Wed, 27 Sep 2006 00:55:51 GMT

thAAAnos, η έννοια filter chain δεν είναι κάτι που μου ήρθε μια μέρα :) Είναι γνωστό design pattern, του οποίου ήθελα ένα implementation για να βοηθήσω τον εαυτό μου και τους απο κάτω μου. Η παρούσα υλοποίηση μας βολεύει απίστευτα τους τελευταίους μήνες, και δε βρέθηκα ακόμη μπροστά στην ανάγκη να την αλλάξω, ή να την ξανασκεφτώ απο τότε ( είναι πολύ παλιό το post ).

Για τη δική μου περίπτωση, το chain δεν είναι απλώς ένα composite filter. Αυτό ήταν το σχεδόν accidental side-effect - κατα βάση είναι ο manager ο οποίος ορίζει το πως θα εκτελεστούν τα φίλτρα. Με νοιάζει και πάρα πολύ μάλιστα το navigation να είναι εξωτερικό του φίλτρου.

Δεν θα είχα καμμία διαφωνία να περνάω pointers στους γείτονες του σε κάθε φίλτρο, αλλά δε με βολεύει. Δε θέλω να γράφω εγώ ή κάποιος άλλος τίποτα παραπάνω απο ένα FilterChain.FromFile(...).Process(...);

Θα μπορούσα κάλλιστα να είχα χρησιμοποιήσει C# delegates σαν ένα είδος function pointer, αλλά έτσι μόνο θα δυσκόλευα τον κώδικα του μικρού μου junior που γράφει VB - άσε που ίσως και να μην κέρδιζα και τίποτα απο performance.

Οπότε οι δικοί μου στόχοι είναι simplicity, ease of use, declarative interface, reuse. Ότι άλλο προκύψει, θα αλλάξει κάτω απ'το ίδιο facade, και κάτω απ'το ίδιο API.

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

dimcasta .. ο decorator δεν είναι filter chain και αντίστροφα, αν και μοιάζουν κ α τ α π λ η κ τ ι κ α. Βασική διαφορά είναι οτι ο decorator "decorates" ένα αντικείμενο, και συνήθως πολλοί decorators ενεργούν στο ίδιο αντικείμενο. Το ίδιο δεν ισχύει στο chain, όπου μπορεί τα return & input types μεταξύ φίλτρων να διαφέρουν. Τέλος, ο decorator δεν έχει πολλές φορές καν return type. It decorates το input του, και μάλιστα με ποικίλλους τρόπους. π.χ. ένας ui decorator θα μπορούσε να κάνει attach σε κάποια events μιας σελίδας, για να προσθαφερεί controls .. ή να κάνει validation, ή , ή , ή ... τέλος πάντων ... εγώ το chain ήθελα :D

thAAAnos .. κερνάω καφέ φίλε οποιαδήποτε στιγμή !!! :)

Απ: Μια υλοποίηση του FilterChain pattern ...

dimkasta — Tue, 26 Sep 2006 23:53:40 GMT

Δεν μπορώ να το διαβάσω όλο γιατί είμαι θολωμένος.

Ρίξε όμως μια ματιά και στο decorator pattern. Μπορεί να σου δώσει κανα δυο ιδέες.

Απ: Μια υλοποίηση του FilterChain pattern ...

thAAAnos — Tue, 26 Sep 2006 21:48:06 GMT

:)

Forget Navigation αυτο ειναι implementation specific...

Το όλο νοημα που θελω να καταλάβεις είναι οτι δεν χρειάζεται η έννοια "filter chain" αλλά μόνο η έννοια "filter" και αυτό δεν έχει να κάνει με την γλώσσα...

Δές το απλά: τι είναι πραγματικά ένα "filter chain" αν όχι ενα composite filter...

Δημιουργόντας την έννοια "filter chain" χρειάζεσαι και την έννοια navigation

εγώ δεν ανέφερα ποτέ τον όρο navigation αλλα *composition* αυτό το επιτυγχανεις είτε με array ειτε με list δεν εχει σημασία δεν φαίνεται απέξω.

Αν θες syntactic sugar σε c++ μπορεις να γραφεις και κατι σαν και αυτο:

data = (Myfilter1,Myfilter2,MyfilterN)(data);

αν και θεωρώ πιο ωραίο το

data = Myfliter1(Myfilter2(MylilterN(data)));

αν δεν θες να ξαναχρησιμοποιησεις το composition που έφτιαξες...

Δεν καταλαβαίνω που ειναι το προβλήμα...?

Όσο για το parallel implementation του chain αυτο που αναφερεις ειναι μαλλόν

abuse δεν έχεις *chain* πια αλλα ενα array από φίλτρα ένα MISD construct δηλαδή που μάλλον για χακία μου φέρνει. Αν ήθελες να το κάνεις κανονικά πρέπει να πάς σε δεντρο από filters πχ σε c++ θα το δήλωνες κάπως έτσι

data_array = tee(Myfilter1,tee(Myfilter2,MyfilterN)(data);

με την tee να είναι φίλτρο που επιστρέφει 2 αντίγραφα της εισόδου...

Όσο για το threading μιλάμε ουσιαστικά για βαριά φιλτρα με data που έρχονται σε stream με το filter_chain δεν ξέρω κατα πόσο ειναι εύκολο γιατι η κλάση σου θα πρέπει να διαχειριστεί όλη την επικοινωνία και τον συγχρονισμό όλων των φιλτρών ενώ αυτο που θές ειναι να επικοινωνούν και να συχρονίζονται μόνο οι γείτονες μεταξύ τους.

Άσε με function composition μπορεις να κάνεις και ωραίο optimization

( ok at least for c++ )

Anyway ποτέ δεν είπα κάντο έτσι. Απλά το ανέφερα μήπως αν το σκεφτείς διαφορετικά βολευτείς καλύτερα. Πχ ακόμα και στα φίλτρα του unix δεν υπάρχει

κάποιος manager για το πως θα εκτελεστούνε, το κέλυφος σετάρει τα κανάλια και αφήνει τα φίλτρα ήσυχα να δουλέψουν.

PS ( κακία :P ) Η C++ υποστηρίζει ήδη το functional programming paradigm χωρις τα blinqy-plinqy που θα βρείτε μπροστά σας και ξανα-ανακαλυψετε τον τροχο. Και programmer-friendly δεν σημαινει programmer-stupid.

Απ: Μια υλοποίηση του FilterChain pattern ...

anjelinio — Tue, 26 Sep 2006 18:44:41 GMT

Νομίζω οτι κατάλαβα τι θέλεις να πείς αγαπητέ, αλλά ...

Η λύση σου είναι βαθιά ριζωμένη στην κληρονομιά της C++. Η συγκεκριμένη είναι ένα linked list on crack. Data (the list & the navigation) & processing logic παρεούλα μέσα σε κάθε φίλτρο. Το νόημα του pattern ΕΙΝΑΙ το array, κι ακόμη περισσότερο ο declarative τρόπος να ορίσεις αυτό το array, δημιουργώντας έτσι νέα filter chain implementations δίχως μια γραμμή κώδικα. Νομίζω οτι είναι πολύ ωραίο να ασχολείσαι με lower-level πράγματα απο το .NET CLR ή το Java JVM, αρκεί να μην αφήνεις το εργαλείο σου να καθορίζει τους ορίζοντές σου - πράγμα που φοβάμαι οτι συμβαίνει με τους C/C++ προγραμματιστές, πολλοί απ'τους οποίους κουβαλάνε στην πλάτη τους νοοτροπίες "κλειστές" οι οποίες εκλείπουν στο νέο, managed, programmer-frienldy κόσμο.

Η υλοποίηση του στύλ Filter_base * my_filter_chain = new Myfilter1(new Myfilter2(new MyfilterN))); όπου θα πρέπει κάποιος να γ ρ ά ψ ε ι αυτόν τον constructor - με συγχωρείς για αυτό που θα πώ - μου φαίνεται απλώς .. ακαλαίσθητη. Η συγκεκριμένη γραμμή κώδικα είναι κάτι που ποτέ δε θα ήθελα να επιβάλλω σε κάποιον να γράψει. Υπάρχει implementation με αυτόν ακριβώς τον τρόπο και σε Java, αλλά απλώς σχεδόν αποκλείει κάθε περίπτωση "δυναμισμού" @ runtime. Ακόμη και με generics - ευχαριστώ πολύ τη C++ και τα templates που έδειξαν το δρόμο προς τα 'κει κατα κάποιο τρόπο.

Αν θές να το δείς και αλλιώς, η δουλειά του φίλτρου δεν είναι να ξέρει ή να ελέγχει με τον οποιονδήποτε τρόπο το "navigation" του chain. Η δουλειά του είναι να πάρει ένα input, και να δώσει πίσω ένα output and that's that. Δεν είναι δικό του concern - αν θές να χρησιμοποιήσουμε και λίγο AOP ορολογία - να ξέρει οτιδήποτε πέραν απο οτι χρειάζεται
α π ό λ υ τ α να ξέρει. Κι αυτό είναι μόνο το input του. Σκέψου, ότι αν το φίλτρο ξέρει μόνο το επόμενο node προς εκτέλεσην, τότε χάνεις κάθε έννοια reusability του φίλτρου. Τί εννοώ ... έχω ένα φίλτρο υλοποιημένο με τον linked list τρόπο που έδωσες. Sequential. Αν εγώ θελήσω να χρησιμοποιήσω το ίδιο φίλτρο σε ένα parallel implentation του chain ... έχασα. Θα πρέπει να κάνω κάποια χακιά, όπως το να μήν του περάσω pointer στο επόμενο φίλτρο, και κάπως ( πιθανότατα .. στο filter chain class ! ) να κανονίσω το navigation εξωτερικά του φίλτρου. Άρα ... επιστρέφουμε κατα κάποιο τρόπο στο array και το εξωτερικό του φίλτρου navigation.

Όσον αφορά τις δυνατότητες πέρα απο τη στενή συζήτηση του αν ένα linked list είναι πιο όμορφη απο ένα array, δεν υπάρχει κανένας περιορισμός. Μόνο στη φαντασία του implementer. Γιατί δε μπορείς να ξεκινήσεις τα φίλτρα σε διαφορετικά threads ? Γιατί δεν μπορείς και έτσι να τα κάνεις load-balanced ? Τα πάντα είναι ένα override στην process(...) του filter chain που θές να φτιάξεις.

Τώρα, όσον αφορά το ότι ένα array ή ένα linked list δεν ανοίγει τόσες προοπτικές όσο ένα graph ... έχεις δίκιο. Αλλά έτσι είναι το pattern, και υπάρχει για συγκεκριμένους σκοπούς. Αν χρειαζόταν να φτάσω σε graphs ... θα χρησιμοποιούσα κάποιο έτοιμο workflow πακέτο, που σίγουρα θα δώσει κάτι ακόμη παραπάνω. Δεν υπάρχει λόγος να φτιάξω ένα αεροπλανοφόρο για να ρυμουλκήσω μια μαούνα στον Ισθμό της Κορίνθου :D

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

Άντε, καλημέρα μας !!!