Newsgroup: it.lavoro.informatica
Titolo: Review del codice Java per posizione internazionale

Per una possibile posizione in UK mi hanno fatto fare un esercizio simile ma non uguale al problema delle n regine. Il programma che ho consegnato è corretto e a loro dire veloce. Tuttavia hanno sollevato una serie di problematiche nel codice che sinceramente mi fanno pensare che costoro siano folli.
 
Se volete commentare anche voi:
 
- Il programma ad un certo punto stampa le soluzioni trovate nel metodo main con un banale ciclo for. Il loro appunto è :
 
printing solutions should be extracted in dedicated class (SRP violation).
 
SRP significa Single Responsability Pattern. Io queste cose le facevo forse anni fa, ora mi sono convinto che estrarre una cosa così banale in una classe apposta è semplicemente overengineering del codice. Certo, a meno che non salti fuori la necessità di un output più complesso e modulare (pdf, html, testo, eccetera). Ma farlo senza averne ancora la necessità io lo reputo un errore. 
 
Mi sono pragmatizzato troppo io oppure sono folli loro?
 
-altro esempio:  instead of System.out.println logger should be used
 
Certo, in un applicazione web non userei System.out, ma per un programmino lanciabile da command line è davvero il caso di scomodare un logger? Ah, System.out non è usato per debugging (in quel caso ok, ci va il logger) ma solo per stampare le soluzioni.
 
- PieceMover logic should be organized in dedicated units
 
Questa classe dice per ogni pezzo come si muove. A dire il vero avevo iniziato con più classi (una per ogni pezzo), ma siccome finivano con contenere un solo metodo implementato in poche righe ho deciso di accorpare i metodi in un'unica classe. Mi sembrava una cosa ridicola tenere una classe per pezzo della scacchiera. Chiaro se le mosse fossero più complicate avrei optato per qualcosa di più strutturato. Anche qua, sono io che esagero con il minimizzare il numero di classi oppure esagera il revisore?
 
 

 costoro siano folli.
 
Non sono assolutamente d'accordo.
Se ti hanno assegnato un esercizio è per valutare come lavori, mica per 
farti risolvere un problemino la cui soluzione è nota e si trova su 
Google. Tu sostieni in sostanza che si tratta di sovraingegnerizzazioni 
su un programma non abbastanza complesso, è ovvio sia così essendo un 
esercizio e non un programma reale, tu avendo tutto il tempo avresti 
dovuto applicare le best practices non giudicare di testa tua se era o 
meno il caso di farlo.
 


Da quello che scrivi direi proprio di si
Le tecniche (pattern) si usano in base ai problemi da risolvere
Se un problema è relativamente banale perchè usarle ?
E' come usare un bazooca per uccidere una mosca
 

 E' come usare un bazooca per uccidere una mosca
 
Certo, nel mondo reale. Ma nel mondo reale non scriverai mai un 
programmino che serve solo e soltanto a risolvere il problema delle n 
regine e stampare a video il risultato.
 
Ci vuole quel minimo di elasticità mentale per capire che se un 
selezionatore ti da un esercizio, con tutto il tempo di fare le cose a 
modo, è per valutare se sei uno che le cose le fa a modo. La soluzione al 
problema volendo la si trova in un battibaleno su Google.

 meno il caso di farlo.
 
 
Si ma che ne so io...poi magari trovi uno che ti accusa di sovraingegnerizzare il codice. Che è proprio quello che temevo.


 
Va be, non l' ho cercata ne mi interessa farlo
 
 
 

> SRP significa Single Responsability Pattern. Io queste cose le facevo forse anni fa, ora mi sono convinto che estrarre una cosa così banale in una classe apposta è semplicemente overengineering del codice. Certo, a meno che non salti fuori la necessità di un output più complesso e modulare (pdf, html, testo, eccetera). Ma farlo senza averne ancora la necessità io lo reputo un errore. 
 
La tua ipotesi "a meno che non salti fuori la necessità di un output più complesso" e' proprio l'origine dell'errore che ti hanno fatto notare. Se "saltasse fuori" la cosa complessa dovresti andare a mettere mano al main dell'applicazione per implementarla. 
 
Prova a metterti un attimo nei loro panni, se volevano verificare la tua conoscenza dei pattern che dovevano fare, darti un progetto da 6 mesi ?
 
-- 
Soprano

 
 
Beh potevano innanzitutto dirlo. La parola pattern non era menzionata nel testo dell'esercizio.


