Γενικό thread αποριών για τη C#.

[M2000]

Αυτό που λες Dictionary LookUp, γίνεται στο κώδκα για αναγνώριση μιας εντολής και μετά πάει στο Select Case. Η επόμενη αλλαγή που θα κάνω είναι να βάλω στο πίνακα κατακερματισμού τα Addressof των συναρτήσεων/μεθόδων που θα καλεί για κάθε εντολή. Κάποια στιγμή θα γίνει αλλά μέχρι τότε δουλεύει και έτσι.

[AllCowsEatGrass]

Diaries of a madman, πραγματικά. Αν έχεις την παραμικρή κρυφή επιθυμία πως κάποιος κάποτε μία μέρα θα κάνει αλλαγές στο “repository” σου… news flash, δεν πρόκειται.

Είναι κάτι σαν το visible universe όσο ο χρόνος περνάει το ποσοστό του σύμπαντος που μπορούμε να εξερευνήσουμε μειώνεται εκθετικά! (την αναλογία κάν’ τη μόνος σου). Βοηθάει σε αυτό η VB6 που αγαπάς τόσο πολύ και φυσικά η δομή που έχεις δώσει στον κώδικα.

tria_kila_kwdikas.vb

[Επισκέπτης]

Δεν ξέρω για το insomnia αλλά για χαρακτήρας στο σύμπαν του Pratchett ο Μ2000 είναι ιδανικός.

[pmav99]

.

[Alithinos]

Έχω μια απορία που δεν σχετίζεται αποκλειστικά με τη C#, αλλά γενικότερα με την αντικειμενοστραφή (ή και μη) ανάπτυξη.

Έχει να κάνει με το refactoring και τον αρχιτεκτονικό σχεδιασμό.

 

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

 

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

Έτσι έκανα το πρώτο μου refactor.

 

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

 

Κάποια στιγμή όμως, δεν θέλει πολύ για να μπερδευτείς με τις πολλές αλλαγές του αρχιτεκτονικού σχεδιασμού, άμα κάνεις ξανά και ξανά refactoring. Ειδικότερα πιστεύω όσο μεγαλύτερο είναι το project, τόσο περισσότερο δύσκολο θα είναι.

 

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

 

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

[sundance_kid]

Δεν μπορούμε να κάνουμε copy paste γιατι ακόμα και το clipboard φέρει incompatibilities με την VB6.

 

Γελάω και κλάνω ταυτόχρονα απ το γέλιο.

[Επισκέπτης]

@Alithinos

 

Δες λίγο το Entity Framework. Για να μην κάθεσαι να αλλάζεις τις κλάσεις κάθε φορά που αλλάζει κάτι στα δεδομένα σου. Τα φτιάχνει όλα αυτόματα κι οποτεδήποτε υπάρχουν αλλαγές στα data ενημερώνεται αυτόματα κι ο κώδικας. Για να μην εφεύρεις τον τροχό κάθε φορά που πρέπει να κάνεις αλλαγές.

[M2000]

Στo IDE της VB6 κάθε φορά που κάνουμε copy (στο πρόχειρο) κοιτάει τι γλώσσα έχουμε στο πληκτρολόγιο και το στέλνει με βάσει αυτό. Στη Μ2000 που είναι γραμμένη με VB6, χρησιμοποιώ unicode αντιγραφή.Άρα πρακτικά δεν υπάρχει πρόβλημα παρά μόνο με το IDE της VB6 (η M2000 γράφτηκε αρχικά με στόχο να έχει κανείς μια free γλώσσα χωρίς την VB6)

[Kercyn]

@Alithinos

Γι' αυτό όταν κάνεις τον σχεδιασμό, προσπάθησε να αφιερώσεις λίγο περισσότερο χρόνο για να δεις αν αυτό που έχεις μπορεί να γίνει καλύτερα και πώς θα δένει με το υπόλοιπο πρόγραμμα κλπ. Βέβαια όσο περισσότερο κάθεσαι και κάνεις αυτό το πράγμα τόσο καλύτερος θα γίνεσαι. Το refactoring δεν το γλυτώνεις ό,τι και να κάνεις (μπορείς όμως να μειώσεις τη συχνότητα και την "ποσότητα" του).

