Lo sviluppo della classe principale, cioè SortItem (che si occupa
in sostanza di generare un array di numeri random e della parte grafica
che rappresenta i numeri sotto forma di linee orizzontali che si vanno
ordinando) comincia prendendo come riferimento l'applet
di James Gosling.
Questa applet risalta subito per essere molto piccola
e, per questo, poco chiara. Quindi la prima cosa da migliorare è
la visibilità. L'applet è stata ridimensionata con
misure più generose e a questo punto è stato d'obbligo sostituire
nel paint i vari drawLine con fillRect per non creare confusione.
Il primo problema occorso nell'"ingrandimento" dell'applet è
un fastidioso
flickering
a causa di
un paint non ottimizzato. Infatti in una prima stesura, prima di disegnare
le nuove linee, si andavano a cancellare tutte quelle esistenti e non solo
quelle effettivamente cambiate. Quindi l'applet ha subito un restyling
profondo in modo da effettuare l'aggiornamento delle linee e attenuare,
se non eliminare, il fastidioso effetto di flickering.
La seconda cosa è che manca una vera interfaccia utente,
nel senso che con l'applet di Gosling l'utente può solo cliccare
su un'applet della grandezza di un francobollo e aspettare che si ordini.
Se poi alla fine del sorting l'utente clicca di nuovo sull'applet non succede
nulla. Allora mi è sembrato indispensabile mettere un
pulsante
di start (che contiene anche il tipo di sorting che si effettuerà)
e un insieme di pulsanti per far decidere la velocità di sorting
all'utente. Il tasto di start permette, quindi, di iniziare un nuovo sorting
appena finito il precedente. L'inclusione dei pulsanti per decidere
la velocità di esecuzione del sorting ha introdotto nuovi metodi
e cambiato quasi tutti quelli esistenti.
Inoltre mi è sembrato utile aggiungere un cronometro (in millisecondi)
per vedere quanto tempo impiegava il sort in questione a ordinare l'array di cui,
per chiarezza, si indica la grandezza con n. Per inserire questo cronometro, che
si attiva ogni qual volta si preme il tasto di start, è stato indispensabile
importare java.util.Date, aggiungere le opportune variabili locali e globali e
modificare i metodi paint e startSort per il totale di una ventina di righe di
codice.
Una cosa che è sembrata del tutto inutile nell'applet
di Gosling è l' importazione di ben 3 librerie (java.io.InputStream,
java.util.Hashtable e java.net.*). Il sospetto dell'inutilità dell'import
è avvalorato dal fatto che eliminandolo non si ha nessun errore
in fase di compilazione nè nessuna anomalia in fase di esecuzione.
Sarebbe interessante capire il motivo di questo import giacchè è
difficile presumere un errore.
Un ulteriore cambiamento che ho fatto è il decidere quale
sorting
di default effettuare. Se Gosling nel suo init aveva deciso che il
sorting di default debba essere il Bubble sort [ if (at == null) {at =
"BubbleSort"; ], nella mia versione mi è sembrato giusto non deciderne
esplicitamente nessuno, in modo da non provocare errori difficilmente scovabili
o risultati inaspettati a causa di distrazione da parte di riutilizzatori
dell'applet.
Infatti non inserendo i seguenti tag -->param name="alg"
value="BidirBubbleSort" <-- nel codice che controlla la mia applet
non parte nessun algoritmo e compare un chiaro NoSort sullo start. Facendo
la stessa cosa in quella di Gosling partirebbe un BubbleSort, sempre che
la classe sia presente.
Nessuna modifica è stata necessaria alla classe SortAlgorithm.
Curioso di vedere se si avverava la promessa della filosofia che ha
ispirato le tecnologie java, cioè il "Write Once, Run Anywhere", ho testato le applet in una distribuzione
Red Hat Linux 6.0 (kernel aggiornato al 2.2.11) sotto il Netscape in
dotazione, dopo aver corretto il bug da cui è affetto il browser
relativamente alla visualizzazione delle applet java. Ebbene,
l'esperimento è riuscito alla perfezione.
Premendo il seguente tasto si possono avere a confronto i due
listati di SortItem, il mio e quello di Gosling.
Gli algoritmi di ordinamento
Gli algoritmi di ordinamento analizzati sono il bubblesort, il bidirectional
bubblesort e il quicksort, sviluppati per conto di Sun dallo stesso Gosling. Ho
ritenuto opportuno aggiungere l'insertion sort, lo shellsort e il mergesort.
Per creare le classi che gestiscono questi tre algoritmi è stato necessario
prima documentarsi su Internet circa il loro procedere logico. E' stato subito
evidente che il materiale in italiano non c'è o, meglio, è pochissimo e poco approfondito.
Il materiale che è stato fondamentale per la preparazione delle classi è stato reperito
sulle onnipresenti università e colleges di lingua anglosassone, per la maggior parte
statunitensi, canadesi, australiani ed europei. Per i contributi più significativi
si vedano i credits.
L'implementazione di insertion sort e shell sort (che sono vicini dal punto di vista logico)
non ha causato problemi insormontabili, ma l'implementazione del mergesort ha dato filo da torcere,
soprattutto dal punto di vista del procedere logico a causa della scarsità della documentazione
trovata e della sua (scarsa) chiarezza. L'analisi della complessità non è stata, d'altronde, una passeggiata!
Per quello che riguarda strettamente la parte della scrittura del codice, devo dire
che senza i tre esempi di Gosling su altrettanti algoritmi difficilmente sarei
stato in grado di creare gli altri tre algoritmi di sorting. Per sapere che tipo di algoritmo di sorting puoi trovare nel jdk 1.2 segui questo link.
I fogli di stile
L'uso dei fogli di stile è diffuso quasi ovunque nei file html.
Il file che raccoglie le proprietà è stile.css.
Le proprietà definite riguardano H1 (il tag del titolo principale),
H2
(il tag per i titoli di seconda importanza), un corsivo standard
che permette uniformità senza troppi sforzi e evitando errori, la
definizione di body dove stabilisco l'allineamento del testo giustificato,
margini, e quella gif ripetuta in verticale sulla sinistra che rimane ferma
come lo sfondo (ma questo dipende dalla proprietà fixed del tag
body definito direttamente in ogni pagina e non nel foglio di stile) nonostante
lo scrolling dell'utilizzatore. Infine è definito come si devono
comportare i link.
L'uso dei fogli di stile integrati all'interno del file html
è impiegato nel file contenente
il listato della classe sortitem come da ultima modifica. La scelta è
stata dettata dal fatto che il particolare foglio di stile era destinato
ad essere usato solo all'interno di quel file.
L'uso di javascript
L'uso di javascript è diffuso in ogni file html dove è
definito la funzione per tornare indietro nell'history del browser.
L'uso di javascript è stato anche indispensabile nel su
menzionato
file del listato di sortitem
per realizzare il commento dello stesso in maniera, per così
dire, interattiva, sul modello dei tooltips dell'interfaccia di Windows
e di altri sistemi operativi. Spostandosi con il mouse su una parte meritevole
di commento - evidenziata a mò di link - appare, appunto, il commento;
una volta spostato il mouse si può tornare alla consueta visualizzazione
della pagina. Qui è riportato
un file semplificato per capirne meglio il funzionamento.
Javascript è stato, inoltre, usato in questa stessa pagina e nelle pagine delle applet per aprire un'altra finestra con precise caratteristiche come la presenza o meno della status bar o della barra di scorrimento, etc.
L' ultimo uso di javascript si può notare nel file
di confronto che riporta il listato della classe sortitem della Sun. Qui
javascript viene usato per un effetto molto usato, a volte anche a sproposito,
cioè per visualizzare un messaggio scorrevole nella status bar
del browser. L'uso di questo effetto è limitato solo qui perchè,
come è noto, impedisce di vedere dove porta un link una volta che
ci si è posizionati su con il mouse.
L'uso dell'html classico
L'uso dell'html è stato, ovviamente, vasto e vario. Le funzioni
che ho usato sono davvero tante tra le quali: creazione del bottone
per aprire una pagina contenente frame, creazione di tabelle
e di "false tabelle" per dare ordine alla pagina, utilizzo dei tag sup
e sub per mettere pedici e apici alle formule e ai segni di sommatoria.
I margini di miglioramento e ampliamento
Ovviamente i margini di miglioramento e ampliamento di questo progetto sono notevolissimi.
Le cose che potrebbero essere migliorate (ma, forse, non con poco
sforzo) sono:
- Una grafica più curata dell'intero progetto: basterebbe avere un pò più capacità
di me e un pò più di buon gusto, il che non dovrebbe essere difficile ;-)
- Un'ottimizzazione del codice di SortItem e delle applet relative all'ordinamento.
- L'implementazione di altri algoritmi di ordinamento noti come radix sort,
selection sort, heapsort e altri, e, avendone le capacità e la fanstasia,
l'implementazione di qualche algoritmo originale e inedito.
- Incrementare il numero di dettagli visualizzabili all'interno del layout dell'applet.