Ma alla fine come è andata, hai passato l'esame, sia pure con la sufficienza?

 std::cout << S<int>::sum<(5,6) << std::endl;
 
http://24.media.tumblr.com/tumblr_lmi0t9vjOG1qzfpi8o1_400.jpg
 
 
-- 
So I throw the windows wide
And call to you across the sky


 
Hai perfettamente ragione :)
 
Ma se tagli il resto  potrebbe sembrare che il fuori di testa sia il 
sottoscritto
 

 sottoscritto
 
no no, mi riferivo alla sintassi del linguaggio, il tuo discorso e' 
perfettamente legittimo :)



 
E' C++ con programmazione generica
Uno dei suoi punti di forza, java li fa un baffo su questo
Ma non voglio aprire flame sui linguaggi,ci mancherebbe altro
 

 mancherebbe altro
 
penso che questo lo sappia.
lo so, non è da uomini puri e duri dirlo, ma resto dell'idea che quella 
sia una discreta perversione.

 Mi sono pragmatizzato troppo io oppure sono folli loro?
 
Il senso del colloquio era di verificare le tue capacita` di design dell'applicazione e di applicare certi principi OO fondamentali, non di verificare semplicemente che l'output fosse corretto. Non ha importanza se durante il colloquio ti chiedono di scrivere il gioco del filetto o un sistema di gestione del traffico aereo, il punto e` che devi mostrare un buon design, per cui no, i folli non sono loro.

il programma che gli ho consegnato è in grado di calcolare 3 milioni di soluzioni in circa 15 secondi.
 
Che non vuol dire nulla, con tutto il rispetto. Sono numeri dati senza alcun punto di riferimento. E comunque un programma velocissimo ma difficilmente manutenibile non e` comunque un buon progrmama.
 
 

 Se un problema è relativamente banale perchè usarle ?
 
Perche` e` un colloquio di lavoro. 

 Beh potevano innanzitutto dirlo. La parola pattern non era menzionata nel testo dell'esercizio.
 
Perche` probabilmente davano per scontato che tu fossi cosi` intelligente da capire che, anche se la traccia era banale, dovevi considerarla un problema lavorativo di tutti i giorni. Non mi sembra ti stessero chiedendo di applicare dei pattern avanzati, ma dei semplici principi di OOP. Da cosa si dovrebbe evincere, altrimenti, che sei un bravo programmatore che sa lavorare con le metodologie moderne?
 


E poi trovi l' esaminatore che dice:
 
perchè hai complicato inutilmente il programma ?
 
Bocciato
 
 
Questo per fare capire che ogni esaminatore la vede con la testa sua
 

 Bocciato
 
Ne dubito. Gli esercizi dati in un colloquio servono a verificare certe capacita`. Se ti do un compito semplice, da risolvere in maniera banale, non riesco a verificare un bel niente di te. Come ho gia` scritto in un altro messaggio, lo scopo di questi colloqui e`verificare se sei un buon designer. Non ha importanza se durante il colloquio ti chiedono di scrivere qualcosa di molto complesso o molto semplice; devi dimostrare che sai applicare la OO in maniera sensata. Quest'azienda non gli ha chiesto, poi, di sovraingegnerizzare il software, gli ha chiesto semplicemente di applicare il SRP, che e` una delle regole fondamentali della OOP.


E vabbeh, ma prima di partire uno chiede che vanno cercando, la 
soluzione ad hoc o una più generica "tarata" sui pattern?
 


Capito, tu sei quello che ad un esame la somma di due numeri la farebbe 
cosi:
 
 
template <typename T>
class S {
     public:
     static T sum(T v1,T v2) { return V1 + V2; }
};
 
std::cout << S<int>::sum<(5,6) << std::endl;
 
 
 
 
Sai, volevo vedere se conoscevi i template (senza specificarlo prima, se 
no è troppo facile)
 
 

 no è troppo facile)
 
