Newsgroup: it.lavoro.informatica
Titolo: C#, Unit Test e metodi non pubblici.

Mi trovo a dover creare un nuovo progetto - roba da qualche giorno - e mi trovo di fronte a una roba che non avevo calcolato relativamente a C#.



Io negli ultimi 10 anni ho sempre lavorato in Python. Li UT dei metodi di una classe è semplice: non esistono metodi privati o protetti!



Invece in C# i metodi non pubblici esistono eccome! Solo che, ovviamente, dall'esterno si accede solo a ciò che è pubblico (o protetto, per ereditarietà) di una classe.



Due i casi: o metto tutto pubblico (mi piace poco) o vado di reflection a nastro (mi piace altrettanto poco).



Tralasciando C#, voi come vi regolate?



-- 

Ciao!

Luca


 Io negli ultimi 10 anni ho sempre lavorato in Python. Li UT dei metodi di una classe è semplice: non esistono metodi privati o protetti!



E` sempre sbagliato (anche in Python) testare direttamente i metodi privati (il fatto che in Python vi sia solo una name convention a definirli, ma siano sempre accessibili, non significa che sia corretto accedervi nei test). Si testa il contratto della classe, non come la classe implementa internamente il contratto. Se la tua classe e` cosi` complessa da necessitare il test diretto dei metodi privati, vuol dire c'e` qualche problema di design. La soluzione piu` ovvia e` modularizzare la classe in maniera tale da testare le singole parti in maniera indipendente. Se si tratta di codice legacy, la reflection puo` essere un'eccezione alla regola. La soluzione a lungo termine e` usare un approccio TDD.


On Wednesday, 14 September 2016 14:48:02 UTC+1, Luca Menegotto  wrote:



[...]

Poi, visto che "i professionisti seri leggono i libri", magari munisciti di questo: 



https://www.amazon.co.uk/Art-Unit-Testing-examples/dp/1617290890/ref=sr_1_1?ie=UTF8&qid=1473862917&sr=8-1&keywords=art+of+unit+testing





 Tralasciando C#, voi come vi regolate?



ci sono 4 opzioni:

- non testare i metodi privati

- allargare la visibilità di tali metodi almeno alla classe di test

- usare una classe di test interna

- usare la reflection



io prevalentemente opto per la prima. altrimenti se è necessario testarli

vuol dire che non devono essere privati.




On Wednesday, 14 September 2016 15:20:54 UTC+1, 4ndre4  wrote:



[...]

Ah, ovviamente, ti conviene munirti di un tool che mostri il coverage dei tuoi test. Qui da me si usa SonarQube: 
http://www.sonarqube.org/


I vari issue sollevati da SQ sono molto utili anche a fare refactoring del codice perche` soddisfi certi requisiti di stile, pulizia, ecc.. 


 
https://www.amazon.co.uk/Art-Unit-Testing-examples/dp/1617290890/ref=sr_1_1?ie=UTF8&qid=1473862917&sr=8-1&keywords=art+of+unit+testing




Vedo se esiste in formato Elettronico. Ormai non acquisto già da un pezzo manualistica cartacea. Grazie per la segnalazione.



-- 

Ciao!

Luca


 vuol dire che non devono essere privati.



Mah. Magari ho frainteso io, però talora ha senso anche testare i metodi privati. Capita di avere spezzoni di codice più o meno ripetuti; la mia soluzione è sempre stata: isolo e generalizzo; però devo sempre testare ciò che ho isolato e genralizzato, e se lo faccio a parte, meglio. Talora capita che ciò che ho isolato e generalizzato sia solo a uso e consumo di due o più metodi di una classe, per cui viene abbastanza naturale renderlo non pubblico.



-- 

Ciao!

Luca


Capita di avere spezzoni di codice più o meno ripetuti; la mia soluzione è sempre stata: isolo e generalizzo; però devo sempre testare ciò che ho isolato e genralizzato, e se lo faccio a parte, meglio. 



Certo, ma quando estrapoli un comportamento, lo incapsuli in una classe B, che diventa un collaboratore della classe A, e la testi in isolamento.



Se pensi che si debba poter testare il comportamento che tu estrapoli in un metodo privato, testando direttamente il metodo privato, non hai capito a cosa serve lo unit testing, e ti sei messo su una strada molto impervia.



I metodi privati non vanno testati,semplice, in quanto sono una cosa 

interna alla classe.

I metodi protected andrebbero testati,eredita in una classe apposita 

fatta per i test

I metodi pubblici idem.





no è qui che ti sbagli.



un metodo privato non è semplicemente un metodo ad uso e consumo della 

classe: è un metodo che *non* *deve* essere chiamato al di fuori della 

classe. essendo un modificatore di visibilità si suppone che tale metodo 

non sia "safe" invocarlo direttamente.



se non ci sono controindicazioni ad essere chiamato direttamente e vuoi 

sottoporlo a test, allora lo rendi pubblico. in questo modo non violi 

l'incapsulamento.



capisco quello che vuoi fare ma non è questo il modo di ottenerlo. se 

vuoi stabilire un contratto per quella classe e nascondere alcuni metodi 

per mera questione di eleganza e pulizia codice, usi le interfacce.




 per mera questione di eleganza e pulizia codice, usi le interfacce.



In effetti, da un punto di vista contrattuale, le interfacce sono molto utili (anzi, guai a non averle!). Io trovo però che abbiano uno scopo differente rispetto a quel che pensavo io.



-- 

Ciao!

Luca


 detta così diventa banale - a mia discolpa, ieri ero davvero cotto.



Non conosco le regole di visibilita' del c# (e nemmeno il linguaggio) ma

in java lo si e' fatto per molti anni, sfruttando il fatto che protected

in realta' significa anche accessibile all'interno dello stesso package.

Per cui piazzavi i test in un'altra cartella (src/main/test) ma stesso

package e il gioco era fatto.



Ma in ogni caso rimane una brutta pratica come ti hanno gia' spiegato.

Non testare quei metodi. Se hai bisogno di testarli significa che vanno

estratti in una nuova classe.



Se non sbaglio questo libro spiega molto bene il perche', e molte altre

cose (e' sul TDD, stile top down se sai cosa significa).


 cose (e' sul TDD, stile top down se sai cosa significa).



ops!



http://www.growing-object-oriented-software.com/



 fatta per i test



direi di no.


 fatta per i test



No, i metodi protected non vanno testati. Se scrivi una classe apposita 

solo per i test, stai comunque sbagliando.



-- 

4ndre4

"The use of COBOL cripples the mind; its teaching should, therefore, be 

regarded as a criminal offense." (E. Dijkstra)

"Ora, questo "Delta11" non è nulla di più di uno scemo del villaggio" - 

(L'Accalappiafasci)


Io trovo però che abbiano uno scopo differente rispetto a quel che pensavo io.



Ovvero?



 Ovvero?



Io anni fa ho usato moltissimo le interfacce per il rendering di oggetti non necessariamente derivati dalla stessa classe base.



-- 

Ciao!

Luca


 situazione lo richiede.



In quel caso hai individuato un nuovo collaboratore dell'oggetto. 

Complimenti! :D



Estrai il metodo e crea una nuova classe. Testa quella nuova classe. Se 

ti secca che sia troppo pubblico, piazzalo in un oggetto con visibilita' 

package (parlo di Java). Quello direi che e' sensato testarlo.



Se la risposta non ti convince ancora, fai un esempio please.


E, per come la vedo io, ha senso che quel metodo possa (non ho detto debba) essere testato singolarmente, se la situazione lo richiede.



Tu devi poter testare la logica che quel metodo implementa, ma non significa che quella logica debba stare in un metodo privato (e tantomeno protected, se l'unico scopo e` renderlo testabile). Come gia` detto, se individui della logica cosi` complessa da necessitare di un test diretto, allora quella logica dev'essere incapsulata in una classe, che avra` il suo bel unit test dedicato.


 
http://www.growing-object-oriented-software.com/




