Newsgroup: it.lavoro.informatica
Titolo: la anti if campaign mi mancava

http://www.antiifcampaign.com/

 
http://www.antiifcampaign.com/
BOT e BTP, I'd daresay they're Italians ;)
--
ale
http://ale.riolo.co.uk

 
http://www.antiifcampaign.com/
è almeno da fine 2007 che sono attivi

 
http://www.antiifcampaign.com/
Se non sbaglio questa "campagna" e' stata promossa da Francesco Cirillo, 
che a livello italiano e' uno dei piu' noti promotori e consulenti delle 
metodologie agili e di XP.
Ora, pur essendo condotta con qualche connotato umoristico e 
folcloristico (tipici del personaggio che l'ha iniziata :-) ), secondo 
me fornisce alcuni ottimi spunti di riflessione per un design robusto e 
pulito del software.
Mi e' capitato di assistere ad un paio di interventi di FC in conferenze 
tecniche, ed assicuro che sono stati sempre molto interessanti.
TheStar

 Se non sbaglio questa "campagna" e' stata promossa da Francesco Cirillo,
se mi dici che e' di bosco tre case,
mi fai tornare indetro di 30 anni !
felice&pago
.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 mi fai tornare indetro di 30 anni !
Ah, questo non te lo so dire, anche se dal cognome potrebbe anche essere.
Ad ogni modo, nel mondo delle metodologie agili e' una persona molto 
conosciuta, ed Internet e' piena di suoi riferimenti e anche di sue foto.
TheStar


ho visto !
e dalla foto potrebbe pure essere chi dico io,
non trovo riferimenti anagrafici,
ho trovato torre annunzaita 1972
se fosse non e' chi pensavo
scusa il disturbo
felice&pago
sciarolkolms
,



Oldissimo.
Le obiezioni sull'uso *facile* dell'IF non sono nulla di recente, da
sempre i massimi esperti di OO mettono in guardia al riguardo.

 
http://www.antiifcampaign.com/
BAH
Da un lato è condivisibile, e la metodologia ad oggetti è favolosa per
tante cose, dall'altro l'esempio che fa mi sembra un po' sciocco :
http://www.antiifcampaign.com/articles/the-simplest-anti-if-code.html
Dice non usate l'if per selezionare il tipo di calcolo, fai
un'astratta e delle derivate.. si ma nella realtà dei calcoli
gestionali è un approccio che ho spesso trovato dispersivo che porta
con se troppi vincoli e complica all'inverosimile affari semplici,
tanto che alla fine impieghi un mese per fare qualcosa che in cobol o
in stored procedure si fa in 4 giorni test compresi, ad alla fine è
pure più stabile.
Per me, l'oo è favolosa quando si fanno oggetti di framework, classi
"informatiche", ed assolutamente inadeguata quando si passa ai dati
tabellari "da gestionale".
Tanto più che nell'esempio si fanno 4 classi derivate, poi però come
lo decidi quale instanzi  ? Magari con un'if a monte :
AbstractBondProfile  classeBB
if(_type == BTP)  {
classeBB = new BOTBondProfile ()
} else if(_type == BOT) {
classeBB = new BOTBondProfile ()
} else {
classeBB = new EUBondProfile
}
Bella gara.


Con una factory che pesca cosa istanziare da un file di 
configurazione/tabella di db?
E poi nel codice usi solo il tipo di base, oppure, senza star li a sprecare 
l'eredità, una bella interfaccia implementata da enne classi, e poi nel 
codice usi sempre oggetti di tipo interfaccia.
Ci sono tanti casi in cui una pacca di IF la puoi gestire in quel modo o 
similari.

similari.
Si ma detta cosi' significa solo spostare il peso dell'elaborazione da
un punto all'altro dell'applicazione, senza avere (imvho) alcun
vantaggio reale nei termini realmente importanti della faccenda
(almeno dal mio punto di vista) quelli prestazionali.

sempre i massimi esperti di OO mettono in guardia al riguardo.
A me sembra un'idea alquanto strana o quantomeno una di quelle
soluzione che servono piu' a far circolare il nome del loro autore che
non ad apportare un vantaggio reale.
Cioe' vorrei capire se si tratta di essere contro i cicli condizionati
in genere o ce l'hanno proprio con la IF (che poveretta che gl'ha
fatto mai di male? mica gli ha trombato la mamma voglio dire).
Cioe' le varie swithc/case, do, for, select vanno bene, la IF no? mah

 l'eredità,