Si sta parlando di un interview in cui ti venga chiesto di realizzare qualcosa di minimamente complesso (quindi presumibilmente non la somma di due numeri), per vedere qual e` il tuo approccio al design di un'applicazione. Non gliene frega niente a nessuno di vedere che la somma viene esatta; quel che e` important e` il processo mentale che ti ha portato a sviluppare il software in un certo modo. Di hacker che buttano giu` quintalate di codice per risolvere un problema ce ne sono tanti; quelli che servono davvero, pero`, sono quelli che quelle quintalate di codice le scrivono in maniera manutenibile. Lo sviluppo del software e` cambiato, negli anni. Oggi si sviluppa con un orientamento preciso ai test, quindi applicare un buon incapsulamento e interfacciamento tra classi e` fondamentale - piu` che in passato. Si`, se chiedo un programma che esegua la somma tra classi, assumo che l'intervistato sia cosi` intelligente da capire che gli sto chiedendo di farmi vedere come disegnerebbe un sistema che ha due ingressi, un'elaborazione, ed un'uscita, in maniera che sia modulare e testabile. Ti sorprendera`, ma l'approccio template con eventuali unit test io lo apprezzerei molto di piu` di un semplice cout della somma.
 
 


Se si vogliono testare queste cose ad un candidato basta come prima 
avvisarlo ed offrirgli un problema che permetta di usare realmente 
queste cose
Non affermo certo di dargli uno sviluppo complesso,basta anche un 
problema semplice ma che deve essere risolto,se si vuole un buon design, 
con alcuni pattern voluti
 
 
Nel nostro caso, prendendo per buono quello che l'OP ha scritto,è una 
autentica carognata
 
 
A me una volta in un esame universitario la prof. mi chiese di 
spiegargli il concetto di stack
 
Non avendo seguito le sue lezioni gli spiegai il funzionamento sullo 
stack partendo dall' alto verso il basso, mentre lei lo aveva spiegato 
dal basso andando il alto
 
Secondo lei questo non andava bene in quanto lei lo aveva spiegato a 
modo suo ed il sottoscritto doveva ripetere (a memoria ?) la lezioncina 
cosi come lo aveva spiegato lei
 
 
L' ottusità di certe persone qualche volta è incredibile
 

 spiegargli il concetto di stack
 
Ti stoppo qui. I prof universitari sono cariatidi chiuse nel loro mondo, che si aspettano che tu ripeta la pappardella a memoria, come te l'hanno spiegata (o meglio, come e` spiegato sul LORO libro che ti hanno obbligato a comprare). Non fanno testo. 
 
Qui si parla di aziende. E` un'altra cosa.


 
Era solo un esempio per fare capire l' ottusità di alcune persone
E non penso che sia solo nell' ambito universitario
Ed in università ho anche conosciuto professori eccellenti
 
 
 

 Era solo un esempio per fare capire l' ottusità di alcune persone
 
L'azienda in questione non si e` dimostrata ottusa. Gia` scritto anche questo. 
 
Ultima mia risposta. 


 
 
Ognuno la pensa come vuole
 

 Ognuno la pensa come vuole
 
Avevo promesso che era l'ultima risposta, ma quel "sui generis" mi ha fatto ridere :)
 


 
 
Mi fa piacere fare sorridere qualcuno
E' domenica, meglio prendere con leggerezza
 
 
 
 

 Anche qua, sono io che esagero con il minimizzare il numero di classi oppure esagera il revisore?
 
A volte non esiste la risposta _giusta_. Esiste quella che piace a chi 
ti ha fatto la domanda. Se non la imbrocchi... AMEN.
 
M.

 Quando progetto sw il cliente non mi dice certo quali pattern usare
 
Il cliente non e` un interviewer ad un colloquio di lavoro tecnico. Continui a mancare il punto fondamentale della discussione.

 E sbaglieresti. Vedi sopra. Non si tratta di complicare inutilmente, ma di sapere applicare certi principi di design. Ti ripeto per la terza volta, che a lui e` stato rimproverato di non aver usato l'SRP, un principio basilare. Con tutto il rispetto, si vede che colloqui non ne fai da un bel po'.
 
Si vabbè. Il problema è che all'uso di pattern non c'è fine:
Io ho fatto circa così:
 
for (String solution : solutions) {
  System.out.println(solution);
}
 
però secondo te avrei dovuto fare così:
 
SolutionPrinter printer = new SolutionPrinter(solutions);
printer.print();
 
Ma cosa mi dici di questa?
 
SolutionPrinter printer = SolutionPrinterFactory.create(solutions);
printer.print();
 
La terza comincia a diventare esagerata oppure no? Se si capisci che senza un contesto reale è impossibile scrivere codice nella maniera giusta. Perchè non esiste una maniera giusta.


Con SolutionPrinter che è un'interfaccia, io direi o la prima senza 
nulla o la terza, quella di mezzo sarebbe né carne né pesce...
 
 


 
 
La questione è che anche l' esaminatore la puo vedere come vuole
Come ha scritto MC:



Ulteriore dimostrazione dell'opinabilità della questione. Tuttavia la terza soluzione richiede:
 
-un'interfaccia
-una classe che implementa l'interfaccia
-una classe factory.
 
Ritengo tutto questo molto ridicolo, o se preferisci un abuso dei pattern. Avrei dimostrato, in altre parole, di non sapere quando e come applicarli.


Scusa, abbi pazienza, ma mica c'hai il testo dell'esercizio, mi è venuta 
la curiosità di vedere come chiedevano di farlo...
 

 La questione è che anche l' esaminatore la puo vedere come vuole
 
Il punto iniziale della discussion era stabilire se questo esaminatore fosse folle. I remarks che questo esaminatore ha fatto servono invece a stabilire che folle non e` affatto; anzi.

 La terza comincia a diventare esagerata oppure no? Se si capisci che senza un contesto reale è impossibile scrivere codice nella maniera giusta. Perchè non esiste una maniera giusta.
 