[groot]

@alithinos

Design. Αυτό ψάχνεις.

 

Διάβασε για software design, object oriented design και, επειδή 100% θα σε βγάλει εκεί, Booch.

[M2000]

Από εδώ http://dotnet.github.io/getting-started/

έβαλα το dotnet στο Ubuntu 14.04

Πρόσθεσα ελληνικά στο Hello World και τα έδειξε εντάξει στην κονσόλα.

Έχει χρησιμοποιήσει κανείς τη C# σε Ubuntu;

[defacer]

Έτσι έκανα το πρώτο μου refactor.

Congrats!

 

Υπόψιν το design είναι πολύ δύσκολη δουλειά να γίνει σωστά, για διάφορους λόγους που νομίζω δεν έχω χρόνο να αναπτύξω τώρα. Και γι' αυτό δεδομένου ότι είσαι και "νέος" στο χώρο παίζει αρκετές φορές να νομίζεις ότι κάνεις design ενώ στην πραγματικότητα κάνεις anti-design. Δε μπορώ βέβαια να ξέρω, αλλά κάτι τέτοιο μου μύρισε η περιγραφή σου.

 

Το ένα είναι αν υπάρχει κάποια τακτική ώστε να ξέρεις κατά τον αρχικό σχεδιασμό πως να διαχωρίσεις καλύτερα το πρόγραμμα σε components, κλάσεις, κτλπ, ώστε να μη χρειάζεται να πηγαινοέρχεσαι από το γράψιμο κώδικα στη σχεδίαση και τούμπαλιν ξανά και ξανά.

Υπάρχει, λέγεται συσσώρευση γνώσεων και προ πάντων εμπειρίας.

 

Μη σε απασχολεί αν τώρα δε μπορείς να καταλάβεις πώς θα μπορούσες να έχεις σκεφτεί "το σωστό" από την αρχή, γιατί δε θα μπορούσες really. Να σε απασχολεί μόνο το αν μετά από 3 χρόνια αναρωτιέσαι το ίδιο πράγμα για το ίδιο πρόγραμμα.

 

Επίσης έχε υπόψη ότι στη ζωή είναι σπάνιο να σου κάνει κανείς τη χάρη να γράψει τα requirements στις πέτρες του Μωυσή, οπότε ακόμα κι αν κάνεις "το τέλειο design" με την πρώτη, πάλι θα χρειαστεί να το αλλάξεις σύντομα γιατί άλλαξαν τα δεδομένα που σε οδήγησαν εκεί.

 

Το άλλο είναι μέχρι πόσες τέτοιου τύπου ριζικές αλλαγές είναι λογικό / θεμιτό / επιτρεπτό να κάνω, και αν υπάρχουν κάποια συγκεκριμένα κριτίρια που μπορώ να έχω για να αποφασίσω αν αξίζει να μπω στο κόπο να κάνω τόσο μεγάλες αλλαγές.

Δεν υπάρχει απάντηση one size fits all. Τα κριτήριά σου είναι αν αυτός για τον οποίο γράφεις το πρόγραμμα έχει α) ώφελος από την αλλαγή που σκέφτεσαι και β) την πολυτέλεια να ξοδέψεις όσο χρόνο χρειάζεσαι για να την πραγματοποιήσεις. Τώρα που το κάνεις για σένα για εξάσκηση οι απαντήσεις θα πρέπει να είναι ναι και ναι, οπότε δεν υπάρχει όριο.

 

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

 

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

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

[Alithinos]

@Alithinos

 

Δες λίγο το Entity Framework. Για να μην κάθεσαι να αλλάζεις τις κλάσεις κάθε φορά που αλλάζει κάτι στα δεδομένα σου. Τα φτιάχνει όλα αυτόματα κι οποτεδήποτε υπάρχουν αλλαγές στα data ενημερώνεται αυτόματα κι ο κώδικας. Για να μην εφεύρεις τον τροχό κάθε φορά που πρέπει να κάνεις αλλαγές.

