Ancora un po’ di teoria ed alcune considerazioni
Eccoci qui di nuovo. Il titolo della lezione suggerisce che oggi inizia l’avventura. Questo è effettivamente vero.
Oggi vedremo cose molto importanti, che ci serviranno per costruire il nostro primo programma.
Iniziamo subito, dunque !.

Riprendendo il discorso iniziato nella precedente puntata, ogni oggetto – oltre ad avere delle proprietà – ha delle “abilità”. Queste abilità sono chiamate “metodi”.

Manca ancora, comunque, un concetto importante ed alcune cose ancora e poi potremo cominciare. Il concetto molto importante che ancora manca è la risposta alla domanda “Quando un oggetto deve eseguire una sua abilità?”.
Ecco, la risposta è “quando un’utente lo chiede”. Tutto il problema consiste, quindi, nello stabilire come accorgersi che l’utente fa le richieste. A questo pensa Delphi tramite gli “eventi”
Un evento è una circostanza che accade mentre un programma è in esecuzione. Ad esempio, la pressione di un bottone del mouse è un evento. Ma anche la pressione di un tasto lo è. Come pure spostare il mouse è un evento.
Il discorso sugli eventi, per ora, è concluso, ma mi riservo di riprenderlo più avanti quando le vostre conoscenze saranno più vaste.

Dicevamo, tante cose sono eventi. Se guardate bene l’Object Inspector, noterete una linguetta con su scritto “Events”.
Guardando bene, vi accorgerete che tutte le voci iniziano per “On”.
Ciò non è un caso, infatti tutti (o quasi) i nomi degli eventi in Delphi iniziano per “On”.

Se premete su quella linguetta, noterete che somiglia molto a quella selezionata di default, chiamata "Properties". Ora, vedrete che tutti i valori sono vuoti. Questo perché noi dovremo attaccare le “abilità” degli oggetti a degli altri metodi che noi creeremo.

Tuttavia, anche in questo caso Delphi non ci lascia soli.
Se infatti si fa un doppio click su uno degli spazi vuoti accanto ai nomi degli eventi, Delphi baderà a creare un metodo, attaccarlo all’evento e predisporre tutto affinché noi possiamo scrivere il codice.
Adesso viene il problema più grosso. Come si scrive il codice?

Uno sguardo approfondito all’Object Pascal
Ogni linguaggio di programmazione ha i propri modi per acquisire input ed esporre output.
L’Object Pascal, ovviamente, non fa eccezione.

Per acquisire un input variabile nel tempo, si usano – appunto – le variabili.
Una variabile è, volendo semplificare, un contenitore adatto solo per un certo insieme di dati.
Per intenderci, non si può usare una stessa variabile per contenere prima il nome e poi l’età di una persona.
Perché sono cose diverse.
Avete presente quei giocattoli per bambini, in cui ad ogni forma corrisponde un solido da incastrare?
Ecco, il discorso è più o meno lo stesso.
Quando si vuole usare una variabile bisogna sempre dichiararla.

Dichiarare una variabile significa sostanzialmente dire a Delphi: “Delphi, guarda che ho bisogno di un po’ di spazio per questo dato”.
Nella dichiarazione s’impone un nome al contenitore.
Il nome del contenitore è spesso indicato come identificatore.
Questo perché il nome di una variabile identifica una variabile stessa in modo univoco.
Ogni variabile, poi, è anche fornita di un tipo.

Un tipo è, semplificando, un insieme di valori che la variabile può assumere.
Un tipo, per esempio, è quello numerico intero che in Delphi s’identifica tramite la parola “integer”, virgolette escluse.
Vediamola, dunque, la dichiarazione di una variabile.

var MioIntero: Integer;

Analizziamo questa dichiarazione.
Prima abbiamo usato “var” che in Delphi indica che si vuole dichiarare una o più variabili.
Per le successive, purché seguano la prima senza soluzione di continuità, “var” si può omettere.
Il “var” si omette anche in altri casi, che vedremo più avanti.

Adesso, prima di proseguire, vorrei soffermarmi su un punto cruciale: i nomi delle variabili.
I nomi dati alle variabili sono importantissimi, perché da soli contribuiscono per un buon 60% alla comprensione di un programma.
Usare dei buoni nomi di variabili significa in seguito uno sforzo nettamente inferiore a quello effettuato usando nomi di variabili non buoni.
Sforzo in che?
Nella manutenzione ad esempio, oppure nell’identificazione dei bug.
I nomi, inoltre, dovrebbero sempre essere in inglese per le ragioni di cui abbiamo discusso nella lezione precedente.

Adesso vi do una dimostrazione pratica di come i nomi di variabile possano semplificare di molto la comprensione di un pezzo di codice. Osservate i seguenti pezzi di codice:

R1:= -b+Sqrt (Sqr (b) - (4*a*c);

Result1 := -CoefficientB + Sqrt (Sqr (CoefficientB) - (4*CoefficientA*CoefficientC);

Quale dei due è più comprensibile? In questo caso sembrerebbe il primo, perché la formula risolutiva di un’equazione di secondo grado si riconosce subito in quanto abituati a quella simbologia.

Ma io mi domando: “E se quelle variabili rappresentassero qualcosa di diverso da un’equazione di secondo grado?” Possiamo essere assolutamente certi, senza alcun’ombra di dubbio, che il primo rappresenti proprio quello?
No, per niente. Il fatto che siamo abituati a vedere le cose in un certo modo, non significa per nulla che sia sempre giusto.

Per il momento vi saluto, la prossima lezione vedremo come si crea una semplice interfaccia utente per il nostro primo programma. Daremo quindi uno sguardo più attento alla “palette dei componenti” e gradualmente ci tufferemo nello sviluppo della nostra prima applicazione.

Alla prossima !.

Torna all'indice Generale del corso di Corso di Delphi di Software Planet