Quello che io ti sto dicendo e` che esiste una maniera giusta di scrivere software durante i colloqui di lavoro ed e` quella che dimostra che sei un bravo sviluppatore software. Se rispondi all'esercizio con una sfilza di System.out.println() non stai dimostrando un bel niente, e come puoi mai pensare che all'esaminatore vada bene? E` come quella barzelletta che gira in rete in cui e` disegnato un triangolo rettangolo, con una x accanto all'ipotenusa e 2 numeri accanto ai cateti, la traccia chiede di trovare x, e il solutore cerchia la x e ci scrive "eccola". Dovresti sapere che l'esaminatore vuole che tu provi che sai implementare del codice object-oriented in maniera che si presti bene ai test, e c'e` un modo preciso per farlo. Ti hanno rimproverato il fatto che non hai isolato il codice in classi, non che non hai implementato una decina di patterns. E` un concetto elementare.

 Ritengo tutto questo molto ridicolo, o se preferisci un abuso dei pattern. Avrei dimostrato, in altre parole, di non sapere quando e come applicarli.
 
Tra "usare l'SRP" e "abusare dei pattern" c'e` un mare grande tre volte l'oceano atlantico. Di questo almeno ti rendi conto, no?
 

 Quello che io ti sto dicendo e` che esiste una maniera giusta di scrivere software durante i colloqui di lavoro ed e` quella che dimostra che sei un bravo sviluppatore software.
 
Non mi hai risposto. Avresti usato la seconda o la terza?


Sei tu che non ti rendi conto che non c'è una facile distinzione tra le due cose, specialmente se non esistono vincoli esterni come nel caso di un esercizio.

 Sei tu che non ti rendi conto che non c'è una facile distinzione tra le due cose
 
E` proprio nel capire le facili distinzioni che si distingue un bravo programmatore. Ti e` stato chiesto di implmentare uno dei principi SOLID. Ti sono state chieste le basi:
 
http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)
 
 

 Non mi hai risposto. Avresti usato la seconda o la terza?
 
Non ti ho risposto perche` la tua domanda ha troppo pochi elementi per poterti dare una risposta sensata. L'ho saltata e sono andato dritto al punto, che non ti sei neanche preso la briga di leggere. Se io fossi un interviewer, a me andrebbe bene qualunque soluzione in cui mi si faccia vedere che sai sviluppare in maniera modulare e testabile. Se ti chiedo cosa prevederesti nella tua soluzione e non mi nomini i test, io ti boccio. Riguardo il design, l'output di un'elaborazione non deve finire necessariamente a video; puo` finire su file o essere mandato a un server esterno. La comunicazione con un qualunque device esterno puo` implicare errori che vanno testate e gestiti. Eccetera, eccetera.
Se stampi il risultato con una sfilza di println() dimostri di non sapere astrarre neanche un po'. Mi spiace, ma sei tu che hai toppato nella tua soluzione, e continui ad arrampicarti sugli specchi cercando di far passare quell'azienda per dei folli. Secondo me dovresti essere piu` umile e metterti sotto a studiare.


 
Non sarà folle, la vede solo a modo suo
Era folle la prof ?
No,era solo ottusa
 
 

 Non sarà folle, la vede solo a modo suo
 
