6
« il: 10 Luglio 2008, 00:42:32 »
Giusto per fare chiarezza a chi legge: la programmazione a cicli non esiste come paradigma; l'RPG (di un tempo) rientrava nella programmazione sequenziale in cui il flusso (input->calcolo->output) era gestito da un ciclo logico infinito, mentre oggi la sua evoluzione l'ha portato ad essere un linguaggio procedurale.
(correggimi tu se dico castronate che di RPG ne sai sicuramente _molto_ piu' di me:).
Ma veniamo al topic, per quanto di (poca) competenza posso risponderti, cercando di essere il piu' chiaro possibile.
"A cosa servono gli oggetti?" "A cosa possono servire in un caso pratico le classi?"
Cerco di risponderti al "domandone filosofico" :) illustrandoti i concetti fondamentali dell'OOP e le differenze di fondo con la programmazione procedurale/modulare.
Come sicuramente sai, elementi indispensabili della programmazione sono le strutture dati e le funzioni; l'insieme di questi costituisce una classe, ovvero un "modello/template" (giusto per fare un riferimento molto azzardato, pensa ai tipi di dati definiti dal programmatore nei linguaggi procedurali) dotato dunque di proprieta' "proprie" (strutture) e procedure (metodi). La classe rappresenta dunque un elemento "astratto", che si concretizza in oggetto qualora sia istanziato (detta in soldoni, una classe non occupa memoria, un oggetto si)
Fin qui puo' sembrare solo una questione di organizzazione di codice (una sorta "creazione di modelli") ma, per quanto detto, puoi capire come la classe e' un "contenitore" di dati che detiene anche le regole (metodi) per potere gestire tali dati, e come dunque la modifica di un singolo modello possa generare modifiche globali in modo ordinato, logico e senza workaround particolari a tutti gli oggetti di tale classe nell'intero progetto. Tale caratteristica in OOP viene detta incapsulamento (proprio per il fatto dell'avere dati e metodi per gestirli all'interno dell'oggetto stesso). Sempre per riferimento, pensa invece alla gestione procedure<->dati nella programmazione procedurale/modulare e come la divisione tra questi elementi sia un dramma in fase di mantenimento del software... E sempre in questo contesto, tieni presente un'altra grande differenza/pregio dell'OOP rispetto alla programmazione procedurale/modulare: i dati di un oggetto vengono gestiti/modificati esclusivamente dall'oggetto stesso, poiche' un secondo oggetto vi accede solo ed esclusivamente attraverso i metodi del primo, e non direttamente...
La seconda caratteristica degli oggetti e' l'ereditarieta', ovvero la possibilita' di derivare una sottoclasse da una classe, e non e' cosa da poco. Esempio astratto: definisci la classe "frutta" e quindi ne scrivi il modello con tutte le sue proprieta' e le sue regole; se ora devi definire la classe "mela" non parti da zero, ma erediti tutte le proprieta' della classe "frutta" ed agisci esclusivamente sulle proprie esclusive della classe "mela". Capisci anche qui che se, a stadio avanzato del progetto, devi fare una modifica alla "frutta" non devi necessariamente andare a mettere mano alle eventuali "mele" "pere" "fichi" che hai nel progetto. Una delle possibilita' (ovvero la terza caratteristica fondamentale dell'OOP) di agire "solo sulle proprieta' della mela" e' quella di modificare i metodi ereditati per farli propri a seconda dell'esigenze della sottoclasse; questa caratteristica si chiama polimorfismo.
"Si può programmare in Gambas, e in altri linguaggi OO, senza usare gli oggetti e le classi?"
Sarebbe come avere la bici elettrica ed usarla a pedali :)
Comunque si, si puo' fare. Basta scrivere in procedurale/modulare.
"Esiste un 'modo' migliore per usare le classi?"
No, dal momento che le classi sono delle entita' astratte, dei modelli.
Spero di essere stato il piu' chiaro possibile e di aver scritto il minor numero di castronerie possibile :D
ciao
Visualizza post