Ottimo libro. L'ho divorato. Aggiungerei anche "Effective Unit Testing" e "Test-Driven" di Koskela.





Mi attacco qui. Grazie a tutti per i suggerimenti.



Luca


 differente rispetto a quel che pensavo io.



lo scopo delle interfacce è esattamente quello che ti ho detto, stabilire 

il contratto fra chi implementa una classe e chi la usa. quindi se è per 

una questione formale basta non mettere il metodo fra quelli esposti 

dall'interfaccia, se invece è una questione sostanziale (ovvero non è 

proprio safe invocare il metodo fuori dall'ambito) allora vincoli con la 

visibilità. però a quel punto diventa anche sostanziale non violare il 

vincolo di incapsulamento neanche nei test: perché vorresti forzare la 

mano e invocare un metodo fuori dal suo contesto quando sai che non è 

progettato per questo?





Andrebbero,e' un optional




 Andrebbero,e' un optional



"Andrebbero" non e` un optional. "Andrebbero" significa "sarebbe buona pratica farlo" e cosi` non e`.




Il giorno mercoledì 14 settembre 2016 15:48:02 UTC+2, Luca Menegotto ha scritto:


Al di la' dell'opportunita' o meno di farlo, e senza tralasciare C#, se usi Visual Studio dai un'occhiata alla classe PrivateObject che la Microsoft ha fatto proprio per testare metodi non pubblici.


Vero, esiste PrivateObject, ma è sostanzialmente una reflection in disguise. Personalmente, sconsiglio *vivamente* di usare questi accrocchi per esercitare i metodi non pubblici. Se i test cominciano ad entrare nei dettagli di come un contratto è implementato, la manutenzione può diventare un inferno e perdono la loro valenza. Se si adotta un approccio TDD, gran parte di questi problemi di design si risolvono naturalmente.



Non sanno piu cosa inventare

Mi chiedo che senso puo avere

Tra l'altro i metodi privati possono anche variare durante la 

manutenzione di una classe pur lasciando inalterati i metodi pubblici.










bellissimo tred...però non ho capito...state facendo accademia come al 

solito?

aaaaaaaaaaaaaaaaaaa ecco...ma i dati dove sono? da dove arrivano? come 

arrivano? dove saranno storicizzati? in che modo? chi li dovrà usare?

a quale scopo?



-- 

Ripristinare il trattato di Vienna è imperativo!

W IL LOMBARDO-VENETO.

W LA LIBERTA'.

ONORE E GLORIA A S.M. CARLO D'ASBURGO-LORENA!!!


 se usi Visual Studio



...Bill Gates andava ucciso nella culla!



 Mi chiedo che senso puo avere



Se non ti fermi davanti al fatto che sarebbe meglio non farlo, un senso ce l'ha eccome. Questo perche' MS sviluppa e vende strumenti di sviluppo, mica metodologie. Una feature del genere era esattamente quello che stava cercando Luca e come lui chissa' quanti altri, quindi MS, il cui scopo e' fare $ fornendo agli utenti quello di cui hanno bisogno (o credono di aver bisogno), e non fare formazione, lo fa. Implementare PrivateObject costa pochissimo, insegnare TDD a valanghe di sviluppatori (che poi magari neanche sono interessati a farlo), invece?






 

E tu continua pure a usare il SEU



cazzo è il SEU?



 

non sei un dinosauro che rimpiange il 36?




Source Entry Utility



Non lo sa cos'e' il seu, lui usa xedit, forse, ma forse usa schede 

perforate.


 perforate.



bah, secondo me non ne sa un cazzo semplicemente perché non ne ha mai

saputo un cazzo.

mi da l'aria di un poveraccio scaricato dal mondo intero che ce l'ha

con tutto e tutti, millantando antiche sapienze che non ha mai avuto.

una carriera dedicata all'imboscamento, ecco questo ce lo vedo.


Implementare PrivateObject costa pochissimo, insegnare TDD a valanghe di sviluppatori (che poi magari neanche sono interessati a farlo), invece?



Devo ancora sentire una ragione valida da parte di quegli sviluppatori, pero`.