La vede come la vede la stragrande maggioranza delle software house serie di questo mondo. La verita` e` che lui non ha passato un colloquio di lavoro in cui gli veniva richiesto di applicare principi SOLID *BANALI* e, anziche` riflettere sui suoi sbagli e imparare, con umilta`, la prima cosa che ha fatto e` rivolgersi ad un gruppo per cercare conferma che non e` lui nel torto, ma sono gli intervistatori ad essere un branco di folli. Arrogante e spocchioso. E ha trovato te che gli dice: si`, hai ragione, gli assurdi sono loro. Ma certo, viste le definizioni di cui sopra, la cosa non mi meraviglia.


 
 
Fatti un giro, dopo questa
 

 Se stampi il risultato con una sfilza di println() dimostri di non sapere astrarre neanche un po'. Mi spiace, ma sei tu che hai toppato nella tua soluzione, e continui ad arrampicarti sugli specchi cercando di far passare quell'azienda per dei folli. Secondo me dovresti essere piu` umile e metterti sotto a studiare.
 
Ora stampare in un ciclo for è sinonimo di "sfilza di println e non saper astrarre". Che dire? ROTFL.

 principale con la programmazione generica
 
O citi un paradigma preciso: procedurale, funzionale, ad oggetti, o accetti che "programmazione generica" e` un concetto che esiste solo nella tua testa.

 Ora stampare in un ciclo for è sinonimo di "sfilza di println e non saper astrarre". Che dire? ROTFL.
 
E` inutile che ROTFLi. Sei arrogante e presuntuoso. Non conosci i concetti base della OOP e vieni qui, con la tua spocchia, a pretendere d'aver ragione. Si, un ciclo for che sputa fuori una sequenza di println e` una sfilza di println. Non aver previsto che l'output delle soluzioni potrebbe essere trattato in maniera diversa da una banale scrittura a video significa che non sai astrarre neanche un po'. Punto. Dai, avanti, posta la tua ennesima risposta in cui cerchi di far capire che sei un genio incompreso.
 

 Il C++ lo conosco, l'ho usato massicciamente, e in parte lo uso, da almeno 15 anni a questa parte. L'ho studiato sui libri di Bjarne Stroustrup, Nicolai Josuttis, Herb Sutter, Stanley Lippman, Andrei Alexandrescu, e molti altri. Non sono in cerca di risposte. Ti consiglio di rivederti certi concetti.. Ti avevo chiesto se per programmazione generica intendi generics(C#, Java, Delphi) o template (C++)
 
Non lo hai chiesto o comunque se lo hai chiesto non era chiaro
Se è questo che volevi sapere bastava scriverlo chiaro
Comunque mi riferivo al C++
i template in java fanno ridere paragonati al C++
C# non lo uso e non mi interessa
 
Libri interessanti quelli citi, li ho letti anch'io a suo tempo
 
  e mi rispondi che no, il tuo concetto e` generale, e` programmazione 
che "ha a che fare con algoritmi". Ti dico che quel che scrivi significa 
molto poco di specifico e per tutta risposta tiri fuori il C++. Sei 
confuso, amico.
 
 
Io so quello che dico
Se non ti e chiaro qualcosa basta chiedere


 Io so quello che dico
 
E` su questo che non siamo d'accordo. Tranquillizzati, e` ormai chiaro che non sei il tipo di fonte a cui mi rivolgerei, se avessi bisogno di sapere qualcosa. 


 
 
Ognuno ha i suoi interlocutori preferiti
 
 

 Lo conosco ma se posso ne faccio a meno
 
E chi se ne frega?


 
E' la stessa domanda che avrei fatto io. Sei stato scartato per quei 
motivi o sono stati commenti? Perche' io avrei risposto ai loro commenti 
motivando le scelte. Anzi in realta' le scelte le avresti dovute 
motivare in anticipo.
 
/* Qua violo la SRP per questo motivo */
 
Sono anche d'accordo con chi ti ha detto che essendo un colloquio di 
lavoro l'applicazione dei design pattern e' fondamentale. Il problema e' 
che poi c'e' gente che esagera! Ovvero dopo il colloquio continui a fare 
gli assoli...


 
http://fcw.com/Articles/2013/12/12/cobol-legacy.aspx
 
 
il 70 % dei sistemi SERI ancora è scritto in COBOL linguaggio procedurale.
 
Banche, assicurazioni, PA, Industria, ecc..
utilizzano ancora un linguaggio procedurale, dal c, al cobol, passando 
per fortran e assembler.
certo non in tutto il loro ambito, ma dove c'è necessità di mantenere un 
controllo e velocità di esecuzione.
nei settori menzionati il COBOL viene utilizzato soprattutto nei sistemi 
contabili e dove c'è la necessita di grandi mole di elaborazioni, come 
possono essere il controllo delle tasse o la chiusura contabile di una 
banca, o la stampa di bollette, controlli anagrafici, ecc..
 

 il 70 % dei sistemi SERI ancora è scritto in COBOL linguaggio procedurale.
 
Si`, si`, lo sappiamo, lo sappiamo. Prima o poi, tra chi difende la vecchia sana programmazione procedurale, c'e` sempre chi viene fuori col 70% dei sistemi bancari scritti in COBOL. E quindi? 
Si tratta di sistemi legacy. Mi stai dicendo che se un cliente ti chiede di sviluppargli un sistema, tu consideri il COBOL tra le posssibili scelte tecnologiche?


sinceramente, non penso di consigliargli il cobol, o altro linguaggio.
 
si verificano le esigenze del cliente e si sviluppano le possibili 
soluzioni (non una ma più di una), che possono essere le più svariate a 
seconda del budget disponibile alle reali esigenze.
 
possiamo andare di java, php, c, pl-sql, bash , .NET o altro
possiamo usare strumenti commerciali o realizzati ad hoc.
 
il tutto è finalizzato alla richiesta del cliente.
 
non cerchiamo di sovraingegnerizzare dove non è necessario, non 
cerchiamo di inventare la ruota, o pettinare bambole.
 
un professionista, quello vero non è quello, bello e figo che sa 
utilizzare i pattern, ma non sa in QUALE contesto utilizzarli, non sa se 
in quel particolare caso sia un plus, o solamente un accrocchio che non 
serve ad una beata fava andando a rallentare o sovraccaricare il sistema.
non ha le conoscenza per stabilire se e dove sia necessario alleggerire 
il tutto per mancanza di risorse HW, o se bisogna utilizzare dei pattern 
o degli strumenti che siano invece magari in grado di scalare, senza 
rimettere mano a tutto l'ambaradm.
 
non sto difendendo la vecchia programmazione o la nuova, non sto dicendo 
che l'esperienza conta o no, o che il 20enne e meglio/peggio del 40enne.
 
sto indicando che se non si è elastici, e non si utilizza la capacità di 
adattamento si fa poca strada.
 
il TDD lo trovo ottimo, ma in alcuni casi è deleterio, perchè ti 
costringe a rallentare per ottimizzare, certo alla lunga ne hai un 
vantaggio, ma nel breve è solo perdita di tempo e se non hai le capacità 
di valutare se il contesto ti permette di sviluppare TDD o no, che fai, 
lo utilizzi a prescindere??
 
Ciao

 lo utilizzi a prescindere??
 
Non esiste UN SOLO contesto in cui non si possa sviluppare TDD. E` una metodologia di lavoro, non un tool. Puoi sviluppare TDD anche in C, in PL-SQL, o nel tuo amato COBOL. Ovviamente fai piu` fatica che con un buon framework object-oriented e di mocking, ma se vuoi, lo fai. E` evidente che non hai esperienza con questa metodologia di lavoro.
 
Ti consiglio di leggere questo:
"Growing Object-Oriented Software, Guided by Tests" di Pryce&Freeman.
 
Ti si chiariranno un po' di idee (tranquillo, so che non lo leggerai mai).
 
Chiudo qui - questo thread e` diventato troppo lungo e senza senso (il punto in cui il pannellista ottantenne di turno tira fuori il COBOL e` di solito la linea che traccio per uscire dalle discussioni di questo tipo) e a me tra l'altro piace discutere con persone che conoscono cio` di cui parlano.

 Hai citato il COBOL quale linguaggio ancora usato per sviluppare il 70% dei sistemi (ma quando mai: si tratta del 70% delle transazioni, non dei sistemi) in risposta ad un mio messaggio in cui dicevo che e` dura usare la metaprogrammazione template C++ ignorando classi e oggetti. Dove sarebbe il nesso? Credi che io ignori che il mondo ha una miriade di sistemi legacy scritti con vecchi linguaggi? O stai per caso dicendo che siccome il COBOL vive ancora su molti sistemi, e` logico e sensato utilizzarlo per svilupparne di nuovi? 
 
Dato che esistono versioni di Cobol ad oggetti, il problema sta nel paradigma procedurale? Ovvero, per te sarebbe inconcepibile proporre un nuovo progetto in Cobol OO che vada a reingegnerizzare Cobol procedurale? 
Penso che oggi come oggi non ci sia un solo linguaggio vecchio che non sia stato "revisionato" con il suo bravo standard con OO. L'unico dubbio che ho è sul Fortran.
 


 
Ricambiando
 

 E chi se frega,tra l' altro non l'ho mai sostenuto
 
Era in risposta ai tuoi giudizi sui generics Java. Non saranno perfetti i generics Java; non sono perfetti i template C++.

Dato che esistono versioni di Cobol ad oggetti, il problema sta nel paradigma procedurale?
 
Ma cosa c'entra?!
Il problema sta in quelle persone che, a distanza di 20 anni dalla nascita della OO, ancora la vedono come un intralcio che fa perdere tempo. Chi se ne frega del nuovo COBOL che va a reignegnerizzare il vecchio codice COBOL. La mia domanda era: useresti il COBOL, oggi, per un qualunque nuovo progetto? Ovviamente e` una domanda retorica detta con un sorriso sornione sulla faccia. A nessuno verrebbe in mente di usare un linguaggio vecchio come il cucco per nuovi progetti. Oggi il software si sviluppa con certe tecniche e metodologie. Siamo lontani dal 1959.

 E` inutile che ROTFLi. Sei arrogante e presuntuoso. Non conosci i concetti base della OOP e vieni qui, con la tua spocchia, a pretendere d'aver ragione. Si, un ciclo for che sputa fuori una sequenza di println e` una sfilza di println. Non aver previsto che l'output delle soluzioni potrebbe essere trattato in maniera diversa da una banale scrittura a video significa che non sai astrarre neanche un po'. Punto. Dai, avanti, posta la tua ennesima risposta in cui cerchi di far capire che sei un genio incompreso.
 
Vedi sopra: facendo un semplice redirezionamento hai l'output su file. Che problema ci sarebbe nell'uso di System.out in un programma che va lanciato da command line?
Ovviamente dire che potrebbe essere utilizzato come libreria non c'entra: in quel caso si useranno le API senza passare per la classe che gestisce l'interfacciamento con l'utente (e quindi non hai System.out).

 ./myapp  > out.txt
 
:) Lo so cos'e` il redirect. Ma non e` il redirect cio` di cui parlavo. Non e` il redirect che risolve un problema di design. Il mio "ma che dici?" era una domanda retorica, tesa a sottolineare il fatto che non e` il redirect che implementa l'interfacciamento tra due sistemi. Lascia perdere, a quanto pare e` roba troppo complicata per te.

 Lascia perdere, a quanto pare e` roba troppo complicata per te.
 
Intanto hai già svincolato due volte.

 Ah però, quindi tu sei solito interfacciare i sistemi tramite logger?
 
Ma smettila, ma quale svicolare e quale logger. Non hai capito una mazza di quel che ho scritto. Sai, in Puglia si dice "ciuccio e presuntuoso".
 


Quale logger? Le cretinate sopracitate le hai scritto tu, mica io. Tra l'altro ti ho già spiegato che il progetto presenta delle API con cui un'altra libreria si può interfacciare per fornire ad esempio la soluzione via web o quel che si preferisce.
 
Ah e se eviti cut strategici e magari gli insulti potresti risultare più educato.

 Ah e se eviti cut strategici e magari gli insulti potresti risultare più educato.
 
LOL... cut strategici? :) Stategici per cosa? Per rispondere a te? 
Che il progetto presenti delle API non significa una mazza e non c'entra una mazza con quanto ho scritto in precedenza. Io parlo di design, tu continui a parlare di implementazione. Sono due livelli separati. Tranquillizzati e approfitta delle vacanze di Natale per ripassarti qualche concetto di base di OOP.
 

 LOL... cut strategici? :) Stategici per cosa? Per rispondere a te? 
 
