Τον τελευταίο καιρό με προβληματίζει αν η χρήση Public static (αντικειμένων,συναρτήσεων μπλα,μπλα) είναι μια σωστή τακτική.
Ας υποθέσουμε ότι έχω μια εφαρμογή η οποία, πέραν του GUI, έχει από πίσω της βαρύ αλγόριθμο που θα χρειαστεί πολλές συναρτήσεις και πεδία.
 Ήδη ο κώδικας της φόρμας είναι βεβαρυμένος από το GUI και θέλω τις συναρτήσεις αυτές να τις βάλω σε ξεχριστή κλάση και αρχείο(είτε για
readablity είτε για modularity). Φυσικά σε αυτό το αρχεία θα είναι Public static.
Άλλωστε πρόκειται  να επιτελούν μια ιδιαίτερη λειτουργία που δεν δεσμεύεται απαραίτητα μόνο με αυτό το GUI.

Ποιά είναι η άποψή σας για μια τέτοια τακτική? Γενικά για  τα public static?

Γενικά δύο τρόποι υπάρχουν για να εκτελείς κάτι έχοντας ένα (ή κανένα) instance της κλάσης σου ενεργό:

- Static (ή shared στη VB)
- Singleton design pattern

Με τον πρώτο τρόπο δεν έχεις απολύτως κανένα instance.
Με τον δεύτερο, έχεις ακριβώς ένα instance.

Άποψή μου είναι οτι ενδείκνυται η χρήση static μεθόδων (η και κλάσεων, στο .NET 2.0) όταν δεν σε ενδιαφέρει κανένα είδος state για την κλάση σου. Ητοι, οι κλήσεις που κάνεις στις μεθόδους σου έχουν την έννοια των "εντολών" (commands) οι οποίες είναι αυτόνομες και τελειώνουν εκεί χωρίς να επηρεαζουν άλλα πράγματα που πιθανώς ανήκουν στην κλάση.

Οταν όμως σε ενδιαφέρει το state, δηλαδή υπάρχουν member variables στην κλάση αυτή τα οποία αλλάζουν τιμή σύμφωνα με τις κλήσεις σου, και ενδεχομένως να θέλεις να κρατήσεις παλαιά states (αποθηκεύοντάς τα με κάποια μορφή serialization ή κάνοντας οτιδήποτε άλλο με αυτά) με σκοπό να τα ξαναχρησιμοποιήσεις αργότερα, τότε ενδείκνυται η singleton. Επίσης όταν παίζεις με serviced components, απο ο,τι θυμάμαι (διορθώστε με αν κάνω λάθος) δεν έχεις άλλον τρόπο.

Τωρα, υπάρχει το εξής θέμα: Αν η εφαρμογή σου είναι multi-threaded και πολλά threads καλούν ταυτόχρονα τις μεθόδους της κλάσης σου, ίσως θα πρέπει να σκεφτεί κανείς να μην χρησιμοποιήσει ούτε static ούτε singleton pattern, αλλά κανονικά instances. Βεβαια, αυτό εξαρτάται κάθε φορά από το context.

---

Σωτήρης Φιλιππίδης

DotSee Web Services

Θα ήθελα να μπορούσα να σου απαντήσω με πιο επιστημονικό τρόπο, αλλά τελικά θα σου το πω όσο πιο απλά μπορώ...

Δεν έχεις κανένα λόγο να μην  χρησιμοποιείς static methods. Το σκεπτικό είναι ότι εφόσον δεν απαιτείται για μια διαδικασία η δημιουργία ενός instance τότε δεν υπάρχει λόγος να την απαιτήσεις εσύ με τον κώδικά σου.

Πάρε ένα απλό παράδειγμα: Ας πούμε ότι έχεις μια κλάση η οποία υποστηρίζει την δημιουργία αντικειμένων που αναπαριστούν μήλα (class Apple). Όταν θέλεις μια μέθοδο η οποία θα τεμαχίσει ένα μήλο σε φέτες (π.χ. public Slice[] Slice(int NumberOfSlices)), τότε απαιτείται να χρησιμοποιήσεις μια instance method αφού θα πρέπει κάθε φορά να τεμαχίζεις ένα συγκεκριμένο μήλο. Αν όμως θέλεις μια άλλη μέθοδο η οποία θα φτιάχνει ένα νέο μήλο "κολλώντας" διάφορες φέτες μεταξύ τους, τότε δεν χρειάζεσαι το instance κάποιου μήλου για να κάνεις την δουλειά. Στην  περίπτωση αυτή είναι πιο κομψό να χρησιμοποιήσεις μια static method. (π.χ. public static Applie CreateFromSlices(Slice[] Slices)). Αν στην συγκεκριμένη περίπτωση δεν χρησιμοποιούσες static method τότε για να "κολλήσεις" τις φέτες θα έπρεπε πρώτα να φτιάξεις ένα instance ενός μήλου που στην πραγματικότητα θα σου ήταν άχρηστο. Θα το χρησιμοποιούσες μόνο και μόνο για να έχεις ένα entry point για την instance method. Δεν έχει νόημα και είναι και πιο αργό αν το βάλεις σε loop.