La cosa migliore dell'OO la vuoi tenere in frigorifero... :-)


Ma non è questione di elaborazione, è più questione di progettazione, in 
quel modo la manutenzione e la personalizzazione del sw è molto semplice, e 
a meno di non avere centinaia di istanziazioni al secondo, le prestazioni 
non sono per nulla un problema.
Per esempio in un mio caso reale, dovendo tirar fuori dei fogli di calcolo 
in seguito ad elaborazioni fatte su dati in un db, per dare la possibilità 
di avere i fogli in formati diversi (per esempio excel piuttosto che la sua 
controparte di openoffice), ho definito un'interfaccia per la generazione di 
questi fogli, e poi lato db posso indicare a mo di configurazione, qual'è la 
classe che realmente si occupa di generare il foglio piuttosto della classe 
che pesca i dati dal DB, in modo che sia molto facile e veloce cambiare al 
volo la generazione dei fogli o in formato xls o in formato open office, e 
per oguno posso anche cambiare la modalità di  elaborazione dei dati per 
adattare i fogli ad esigenze specifiche. E tutto questo aggiornando una riga 
in una tabella del DB e scrivendo a parte delle DLL specifiche da includere 
nel sw, senza star li a far manutenzione su tutto il sw.
Certo, parlando di interfacce, bisogna poi star attenti a non cambiare un 
giorno si e l'altro anche la definizione dell'interfaccia, visto che poi 
tocca ripassarsi tutte le classi che la implementano, ma anche se fosse 
così, diciamo nel periodo di pieno sviluppo, tutto sarebbe guidato molto 
bene dalla fase di compilazione, non ne scapperebbe una di classe su cui 
dover mettere le mani.

 decidi quale instanzi  ? Magari con un'if a monte :
Usa un linguaggio dinamico come PHP:
$classname = $_type."Profile";
return new $classname();
;)
Bye.


Ci sono molti linguaggi OO che non supportano l'erediterietà multipla, 
mentre per l'implementazione di interfacce non c'è nessun limite.
Per come l'ho capita io e per l'esperienza mia, le interfacce sono una 
raccolta di comportamenti su cui si vuole disaccoppiamento rispetto a enne 
possibili implementazioni, e sono trasversali rispetto a tutto il dominio di 
una applicazione.
Invece la modellazione tramite classi ed ereditarietà è più una questione 
legata alla rappresentazione del dominio, e comunque è una rappresentazione 
molto rigida che deve essere fatta solo dopo aver chiarito molto bene qual'è 
il dominio sul quale è scritto il sw.

 in seguito ad elaborazioni fatte su dati in un db, per dare la possibilità
Si però sposti completamente il caso ad un altro livello che nulla
c'entra con l'originale ed in questo caso do perfettamente ragione a
te (a meno dell'ereditarietà che non usi, tagliandoti gratuitamente
una strada).
Ma anche te dai ragione a me, perchè quelle sono classi "informatiche"
e di libreria : roba IT come l'export su file excel è rappresentabile
bene in oo perchè è coerente, riesci ad immaginarla come una oggetto e
si comporta come tale perchè è immersa in un ecostistema di oggetti.
Ma un contratto, un conto corrente, un titolo non sono oggetti.
Ci puoi provare ma non lo sono perchè li hanno inventati e scritti non
degli informatici ma dei rinco....niti della finanza che non seguono
nessuna regola se non quella della fantasia.
A loro basta scrivere un nuovo comma nel contratto e nascono decine di
if, e non puoi fare tanto il fighettino degli oggetti perchè sono
proprio IF: se il cliente ha meno di 18 anni, è biondo, abita a
Ferrara, fa le superiori e almeno un suo parente è rosso di capelli e
la mattina fa colazione con girella allora le commissioni sui
movimenti fatti nelle giornate col sole sono gratis.
Vai fallo ad oggetti.


Beh, si, puramente ad oggetti è impossibile, ma la campagna anti if non mi 
pare sia così assoluta, nel senso che anche il caso che hai descritto può 
essere visto ad oggetti previa una parte che elabora un certo profilo di 
informazioni per tirar fuori una classe adatta a far quel che serve.
Nel senso, tu nel tuo flusso normale non istanzi direttamente un tipo, ma lo 
fai fare appunto ad una factory che in base al profilo del cittadino, ti da 
indietro il tipo corretto e tu o usando un tipo base che è l'interfaccia 
oppure una classe base, fai quello che devi fare in modo logico, cioè 
seguendo il flusso di elaborazione a livello più alto, ma lasciando poi far 
fare i conti corretti ai tipi concreti che sono usciti fuori dalla factory.
E' chiaro che tutti gli if non spariscono, ma si spostano ad un livello 
diverso dal flusso normale di elaborazione, ma già questo non mi pare sia un 
vantaggio da poco per successive manutenzioni visto che hai praticamente 
isolato molto bene i punti dove si sa è necessario mettere mano.

nel sw, 
in tutto questo ambaradan dove sta la difficolta' di gestire una IF
(pure se di quelle brutte annidate?) dove sta il risparmio in termini
di tempo per il rpogrammatore? Sempre codice devi scrivere...
Allora guarda ti faccio un esempio proprio di questi giorni, stiamo
preparando l'annuale aggiornamento di alcuni nostri moduli
all'adeguamento delle specifiche del 770 per la generazione dei file
per la trasmissione telematica.
L'attività funziona cosi':
1 - si prendono le specifiche tecniche rilasciate dal ministero e si
adeguano i file di db;
2 - si adeguano i programmi alle nuove elaborazioni richieste.
Quest'anno in particolare all'agenzia delle entrate si sono
sbizzarriti aggiungendo per alcuni tipi di record, interi nuovi frame
di dati.
Poco male, sia il db che i due programmi di elaborazioni (parliamod i
robba sviluppata per as/400, quindi db2 e rpgile) sono li che
aspettano i nuovi moduli.
La struttura e' molto semplice, ci sono due programmi:
Pgm1 ravana e sfruguglia il db alla ricerca dei movimenti di
contabilita' interessati dalla cosa e genera i dati (in apposita
tabella di db) per l'elaborazione richiesta, poi a secondo del tipo di
elaborazione richiesta (stampa certificazioni, definitiva o prova,
preparazione file per trasmissione telematica) richiama il realtivo
pgm di competenza passandogli i relativi parametri (i tipi record da
elaborare, il template da utilizzare e cosi via).
Il pgm per la trasmissione telematica pgm2 e' composto da tanti moduli
quanti sono i vari tipi record, ogni tipo record e' descritto in
apposita tabella db dove c'e' un record che "mappa" la sua struttura
(che cambia ogni anno) legge dal db i movimenti interessati e genera i
record per la trasmissione telematica opportunamente formattati
secondo le deliranti richieste dell'AE.
Facile da gestire come il tuo (se cambia il tracciato dell'AE cambio
il record nella tabella in cui e' descritto, se l'AE aggiunge un tipo
record aggiungo un modulo a pgm2, per pgm1 la cosa e' indifferente).
in tutto questo utilizzo delle if per far scegliere a pgm1 chi
chiamare dopo di se o se chiudersi o bella li'. 
Quanto mi costa gestire quella if nell'economia generale del mio
sviluppo?

 il dominio sul quale è scritto il sw.
Bè, un'analisi accurata preventiva andrebbe fatta sempre, in
verità :-)

 record aggiungo un modulo a pgm2, per pgm1 la cosa e' indifferente).
Qui hai semplicemente spostato le IF che avresti dovuto mettere nel
programma (IF tiporecord1 ...; IF tiporecord2...) in una tabella di
parametri esterna (leggi: pseudolinguaggio di programmazione del
generatore della trasm. telematica), perchè hai ritenuto giustamente
che fosse più conveniente non intervenire sul codice del generatore
(RPG, se ho capito bene).
Avresti anche potuto risolvere in modo più sofisticato, progettando un
linguaggio vero e proprio, con la sua sintassi, e scrivendo un
traduttore verso l'RPG od altro, che ti generasse ogni volta il
programma completo.
Il tutto in barba eventualmente ad OO o meno. Infatti è probabile che
un tale linguaggio sia puramente dichiarativo.
Certo se sei costretto ad usare un singolo linguaggio per fare tutto,
Java, RPG, ecc., prima o poi devi venire a compromessi.


Ovviamente la definizione dell'interfaccia è in comune tra il sw vero e 
proprio e le singole dll che contengono le varie classi che implementano 
l'interfaccia.
Quando tu apri un sorgente di una di queste classi, dentro c'è il 
riferimento all'interfaccia che implementano, quando compili per generare la 
dll vedi subito se la classe implementa correttamente l'interfaccia. Se la 
compilazione è ok, allora la dll la puoi distribuire e tutto gira liscio, a 
meno di errori di run-time che però non riguardano l'implementazione 
dell'interfaccia in se, ma da cosa/come fa l'oggetto istanziato. Ma 
sarebbero gli stessi errori generati con un'istanziazione statica fatta a mo 
di test.

 movimenti fatti nelle giornate col sole sono gratis.
Senza andar di fantasia, mi è toccato sviluppare un programma di
pianificazione della produzione dove erano talmente tante le regole da
implementare (diametri, materiali, verniciature, trattamenti protettivi,
pesi, saturazione linea, disponibilità personale, urgenza della produzione,
etc) che gestire tutto *solo* in modo OO puro sarebbe stato un vero
delirio.
Ciò che è parametrizzabile si parametrizza via db, ma per certi vincoli
consolidati ci sbatti un bell'If e finisce lì, paradossalmente ne guadagna
anche la leggibilità.
PaF

 lo decidi quale instanzi  ? 
Magari con un sistema a plug-in; disegni un nuovo plug-in, lo registri
e fai che sia lui a creare l'istanza.
In fin dei conti, una classe astratta (o anche semplicemente una classe
base) non e' altro che un contratto.
Detto questo. Io credo non esista lo strumento assoluto. L''if' e' uno
strumento, e come tutti gli strumenti il suo impiego puo' essere
motivato in mille modi.
Io, da sviluppatore, odio i gerolamiSavonarola (prego di apprezzare
l'istanziazione ;-) ) che vorrebbero impormi cose in modo differente
senza conoscere le motivazioni per cui le faccio in quel modo.
-- 
Ciao!
Luca

 di test.
Mi sembra una casistica piuttosto particolare, dove ti puoi permettere
di separare gli errori di istanziazione dell'interfaccia da quelli di
esecuzione del codice dell'oggetto, probabilmente perchè usi librerie
già pronte e testate.
Però se la libreria la devi scrivere tutta tu, va valutato bene se
conviene rinunciare a certi controlli in compilazione e puntare sui
test di esecuzione.

> Senza andar di fantasia, mi toccato sviluppare un programma di
Si, io ho conosciuto entrambi i tipi di scienziati, quelli che
vogliono fare tutto con le "if" e cioè con regole scriptate e poche o
nessuna tabella di configurazione e quelli che vogliono fare tutto ad
oggetti. E qualcuno è finito pure molto male, con relativo buco di
bilancio, avvocati e arbitrato conesso. Belle esperienze, ho
decisamente imparato molto di più dai progetti finiti male o
malissimo, impari come non farte gli stessi errori quando poi tocca a
te.


Non so nulla di AS/400 e compagnia, ma un if di quel tipo che fa solo da 
switch per il richiamo di altri pezzi non è ovviamente critico, fai in modo 
cablato quello che si potrebbe fare in modo non cablato. Il punto è che se 
uno può fare a meno di metter mani al codice, ricompilare, e rifare il 
deploy oltre che dei pezzi nuovi anche della parte comune che è incaricata a 
coordinare i pezzi nuovi, è meglio. Poi, più sono numerosi i pezzi in 
comune, più la probabilità di dimenticarsi di fare qualcosa in questo iter 
sale, e gli incidenti si sa benissimo che succedono mica perché uno li cerca 
apposta, ma perchè capitano le solite coincidenze sfigate che ti distraggono 
e ti fanno saltare un passo e caschi dal pero.
Alla fine è come per i bug, più lungo è un programma più è probabile che ce 
ne siano, quindi più cose (anche se chiare e documentate) devi fare per far 
manutenzione, più è probabile che qualcosa di scappi. In quest'ottica poter 
solo implementare parti nuove, senza toccar nulla di tutto il resto, e 
configurare il richiamo delle parti nuove o tramite file di cfg o tramite 
db, riduce la superficie di sfiga che induce alle cappelle... :-)

 ha scritto nel messaggio 
news:40lj1692lijk7hrbd...@4ax.com...

...io uso ancora il GOTO quando mi semplifica la vita,
e pure gli indicatori di livello L1,L2...etc che sono fenomenali in certe 
situazioni.
All'inventore del CHAIN gli farei addirittura un monumento, alla faccia 
degli sql-listi...
Pensa quanto me ne puo' fregare degli  anti-if...:-)
ciao
fm 

...io uso ancora il GOTO quando mi semplifica la vita,
questo mi e' capitato di recente...
e usi pure il CAB?

 Cioe' le varie swithc/case, do, for, select vanno bene, la IF no? mah
le prime due righe del link che tu stesso hai riportato:
"The primary purpose of our campaign is to become aware of the design
consequences of using IFs and *of control structures in general*".

 Pensa quanto me ne puo' fregare degli  anti-if...:-)
guarda che parlano di "Object Oriented contexts".
a quanto pare leggere per capire di cosa si parla deve essere passato
di moda.

 return new $classname();
c'è bisogno di un linguaggio dinamico?
Class.forName(classname).newInstance();

 Class.forName(classname).newInstance();
Direi di si`, visto che quella che citi e` una funzione che rende 
dinamico Java, dato che carica una classe a runtime e non a compiletime.
Bye.

 ha scritto nel messaggio 
news:or8m16hhvi2mu83k4...@4ax.com...

quasi mai....lo trovo poco leggibile.
ciao
fm 

 senza conoscere le motivazioni per cui le faccio in quel modo.
scusa ma te ogni volta che leggi un design pattern, delle linee guida
o una best practice ti  inalberi sempre in questo modo come se ti
volessero imporre qualcosa?
nel caso di specie la questione è semplice. molti di quelli che
programmano ad oggetti e in particolare con un modello di sviluppo
test driven sanno benissimo cosa vuol dire avere un codice pieno di if
e/o strutture di controllo: te considera che ogni volta metti una "if"
raddoppi (minimo) i casi di test a copertura del codice,  ergo se ti
imponessi come criterio di qualità l'avere tutto il codice coperto dai
test ti verrebbe naturale pensarla in quel modo.

 pure più stabile.
detto in tre parole: non è vero.
un programma ad oggetti, ovviamente analizzato in modo corretto ad
oggetti, tutto è tranne che complicato e dispersivo. in realtà dal
punto di vista del programmatore non c'è neanche un paragone fra
individuare il codice fra classi, metodi e proprietà rispetto, ad
esempio, ad una miriade di forms o (peggio) una stored procedure di
qualche migliaio di righe.
sulla stabilità parliamone. tempo fa abbiamo ripreso in mano dei
programmi cobol di fatturazione di un cliente che voleva "migrare" al
nuovo gestionale; programmi stabilissimi e che funzionavano da
decenni, ma che una volta analizzati all'interno si scopre che sono
pieni zeppi di codice obsoleto che nella migliore delle ipotesi non si
sa nemmeno se funziona, ma spesso ci sono anche bug evidenti alla
lettura del codice, perché sono parti dove il flusso del programma non
passa mai da chissà quanto tempo. siccome non è affatto un caso
isolato quello di trovare "bombe ad orologeria" dentro a questi
programmi che fanno il loro sporco lavoro da decenni, mi chiedo se è
questo un criterio serio per giudicare la qualità del software: mi
pare infatti che questi siano programmi ultrastabili fintanto nessuno
li tocca e allora grazie al piffero.

 li tocca e allora grazie al piffero.
Qui tocchiamo argomenti filosofici. 
Un bug è ontologicamente sussistente ?
PaF