No per carità, puoi tranquillamente continuare a rispondere all'uomo di paglia che ti sei creato. E con questo chiudo.

 No per carità, puoi tranquillamente continuare a rispondere all'uomo di paglia che ti sei creato. E con questo chiudo.
 
Ecco, bravo, chiudi, che ci fai miglior figura. Consigli per il prossimo colloquio: meno spocchia, meno arroganza, e piu` studio dei fondamenti del design OO. 
 


Si, però dovresti ancora rispondere alla sua domanda con le 3 opzioni, 
visto che la metti sul design OO che poi presuppone ovviamente una 
implementazione (visto che non stiamo a filosofeggiare poi nel 
concreto...), ti manca di indicare quale gradisci.
 

 Si, però dovresti ancora rispondere alla sua domanda con le 3 opzioni,
 
"dovresti"? LOL... io non ho nessun obbligo di rispondere a nessuno. La sua risposta l'ha gia` avuta. Se leggi i miei messaggi ci trovi una risposta chiara: nella prima opzione non c'e` alcun astrazione, e il comportamento non e` testabile, la terza usa una factory passando le soluzioni, cosa che non ha senso, la seconda usa un'interfaccia chiamata "SolutionPrinter", cioe` un'interfaccia che ha gia` nel nome il concetto di "print", che non va bene ugualmente. Gli e` stato indicato di usare un Logger, ovvero una classe che puo` trasformare l'input ricevuto in qualunque cosa (output a video, memorizzazione su database, invio via socket ad un altro agente, ecc...). Cosi` avrebbe dovuto fare. 