Ενδιαφέρον φαίνεται. Θα το έχω στο νου μου για αργότερα. Νομίζω πως θα ήταν καλύτερο να μάθω πρώτα ακόμα καλύτερα τη C#, ή δεν είναι έτσι ?

 

@Alithinos

Γι' αυτό όταν κάνεις τον σχεδιασμό, προσπάθησε να αφιερώσεις λίγο περισσότερο χρόνο για να δεις αν αυτό που έχεις μπορεί να γίνει καλύτερα και πώς θα δένει με το υπόλοιπο πρόγραμμα κλπ. Βέβαια όσο περισσότερο κάθεσαι και κάνεις αυτό το πράγμα τόσο καλύτερος θα γίνεσαι. Το refactoring δεν το γλυτώνεις ό,τι και να κάνεις (μπορείς όμως να μειώσεις τη συχνότητα και την "ποσότητα" του).

Χμμ, αυτό σκέφτηκα και εγώ. Πως θα έπρεπε να αναλώσω περισσότερο χρόνο. Αλλά ξέρεις τι ? Νομίζω πως μερικά πράγματα ίσως είναι πιο δύσκολο να τα προνοήσεις, από το να τα βρεις ενώ γράφεις το κώδικα. Σίγουρα άμα αφιέρωνα περισσότερο χρόνο θα σκεφτόμουν και καλύτερα, και θα σημείωνα και περισσότερες λεπτομέρειες, αλλά είναι και αυτός ο ενθουσιασμός που αποκτάς όταν πιστεύεις ότι βρήκες τη λύση, πως να κάνεις κάτι, και θες ευθύς αμέσως να βουτήξεις και να αρχίσεις να το φτιάχνεις...

Θα προσπαθήσω από δω και πέρα να αναλύω πιο διεξοδικά το κάθε project πριν αρχίσω το γράψιμο.

 

@alithinos

Design. Αυτό ψάχνεις.

 

Διάβασε για software design, object oriented design και, επειδή 100% θα σε βγάλει εκεί, Booch.

Έχεις να προτείνεις κάποιες πηγές ?

 

Congrats!

 

Υπόψιν το design είναι πολύ δύσκολη δουλειά να γίνει σωστά, για διάφορους λόγους που νομίζω δεν έχω χρόνο να αναπτύξω τώρα. Και γι' αυτό δεδομένου ότι είσαι και "νέος" στο χώρο παίζει αρκετές φορές να νομίζεις ότι κάνεις design ενώ στην πραγματικότητα κάνεις anti-design. Δε μπορώ βέβαια να ξέρω, αλλά κάτι τέτοιο μου μύρισε η περιγραφή σου.

 

Υπάρχει, λέγεται συσσώρευση γνώσεων και προ πάντων εμπειρίας.

 

Μη σε απασχολεί αν τώρα δε μπορείς να καταλάβεις πώς θα μπορούσες να έχεις σκεφτεί "το σωστό" από την αρχή, γιατί δε θα μπορούσες really. Να σε απασχολεί μόνο το αν μετά από 3 χρόνια αναρωτιέσαι το ίδιο πράγμα για το ίδιο πρόγραμμα.

 

Επίσης έχε υπόψη ότι στη ζωή είναι σπάνιο να σου κάνει κανείς τη χάρη να γράψει τα requirements στις πέτρες του Μωυσή, οπότε ακόμα κι αν κάνεις "το τέλειο design" με την πρώτη, πάλι θα χρειαστεί να το αλλάξεις σύντομα γιατί άλλαξαν τα δεδομένα που σε οδήγησαν εκεί.

 

