Finalmente ci siamo!
Dopo mesi di pensieri accatastati e svariate (mentali) interrogazioni parlamentari, ecco il post 0 che inaugura questo blog. Il primo di una (mi auguro!) lunga serie per approfondire principalmente la tematica della programmazione ad oggetti declinata al mondo LabVIEW*.
Bene, ora non ci resta che partire.
A differenza di altri linguaggi nativamente ad oggetti come Java e C#, Labview non lo è. Il supporto al mondo OOP in LabVIEW è stato introdotto nel 2006, con LabVIEW 8.2. Nonostante dal 2006 a oggi siano passati quasi 20 anni, alla luce della mia esperienza e dalle chiacchiere scambiate con altri programmatori LabVIEW, ho realizzato che la programmazione ad oggetti è, almeno in Italia, ancora poco praticata.
A mio avviso, le ragioni di questo sono principalmente due. In primis, la forma mentis di noi programmatori LabVIEW. Come dicevo qualche riga fa, le classi in LabVIEW sono disponibili dal 2006 e molti programmatori che hanno iniziato a utilizzare questo linguaggio di programmazione da prima si sono abituati a programmare secondo il metodo “classico”. Va da sé che spesso le nuove leve di programmatori, ricevendo una formazione dagli ante-oop, si abituano al metodo classico precludendosi la possibilità di conoscere modi alternativi e senza dubbio più potenti per l’implementazione delle proprie applicazioni. Altra ragione per cui la OOP è poco pratica è perché spesso il neo programmatore LabVIEW non ha un background informatico e impara a programmare in un contesto non informatico. LabVIEW è infatti spesso usato in laboratori, centri di ricerca, e reparti di controllo qualità perché preferito ad altri linguaggi data la sua naturale facilità, velocità e versatilità nel dare vita ad applicazioni di testing (acquisizione, elaborazione e visualizzazione dati). In questi contesti, la programmazione ad oggetti corre il grosso rischio di rimanere in panchina.
I detrattori della programmazione ad oggetti potrebbero facilmente contestare che un software possa essere benissimo sviluppato anche senza l’approccio OOP. Questo è vero ma il mancato utilizzo di questo paradigma è limitante. Nell’immagine che segue ho sintetizzato i vantaggi forniti dall’approccio OOP.
Migliore manutenibilità del codice
Riusabilità del codice
Migliore modularità degli applicativi
Sviluppo software condiviso
Migliore gestione dei progetti
Progettazione naturale
Come illustrato sopra, l’approccio OOP permette quindi di ottenere codice modulare garantendo lo sviluppo condiviso sullo stesso progetto software. In aggiunta, il codice è più facilmente manutenibile, più pulito e ordinato e allo stesso tempo la gestione dei progetti risulta più semplice. Infine, l’approccio OOP fornisce un supporto naturale alla modellazione software degli oggetti del mondo reale o del modello astratto da riprodurre il ché semplifica di molto la progettazione. Per esempio, supponendo di dover creare un software per la gestione dei prestiti bibliotecari, è probabile che si renda necessario definire le classi Libro, Prestito e Persona (o Utente).
E con questo per ora è tutto. Ci vediamo al prossimo post.
Nel frattempo, lascio qui sotto un paio di link di approfondimento sul tema:
- LabVIEW Object-Oriented Programming: The Decisions Behind the Design
- LabVIEW Object-Oriented Programming FAQ
* Per brevità, quando parlo di LabVIEW faccio riferimento al linguaggio G di cui LabVIEW è l’unico ambiente di sviluppo.