Peccato non aver avuto il testo completo dell'esercizio.
 

 Peccato non aver avuto il testo completo dell'esercizio.
 
Ci sono i "remarks" fatti dall'azienda. Del tutto comprensibili.
 
Dai, su, non difendere l'indifendibile. Ti saluto (non affrettarti a rispondere, perche` questa volta chiudo davvero).

 generalizza il concetto di "solution printer" in qualcosa di piu` astratto e riusabile.
Visto che la responsabilita' della classe e' quella di produrre un 
output, l'astrazione non dev'essere nella classe, ma nel device che 
riproduce l'output. Il verbo "printare", come lo chiami tu, da quando 
esistono i linguaggi e' sempre stato utilizzato come sinonimo produrre 
una rappresentazione grafica di un dato, non quello di spandere 
inchiostro sulla carta. Mentre "loggare" ricorda piu' l'azione di 
registrare, quindi rendere un dato persistente. Se l'intenzione del 
programma e' quella di produrre un output transiente, il nome logger ne 
tradisce il contratto. Inoltre logger e' un termine gia' universalmente 
utilizzato per altri scopi, quindi qualsiasi altro uso ne si voglia 
fare, traviserebbe il concetto comunemente attribuito.
Magari Writer poteva essere piu' azzeccato, ma anche in questo caso c'e' 
un certo richiamo alla persistenza che disturba. In certi contesti e' 
stato utilizzato Outputter che senz'altro richiama l'astrazione del 
device di output, che mi sembra anche piu' azzeccato.
Tutto ciò a prescindere dal risultato del test, su cui mi sembra inutile 
inferire senza conoscerne l'ipotesi.
Immagino che il prossimo nome che estrarrai dal cappello sarà MirrorClimber.
 

riproduce l'output.
 
La responsabilita` della classe (chiamiamola "Solver"?), da quel che si deduce dai commenti fatti dall'azienda, e` di produrre delle soluzioni, non un "output". Se il risultato dell'elaborazione e`, diciamo, una List<Solution>, lo stamparle a video deve essere responsabilita` di un'altra classe. A quel punto, pero`, anziche` limitare l'output a video, si puo` astrarre il concetto di output in un log. La classe potrebbe non avere un metodo "print()" (che accoppierebbe troppo la classe con un output preciso) ma un metodo "log(Logger logger)". Il Logger sarebbe peraltro anche "mockabile" durante i test. Dai, su che e` un concetto elementare di design OO, dependency injection, etc.., ci puoi arrivare anche tu. Vedi tu di non arrampicarti sugli specchi per il puro gusto di fare polemica ;)
 
Parto per le vacanze. Buon anno, "dottore".


Vai che ne hai bisogno. Buon anno anche a te.

 ti ha fatto la domanda. Se non la imbrocchi... AMEN.
 
vi lascio credere che sia solo fortuna. io dico che il contesto in cui viene
posta la domanda già ti dice che tipo di risposta devi dare. se io sono un
esaminatore e ti chiedo di fare un esercizio, ti do tutto il tempo necessario
per farlo e ti chiedo di mandarmi il codice per una review, non ci vuole una
grande scienza per capire che poi entrerò nel merito della qualità del
codice. se volessi misurare la tua capacità di tirare a far ciccia avrei
strutturato la cosa in modo diverso, magari dandoti poco tempo, che senso avrebbe
lasciarti libertà di fare le cose in tutta calma se poi volessi vedere come
te la cavi a cercare la via più breve?
 

 "Growing Object-Oriented Software, Guided by Tests" di Pryce&Freeman.
 
Grazie mille per il suggerimento...l'ho letto una volta e mezza :D. 
 
Non è che avresti altri libri altrettanto eccezionali da suggerire?