Δεν υπάρχει απάντηση one size fits all. Τα κριτήριά σου είναι αν αυτός για τον οποίο γράφεις το πρόγραμμα έχει α) ώφελος από την αλλαγή που σκέφτεσαι και β) την πολυτέλεια να ξοδέψεις όσο χρόνο χρειάζεσαι για να την πραγματοποιήσεις. Τώρα που το κάνεις για σένα για εξάσκηση οι απαντήσεις θα πρέπει να είναι ναι και ναι, οπότε δεν υπάρχει όριο.

 

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

 

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

 

Anti-design ? 

Υπάρχει και αυτό ? 

Βασικά η πρώτη ιδέα που θα έρθει για μια υλοποίηση, δεν είναι πάντα η καλύτερη. Η χαρά όμως που παίρνεις επειδή βρήκες πως να το κάνεις να κάνει αυτό που θες, να δουλεύει, μπορεί να κάνει να μη σκεφτείς εκείνη τη στιγμή ότι υπάρχει και ακόμα καλύτερος τρόπος, και να αρχίσεις να το υλοποιείς με αυτό τον τρόπο επειδή 'δουλεύει', και επειδή είσαι ακόμα χαρούμενος και έχεις αυτό το αίσθημα ικανοποίησης, να έχεις για όσο κρατά αυτός ο ενθουσιασμός τη ψευδαίσθηση ότι και ο τρόπος αυτός είναι πραγματικά καλός / αρκεί. Μετά από μερικές μέρες που σου χει περάσει αυτό το συναίσθημα και συνεχίζεις να υλοποιείς, σκέφτεσαι "Μα για κάτσε... Αφού αυτό μπορώ να το κάνω και με τον άλλο τρόπο, και ο άλλος τρόπος ενδεικνίεται ακριβώς για αυτή τη περίπτωση... Γιατί παιδεύω τον εαυτό μου έτσι ?"

 

Άρα είναι λογικό να κάνω τέτοια λαθάκια ε ? Ωραία! 

Χαίρομαι για αυτό.

 

Άρα λοιπόν το μυστικό είναι εργασία και χαρά και μπόλικη εξάσκηση!

Θα τα καταφέρω, που θα πάει...

 

 

 

Υ.Γ. Τελικά μπόρεσα να το κάνω να δουλέψει και μετά το τελευταίο refactor, που με μπέρδεψε. Χθες το βράδυ που προσπαθούσα είχα κολλήσει απίστευτα. Ίσως να είχε κουραστεί και το μυαλό μου από τη μέρα, και να έφταιγε και το ότι ήταν βράδυ...

Με βοήθησε όμως πάρα πολύ η λειτουργία του Virtual Studio που βάζεις τη κόκκινη τελείτσα και εκτελείται ο κώδικας βήμα - βήμα, βλέποντας τι τιμές παίρνουν οι μεταβλητές σε κάθε βήμα.

Χρυσό feature.

Το (αστείο ?) της υπόθεσης είναι ότι σήμερα, με το νέο σχεδιασμό / refactor πλέον, έφτασα το πρόγραμμα σε 1 ημέρα σε επίπεδο που κατά τη πρώτη μου υλοποίηση μου είχε πάρει πάνω από 10 μέρες να το φτάσω. Έχω ήδη γράψει τις βασικές κλάσεις και μεθόδους που πράττουν στα δεδομένα, και εισήγαγα τα δεδομένα για τις πρώτες 8 "περιπτώσεις"!

Ενώ στη δουλειά που είχα κάνει στη πρώτη υλοποίηση που μου πήρε πάνω από βδομάδα, είχα φτάσει μέχρι τις 24 περιπτώσεις.

 

 

Υ.Γ.2. Βασικά ο αρχικός τρόπος εισαγωγής δεδομένων είχε ως εξής: Για κάθε 'περίπτωση' χρειαζόμουν τουλάχιστον 5 τιμές σε συναρτήσεις άλγεβρας boolean, που έβαζα μέσα σε if/elsif, 1 if/elseif για κάθε περίπτωση, οι οποίες if/elseif ήταν με τη σειρά τους μέσα σε κάποιο case μιας switch, γιατί μιλάμε για περίπτωση της περίπτωσης... Συν του ότι έβαζα απόλυτες τιμές σε κάθε if/elseif, δηλαδή πραγματικούς literal αριθμούς.