Sanno dire "non sono interessato a farlo", ma quando gli chiedi perche`, balbettano.








 [...]un poveraccio scaricato dal mondo intero 



Ma scherzi? Lui e` un "professionista serio". Delle stronzate, ma serio.



non mi offendere...IO NON HO MAI LAVORATO COL 36 roba da 

ragionieri..,..IO LAVORAVO COI COMPUTER VERI

S/360

S/370

43XX



POI  PASSATO AI MINI

PDP

TEXAS INS.



POI PASSATO A *NIX NCR E COMPAQ



SEMPRE IN COBOL UNICO LINGUAGGIO PER SERI INFORMATICI



....e non mi offendere piu!




la presunzione è la madre di tutte le cazzate




pensa alle tue di stronzate che ne spari a raffica!




perchè a differenza tua sanno distinguere le pirlate dalle cose serie




Ah, ma quello mica lo metto in discussione. Dico solo che MS ha perfettamente ragione a implementare cose simili. Che sia il caso di usarle e' tutta un'altra storia


 cazzo è il SEU?



SEUCK



https://it.wikipedia.org/wiki/Shoot%27Em-Up_Construction_Kit








Magari mi manca un pezzo visto che non conosco il c#. Ma accedere ai

campi private lo si fa anche in Java via reflection (al di fuori del

testing parlo), e puo' avere un senso.






 Ah, ma quello mica lo metto in discussione. Dico solo che MS ha perfettamente ragione a implementare cose simili. Che sia il caso di usarle e' tutta un'altra storia



Non capisco: ha senso implementare qualcosa se e` il caso di usare quel qualcosa. Se non e` il caso di usarlo, non ha senso implementarlo. Tu puoi congetturare che Microsoft abbia furbescamente introdotto quella caratteristica per fare soldi - cosa a mio avviso molto opinabile perche` non la vedo proprio come una feature che invogli maggioramente uno sviluppatore a comprare il prodotto.




 testing parlo), e puo' avere un senso.



PrivateObject e` specifica per i test e quello scopo: "Allows test code to call methods and properties on the code under test that would be inaccessible because they are not public." (
https://msdn.microsoft.com/en-us/library/microsoft.visualstudio.testtools.unittesting.privateobject.aspx
)



La reflection esiste anche in C#, con GetType()/GetMethod()/Invoke() puoi accedere ai metodi privati esattamente come fai in Java.


 Se non e` il caso di usarlo, non ha senso implementarlo. Tu puoi congetturare che Microsoft abbia furbescamente introdotto quella caratteristica per fare soldi - cosa a mio avviso molto opinabile perche` non la vedo proprio come una feature che invogli maggioramente uno sviluppatore a comprare il prodotto.



Secondo te MS ha altri scopi oltre a quello di fare soldi?

Secondo me sottovaluti la quantita' di sviluppatori che ha sentito parlare di unit test e che vuole adottarli senza averne capito del tutto la filosofia. Uno sviluppatore che si fa domande come quella che ha dato origine al thread se trova PrivateObject prima di venire a scrivere qui molto probabilmente rimane convinto che vadano testati a quel modo anche i metodi privati e la trovera' per forza di cose una feature comodissima. Di sicuro e' solo una goccia nel mare di cose che offre Visual Studio, ma poi si pesano anche queste piccolezze quando uno si trova a scegliere fra .net e java per il prossimo progetto e giustamente MS ne tiene conto.


 comodissima. 



anche perché si parla di regole generali, non di norme scolpite nella 

pietra.

io sono dell'idea che se un metodo è privato vuol dire che non è 

progettato per essere invocato stand alone, quindi neanche nei test. 

viceversa se il metodo può essere chiamato dall'esterno non c'è ragione 

di essere privato. molti confondono la visibilità (che è un accorgimento 

progettuale) con il contratto (che è una convenzione) e usano la 

visibilità per "nascondere" ciò che non fa parte del contratto. per me è 

sbagliato, ma leggendo in rete la discussione è tuttaltro che chiusa.


Di sicuro e' solo una goccia nel mare di cose che offre Visual Studio, ma poi si pesano anche queste piccolezze quando uno si trova a scegliere fra .net e java per il prossimo progetto e giustamente MS ne tiene conto.



Continuo sinceramente a dubitarne.


 visibilità per "nascondere" ciò che non fa parte del contratto.



Probabilmente non ho capito che intendi, ma io non ci vedo niente di sbagliato nell'usare la visibilita` per rappresentare il contratto. Dov'e` l'errore?







Tra l'altro i metodi privati possono scavalcare l'invariante di una classe




 quando uno si trova a scegliere fra .net e java per il prossimo progetto 



Ocio. VisualStudio non è .net... E, personalmente, a me .net piace, anche nell'implementazione di Novell.



PS. Visual Studio Community non si paga.



-- 

Ciao!

Luca






 Probabilmente non ho capito che intendi, ma io non ci vedo niente di sbagliato nell'usare la visibilita` per rappresentare il contratto. Dov'e` l'errore?



Mi accodo. Anche se devo dire che ho usato per anni Python: li tutto è visibile, e, devo dire, non ho sofferto la cosa.



-- 

Ciao!

Luca


 Li tutto è visibile, e, devo dire, non ho sofferto la cosa.