Static methods are μια χαρά...

Το πρόβλημα που σου προκύπτει εσένα δεν έχει να κάνει με τις static methods τόσο πολύ όσο με τον διαχωρισμό του presentation layer (GUI) από το business layer που πολλές φορές ειδικά όταν γράφεις για WinForms είναι εύκολο να σε μπερδέψει. Θα το ξεδιαλύνεις καλύτερα όταν αρχίσεις από τον Business Logic Layer (ή όπως αλλιώς θες πές τον). Γράψε πρώτα κλάσεις που κάνουν τις δουλειές που θέλεις άσχετα με το GUI. Forget GUI for a moment... Δεν χρειάζεται καν να κάνεις το πλήρες implementation. Φτιάξε το όμως έτσι που να είναι προφανές το ποια κλάση κάνει ποια δουλειά και γιατί. Θα δεις ότι τελικά οι φόρμες σου μπορούν να γραφτούν απλά και ο κώδικα που δεν πρέπει να βρίσκεται εκεί δεν μπει σε λάθος μέρος γιατί η δομή του κώδικά σου θα είναι στημένη από την αρχή με βάση την λογική του προβλήματος που πας να λύσεις και όχι την λογική του GUI των Windows.

φιλικά
rousso

υ/γ: Βέβαια πάντα υπάρχει καλύτερος τρόπος και μην αρχίσεις να παίρνεις το παράδειγμα τοις μετροιτοίς... Π.χ. Στο παράδειγμά που σου έφερα εφόσον η CreateFromSlices επιστρέφει Apple τότε θα μπορούσες να την φτιάξεις και ως instance method η οποία αντί να δημιουργεί ένα νέο μήλο να τροποποιεί τον εαυτό του κλπ... Μην μπεις σε αυτή την λογική γιατί θα χάσεις το point.

 

---

rousso

Χρησιμοποιώντας στατικές μεθόδους χάνεις το βασικότερο πλεονέκτημα του OOP, το inheritance και ως συνέπεια μελλοντική επεκτασιμότητα του προγράμματός σου. Αυτό δεν σημαίνει οτι οι στατικές μέθοδοι είναι evil, το πλεονέκτημά τους είναι οτι είναι global, τις καλείς απο οπουδήποτε (π.χ. εγώ τις χρησιμοποιώ για εύκολο και γρήγορο logging ή για να κρατάω connections σε μια βάση κ.α.).

Ακριβώς αυτό σκεφτόμουνα. Εφόσον δεν υπάρχει η ανάγκη για objects γιατί πρέπει σώνει και καλά να δημιουργήσω? Είπαμε κάνουμε OOP αλλά γιατί δημιουργούμε μπελάδες από κεί που δεν υπάρχουν.

Συνήθως, όπου αρχίζουν να μαζεύονται πολλές static, κάπου πρέπει να μαζέψεις σε objects ή σε controllers και δεν το έχεις καταλάβει ακόμα. Συνήθως οι περισσότερες από αυτές παίζουν με τα ίδια η παρεμφερή δεδομένα.

Ένας λόγος για να τις μαζέψεις πχ σε controllers, είναι το performance. Πχ. Κάθε μία από αυτές δέχεται μερικές παραμέτρους. Αν θέλεις να είσαι απόλυτα σωστός, η κάθε μία θα πρέπει να κάνει τους δικούς της εξαντλητικούς ελέγχους σε όλα τα δεδομένα που παίρνει πριν αρχίσει να κάνει την δουλιά για την οποία δημιουργήθηκε. Αν καταφέρεις και ομαδοποιήσεις κάποιες από αυτές πάνω σε ένα controller, τότε μπορείς να κάνεις validate τα κοινά input parameters στο initialization του controller και να γλυτώσεις πολλαπλούς ελέγχους για τα ίδια δεδομένα.

Επιπλέον, το να είναι πάνω σε κάποιο object σου δίνει τη δυνατότητα να επωφελείσαι από inheritance για διαφοροποιήσεις.

Σαν μεθοδολογία θα σου πρότειτα το εξής. Διατήρησε τα statics σου με πολύ καλή οργάνωση και κάνε τους τακτικό refactoring ώστε να έχεις πάντα όσο το δυνατόν μεγαλύτερη ομοιογένεια. Κάποια στιγμή θα μιλήσουν μόνες τους και θα καταλάβεις που και πως πρέπει να μετακινηθούν πάνω σε objects.

Κάνε post πάντως μερικά ονόματα από τις functions σου μήπως μας κάνει κάτι click...

---

Χρήστος Γεωργακόπουλος