Έτσι έγραφα μέσα σε κάθε case μια συστοιχία από if/elseif, βάζοντας στις συνθήκες των if/elseif χειροκίνητα τις πραγματικές τιμές.

Ο νέος τρόπος έχει ως εξής: Έφτιαξα μια κλάση για τη κάθε 'περίπτωση', η οποία έχει και τον Constructor της, ώστε να δέχεται απ' ευθείας τιμές κατά την αρχικοποίηση. Ο έλεγχος αντί να γίνεται με πολλαπλές if/elseif και με literal τιμές όπου η κάθε if/elseif θα λειτουργεί μόνο για μια περίπτωση, γίνεται με overloaded operator, και αντί για literal τιμές ορίζονται με ονόματα μεταβλητών που αποκτάν τις τιμές τους κατά την αρχικοποίηση και δημιουργία του αντικειμένου, που σημαίνει πως υπάρχει μόνο μια φορά γραμμένη μια if και μια else, και δεν χρειάζεται να φτιάχνω διαφορετικές if/elseif για κάθε αντικείμενο / υπόθεση.

Έτσι το μόνο που έχω να κάνω πλέον για τη προσθήκη κάθε νέας περίπτωσης είναι να φτιάξω και να αρχικοποιήσω ένα νέο αντικείμενο, δηλαδή να γράψω 1 σειρά κώδικα!    Όχι ολόκληρα κατεβατά!

[M2000]

Με απλά λόγια περνάς έναν ποιοτικό έλεγχο σε δεδομένα και τα φέρνεις διαδοχικά "αντιμέτωπα" με αντικείμενα που θα τα χαρακτηρήσουν. Απέφυγες ένα μεγάλο select case (switch στην περίπτωσή μας), και απλά έχεις ένα αντικείμενο με παρουσίες όσες και οι χαρακτηρισμοί. Δεν κέρδισες τίποτα όμως! Αυτά τα αντικείμενα δεν θα χρησιμοποιηθούν αλλού, αρα δεν υπήρχε λόγος να γίνουν. Θα μπορούσες να είχες struct σε πίνακα και να περνάς κάθε struct από μια διαδικασία ελέγχου.

(μάλιστα σε κάθε struct θα μπορούσες να είχες ένα πεδίο για το επόμενο που θα ελεγχθεί ώστε αν έχεις π.χ. τα

Α, Β, Γ και θέλεις σε κάποια περίπτωση από το Α να πας στο Γ θα μπορούσε το Struct να έδινε ΄"λύση". (Ουσιαστικά η συνάρτηση που θα ενεργούσε βάσει του Struct).

[Alithinos]

Ε όχι και τίποτα!

Ο λόγος που υπήρχε για να γίνουν τα αντικείμενα, είναι ότι έχουν Constructor, που μου επιτρέπει να περνάω όλες τις τιμές της κάθε υπόθεσης σε 1 γραμμή κώδικα.

Συν επιπλέον λόγος ότι στο αντικείμενο μπορώ να χρησιμοποιήσω υπερφορτωμένο τελεστή, ο οποίος κάνει τους ελέγχους boolean, τον οποίο τον έγραψα και αυτόν 1 φορά, αντί του να γράφω το τύπο boolean κάθε φορά σε ξεχωριστή if/elseif.

Από εκεί που για να φτιάξω κάθε νέα υπόθεση έγραφα 8 σειρές κώδικα, τώρα αρκεί μια.

 

Τώρα η εισαγωγή υπόθεσης είναι O(n) όχι O(8*n).

 

Σκοπεύω να γράψω τουλάχιστον 120 υποθέσεις, που σημαίνει ότι το πρόγραμμα μου θα είναι κατά τουλάχιστον 840 σειρές μικρότερο, και θα ολοκληρώσω την εισαγωγή των περιπτώσεων 8 φορές πιο γρήγορα.

((8 * 120 = 960) - 120 = 840)

Δεν το λες και 'τίποτα' αυτό.