Tutto e` *accessibile*, che NON vuol dire visibile. La visibilita` e` strettamente legata al contratto. Se un metodo della tua classe e` accessibile, non vuol dire che sia visibile da contratto. Il fatto che tu abbia un doppio underscore come prefisso dei nomi dei metodi privati, in Python, non significa che sia corretto testarli direttamente. Quei metodi sono accessibili ma contrattualmente NON visibili, e quindi non e` corretto testarli direttamente.




On Friday, 23 September 2016 16:49:01 UTC+1, 4ndre4  wrote:



[...]

E aggiungo che usare gli specificatori di visibilita` (e.g. "public", "private", "protected") non e` un modo per *impedire* all'utilizzatore della tua classe di accedere a quei metodi. Bastano due righe di reflection, infatti, e quel vincolo sarebbe superato. Lo scopo e` quello di definire, per l'appunto, un contratto.




 Il fatto che tu abbia un doppio underscore come prefisso dei nomi dei metodi privati, in Python, non significa che sia corretto testarli direttamente. 



Vero quel che dici in fondo - mi sto documentando, e mi avete convinto - ocio: formalmente sono quelli con undescore semplice quelli privati; i metodi preceduti da dunder sono preferibilmente a uso e consumo degli sviluppatori del linguaggio Python.



-- 

Ciao!

Luca


 E aggiungo che usare gli specificatori di visibilita` (e.g. "public", "private", "protected") non e` un modo per *impedire* all'utilizzatore della tua classe di accedere a quei metodi. 



Verissimo. E' un modo per dire: io l'ho disegnata così (contratto). E Intellisense così la capisce. Per fortuna.



-- 

Ciao!

Luca


ocio: formalmente sono quelli con undescore semplice quelli privati;



Si`, pensavo a quello. Ho scritto doppio underscore, ma in realta` era a quello che mi riferivo.


 Mica sempre. Per fare un esempio stupido seguendo il tuo criterio le sigarette non verrebbero prodotte.



mi sembra ovvio: anche se si seguisse il mio esempio (non fumo) le sigarette non verrebbero prodotte.



non vedo perche' produrre roba che non viene usata da nessuno.


 Verissimo. E' un modo per dire: io l'ho disegnata così (contratto).



l'interfaccia è il contratto.

la visibilità è un modo per dire: non è pensato (progettato) per 

essere chiamato fuori dal contesto private/protected.

per esempio, un metodo che fa parte di una sequenza di operazioni e

se invocato da solo lascerebbe l'oggetto in uno stato non consistente.



Ovvio. Ma c'e' un sacco di roba che viene usata anche se non sarebbe il caso di farlo


 Continuo sinceramente a dubitarne.



sara' come dici tu, pero' PrivateObject esiste e io dubito che chi lavora in MS non sappia che non e' il caso di testare metodi private...



Un contratto e' un po di piu che una semplice interfaccia

Un contratto e' composto dall'interfaccia pubblica di una classe piu le 

sue invarianti




On 28/09/2016 10:03, Paguro Bernardo wrote:



[...]

 >Il fatto che non renda una cosa piu' appetibile per me non significa 

che non lo faccia per un altro.



Mi continua a suonare strano. Non capisco a chi possa sembrare 

appetibile una cosa del genere. Oltretutto, aggiungere funzionalità ad 

un prodotto software costa, e tanto. Bisogna farlo se ne vale la pena. 

Chi ha convinto un product manager MS che C# aveva bisogno di quella 

caratteristica deve essere veramente un bravo venditore. Sarei curioso 

di vedere chi è che usa per davvero quella roba.



 >Probabilmente tendi a dimenticare che purtroppo la maggior parte delle 

persone che si occupa di informatica non ha tutta sta competenza e 

spesso non ha neanche la voglia (ma in molti casi anche il tempo e la 

possibilita') di migliorare.



No, no, tranquillo: alcuni elementi di questo ng me lo ricordano 

continuamente.



 > secondo me confondi come ti piacerebbe fosse il mondo con come 

realmente e'.



Au contraire: so bene qual è la qualità media degli sviluppatori; so 

bene che molti di loro starebbero meglio con una zappa in mano. Il punto 

è che io ritengo che, per fare lo sviluppatore, siano necessari 

determinati requisiti. Se si vuol fare quel mestiere, si *deve* studiare 

e si *deve* essera al passo. Non ci sono alternative. A meno che non lo 

si voglia fare male. Capisco che il tempo è una risorsa limitata per 

molti, ma se il medico si aggiorna, può farlo anche uno sviluppatore - 

tanto più che ciò che gli serve spesso è online, free, o disponibile per 

pochi soldi. La mia azienda, tanto per fare un esempio, ha un contratto 

con Safari Books che ci consente di leggere gratuitamente qualunque 

testo di informatica, e mette a disposizione 5000 dollari l'anno, a 

sviluppatore, per la tuition. Per cui, scuse non ne abbiamo.



 >Non conosco Luca, ma da quello che leggo qui dentro mi pare uno che 

lavora seriamente e pure competente,



Be', una persona che non sa che i metodi privati non vanno testati 

dimostra di non avere una grande competenza nello unit testing. Non c'è 

assolutamente nulla di male in questo ("nessuno nasce imparato"); 

l'importante è sanare il gap. A volte, leggere qualche libro aiuta (e 

sul testing ce ne sono tanti). È anche importante avere i mentori giusti 

sul lavoro.



 > >dubito che chi lavora in MS non sappia che non e' il caso di testare 

metodi private...



MS è un universo. Ti dico solo che nel 2008, quando sono stato al 

Microsoft Development Center di Vedbæk, in Danimarca, e ho chiesto ad 

uno dei loro ingegneri se usassero .NET per sviluppare Dynamics, mi ha 

guardato come se avessi bestemmiato.



-- 

4ndre4


 Un contratto e' un po di piu che una semplice interfaccia



