Χμμ .. το abstract class δεν έχει άμεση σχέση με web development, ή client development κτλ κτλ.
Η έννοια είναι κοντά σε αυτή του interface, με τη διαφορά ότι το abstract class έχει και κώδικα μέσα. Π.χ. ...
Πες ότι έχω μια σελίδα, η οποία παίρνει δεδομένα απο 4 web services, τα οποία μετά δείχνει στη σελίδα. Και σαν "καλός" developer, σκέφτομαι ότι θα ήταν καλή ιδέα αυτόν τον κώδικα που μιλάει στο εκάστοτε web service, να τον υλοποιήσω μέσα σε κλάσσεις, κι όχι μέσα στο ίδιο το aspx ή code behind.
Άρα ... κάθε τέτοια κλάσση, θα έκανε περίπου τα ίδια πράγματα - φτιάχνει τον proxy στο εκάστοτε web service, κάνει την κλήση για να πάρει δεδομένα, τα επεξεργάζεται, σκοτωνει τον proxy, και επιστρέφει τα "επεξεργασμένα" στη σελίδα.
Αν έχω 4 - 5 διαφορετικά web services, άρα και 4 - 5 διαφορετικές κλάσσεις για να τους μιλάω, όλες οι κλάσσεις θα κάνουν τα παραπάνω πράγματα. Τα περισσότερα απο αυτά είναι κοινά. Οι μόνες διαφορές τους είναι το "φτιάξε τον proxy", "κάνε την κλήση", "επεξεργάσου τα δεδομένα". Η βασική λειτουργικότητα απο κάτω είναι κατα τ' άλλα η ίδια.
Σε κάποιο τέτοιο σενάριο λοιπόν, είναι σχετικά λογικό να γράψω μια abstract class η οποία υλοποιεί τα "κοινά" μέρη, και αναγκάζει το developer που θα κάνει inherit απο αυτή να υλοποιήσει μόνο τα "διαφορετικά" κομμάτια. Έτσι, κρατάω τον έλεγχο της υποδομής, και βάζω το developer να γράψει μόνο αυτα που χρειάζεται να γράψει.
Ένα επίσης προτέρημα είναι ότι έχοντας υλοποιήσει έτσι την εφαρμογή, μπορώ να πάω σε αυτή την κλάσση αργότερα, και να βάλω διάφορα πραγματα μέσα - πχ. logging, execution time statistics κτλ κτλ - και με μια μόνο αλλαγή, έχω "καθαρίσει" για 4 - 5 κλάσσεις
...
ίσως δεν είναι και το καλύτερο παράδειγμα για ένα abstract class, αλλά τι να περιμένεις μεσημεριάτικα ...
Angel
O:]