Casino online

Mercato forex

La maggior parte degli aspiranti programmatori che vedo non sa cosa sia una classe. Questo implica il non sapere costruire un'applicazione ottimale, perchè tutto quello che riguarda il .net si basa sulle classi e sugli oggetti. In questo breve articolo spiegherò quello che, secondo me, costituisce il modo migliore di sviluppare un programma.


Un programma si può dividere essenzialmente in due parti: il Data Layer e il GUI Layer. Il primo riguarda tutto il codice svolto dall'applicazione e in generale ogni cosa che non viene a contatto diretto con l'utente; il secondo, invece, riguarda proprio l'interfaccia e tutte quelle parti di codice finalizzate a mediare l'interazione tra utente e software. Quest'ultima parte è anche quella che svolge il lavoro di "bassa manovalanza", ad esempio visualizzare gli errori con message box, aggiungere elementi alle liste, caricare un elenco, modificare delle label, eccetera... Il Data Layer, d'altra parte, costituisce la vera fonte di controllo di tutta l'applicazione, ed è quella tramite la quale si può capire meglio lo stile del programmatore e in cui egli mette le sue idee migliori. Canova l'aveva capito: faceva scolpire il marmo ai suoi studenti fino a che la figura non fosse abbozzata e poi interveniva lui stesso a rifinire i dettagli e in generale ciò che poteva fare solo lui e nessun altro. Il programmatore deve svolgere entrambi i compiti, ma la sua abilità si evidenzia nel primo strato.


Il primo passaggio da fare è ovviamente avere un'idea sulla quale costruire l'applicazione. Non si arriva da nessuna parte se l'obiettivo non è ben chiaro, e spesso è proprio questo che manca. L'idea è una fase della scala che riguarda principalmente la programmazione "per passione", ossia quella degli autodidatti come me, e solo in minor parte coloro che programmano per professione. Un cliente non sarebbe contento nel sentirsi dire che quello che chiede starebbe meglio posto in altro modo, ma indubbiamente quando un ingegnere si sente proporre una commissione, deve prima ipotizzare un buon modo di svolgere tutto quello che gli viene chiesto.


Prima di partire in quarta a scrivere, bisogna soffermarsi su un'importantissima questione, quella della fattibilità. Non tutti i programmi pensabili sono anche fattibili (mentre è vero il vicevesra). Infatti, una volta ottenuta l'idea di base bisogna innanzitutto controllare che si abbiano i mezzi per portare a termine ogni sua parte. Ad esempio, vi viene in mente di creare un programma per monitorare tutti i processi sul sistema e per poterne leggere il contenuto. Pensate di conoscere bene come fare, ma vi sfiora per un momento la domanda "e come faccio a leggere il contenuto?", a cui subito dopo rispondete "in qualche modo farò, ci penserò dopo". Niente di più sbagliato. Se non sapete prima esattamente come e cosa fare, non vale neanche la pena di iniziare. Per questo, è necessario documentarsi prima di iniziare il lavoro, o si correrebbe il rischio di arrivare a metà dell'opera e accorgersi di non potere continuare, e di aver, quindi, buttato via tempo e fatica. Non riuscendo a reperire niente su google (il che significa o che quello che state cercando di fare è impossibile, o che non avete cercato abbastanza), potete sempre chiedere da qualche parte, ad amici o su forum.


Una volta appurato che tutto quello che avete pensato è anche possibile in pratica, non resta niente altro da fare che iniziare a scrivere, no? No, non ancora. Questo passaggio è quello meno considerato, o del tutto ignorato. L'analisi vi permette di pensare prima a come strutturare l'applicazione e, visto che stiamo parlando in un linguaggio fortemente OOP, di come formare la sua struttura di classi. È importante che ogni entità logica sia racchiusa in un wrapper fisico, ossia in una classe; che i vincoli di ereditarietà siano pertinenti, qualora esistano; che i namespace raggruppino logicamente insiemi di classi che lasciare amassate sarebbe impensabile. Ad esempio, se state pensando di creare un gioco di ruolo, come farete a rappresentare una creatura? e gruppi di creature? e il giocatore? E ancora: quale relazione ci sarà tra le creature? Attraverso quali classi il giocatore disporrà di un equipaggiamento? Quale sarà il modo migliore di rappresentare un singolo oggetto di gioco? Che raggruppamenti logici mi conviene adottare? Come gestirò le risorse? e i salvataggi? E si potrebbe andare avanti per molto tempo...
Tutte le domande sopra citate sono solo esempi di quei processi che si dovrebbero seguire neanche durante, ma addirittura prima della fase di sviluppo. La strutturazione mediante classi è una caratteristica che fin'ora non ho ancora incontrato nei programmi che ho visto (con l'eccezione, forse, di due o tre applicazioni non da poco), mentre dovrebbe costituire il pilastro fondante della programmazione. È anche utile costruire grafici, diagrammi e schemi di tutti gli oggetti esistenti: l'ideale sarebbe modellarli usando UML, il linguaggio descrittivo ufficiale per la modellazione di programmi OOP.
E non finisce qui: l'analisi non implica solo pensare sul piano formale, ma anche su quello contenutistico. Non soltanto cosa e dove, ma anche come e perchè: queste sono le domande a cui bisogna porre risposta. La creazione di algoritmi nuovi e originali, l'invenzione di formule particolarmente azzeccate, l'implementazione di metodi non ancora sperimentati o di idee che vi vengono durante le lezioni di storia dell'arte (può capitare). Questo è il nocciolo - il kernel, con un gioco di parole - della programmazione.