Qui, la parola "contratto" e` usata in termini generali per indicare il 

protocollo di collaborazione tra le classi. L'interfaccia costituisce il 

contratto:



"Interfaces form a contract between the class and the outside world, and 

this contract is enforced at build time by the compiler." 

[
https://docs.oracle.com/javase/tutorial/java/concepts/interface.html
]



Nel DbC, invece, il concetto di "contratto" va piu` nello specifico, 

includendo precondizioni, postcondizioni, invarianti di classe, ecc...



-- 

4ndre4


 guardato come se avessi bestemmiato.



E allora, che cosa hanno usato?

NOTA: dal momento che si tratta di un CRM accessibile, suppongo, via web (si, ho visto anche CRM ancora con client a UI tradizionale), probabilmente manco io userei .NET (divento noioso se accenno a  qualcosa che inizia per P e non è Pascal?); e nemmeno un server Windows, per dire.

NOTA2: Però SQL Server è pesantemente basato su .NET. Non so se usi altro.



-- 

Ciao! 

Luca


 E allora, che cosa hanno usato?



Non lo so. Mi hanno solo detto che avrebbero migrato il code base da li` 

a poco. Mi e` solo sembrato molto strano che non usassero i loro stessi 

strumenti di sviluppo per certi prodotti, ma non ero ne` in grado di 

approfondire, ne` interessato a farlo.



-- 

4ndre4


 anche per studiare. 



Ni. Spiego: quanto all'attività fisica (*), a quasi 52 anni non è un'opzione, è una una terapia anti-aging (senza contare le endorfine, la vitamina D, ecc.) che, nota, migliora anche il tuo rendimento sul lavoro. Gli altri intessi: dipende; se parli di andare a cercare Pokemon, concordo; se si tratta di occuparti di sociale o, banalmente, del quartiere dove vivi, io penso che sia tempo speso molto bene. 

Credo davvero che l'approccio 'fa parte del lavoro' sia per me il più corretto. Dirò una banalità: 7 ore a 'pigiare tasti' (passamela) e 1 a studiare cose nuove alla fine rende più che non 'pigiare tasti' per 8 ore. Questo, ovviamente, a meno di emergenze.



(*) rigorosamente all'aria aperta.



-- 

Ciao!

Luca


 Ni. Spiego: quanto all'attività fisica (*), a quasi 52 anni non è un'opzione,



Non dico che debba essere alternativa allo studio. Dico che studiare e 

aggiornarsi fa parte delle cose che rappresentano "tempo speso molto 

bene". Anche perche` l'attivita` fisica che serve veramente sono 20-30 

minuti di esercizio aerobico a bassa intensita` 2-3 volte a settimana.



-- 

4ndre4


 minuti di esercizio aerobico a bassa intensita` 2-3 volte a settimana.



Gli ultimi indirizzi parlano di '18.000 passi due volte la settimana e 12.000 passi negli altri giorni'. 

Il che in effetti è un po' di più di quanto dice qui:

http://www.fondazioneveronesi.it/articoli/cardiologia/camminare-basta-mezzora-al-giorno/


