Περί σχεδίασης OOP

[kaliakman]

Εγώ άν είχα να αντιμετωπίσω αυτό το πρόβλημα θα έφτιαχνα ένα Factory Pattern πάντως και θα ξεχνούσα αλληλεπιδράσεις παιδιών, if-else κτλ γιατί όσο χάνεις απο πολυμορφισμό τόσο πιό περιπλοκος γίνεται ο κώδικας και τόσο πιό εύκολο να κάνεις λάθη.. 

Εγώ προτείνω να ξεχάσουμε γενικότερα το πρόβλημα.. Τι προτείνεις εσυ;

 

Επίσης που κολλάει το Factory εδώ; Βλέπεις πουθενα πρόβλημα με την δημιουργία των κλάσεων;

 

Ο TS αν δεν ήθελε "αλληλεπιδράσεις παιδιών" δεν θα το έψαχνε εξαρχής.

[BabyRage]

Η ερώτηση του topic starter απευθύνεται σε κάτι εγκυκλωπαιδικό (του στυλ: γιατι συμβαίνει αυτό ή προσπαθεί να λύσει κάποιο συγκεκτιμένο πρόβλημα; Πιστεύω ότι πάντα υπάρχει καλύτερη λύση από περίπλοκες μορφές πολυμορφισμού. 

[DevFromHell]

Αυτό εννουσα και γώ 

 

Δέν απάντησα στην απορία του ανθρώπου.. απλώς την επέκτεινα γιατί είτε αλληλεπιδρούν μεταξύ τους τα παιδιά-κλάσεις είτε όχι πρέπει να είναι και thread-safe.. Στο virtual method invocation πρέπει να κάνουμε locking ή double-checked locking.. Αυτά τουλάχιστον λέει το eBook που διαβάζω για την πιστοποίηση της Java 8.. 

 

Με το Factory Pattern μπορεί να δημιουργήσει όσα instances κλάσεων θέλει και μάλιστα με το set των input παραμέτρων που θέλει.. Εχει και άλλα patterns που κάνουν παρόμοια δουλειά.. 

 

Ωστόσο είμαι περίεργος να δώ τί προτείνετε εσείς που είστε πιό έμπειροι.. 

 

Βρήκα και αυτό αλλά δέν ξέρω πόσο σχετικό είναι http://stackoverflow.com/questions/33265069/interactions-of-subclasses-inheritance-and-mutators-accessors

 

Αυτό το multiple dispatch σε ποιά ενότητα της Java είναι? Πρώτη φορά το βλέπω σήμερα.. μάλλον δέν πολυχρησιμοποιείται.. πιο πολύ Strategy, Visitor, Observer έχω δεί

[defacer]

Δηλαδή pure virtual στο base και concrete implementations στα derived που κάνουν καλούν με  τον εαυτό τους την αντίστοιχη συνάρτηση της .

 

Αλλά αυτό ναι μεν δουλεύει αλλά φαίνεται ότι για πιο πολύπλοκες ιεραρχίες κλάσεων(Ήδη έχω 7 εγώ πχ) γίνεται χαμός και είναι δύσκολο να γίνει maintain.

 

Υπάρχει καλύτερος τρόπος έστω και πιο πολύπλοκος να στηθεί αλλά καλύτερος για scaling?

 

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

 

Πιό πολύπλοκοι τρόποι για καλύτερο scaling υπάρχουν, ξέρω τουλάχιστον δύο προσεγγίσεις: είτε με κάποιο προϋπολογισμένο table με member function pointers, είτε με TMP (template metaprogramming). Και οι δύο επιλογές (ειδικά η δεύτερη!) είναι very advanced level οπότε beware. Επίσης, θα γίνονται πράγματα στον κώδικα που πιθανόν δε θα σου αρέσουν 

 

Για dispatch tables μπορείς να δεις implementation εδώ, για TMP στο Modern C++ Design του Alexandrescu (μιλάμε τώρα θα χρειαστεί να χωνέψεις ολόκληρα κεφάλαια εισαγωγικών τεχνικών TMP πριν φτάσεις να μπορείς να διαβάσεις το συγκεκριμένο κεφάλαιο που μιλάει για multimethods).

 

Όπως καταλαβαίνεις δε μπορώ να αναλύσω παραπάνω τέτοια μεγέθη εδώ. Good luck!

[BabyRage]

Reported all of you. Το θέμα που δεν έχω καταλάβει εγώ είναι τι πρόβλημα προσπαθούν να λύσουν όλες αυτές οι κλάσεις και οι υποκλάσεις. Ποιος είναι ο σκοπός πέρα από το ότι θέλω οι κλάσεις μου να είναι έτσι. μήπως υπάρχει καλύτερος σχεδιασμός.   

 

Επίσης από ότι καταλαβαίνω μιλάμε για C++. Η Java τι σχέση έχει με αυτά DevFromHell? 

[CookieMonster80]

Αρχικά να ηρεμήσουμε λίγο όλοι γιατί δεν έχουν νόημα οι τσακωμοί.

 

Λοιπόν ας τα πάρουμε από την αρχή:

 

@BabyRage

Όλο το θέμα είναι για μια εργασία με σωματίδια τα οποία αλληλεπιδρούν μεταξύ τους και η ιεραρχία είναι "standard" οπότε δεν νομίζω ότι υπάρχουν καλύτεροι/ευκολότερα υλοποιήσιμοι τρόποι για να λυθεί αυτό το πρόβλημα. 

 

@defacer 

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

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

 

@DevFromHell

Αλήθεια δεν ξέρω αν έχεις καταλάβει ποιο είναι το πρόβλημα. Σίγουρα πάντως δεν υπάρχει πρόβλημα που να απαιτεί FactoryPattern στην συγκεκριμένη απορία.Ακόμα λογικό είναι μην έχεις ακούσει για double dispatch αλλά για Visitor πχ μιας και το δεύτερο είναι ένας τρόπος υλοποίησης του πρώτου. Επίσης όσα είπες για threads και τα λοιπά δεν είμαι σε θέση να ξέρω αν αυτά που λες ισχύουν ή όχι αλλά πάντως δεν έχουμε σημασία αφού δεν μιλάμε για πολυνηματική εφαρμογή.

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

 

Σας ευχαριστώ όλους,

και ειδικότερα τον defacer που μου έδωσε το έναυσμα να βρω την λύση (σχεδόν) μόνος μου.

[defacer]

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

 

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

 

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