Gli indici sono figli del demonio

Non come il copia incolla è figlio del demonio, ma quasi.

Riassumo tutto quanto seguirà con questa frase : usare gli indici per rappresentare lo stato del problema tende a produrre roba leggermente più performante, ma con riusabilità e valore infimi.

Potrà suonare banale, ma rappresentare una lista con una coppia di indici e un’altra lista non è il massimo della limpidezza.

Eppure questo è quanto avviene con grande frequenza, credo che tutti abbiano scritto qualcosa del genere :

for(int i=0; i < list.size(); i++) {

Tag tag = list.get(i);
if(tag.isOpen()) {
for(int j=i; j < list.size(); j++) {
Tag innerTag = list.get(j);
if(innerTag.isText()) return innerTag;
}
return null;
}

}

Invece di scrivere questo :

for(int i=0; i < list.size(); i++) {

Tag tag = list.get(i);
if(tag.isOpen()) {
List innerList = list.subList(i,list.size()-1);
for(int j=0; j < innerList.size(); j++){
Tag innerTag = innerList.get(j);
if(innerTag.isText()) return innerTag;
}
return null;
}

}

A occhiata queste due soluzioni sembrano equivalenti. Anzi, la prima è più “economica” e compatta.

Le due soluzioni però differiscono profondamente in quanto a incapsulazione. La seconda incapsula tutte le informazioni dentro all’oggetto “innerList”, la prima invece le disperde tra “i” e “innerList”.

Non a caso la seconda, quando si rifattorizza, richiede un parametro in meno, e si presta immediatamente al riuso, anche al di fuori del contesto iniziale :

for(int i=0; i < list.size(); i++) {

Tag tag = list.get(i);
if(tag.isOpen()) {
return getFirstText(list.subList(i,list.size()-1);
}

}
……….

Tag getFirstText(List < Tag > list) {
for(int j=0; j < innerList.size(); j++){
Tag innerTag = innerList.get(j);
if(innerTag.isText()) return innerTag;
}
return null;
}

Nel caso senza “innerList” l’estrazione del metodo avrebbe prodotto una cosa del genere :

Tag getFirstText(List < Tag > list, int i) {…..

Questo è un esempio banalissimo, ma ho notato che moltissimo codice non viene rifattorizzato per mancanza di coesione dei dati : estrarre metodi, identificare oggetti nascenti, dare nomi significativi è estremamente difficile se l’entità “foglia estrema del secondo albero” è identificata da tre integer e una stringa.

L’uso di indici quindi, per quanto non sembri immediatamente dannoso, porta a codice che sembra “per sua natura” monolitico. Ferma i tentativi di refactoring ancora prima che nascano, semplicemente grazie a quelle che, alla fine dei conti, sono delle strutture dati mal definite, ergo, non adatte al problema.

Comments

credo che le parentesi angolari abbiano fatto un bel casino nel tuo feed, occhio :)
Posted by riffraff on 03/16/2007 09:16:37 AM

L’RSS a me funziona correttamente. Le angolari (in combinazione con i “;”) mi avevano fatto sparire parti del post, ma l’ho sistemato aggiungendo degli spazi, confermi? Tra l’altro ho aggiunto qualche linea al codice su consiglio di un collega, per rendere più chiaro il punto.
Posted by ratta on 03/16/2007 09:28:14 AM

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s