(non fermarti al titolo, l'ideale, dice, son 10.000 passi).

Si noti che quando parla di passi parla di quanto si è fatto durante tutto l'arco della giornata. Un cameriere che fa due servizi giornalieri probabilmente li supera. Il problema è che il nostro lavoro è sendentario, per cui, anche volendo considerare i 10.000, se ne faranno si e no 2000 in attività normale e ne restano 8000; son quasi 6 km, che percorsi di buon passo significano circa 1 ora o poco più. E credi, alla fine diventa quasi una droga: a causa di un piccolo incidente son fermo da venerdi scorso, e sto scaplitando.



Circa l'aggiornamento, come ti dicevo, fa parte del lavoro, e allora lo considero nel tempo del lavoro.



-- 

Ciao!

Luca






 Circa l'aggiornamento, come ti dicevo, fa parte del lavoro, e allora lo considero nel tempo del lavoro.



Punti di vista. Per me la programmazione non e` mai stata solo lavoro.



-- 

4ndre4




Neanche per sogno.

L'interfaccia stabilisce i termini del contratto, indipendentemente da 

chi l'implementa.


 Punti di vista. Per me la programmazione non e` mai stata solo lavoro.



Manco per me. Però ho anche altri interessi. Mi piace essere interdisciplinare.



-- 

Ciao!

Luca


 regimi MOLTO poco intensi



Questo, non posso che condividerlo. A parte l'andar per monti, che pratico la domenica - e devi andare per forza a ritmi lenti (*), sennò non vai da nessuna parte - io sono un fautore del camminare. Magari coi bastoncini, ma camminare, puro e semplice. Aggiungo anche: all'aria aperta; io sono convinto che chiudersi in una palestra sicuramente sia meglio che non far nulla, ma l'aria aperta e il sole non si battono (mi rendo conto di esser fortunato, da questo punto di vista: esco di casa e ho subito splendide colline).



(*) Escludo ovviamente quelli che fano corsa in montagna. Hanno tutto il mio rispetto, però quella è una disciplina sportiva, siamo sopra la semplice attività fisica.



-- 

Ciao!

Luca




Non so quanti anni tu abbia, ma arrivato 40 anni ho deciso che dedicare un terzo della mie 24 ore all'informatica era piu' che sufficiente. E gia' cosi' vorrei fare un sacco di cose che non riesco a fare perche' il tempo non e' mai abbastanza. Fra le cose che faccio c'e' anche studiare, ma assolutamente niente che abbia a che fare col lavoro.




 che abbia a che fare col lavoro.



Amen.



Ciao

  Francesco




 Non so quanti anni tu abbia, ma arrivato 40 anni ho deciso che dedicare un terzo della mie 24 ore all'informatica era piu' che sufficiente



Io di anni ne ho piu` di te e dedico parte del mio tempo libero a studiare (leggo anche altro, ovviamente) perche` quel che faccio per lavoro e` anche un mio interesse extra-lavorativo. Per me e` molto difficile dedicare le ore lavorative allo studio perche` ... devo lavorare, e la documentazione per leggere per lavoro e` gia` abbastanza, purtroppo.



Devi escludere però anche quelli che vanno in montagna o ai parchi a 

passeggiare. Per essere attività fisica devi faticare, passeggiando puoi 

farti anche 20 km e conta zero.



-- 

Soprano


 negli stessi problemi dell'attivita` sedentaria:



Del tutto opinabile, e non occorrono video youtube a dimostrarlo. 



Chiunque faccia attività sportiva un po' seriamente va ampiamente oltre 

alle due ore settimanali di "passeggiata veloce", e _tutti_ quelli che 

conosco che lo fanno stanno benissimo fisicamente e mentalmente.



-- 

Soprano


 conosco che lo fanno stanno benissimo fisicamente e mentalmente.



Se tu avessi guardato quel video, scopriresti che a volte lo "star benissimo fisicamente" e` un'illusione. I risultati si vedono dopo molti molti anni.

C'e` poco da fare: se i dati mostrano che in 40 anni di monitoraggio, quelli che stanno meglio sono quelli che hanno svolto attivita` a bassa intensita`, c'e` poco da opinare.




 farti anche 20 km e conta zero.



proprio zero no, ma praticamente se vuoi opporla come rimedio alla vita 

sedentaria dovresti praticarla per un tempo almeno uguale a quanto ne 

trascorri seduto. cioè dovresti farne lo stile di vita prevalente allora 

sì staresti bene.



al cuore fa bene l'attività aerobica ovvero che lo tiene ad un regime 

65/70% della soglia limite. è vero la corsa non fa bene alla schiena 

(specie se uno è un po' sovrappeso) e la camminata è meglio però bisogna 

farla in modo da arrivare ad essere aerobica, tipo in salita ad esempio.








 farti anche 20 km e conta zero.



Beh, a parte che sfido chiunque a fare 20 km, pur passeggiando, senza fare un minimo di fatica, vero, la camminata deve essere abbastanza sostenuta (se in piano, intorno ai 4,5 / 5,5 km/h). Ovviamente, poi, quando parlo di montagna non intendo "vado in centro a Asiago, su e giù per il corso principale", intendo: "prendo gli scarponi e mi faccio una bella escursione, di minimo 4 ore e con almeno 5/600m di dislivello".

Senza contare le variabili 'aria aperta' e 'sole'. Anche passeggiando semplicemente, quelle due variabili contano abbastanza.



-- 

Ciao!

Luca


 farla in modo da arrivare ad essere aerobica, tipo in salita ad esempio.



Se hai un minimo di allenamento, con la camminata non arrivi al 60/70% del tuo ritmo cardiaco limite, a meno che tu non abbia salita e non forzi un po' la velocità. Se non hai salita - dove io comunque uso i bastoncini, per questione di equilibrio e di scarico alle giunture in discesa - si può andare di Nordic Walking e passa la paura!



-- 

Ciao!

Luca






 forzi un po' la velocità. 



beh sì, è quello che ho scritto anch'io mi pare.


 C'e` poco da fare: se i dati mostrano che in 40 anni di monitoraggio, quelli

che stanno meglio sono quelli che hanno svolto attivita` a bassa intensita`,

c'e` poco da opinare.



Con il rischio poi che al primo sforzo imprevisto e sostenuto ci

schiattano le penne...






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




due video su youtube non forniscono referenza. E ti spiego anche perche', guarda la figura che mostra al minuto 3:31 del secondo video. Mostra il cuore con le calcificazioni alle coronarie nella parte destra (di uno che fa sport), e lo confronta con il cuore senza calcificazioni alle coronarie (di uno che non fa sport). L'immagine a dx non e' allineata con quella a sx, ovvero lo e' per quanto riguarda i piani coronale e sagittale, ma sono sfasate nel piano assiale. In parole povere, sebbene le due immagini sembrino simili, sono immagini di due cose diverse, e' confrontare mele con pere. Un qualsiasi peer review di una qualsiasi rivista scientifica non avrebbe mai accettato un'immagine del genere. Senza considerare poi, che il contrasto tra le due immagini non e' linearmente normalizzato, sfalzando gli HU (e ti dico anche i valori, tra i 200 e gli 800) e quindi facendo apparire piu' luminose zone con alta xray-absorption, che potrebbe anche esser dovuta all'agente di contrasto e non alla calcificazione. Continuo o basta cosi'? 



Il fatto e' che non voglio mettere in discussione la buona fede di chi parla, probabilmente il suo intento era di lasciar passare un certo messaggio, ossia che il troppo sport puo' far male al cuore, spero senza dare indicazioni individuali su quanto sport fare (non ho visto tutto il video ne' intendo vederlo tutto). Sebbene interessante, e con un potenziale, il valore scientifico di quello che dice e' zero. Sta dicendo che ha assunto un ricercatore da due anni che sta studiando quali danni possa fare al cuore una certa attivita' fisica. Ottimo, ma le conclusioni le si possono dare a studio avvenuto, con in mano l'articolo dello studio (= non le sa neanche lui al momento in cui parla, e anche se ha una sua idea, sono solo ipotesi, non ancora al vaglio della comunita' scientifica, ad esempio, quali indicatori usa per correlare la calcificazione all'attivita' fisica? Ha fatto uno studio longitudinale? Uno studio longitudinale per questo tipo di indagini dura decine di anni, in 2 anni mi pare difficile arrivare a conclusioni riconosciute dalla comunita' scientifica). Non ho intenzione di parlar male del tizio, non lo conosco e a pelle mi sembra anche una persona seria, ma il suo intervento deve essere preso per quello che e', e son sicuro che -se e' onesto- in questo che ho scritto mi darebbe senz'altro ragione.



Non per polemica, ma se si mettono alla berlina le terapie taldeitali per la cura dei tumori (come nell'altro thread), non mi sembra neanche giusto far passare messaggi scorretti, o sbaglio? 





Le invarianti sono pubbliche

Non hanno niente a che vedere con l' interno della classe

Ma almeno sai cosa sono le invarianti ?












 Ma almeno sai cosa sono le invarianti ?



Lo sai, *TU*, cosa e` un'invariante di classe? Affermare che non hanno a 

che vedere con "l'interno" di una classe, dimostra che forse non ti e` 

del tutto chiaro.



-- 

4ndre4


 schiattano le penne...



No, perche` il cuore e` comunque allenato. Se non l'hai capito, e` 

proprio la salute del cuore che quel tipo di esercizio migliora.



-- 

4ndre4



viene forte il dubbio che lo sappia te. non capisco infatti il motivo 

della tua obiezione iniziale: stavo spiegando che non tutti i metodi 

pubblici di una classe fanno parte del contratto (e che quindi non c'è 

bisogno di ridurre la visibilità per escluderli), non stavo definendo la 

design by contract programming con l'intento di essere esaustivo.



fra l'altro per il concetto di invariant non ha senso dire "sono 

pubbliche" per lo meno non nello stesso discorso in cui "public" è inteso 

come modificatore di visibilità dei metodi della programmazione ad 

oggetti.


 Non per polemica, ma se si mettono alla berlina le terapie taldeitali per la cura dei tumori (come nell'altro thread), non mi sembra neanche giusto far passare messaggi scorretti, o sbaglio?



Quali messaggi scorretti? Di che parli? Non devi neanche permetterti di 

mettere sullo stesso piano le due cose. Io non ho citato un cialtrone 

che raccomanda impacchi di ricotta e clisteri di caffe`, ho citato un 

cardiologo che riporta dati che sono ampiamente condivisi, come ho 

detto, all'interno della comunita` medica e sportiva. Che i 

low-intensity workouts siano piu` efficaci per la salute del cuore, a 

lungo termine, e` qualcosa che puoi riscontrare da moltissime fonti.



-- 

4ndre4



Si', ma visto che sono una persona democratica, non sospetto che sia tu 

a non saperlo, ma che tu stia abusando di un termine che comunemente ha 

un significato che non verifica le tue affermazioni.

Da wikipedia:

"In informatica, un predicato è detto invariante per una sequenza di 

operazioni quando il predicato risulta vero prima e dopo dell'esecuzione 

della sequenza."

Quindi, se il predicato fa parte di una classe:

a) non puo' che riguardare la classe stessa, in quanto verosimilmente 

espresso nel suo costruttore.

b) l'interfaccia della classe, costituita da un sub-set dei metodi 

pubblici della classe, costituisce un contratto, degli invarianti non 

gliene puo' fregar di meno, per cui il contractor che utilizza 

l'interfaccia, ignora se eventuali invarianti siano pubblici e 

soprattutto anche se esistano.



Se invece stai parlando della progettazione per contratto, stai parlando 

del comportamento della classe in fase di esecuzione e test, quindi 

della sua qualita' e consistenza nell'utilizzo. Ma questo non riguarda 

l'interfaccia. In pratica, se sparpagli degli assert nella tua classe, 

il contractor non e' tenuto a saperlo.




4ndre4

<626401fd-4bc7-4f8f...@626401fd-4bc7-4f8f-b641-563ae0f72920.invalid>

ha scritto:


Fai come vuoi, ma quando si presenterà il primo sforzo serio

si dovrà COMUNQUE fare i conti con esso.






 schiattano le penne...



preoccupato per quando farai sesso per la prima volta?


 detto, all'interno della comunita` medica e sportiva. 



E dajie con sti "dati", i dati che ho visto io, le due CT a confronto, hanno la stessa validita' scientifica dei clisteri di caffe'. Come non va bene parlare di clisteri di caffe', non andrebbe neanche bene citare con tanta sicurezza video di youtube, sol perche' chi parla e' cardiologo, o sol perche' TEDx seleziona per bene l'oratore. Potrebbero anche esser le persone piu' competenti e professionali al mondo sull'argomento, e NON lo metto in dubbio, ma quei video su youtube non forniscono referenza. Non credo ci sia molto altro da aggiungere.





Il concetto di invariante (come anche precondizioni e postcondizioni) e' 

presa da un libro di fine anni 80 di Bertrand Mayer,OO sw construction 

in cui scrive del linguaggio Eiffel.



I concetti di invariante,precondizioni e postcondizioni si possono 

applicare a qualunque linguaggio OO in pratica.




 applicare a qualunque linguaggio OO in pratica.



non ti stiamo contestando questo. non svicolare.




Appunto, dell concetto di invariante occorre tenerne conto in fase di 

progettazione del sw.

Con l'interfaccia pubblica ed il contratto su cui e' basata, non 

c'azzecca proprio.


 Io di anni ne ho piu` di te e dedico parte del mio tempo libero a studiare (leggo anche altro, ovviamente) perche` quel che faccio per lavoro e` anche un mio interesse extra-lavorativo. 



Beato te (forse). A me famiglia, sport e musica interessano molto di piu'.








 applicare a qualunque linguaggio OO in pratica.



Al netto delle cantonate che stai prendendo, pure questa affermazione 

merita approfondimenti.



Solo con i liguaggi OO?



Il concetto di invariante praticamente si (o a livello di modulo 

concepito come metodi statici )

Precondizioni e postcondizioni sono per i metodi,quindi si possono 

applicare anche a normali funzioni

Se hai qualche altra idea accomodati.










Nessun  svicolo

Questi sono i concetti a cui mi riferivo

Tanto lo so,tu e i tuoi compari non vedete l'ora di darmi addosso come 

al solito ed ogni scusa e' buona.




 c'azzecca proprio.



In linguaggi come eiffel l'invariante e' proprio un concetto del 

linguaggio (come anche le precondizioni e le postcondizioni)

Fanno parte dell'interfaccia pubblica della classe.

In c++ si simula con degli assert ma il concetto e' lo stesso






 al solito ed ogni scusa e' buona.



ma che palle. intervieni con delle precisazioni che col discorso non ci

azzeccano nulla, te lo faccio notare e ti offendi pure. par di essere all'asilo.



Avevo affermato che una invariante fa parte del contratto pubblico di 

una classe.

Cosa c'e di sbagliato in questo non lo so.

Se lo sai spiegalo tu.




 In c++ si simula con degli assert ma il concetto e' lo stesso

Anche in java, direi da 1.5 in poi con l'introduzione dell'assert.



Tu pero' stai confondendo il punto di vista dell'utilizzatore esterno 

con quello del progettista.



Ad esempio (uso il protocollo JMX, ma potrei usare il SOAP con qualche 

complicazione in piu'):

public interface Pubblica  {

   public String prendiQuest(Integer questo);

   public String prendiQuello(Integer quello);

}

public class Utilizzatore {

   Pubblica  proxy;

   public Utilizzatore {

     init();

   }

   protected void init() {

    JMXServiceURL url =

     new JMXServiceURL("service:jmx:rmi:///jndi/rmi://host:9999/server");

    JMXConnector connector = JMXConnectorFactory.connect(url, null);

    MBeanServerConnection connection =

     connector .getMBeanServerConnection();

    ObjectName name =

     new ObjectName("Proxy:type=Pubblica");

    proxy = JMX.newMBeanProxy(connection, name, Pubblica.class, true);

   }

}

Dal punto di vista della classe Utilizzatore non e' dato sapere di 

invarianti, precondizioni e post-condizioni, che invece sono fatti che 

eventualmente interessano solo chi istanzia la classe che implementa 

quell'interfaccia, ovvero il server JMX, che mi mette a disposizione un' 

istanza mediante l'interfaccia Pubblica: il proxy.

Come vedi, non solo Utilizzatore non conosce i meccanismi di 

funzionamento della classe concreta, ma non ne conosce neanche il nome 

ed eventuali altri metodi, pubblici e non, non esposti nell'interfaccia. 

Conosce solo l'url del server JMX ed il nome convenzionale assegnato al 

bean a cui e' interessato e di sicuro conosce solo i metodi implementati 

dal proxy, che del resto sono solo quelli dell'interfaccia Pubblica.



Dovresti anche aver capito che, in questo thread, con la locuzione 

"interfaccia pubblica" si intendeva questo. Tu hai introdotto 

un'informazione che esulava da questo utilizzo, per cui, avendo 

utilizzato la stessa locuzione "interfaccia pubblica" ma in un ambito 

diverso (quello della progettazione), il tuo intervento e' risultato 

misleading, per utilizzare un eufemismo, ovvero "a cazzo" per citare 

l'obiezione di altri.





Le invarianti sono in pratica delle precondizioni e postcondizioni che 

si applicano a tutti i metodi pubblici, quindi come fa a dire che 

l'utilizzatore non le deve conoscere ?

Se chiamo un metodo ed una precondizioni fallisce la colpa e' del 

chiamante non del progettista della classe.

Una postcondizione che fallisce invece la colpa e' del progettista della 

classe.






 l'utilizzatore non le deve conoscere ?



hai evidentemente qualche problema di comprensione nella lettura, visto 

che sistematicamente opponi argomenti su cose non scritte. oppure, cosa 

altrettanto probabile, fai queste continue domande nel disperato 

tentativo di invertire l'onere della prova.



facciamo che rispondi te ad una domanda: se le interfacce sono il 

formalismo per esporre all'utilizzatore le signature dei metodi del 

contratto, qual'è il formalismo per esporgli le invarianti?


 classe.

E quindi? Cosa c'entra con l'interfaccia?





invariant,per quei linguaggi che lo hanno.








int sqrt(int) v {  PREC(v > 0); <body> ; return ..;}



e gia,chissa cosa ha che fare la precondizione con l'interfaccia pubblica.













per quei due linguaggi che ce l'hanno, ad essere precisi.


 e gia,chissa cosa ha che fare la precondizione con l'interfaccia pubblica.

Questa e' un'implementazione concreta, non e' l'interfaccia. Se il 

contractor chiama sqrt(-1) si becchera' un vaffanculo. In un'interfaccia 

java sarebbe:

int sqrt(int number) throws NotPositive;





Come vuoi tu










se sqrt fosse un metodo pubblico di una classe quello fa parte 

dell'interfaccia pubblica della classe.

Ma,ripeto,dipende cosa intendi tu per interfaccia





veramente è oggettivo. 




Non si tratta di "cosa intendo io", si tratta di cosa si stava discutendo.

Indipendentemente dal fatto che in java abbia il modo di formalizzare 

l'interfaccia di una classe mediante interface - dove non e' detto che 

tutti i metodi pubblici di una classe debbano obbligatoriamente farne 

parte - l'interfaccia della classe la puoi definire parimenti, quindi 

tramite un sub-set dei metodi pubblici, anche con altri metodi, ovvero 

ove si stabilisca un contratto tra le parti esterno alla classe. 

L'esempio del webservice SOAP, e' appunto un modo per formalizzare 

questi contratti, language-independent.

Inoltre non e' neanche detto che il contratto debba obbligatoriamente 

essere onorato da una singola classe e viceversa una singola classe 

potrebbe onorare piu' contratti, si tratta di contratti tra 

applicazioni, agnostici delle rispettive implementazioni.