Tutto ciò che è stato prima pensato deve poi anche essere messo in pratica, ed è qui che in molti casi si riscontrano i problemi peggiori. Quando quello che avete in testa comincia a non coincidere con quello che fa il computer, allora iniziano i guai, e la caccia all'errore. Ricordate che il computer è un asino veloce; non può "sbagliare" (relativamente al codice), ossia non può non fare ciò che è stato scritto dal programmatore, perciò sappiamo benissimo di chi è sempre la colpa. Ma questo fenomento è arginabile, e i casi possibili sono questi:

• Appare un'eccezione: nel caso migliore, avrete che il codice genera un'eccezione. Quindi potrete disporre non solo di una descrizione dettagliata del problema, ma potrete anche sapere il punto preciso in cui essa di genera, e i valori degli oggetti che sono coinvolti nell'esecuzione del codice. Tutti questi fattori permettono una risoluzione veloce nella maggior parte dei casi. Quando invece le eccezioni si fanno più vaghe (esempio classico: "A generic error occurred in GDI+"), allora è necessario prendere contatti con qualcuno di più esperto
• Il programma "non fa quello che volete": inutile dirlo, la colpa è sempre vostra. Questi errori sono i più infidi, poiché non si conoscono bene le circostanze del codice, e si può solo ipotizzare di aver sbagliato in qualche punto. Spesso capita che manchi qualche piccolo segno, o che una parola sia presa per un altra. Non per niente, è caduto uno shuttle per un trattino mancato nel codice che gestiva il direzionamento dei razzi. La cosa migliore da fare è rileggere il codice, "compilandolo mentalmente", ossia pensando a cosa dovrebbe fare il computer per ogni singola operazione scritta: in questo modo si evidenziano tutte le incongruenze. Ricordate sempre di non dare niente per scontato, e rileggete anche il codice di cui siete sicuri, poiché è lì che spesso si nasconde lo sbaglio. Se al momento non riuscite a trovare soluzione, riposate qualche giorno e accostatevi al codice dopo aver distolto la mente dal programma: essendo meno coinvolti nel sorgente, si potrà notare ciò che prima era sfuggito

Durante questa fase bisognerebbe anche mettere in conto la questione della riusabilità: ossia, il codice dovrebbe essere scritto in maniera tale da essere svincolato dall'applicazione in sé, in modo da poter essere riutilizzato in altri programmi senza bisogno di riadattarlo o modificarlo, ma semplicemente importandolo nel progetto. Questo aspetto della programmazione è già stato analizzato nella mia guida e viene anche definito incapsulamento.


Una volta scritto il codice, o una sua parte, si rende necessario controllare che esso funzioni e, prima di tutto, ipotizzare una vastissima gamma di situazioni possibili in cui si potrebbe trovare, in modo da arginare tutti i possibili inconvenienti. Dopo aver eseguito un debug superficiale, per fixare i bachi più gravi e vistosi, è buona regola mostrare e far provare l'applicazione ad altri, non necessariamente persone che conoscono l'informatica (e, anzi, queste persone sono la migliore cavia). Così facendo verranno evidenziati gli errori che sono sfuggiti al programmatore e che - quasi sicuramente - si manifesteranno al debutto del software quando meno ve l'aspettate.


Nel caso in cui il codice scritto sia reperibile e usabile da terzi, è quasi un must scrivere una documentazione approppriata, usando gli opportuni attributi xml che ho anch'essi esposto nell'ultima sezione della guida. Ogni metodo, proprietà o membro in generale dovrebbe essere documentato, ossia provvisto di una descrizione esaustiva del suo compito e della funzione di ogni sua parte. Solo in questo modo gli altri sviluppatori saranno in grado di sfruttare al meglio le potenzialità di un codice ben scritto.


In realtà ci sarebbe anche l'aspetto della manutenzione del software, ma questo si può far ricadere sotto le categorie Implementazione e Debugging. Arrivati a questo punto, quindi, si termina il ciclo di costruzione del software e si è pronti per la pubblicazione. Seguite queste regole, che sono essenziali per la buona riuscita di un'applicazione.