Libro "VB 2010 spiegato a mia nonna" (14)

Il programma per guidare

Abbiamo fatto l’esempio dell’automobile e quindi ci viene spontaneo pensare a come potrebbe essere formulato un programma per guidare.

Nel programma dovremmo avere una sequenza di istruzioni per avviare il motore, per innestare la marcia, per avviare l’automobile, per inserirci nella carreggiata, per accelerare o rallentare, per accostare, per fermarci, per spegnere il motore e altro.

Non basta: nel momento in cui l’automobile è in movimento sulla strada, ci saranno, probabilmente, anche molti altri oggetti-automobile sulla stessa strada, oltre a oggetti-pedone, oggetti-autobus, oggetti-sbarre del passaggio a livello. Non finisce qui.

Dovremo anche prendere in considerazione la variabilità della strada: buche nell’asfalto, divieti o sensi unici, curve, incroci, passaggi pedonali, segnalazione  verticale (cartelli e semafori) o orizzontale (strisce), condizioni climatiche, condizioni di
luce (giorno-notte), condizioni di traffico.

Tutte le situazioni che si presentano sulla strada, davanti a noi, dietro di noi, a destra e a sinistra sono eventi che possono condizionare molto la nostra possibilità di movimento o di comportamento alternativo al semplice “andare avanti”.

Queste alternative sono quelle che, nei linguaggi di programmazione, sono chiamate istruzioni di scelta: in alcuni punti dei programmi è necessario decidere quale delle varie possibilità bisogna prendere in considerazione.

La decisione che sarà presa nell’ambito del programma dipenderà da vari fattori: lo stato attuale dell’oggetto o degli oggetti interessati e, in alcuni casi, la scelta dell’utente.

Nella vita reale, spesso, ci poniamo delle domande, anche inconsciamente, le cui risposte possono essere positive, negative o… una via di mezzo, perché le cose non sono mai solo bianche o nere ma possono avere varie sfumature di grigio.

Per un computer il grigio non esiste (tranne nei colori dello schermo!). Infatti, le scelte hanno in ogni caso una risposta riconducibile a due sole possibilità: vero o falso.

Le risposte “vere a metà” o “un po’ false” per il computer non esistono, perché non sa in alcun modo interpretare queste sottili sfumature.

Tornando alle nostre istruzioni di scelta, il percorso spesso si divide in due strade diverse: se la risposta è vera si prosegue verso un’istruzione, se è falsa si prosegue verso un’istruzione diversa.

In alcuni casi le scelte possono essere anche più di due. Supponiamo, per esempio, che il nostro lavoro si svolga in un ciclo settimanale di cinque giorni:

  1. tutti i Lunedì registriamo gli ordini di acquisto che arrivano dai clienti;
  2. tutti i Martedì andiamo in magazzino e prepariamo le merci da spedire;
  3. tutti i Mercoledì emettiamo e registriamo le fatture;
  4. tutti i Giovedì consegnamo i pacchi e le fatture al corriere per le consegne;
  5. tutti i Venerdì registriamo i pagamenti.

Se dovessimo scrivere un programma in grado di offrirci un piano di lavoro della giornata, potremmo scrivere qualcosa del genere (in linguaggio naturale):

Che giorno è oggi?
   Se è Lunedì:
      registrare gli ordini
   Se è Martedì:
      preparare le merci


Oppure potremmo considerare ciascuna scelta individualmente:

Oggi è Lunedì?
   Se sì: registrare gli ordini
   Se no: ignora
Oggi è Martedì?
   Se sì: preparare le merci
   Se no: ignora

In genere si preferisce la prima forma, perché è più strutturata e quindi anche più comprensibile ed efficiente. Nulla ci vieta, tuttavia, di preferire la seconda forma, quando le condizioni di scelta sono più complesse o quando si ritiene che si possa ottenere maggiore comprensibilità nel flusso del programma.

Un altro tipo di flusso di esecuzione è quello costituito dalla ripetizione di una o più istruzioni. Si definisce un blocco di istruzioni che devono essere eseguite un certo numero di volte oppure che devono essere eseguite finché non cambia una condizione (ovvero lo stato di un oggetto).

Se prendiamo in considerazione le azioni di una certa giornata del caso precedente, per esempio il Lunedì, il programma potrebbe essere strutturato come segue:

Prendi il pacco di ordini;
Inizia dal primo ordine;
Per ogni ordine:
   Inserisci i dati anagrafici del cliente
   Inserisci i dati dell’ordine
   Per ogni riga dell’ordine:
      Inserisci il codice del prodotto
      Inserisci la quantità ordinata
   Ripeti finché ci sono altre righe
   Conferma l’inserimento
   Sposta l’ordine in un altro pacchetto
Ripeti finché ci sono altri ordini
Archivia gli ordini

Se la struttura del programma diventa troppo complessa o se il gruppo di istruzioni deve essere eseguito in varie parti del programma, è opportuno definire un sottoprogramma, cioè una subroutine (Sub) o una funzione (Function):

Prendi il pacco di ordini;
Inizia dal primo ordine;
Per ogni ordine:
   Passa a SUB Inserisci i dati
   Sposta l’ordine in un altro pacchetto
Ripeti finché ci sono altri ordini
Archivia gli ordini

SUB Inserisci i dati
   Inserisci i dati anagrafici del cliente
   Inserisci i dati dell’ordine
   Per ogni riga dell’ordine:
      Inserisci il codice del prodotto
      Inserisci la quantità ordinata
   Ripeti finché ci sono altre righe
   Conferma l’inserimento
Ritorna

Se in un altro punto del programma dobbiamo eseguire le stesse istruzioni, non abbiamo la necessità di riscrivere nel programma principale la sequenza di istruzioni elementari necessaria, ma possiamo invece avvantaggiarci del fatto che nel programma principale possiamo semplicemente fare una chiamata al sottoprogramma “Inserisci i dati”.

Ci sono due principali vantaggi in questo modo di operare: prima di tutto non complichiamo il programma principale con tutti i dettagli, rendendolo molto più leggibile e comprensibile; secondariamente, potremmo in futuro cambiare la sequenza di istruzioni che compone il sottoprogramma senza modificare in alcun modo il programma principale.

Infatti, nel sottoprogramma si potrebbe cambiare l’ordine di esecuzione delle istruzioni oppure si potrebbe definire una sequenza di istruzioni completamente diversa.

(…segue…)

Fonte: Cap. 1 – libro “Visual Basic 2010 spiegato a mia nonna”, Edizioni FAG Milano, Autore Mario De Ghetto, 2011, http://bit.ly/NRO6Cn.

Pubblicato il 28 luglio 2012, in Programmazione, VB2010SAMN, VS 2010 con tag , , , , . Aggiungi il permalink ai segnalibri. Lascia un commento.

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

%d blogger cliccano Mi Piace per questo: