Newsgroup: it.lavoro.informatica
Titolo: VW e centralina taroccata: le ultime rivelazioni :)

c'era un semplice 'if' alla base di tutto e la centralina si posizionava

in "test mode": 

http://www.consumerreports.org/cro/cars/volkswagen-emissions-cheat-exploited-test-mode.htm


E secondo me per capire che la vettura era ferma usavano un banalissimo 

accelerometro, di quelli presenti negli smartphone. 

Non e' un caso che Bosch produce anche accelerometri e che il loro prezzo 

oggi e' inferiore a 1 dollaro: 

http://www.digikey.com/en/articles/techzone/2013/dec/expect-sensor-prices-to-fall




Cara VW, keep calm and pensa: ma quanto poteva durare questa storia? 



   Poteva durare fintanto che i controllori erano compiacenti e nelle 

sfere alte gli accordi tenevano.  Ma la VW ha fatto un errore:



http://www.zerohedge.com/news/2015-09-22/dear-volkswagen-was-your-biggest-mistake




   Riassunto in questi due diagrammi:



http://www.zerohedge.com/sites/default/files/images/user5/imageroot/2015/09/GM%20VOW%201.jpg


http://www.zerohedge.com/sites/default/files/images/user5/imageroot/2015/09/GM%20VOW%200.jpg






   Ciao,





-- 

Alessandro Selli 
http://alessandro.route-add.net


AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.

WARNING: messages sent to "trappola" will never reach me.


 in "test mode": 

CUT



Non a caso l''if' è una delle istruzioni più importanti nella

codifica in un linguaggio di programmazione, se non la più

importante!



Con un 'if' si può cambiare anche il corso della storia... ;-)






 importante!



http://antiifcampaign.com/



 
http://www.consumerreports.org/cro/cars/volkswagen-emissions-cheat-exploited-test-mode.htm






Ma l'hai letto l'articolo? Il test mode di per se non c'entra niente:

"The existence of a testing mode isn't a red flag. Most new vehicles have a similar setting."

........because........

"The vehicle could otherwise interpret the test procedure as a dangerous situation or malfunction, activating traction control or stability control. By enabling a test mode, the vehicle will be able to operate during the test process." 



un punto di forza del linguaggio direbbe l'amico "eno".






pure con un while o un for scritti in modo non corretto.




 Cara VW, keep calm and pensa: ma quanto poteva durare questa storia?



non vorrei dirlo ma ho la sensazione che stia per scoppiare in europa

un dieselgate.

stando a quanto ho sentito le norme euro6 vietavano esplicitamente questo

tipo di accorgimenti software, il che lascia alquanto sospetti.

negli states gli organismi che controllano sono *realmente* indipendenti,

in europa assomigliano più a un consorzio di quelli che devono essere

controllati. poi ci si meraviglia se gli attacchi vengono da là, è ovvio

che qua cane non morde cane.







   In questo senso?  :-)

https://www.youtube.com/watch?v=lNjUY3QBl_I




 ha scritto:


4,136 pseudo programmatori. Continuate così... :-D






 pure con un while o un for scritti in modo non corretto.



Vedi sopra ;-)






 4,136 pseudo programmatori. Continuate così... :-D



Hai almeno capito di che si sta parlando?




 4,136 pseudo programmatori. Continuate così... :-D



si, si. te invece continua a cospargere il codice di if, poi se un giorno

ti verrà voglia di scrivere dei test (perché adesso evidentemente non lo

stai facendo) se ne riparla.




 ha scritto:


Ripudiare l'"If" è come ripudiare il martello per un falegname.



Capito?








 negli states gli organismi che controllano sono *realmente* indipendenti,



Però è interessante la disamina della questione su HdMotori.

Io son convinto che sarebbero meglio controlli più aderenti alla realtà.



-- 

Ciao!

Luca





Mi son spulciato l'intero sito, ma non si evince da nessuna parte che 

cosa si intende per "bad, dangerous IFs". In altre parole pretendono che 

gli sviluppatori si "associno" senza descrivere ne problema ne soluzioni.



IF è uno dei costrutti semantici di base di controllo del flusso in un 

linguaggio imperativo, non vedo perchè dovrebbe essere "male". Vero che 

molti "if" possono essere sostituiti da polimorfismo, ma non per questo 

if diventa il male.



-- 

Soprano


 Capito?



Lo vedi che non ci hai capito un cazzo? Si parla di "dangerous ifs", rimbambito.




 gli sviluppatori si "associno" senza descrivere ne problema ne soluzioni.



Ma non dire stronzate!



http://antiifcampaign.com/get-started/




Ci sono tanto di esempi! Certo che se questo gruppo riflette il livello di competenza informatico italiano, il paese sta proprio fresco.




Ehhhh pazienza.




 E dove li hai visti sti esempi? 



Non serve fare troppi esempi, per capire di che si sta parlando. Basta un hint.

D'altronde i vostri anni e anni di lavoro a che servono? Non ti basta scrivere codice tutti i giorni, per accorgerti di come la complessita` di una certa logica puo` espandere esponenzialmente ad ogni nuovo "branch" del tuo codice? Sara` forse un caso che la cyclomatic complexity viene proprio calcolata in base ai path del codice? Bisogna davvero spiegarvi cos'e` un "dangerous if"?



Bastava uno completo e non l'han messo, per una campagna "culturale" mi 

par un po' pochino.

Anche se io un'idea di perché non han messo la versione senza if me la 

son fatta, visto che ci sono enne modi per farlo, apridicielo poi ci 

sarebbe stato il flame tra gli anti-if per mettersi d'accordo su 

qual'era l'approccio migliore.

Comunque le if mostre sono ben altre, altro che quel mezzo esempio.




 ha scritto:


Il sito si chiama "
antiifcampaign.com
".



Il messaggio che indica chiaramente è che l'"If" è il male.



Chi è il rimbambito adesso?








 





allora, proviamo a fare un esempietto pratico.

Io ho questo codice (parlo di java):









int x = calculateX(); //funzione che restituisce un intero

if(x == 1) {

    doSomethingX1();

} else if(x == 2) {

    doSomethingX2();

} else if(x == 3) {

    doSomethingX3();

} else if(x == 4) {

    doSomethingX4();

} else {

    doSomethingElse();

}







qui ci sono parecchi if, quale potrebbe essere un approccio

alternativo?

A me viene in mente uno switch case:





int x = calculateX();

switch (x) {

    case 1:  doSomethingX1();

             break;

    case 2:  doSomethingX2();

             break;

    case 3:  doSomethingX3();

             break;

    case 4:  doSomethingX4();

             break;

    default:  doSomethingElse();

              break;

}





forse così è già un po' meglio di tutta quella sequenza di if else if.

Il codice con lo switch risulta un po' più semplice da manutenere.

Altre possibilità?


 if diventa il male.



Ooooooohhh ogni tanto qualcuno dotato di sale in zucca capita

da queste parti. Grazie per la spiegazione che hai dato loro,

alle volte proprio la pazienza da parte mia finisce...








 D'altronde i vostri anni e anni di lavoro a che servono? Non ti basta 

scrivere codice tutti i giorni, per accorgerti di come la complessita` di una 

certa logica puo` espandere esponenzialmente ad ogni nuovo "branch" del tuo 

codice? Sara` forse un caso che la cyclomatic complexity viene proprio 

calcolata in base ai path del codice? Bisogna davvero spiegarvi cos'e` un 

"dangerous if"?



Ancora con stò "dangerous if"! Oooohhh ma sembra che sia uno spauracchio!!! :-D



Allora ti confido un segreto, non esiste un "dangerous if", esiste solo un

"dangerous programmer".






 ha scritto:


Sono 20 anni che il software che ho scritto io gira senza problemi.

E non mi prendo certo paura di un "dangerous if"! :-D










Un dictionary con l'intero in chiave e un delegate come valore?




 par un po' pochino.



esticazzi?



scusa eh, ma veramente qui si sfora nel ridicolo: il flame qui lo stai 

facendo te e non certo quelli "anti-if".



se vogliamo esporre e discutere le opinioni, bene, io dico perché mi trovo

d'accordo e tu dici perché invece sei in disaccordo. se invece la vogliamo

buttare in baruffa dicendo che quella è una crociata con i soliti cazzi & 

mazzi di chi non si vuol fermare nemmeno a riflettere sulle proprie 

convinzioni, bene lo stesso ma non è discussione che fa per me.




Egregio, l'hai fatta fuori dal vasino.

Completa l'esempio o mosche. Nessun flame.







ho provato a cercare un po' su internet. Da quello che ho visto i delegate

esistono in C#, ma non in java.

Io conosco solo il java, per cui provo a tradurre in codice java quello

che ho recepito della tua idea

(io riesco a ragionare solo se ho il codice davanti, altrimenti così

in astratto faccio fatica).

Poi dovresti dirmi se è quello che hai in mente.







class DoSomething { //base class for do something method

    void doSomething();

}



class DoSomethingX1 extends DoSomething {

    @Override

    public void doSomething() { 

        doSomethingX1();

    }

    public void doSomethingX1() { 

        //business logic for x == 1

    }

}



class DoSomethingX2 extends DoSomething {

    @Override

    public void doSomething() { 

        doSomethingX2();

    }

    public void doSomethingX2() { 

        //business logic for x == 2

    }

}



class DoSomethingX3 extends DoSomething {

    @Override

    public void doSomething() { 

        doSomethingX3();

    }

    public void doSomethingX3() { 

        //business logic for x == 3

    }

}



class DoSomethingElse extends DoSomething {

    @Override

    public void doSomething() { 

        doSomethingElse();

    }

    public void doSomethingElse() { 

        //business logic for other values for x

    }

}



Map<Integer, DoSomething> doSomethingMap = new HashMap<Integer, DoSomething>();

doSomethingMap.put(new Integer(0), new DoSomethingElse());

doSomethingMap.put(new Integer(1), new DoSomethingX1());

doSomethingMap.put(new Integer(2), new DoSomethingX2());

doSomethingMap.put(new Integer(3), new DoSomethingX3());







/*

 * returns an int between 0 and 4

 */

int x = calculateX();



DoSomething doSomething = doSomethingMap.get(new Integer(x));

doSomething.doSomething();







non sono stato lì a esplicitare il DoSomethingX4, tanto il

concetto mi sembra chiaro.



Il codice che ho scritto non l'ho testato in alcun modo, quindi

potrebbe non essere corretto.

Ma al di là della correttezza formale, è questo che tu hai in

mente?


 Completa l'esempio o mosche. Nessun flame.



ma figurati, sai che cazzo me ne frega delle tue mosche.


 E non mi prendo certo paura di un "dangerous if"! :-D



poi un giorno fra te e delta11 ci spiegherete che razza di metrica è

dire "sono 20 anni che gira" per misurare la qualità del codice.






Si direi di si, la chiave univoca ti protegge dal fatto di non poter 

avere più comportamenti associati ad uno stesso valore, e il codice 

variabile (via istanza di una classe specifica come hai fatto tu, ma si 

poteva usare anche del codice anonimo tipo le lambda) associato alla 

chiave ti fanno avere a disposizione enne comportamenti smistabili senza 

ricorrere ad una serie di if o a uno switch.

Se poi butti tutto dentro ad un file esterno di configurazione e vai 

solo di reflection puoi togliere/mettere/cambiare comportamenti senza 

toccare il sorgente.





Ass you like! :-D




 if diventa il male.



premesso che il link era una boutade e non ho nessun interesse a prenderne

le parti, esprimo la mia opinione personale. 



hai detto una cosa giusta, il polimorfismo (ad esempio) dovrebbe essere

preferibile ai costrutti di controllo flusso condizionali. il motivo

è chiaro, il codice risulta essere più manutenibile, più testabile e quindi

meno prono ad errori.



considera che in un metodo ogni "if" come minimo raddoppia i percorsi del

codice, quindi come minimo raddoppia i casi di test per quel metodo. 

come minimo, perché aumenta il numero di righe, la complessità del codice

e i casi di conseguenza (esempi: blocchi if nidificati, variabili che

vengono valorizzate in uno o più blocchi if e poi usate altrove a costituire

a loro volta blocchi condizionali, etc...).



vogliamo parlare poi della leggibilità? è difficile tu possa capire a colpo

d'occhio cosa fa il codice se è farcito di if. l'unico modo è, al solito,

armarsi di debugger e seguire passo passo, sperando di ricostruire il caso. 



sì, secondo me le if sono "il male" e per quanto possibile vanno evitate

a favore di metodi brevi e lineari ovvero facilmente testabili. 99 su 100 

quando vedo metodi di centinaia di righe arzigogolate significa che chi

l'ha scritto o aveva fretta boja o era un cialtrone, in ogni caso è indice

di codice non pensato.








Un classe template avente come parametro un int e specializzata sull' 

valore dell' int.

Putroppo non funziona in quanto x non è costante e quindi un switch  per 

selezionare la classe voluta occorre farlo.

Non si puo fare a meno delle if in un modo o nell' altro ma certamente 

usarli il meno possibile (switch compresi) si.








 Io ho questo codice (parlo di java):



ma non è così che funziona, eh...



se prendi un pezzo di codice con delle if e chiedi "trova un'altro costrutto

equivalente" cosa vuoi che ti si risponda? se il codice è pensato così, è

così che te lo tieni.

il discorso è che tu avresti dovuto progettare a monte il codice in modo

diverso, utilizzando altri elementi del linguaggio java, in modo da 

superare la necessità di tutte quelle condizionali.








beh devo dire che questa tua idea rappresenta un approccio alla

programmazione che sinora non ho riscontrato a livello professionale.



Io ho sempre visto codice con le if, o al massimo con le switch

(molto più spesso con le if, devo dire), tipo quello che ho postato

per primo.



Comunque come idea mi sembra interessante, magari poi provo a testare

un attimo ed eventualmente a proporre questo nuovo approccio.

Comunque alla fine, per quanto riguarda la manutenibilità del

codice, anche usando le if o le switch come nell'esempio che ho fatto

ci sono i metodi apposta per la business logic, cioè i metodi

doSomethingX1(), doSomethingX2() ecc.

Se la business logic va cambiata puoi anche cambiare semplicemente

il corpo di quei metodi senza toccare le if.



Però anche la tua idea non è male.



a parte il fatto che si può sempre fare del refactoring, ovviamente

col tempo adeguato davanti, quello che chiedevo io era nient'altro

che un modo alternativo alle if per scrivere lo stesso pezzo di

codice.

Quindi chiedevo come si può progettare un codice come quello

dell'esempio per evitare le if, dato che di questo si parlava.

E ho messo un esempio pratico per capirci bene, che col codice

davanti si ragiona molto meglio.



Comunque in generale progettare il codice non è così semplice

come dirlo.

Se si tratta di pezzi come questo è un conto, ma nella vita reale

il codice devi progettarlo tenendo conto delle funzionalità che

devono essere implementate, dei vari comportamenti diversi che devi

avere.

Non è mica cosa semplice.



Tanto più che le specifiche richieste variano nel tempo. La

specifica di oggi tra due settimane potrebbe essere diversa,

e allora quello che hai progettato magari è da buttare.

Purtroppo bisogna sempre tener conto delle problematiche

reali.

Comunque l'idea di usare il polimorfismo nel modo suggerito

da AleTV mi pare interessante, come ho già detto.


 usarli il meno possibile (switch compresi) si.



Giusto, ed è questo quello che alcuni non capiscono qui, quindi

lo rimarco a loro uso e consumo:



"*Non si puo fare a meno delle if in un modo o nell' altro*"










 ha scritto:


"Per qualità del software si intende la misura in cui un prodotto software 

soddisfa un certo numero di aspettative rispetto sia al suo funzionamento sia 

alla sua struttura interna." (fonte:

https://it.wikipedia.org/wiki/Qualit%C3%A0_del_software
)



Eccoti la metrica che cercavi ;-)










 Io son convinto che sarebbero meglio controlli più aderenti alla realtà.



IL problema è che per essere scientifici e  comparabili i test devono avvenire in un ambiente e con modalità rigorosamente controllati. Effettuarli in strada molto difficilmente consente questo.






 IL problema è che per essere scientifici e  comparabili i test

 > devono avvenire in un ambiente e con modalità rigorosamente controllati.

 > Effettuarli in strada molto difficilmente consente questo.



Però è anche vero l'opposto: ben difficilmente con una breve analisi di 

laboratorio (hai certamente letto di che tempi si parla) riesci ad avere 

una rappresentazione corretta della realtà.



Per me i casi son due: o allunghi i tempi in laboratorio, o fai una cosa 

mista, pesando correttamente il laboratorio e la realtà.



-- 

Ciao!

Luca







Non credo proprio che i paladini dell'anti-if intendessero sostituire gli 

if-else con gli switch-case, ma dal loro sito non lo sapremo mai :)



-- 

Soprano


 mista, pesando correttamente il laboratorio e la realtà.



Mah, forse i test in laboratorio si possono migliorare un poco. Ma di certo farli su strada sarebbe impossibile (intendo strada comune). Forse su una pista, tuttavia anche lì come fai a fissare rigorosamente le condizioni al contorno, ad esempio pressione, temperatura ed umidità atmosferica? Una pista al chiuso? E chi paga un tale costo?




 indice di codice non pensato.





Semanticamente parlando, l'if è un modo di implementare un flusso 

condizionale, che è presente in qualsiasi algoritmo o programma che dirsi 

voglia. 



Poi sono d'accordo che si può scrivere lo stesso codice in mille modi 

diversi più o meno leggibili, più o meno riusabili, ecc. ecc. 



Infine è anche questione di gusti. Ad esempio a me è sempre piaciuto 

programmare Single Entry, Single Exit e ho sempre preferito 1) tra i 

seguenti analoghi:



1)

****

int result;

if (blablabla)

   result = 42;

else

   result = 97;

return result;

****



2)

****

if (blablabla)

   return 42;

else

   return 97;

****



3)

****

if (blablabla)

   return 42;

return 97;

****



La mia prof di informatica mi avrebbe scannato vivo in aula se avessi 

scritto una cosa tipo 3), ma oggi pare essere il modo di programmare più 

trendy.



-- 

Soprano


 di competenza informatico italiano, il paese sta proprio fresco.



Invece se il paese si basa sui "paladini dell'if" col sito in inglese e 

gli esempi, anzi L'UNICO ESEMPIO con getRisposteDomanda, 

getIdQuestionario ecc., siamo apposto



-- 

Soprano


 return result;



result = (blablabla) ? 42 : 97;

return result;



Struttura che esiste in moltissimi linguaggi.

E non ho mai preferisto la forma più compatta perché qui, mettere un 

breakpoint, è un attimo.



-- 

Ciao!

Luca




 seguenti analoghi:



L'1 è senza dubbio il migliore: facilmente leggibile e scalabile... usa 

na variabile in più però...


Ammetto di usare tutti e tre talvolta... ma 2 e 3 sono rischiosi in 

caso di manutenzioni "in poco tempo" perchè rischi di perdere pezzi di 

codice (nella realtà non sono mai così puliti :D)



-- 

Al3xI98O

«L'importante non è cadere, ma sapersi rialzare»


Luca Menegotto in data 01/10/2015 13:43:56 disse:


Quoto se sono cose banali, se sono cose più complesse uso dei metodi:



result = (blablabla) ? CasoA() : CasoB()

return result;



A volte compatto ma è una passa testare, è vero!



 Soprano



Beh credo più che altro sostengono di utilizzare i concetti legati alla oop.

Ad esempio costrutti tipo:

if(object instanceof String) else if (object instanceof Pota)

sono deprecabili in favore di un utilizzo migliore del paradigma, che favorisca la manutenibilità del codice.








l'if-else ternario. Lo uso moltissimo anch'io, mi piace davvero

molto.

E' molto adatto alle situazioni in cui hai due possibili

risultati che dipendono da una variabile (o espressione)

booleana.

A me piace anche usare degli if else ternari annidati, tipo:



result = (boolean_expr1 ? (boolean_expr2 ? a : b) : c);


 





come ho detto rispondendo a Menegotto, e come del resto ha detto lui

stesso, per una cosa come questa c'è anche l'if-else ternario.



p.s.

ma tu, se hai una sola riga di istruzioni, non metti le parentesi?

Cioè, scrivi



if (blablabla) 

   result = 42; 

else 

   result = 97;



invece di



if (blablabla) {

   result = 42; 

} else {

   result = 97;

}

?



che con le parentesi è molto più leggibile e manutenibile...


 di un ciclo while?



Non lo è infatti, non è nemmeno necessario per la teoria della computabilità quando hai la ricorsione (o un suo caso speciale come l'iterazione). Pragmaticamente, se hai pattern matching e if expressions puoi fare come se non esistesse.


 
http://antiifcampaign.com/




Non sarò il loro target (non voglio usare certi tipi di "Objects" e il subtype di defautl invece che ad-hoc/parametrico, le istanze dell'Expression Problem senza il supporto di first-class modules non mi vanno, etc.) ma di certo posso dire che il problema sul sito è proprio presentato da cani eh.



Praticamente il modo di fare design in Smalltalk (che un if statement non l'ha tra l'altro) e che è stato volutamente rigettato all'epoca da quasi tutti. Go figure.


 reali.



stiamo parlando di problematiche reali.


 male non è così marcata come per chi non lo conosce. 



Quotissimo.

L'if è una scorciatoia che alla lunga porta alla illeggibilità del codice.


 result = (boolean_expr1 ? (boolean_expr2 ? a : b) : c);



evviva la leggibilità :)



-- 

Soprano


 have a similar setting." 



negli altri veicoli manca l'IF incriminato che fa scattare la trappola.



-- 

Massimiliano Adamo








il tempo, lo stress e la fretta, rootkit, non sono affatto

giustificazioni.

Quando il budget è poco, bisogna fare le cose alla svelta e

ogni 30 minuti continuano a chiederti "come va? funziona? hai

finito?", diventa difficile mantenere la lucidità necessaria

per far bene le cose.

Almeno per me è così.



Se mi mettono sotto pressione, se mi chiedono ogni 30 minuti

a che punto sono, e se poi ogni cosa che faccio mi dicono su

perché non è fatto secondo la loro testa (spero che si capisca

l'espressione "dire su"), per me sono le peggior condizioni

possibili di lavorare, e allora faccio alla svelta perché il

lavoro sia finito.





Se invece mi danno il tempo necessario per pensare a come fare

una cosa, non mi mettono sotto pressione e non mi stressano

ogni 30 minuti, allora per me è più facile cercare di fare un

lavoro fatto bene, oltre che funzionante.



Io sono fatto così.





perché, quell'espressione ti pare poco leggibile?

A me sembra chiara.

Poi certo, dipende anche da cosa sono le boolean_expr, ma

potrebbero essere anche delle variabili valorizzate prima :)


 





probabilmente sì.

Come appunto l'ereditarietà, come mostra l'esempio

che ho postato.

Puoi definire una classe base (DoSomething), cosicchè

tutte le classi che si occupano della business logic di

quel punto la estenderanno.

Poi in ogni classe derivata metti la logica che devi mettere,

e con la mappa associ le classi ai possibili valori.

Se devi modificare la logica, cambi la classe corrispondente.



Inoltre, con l'ereditarietà, se per qualche motivo tutte le

classi derivate devono esegire una certa logica comune

prima di differenziarsi, questa logica la metti tranquillamente

nella DoSomething, e nelle classi drivate la richiami facilmente.





Solo che io mi domando se, nel caso di un esempio semplice come

quello che ho fatto, valga la pena implementare questo meccanismo.

Certo, togli gli if e usi i concetti della oop, ma forse per un

pezzo così semlice anche con gli if o con lo switch puoi lo stesso

fare un buon lavoro.



Voglio dire, bisogna anche tener conto della complessità delle

situazioni, per decidere un approccio piuttosto che un altro.


 lavoro sia finito.



si però qui sposti la discussione su un piano che non mi interessa. voglio

dire, anche supponendo che te sia dalla parte della ragione il problema non

sarebbe lavorare più o meno bene, ma tollerare quel clima. non ho la

presunzione di citare me stesso, ma la totalità delle persone di cui ho 

un minimo di stima professionale in situazioni come quella reagirebbero con

decisione e sicuramente non lo subirebbero.





L' importante no è usare gli if (o switch) ma l' importante è che siano 

localizzati e non duplicati.

Alla fine la scelta della classe figlia deve essere fatta in qualche 

modo, l' importante che sia fatta in un punto solo,magari un function 

che ritorna un puntatore di tipo padre che in realtà punta al figlio 

(poliformismo)

Anche un array o map di puntatori a padri potrebbe andare bene 

(dispatching).










dunque, io i puntatori li ho visti un po' (ma poco) all'università,

quando ho studiato un po' il C.

Ma in ambito lavorativo, come ho detto più volte, ho lavorato solo

in java, e che io sappia in java non ci sono i puntatori.

Ma tu come scriveresti, in java, l'esempio dei DoSomething?

Potresti postare un po' di codice, in modo da vedere concretamente

la tua idea?

Mi piace vedere idee diverse.










un semplice metodo per il poliformismo è facile

Supponendo che la classe parent sia genitore di child1 e child2





public static parent doSomething() {

	...

	switch(cond) { //una condizione

		case ..: return new child1(..);

		case ..: return new child2(...);

	}

	assert(false);

	return null;

}





L' importante è che la scelta della classe venga fatto in un punto solo 

del codice come in questo caso; basta chiamare  doSomething dove serve.

Visto che in java non esistono funzioni ma metodi questo metodo  è 

dichiarato statico  pubblico  in parent (il luogo migliore in cui metterlo)














 dichiarato statico  pubblico  in parent (il luogo migliore in cui metterlo)



hai descritto in maniera approssimativa un ibrido fra il factory pattern e

il factory method pattern.






E' un factory,come credevi che facessi ?

Se hai idee migliori spiega.



Io la chiamerei con il nome instance ma ho tenuto il nome voluto da Kojak.




 Se hai idee migliori spiega.



non ho "idee migliori" (migliori per cosa?). conosci i design pattern? bene,

se li conosci saprai che ce ne sono diversi creazionali, fra cui factory e

factory method. quello che hai descritto è un ibrido fra questi due. 







In java sono tutti factory method, non esistono funzioni fuori da una 

classe.



 classe.



seh, buonanotte.

https://en.wikipedia.org/wiki/Factory_method_pattern


https://en.wikipedia.org/wiki/Abstract_factory_pattern


https://en.wikipedia.org/wiki/Creational_pattern













Dettagli




 Dettagli



sì, che bisognerebbe conoscere però.






Non sono un purista java per conoscere a memoria i nomi dei vari pattern

Java per me è solo uno strumento di lavoro e basta.

Come linguaggio non mi esalta per niente.

Come tu sai i miei linguaggi preferiti sono C++,C e perl




 Come tu sai i miei linguaggi preferiti sono C++,C e perl



dire semplicemente e serenamente che una cosa non la conosci deve

davvero costare una cifra al tuo ego...










Conosco i pattern, li uso tranquillamente in C++

Solo non ricordo a memoria tutti i nomi e la varie sfumature.

La prima via verso l' illuminazione è conoscere i propri limiti,non lo 

sapevi ?

Quello che non so non ho alcuna difficoltà ad ammetterlo,ma tu ?








 Non viene scritto.



no via, non ci posso credere.

basta, fai conto non ti abbia detto niente. in java ci sono i puntatori e

vaffanculo.










flames a parte, sono abbastanza d'accordo con quanto ha detto rootkit,

anche per quanto riguarda i puntatori.

E poi lo switch non lo hai eliminato :)

Comunque anche questa mi sembra un'idea abbastanza interessante.




 che tiene traccia di istanze di tipi non primitivi



Ma non è un puntatore. E mi stpisce che tu non conosca approfonditamente 

i puntatori (almeno questo si desume da quel che scrivi).



Un refrence in generale è un'etichetta, un puntatore una variabile che 

contiene fisicamente un indirizzo di memoria. Da un punto di vista 

puramente concettuale, si somigliano. Ma mentre il puntatore è 

un'"indicazione" diretta, per dereferenziare un reference devi passare 

per il sistema operativo.



Visto che mi pare di aver capito che conosci le API di Windows (e quindi 

sei stato frequentatore di Charles Petzold e compagnia), in generale un 

reference è più vicino a un handle che non a un puntatore.



-- 

Ciao!

Luca










Certo,gli handle

Esistevano anche nel mac della apple,anni 90, ben prima dell'attuale os 

basato su unix.

E naturalmente su windows

Ma non sono mai stato un frequentatore di Charles Petzold e compagnia 

pur conoscendo i suoi libri.

Credo che ti stia confondendo con qualcuno d'altro.









Alla fin fine,a quanto a sembra, i reference sono dei puntatori (handle) 

a risorse in cui per ottenere l' oggetto occorre fare richieste all' OS 

(ma piu che all' OS direi al sistema java)

Comunque la faccenda è chiarita.

Per gli switch (o if) non ho mai scritto che occorre eliminarli del 

tutto, ma solo localizzarli

Quindi non copiare codice inutilmente.








 Credo che ti stia confondendo con qualcuno d'altro.



Peccato. Il buon Charles scriveva (scrive?) libri molto formativi.



-- 

Ciao!

Luca




 di memoria dell'oggetto cui mi voglio riferire. 



Non sono tanto d'accordo. Penso che la variabile puntatore, come usata in C e simili, contiene un indirizzo di memoria, a cui non necessariamente deve corrispondere un costrutto del specifico di quel linguaggio (non scrivo oggetto per evitare confusione). Pensa all'accesso ai registri di qualche apparato/periferica hardware, che sono mappati ad una certa locazione di memoria fissata ed immutabile. A parte ovviamente il "costrutto" più elementare, che è il byte.




 a loro volta blocchi condizionali, etc...).



Questa parte mi lascia perplesso anzichenò. Ora, io sarò l'ultimo dei coglioni in termini di programmazione, ma il numero di casi di test (che per adesso consideriamo uguale al numero di branch del programma, anche se non è detto sia così) non è dato dall'implementazione, ma dal problema/dominio in cui stai lavorando. Banalizzando, se l'algoritmo deve trattare un dato che può essere positivo o negativo e dare un risultato diverso a seconda dell'uno o dell'altro caso, tu comunque dovrai scrivere (almeno) due casi di test e il programma dovrà in un modo o nell'altro avere due branch o comunque due linee di esecuzione diverse, siano esse fatte con un IF, un GOTO, una dictionary, lambda functions o sarchiaponi. 

Ma sicuramente sbaglio io ;)



bye!


 Ma sicuramente sbaglio io ;)





io direi che il principio sia fare in modo che tutto il codice sia coperto

dai test. banalmente, se dentro un blocco if tu hai un bug e non testi mai

la condizione per cui quella if è verificata, quel bug non lo scovi. 

ci sono strumenti (ne conosco diversi in java) che ti dicono il coverage

e quali linee di codice non sono mai percorse durante i test.



se uno adotta la tdd la prima preoccupazione è scrivere codice testabile. 

tu hai fatto un ipotesi di caso tutto sommato ben testabile, ma mettiamo

invece questo caso:



if(getSomeStuff(param) == getSomeOtherStuff(param)) {

...

};



questo non è testabile se non costruendosi un case apposta che ti consenta

di entrare "di forza" in quella if (nel caso "mockizzando" i due metodi).














 Penso che la variabile puntatore, come usata in C e simili, contiene un

 > indirizzo di memoria,



Punto. Cosa ci sia a quell'indirizzo di memoria è tutt'altra questione. 

In questo il C è potente e pericoloso: sistema velocissimo per l'accesso 

ai dati, considerata anche l'aritmetica applicabile; ma se accedi a una 

locazione casuale (o, peggio ancora ci scrivi) i danni sono assicurati!



-- 

Ciao!

Luca












Ne ho letto qualcuno a suo tempo.




 locazione casuale (o, peggio ancora ci scrivi) i danni sono assicurati!



Certamente, è pericoloso. E' anche vero però che il s.o. non dovrebbe consentire ad un qualsivoglia programma di puntare fuori dalla sua partizione di memoria, come dicevamo in altra discussione. 







L'OS protegge gli altri su altri processi, questo è un suo compito

Ma non proteggere tutti gli errori logici di accesso tramite puntatori 

all'interno di uno stesso processo in quanto i controlli li fa a livello 

di pagina




 Certamente, è pericoloso. E' anche vero però che il

 > s.o. non dovrebbe consentire ad un qualsivoglia

 > programma di puntare fuori dalla sua partizione di

 > memoria, come dicevamo in altra discussione.



E' esattamente il motivo per cui ormai C è relegato a programmazione di 

microcontrollori come sostituto di Assembly; d'altra parte, facevamo 

casini inenarrabili noi, all'epoca, che eravamo veramente ben formati, 

figurati cosa potrebbe fare lo zio Luca (io) attualmente, che son almeno 

20 anni che non ci spippola, o qualsiasi altro tecnico che non ha la 

forma mentis per gestire una cosa del genere.

Molto meglio Python, Ruby, Java, C# o quel che si vuole.



-- 

Ciao!

Luca






 di pagina



Se tu usi uno degli n-mila linguaggi che NON hanno i puntatori, problemi 

non ne hai.

E, detto tra noi, per il 90% delle occasioni, e forse son stato scarso, 

non servono proprio.



-- 

Ciao!

Luca






 Intendi con managed,le classi shared_ptr,unique_ptr e weak_ptr ?



No, per managed, nel mondo .NET, si intende che il risultato passa sotto 

.NET (IL, CLR e compagnia cantante). Perdona, non sono stato chiaro.

Negli ambienti di sviluppo MS, C++ vive in modo doppio: puoi scegliere 

se ottenere il risultato compilato nativo, o puoi scegliere se ottenere 

un risultato .NET.



-- 

Ciao!

Luca





Ma questo è il C,e se si vuole avere a che fare con strutture a basso 

livello in modo efficiente i puntatori sono indispensabili.

Senza contare lo heap il cui accesso lo si deve fare con puntatori,che 

piaccia o no.

Anche java fa cosi,ma li ci pensa il GC che è impensabile in C.






Lo so che li il C++ vive anche sotto .NET,ma mai usato in quell'ambiente

E .Net non è un ambiente che uso anche per altri linguaggi.






 non servono proprio.



Assolutamente vero. Certo se vuoi la velocità, li usi :-) O se devi chiamare qualche funzione di libreria a standard C. O se vuoi inventarti qualche acrobazia cpn i puntatori a funzione.


 di entrare "di forza" in quella if (nel caso "mockizzando" i due metodi).



Non è questo il punto che cercavo di dire... il mio esempio era veramente il massimo della banalità. Se hai bisogno di mettere una condizione che biforca l'esecuzione della logica se LaRobaDaUnaParte è uguale o meno a LaRobaDaNartraParte, mi pare abbastanza ovvio che dovrai preparare due test dove in un caso è tutta la stessa Roba, e nell'altro caso è Roba diversa. Lo metti come se fosse un fastidio o un lavoro accessorio, ma come lo dovresti evitare? 

E non vedo come possa cambiare qualcosa il costrutto usato per biforcare il codice. 


 Oddio, problemi di memoria trashata ce li puoi avere pure con certe versioni di Cobol, che non hanno i puntatori.



OK, ma in questo caso pianifichi anche la garbage collection.



-- 

Ciao!

Luca







Ma che è sto problema dei puntatori ?

C è un assembler portabile ed un assembler portabile deve avere i 

puntatori,non se puo fare a meno.

D'altronte oggi esistono strumenti di sviluppo in altri linguaggi di ben 

piu alto livello che C e vanno bene per soddisfare i comuni applicativi.




 piu alto livello che C e vanno bene per soddisfare i comuni applicativi.



Mah, visto che "di questi tempi" si parla di db, perfino Sqlite, ovvero un sistema di archiviazione locale senza eccessive pretese, è scritto in C.

Direi che il concetto di "comune applicativo" è molto elastico, e molti se ne impipano altamente dei moderni linguaggi di ben più alto livello. Forse sono degli irrimediabili testoni :-)






Se vogliono il C imparino ad usarlo ed ad accettarne anche le 

problematiche connesse.

Uso il C da una vita ma mai mi sognerei di togliere i puntatori pur 

conoscendo i problemi connessi.




lavoro sia finito.



Ti trattano come si fa con la bassa manovalanza...

evidentemente tu permetti a loro di farlo.



Praticamente hai accettato l'equazione:



programmatore =  garzone di bottega





Pensi che un qualsiasi artigiano (non voglio nemmeno dire professionista)

accetterebbe di lavorare cosi'?



Non sei mai stato da un meccanico farti riparare l'auto?

Mai chiamato un imbianchino a tinteggiare una stanza?



Prova a comporarti con uno di loro nel modo che hai descritto...e vedrai.



ciao

fm






 informatico italiano,



no, questo gruppo riflette il livello di *spocchia* informatica italiana



-- 

"Anche quelli che sostengono che tutto è predeterminato guardano bene,

prima di attraversare la strada." -- Stephen Hawking




 



altroché se ci sono stato. Troppe volte...