[SIForge.org] Strange Patterns 2

Marco Lamberto (26 apr 2005, 20:32:43)

Conoscendo Perl, la reference di SLEEP mi sembra strizzare l'occhio in molte cose piu` a PHP che a Perl (array in primis), non che sia un male pero` ... Inolte checkError non mi garba molto, gia` in C non amo giocare con l'errno, in Perl puoi giocare con delle clausole booleane a fine comando che rendono la cosa un po' piu` gradevole (per i Perl-ofili). ;P Per la relfection di Java condivido anche io un po' della scetticita` di Stefano, purtroppo per cose particolarmente arzigogolate si rischia di infilarsi in vespai. Ciao, Marco

Stefano Fago (26 apr 2005, 13:57:14)

1) ...noi di SIFORGE sappiamo attendere ;-) 2) il testo che proponi è molto bello ma...Attenzione! Il bravo programmatore che gioca con la reflection(Eh sì! Il libro è strutturato come le avventure di un developer) poi si và a scontrare con il ClassLoader e a quel punto, nella realtà, sono cavoli!...Memory Leak, thread impazziti, classi ripetute...wwwowww! :-( 2) Big Design Up Front: questo tema è veramente una patata bollente...Sapessi come si sono litigati l'approccio più figo gli agile e gli XP-er! E' comunque interessante un testo come questo(giusto per riordinarsi le idee o avere un punto di vista differente): -------------------------------------------------------- Extreme Programming Refactored By Matt Stephens and Doug Rosenberg Publisher: Apress L.P. Cuts through the hype and tells "the other side of the story" about Extreme Programming Provides a thorough and systematic analysis of XP practices and separates the "agile" from the "fragile" Proposes better ways of achieving XP's agile goals, applicable to a much wider range of projects ------------------------------------------------------------------- E poi ci sono dei testi sul TDD e refactoring che se si leggono ti fanno crollare ogni convinzione!... Comincio a credere che ci voglia tanta FEDE e tanta ESPERIENZA e...tornare al COBOL!... p.s. Hai visto SLEEP(perl like scripting) http://sleep.hick.org/ ????

gabriele renzi (26 apr 2005, 12:43:57)

eh, purtroppo nn ho molto tempo per scrivere qualcosa di completo :/ Comunque cerco di spiegarmi meglio: quello che intendevo è in realtà quello che dicono anche Marco e Stefano (che però non era evidente dall'articolo, almeno per me che sono tonto), ovvero che spezzare le interfacce è un'ottima cosa *se e solo se* questa frammentazione emerge dallo sviluppo ma non se compare come risultato di un Big Design Up Front. In "Object Oriented Software Construction" si parla di Taxomania come di una specie di "disfunzione del design" in cui si cerca di massimizzare il riuso imponendo l'esistenza di una classe (la notazione è diversa, ma il concetto è analogo) per ogni singola differenza. Il fatto però è che, a fronte di un lavoro di design massiccio, il guadagno pratico in modularità è ridotto o assente, poiché alcuni artefatti potrebbero non essere mai necessari. Basta pensare ad una gerarchia in cui per l'interfaccia Serializzabile esistano due superinterfacce ScrivibileSerializzata e LeggibileSerializzata. E' indubbiamente una divisione dei ruoli sensata, ma non accadrà mai (credo) di voler serializzare una struttura senza volerla leggere di nuovo. L'argomento relativo all'uso di moduli non sotto il diretto controllo del design (esterni o quant'altro) è analizzato in maniera interessante nel libro "Java Reflection in Action", e affrontato senza l'uso di adapter ma tramite reflection, vi rimando a quello (magari un'occhiatina tramite Safari.oreilly.com :) Infine, Nice è proprio quello (nice.sf.net) ed è imho un progetto molto interessante, anche se non ci ho mai fatto nulla tranne giocarci. E' interessante perché si tratta sostanzialmente di un linguaggio che è "più java di java". Con ciò intendo che gli sviluppatori di Nice hanno fuso dei concetti dei linguaggi funzionali come ML dove (quasi) ogni errore di tipo è bloccato a compile time, in java, ottenendo come risultato molte più garanzie sulla robustezza del programma, ed anche una maggiore espressività. Inoltre, grazie al multiple dispatch, è possibile specializzare qualsiasi metodo già esistente per una nuova signature (per la differenza tra overloading e MMD rimando a http://c2.com/cgi/wiki?MultipleDispatch). In questo modo non c'è bisogno di inventare un'interfaccia, ne' una gerarchia di adpater, basta aggiungere, solo quando necessario, un nuovo metodo speciallizato. Ora vado a leggermi il pdf che sembra interessante :)

Stefano Fago (26 apr 2005, 09:29:33)

Suppongo NICE (http://nice.sourceforge.net/), forse l'unico concorrente serio di Groovy!...Lo usi correntemente? Sembra molto carino, ma nel caos dei linguaggi di scripting preferisco riferirmi ai grandi (Python, Ruby, JavaScript and so on) comunque...sempre aperti alle news! Relativamente al tuo commento: 1) La reflection è, quando usata con cautela, un'ottima cosa anche se è bene tener presente quello che zio Bob Martin ci ha indicato: KILL RTTI! Anche se può sembrare una posizione da dinosauro, l'unico progetto che ho visto funzionare bene con un team di 15 persone junior e 2 senior, è stato quello in cui, per tipizzazione, gli junior erano costretti ha fare la "cosa giusta"! 2) Hai assolutamente ragione sul fatto che un'eccessiva specializzazione/frammentazione delle interfacce può essere un caos-engine. Un autore del giro di Fowler ha preso, a riguardo, posizioni un pò XP: http://www.martinfowler.com/ieeeSoftware/continuousDesign.pdf! La verità è nel mezzo: quanto dico lo puoi vedere, persino, nell'approccio TDD! Utilizzando i mock-object emergono necessità rispetto al concetto iniziale che ti fanno alterare il design iniziale...Dalla cosa più facile, che generalmente è un elemento concreto, ti ritrovi ad un paio di interfacce, un'implementazione ed un Context per i servizi globali o elementi di utilità! NetBeans(IDE Javoso) è basato sul concetto di COOKIE(weak interface) COMPOSITION per il MIXING di responsabilità: rivedere la risposta di Giovanni! Va bene! La smetto qui; però è una discussione interessante: fatti coraggio è parlaci della tua esperienza! GRAZIE

Marco Lamberto (26 apr 2005, 06:46:43)

Dimenticavo, Gabriele, siii, se hai tempo scrivici qualche cosa!! :) Come ben sai sono un tuo fan sfegatato! ;) Marco

Marco Lamberto (26 apr 2005, 06:45:34)

MMD = multimethod dispatch. In ogni caso credo che la frammentazione delle interfacce vada valutata di caso in caso e non debba essere un puntiglio sin dall'inizio, ovvero, se rifattorizzando serve "rompere" che si spezzi pure! Non penso esista La ricetta, ma come al solito al programmatore e soprattutto al suo buon senso, e` lasciato il resto. ;) Ciao, Marco

Giovanni (25 apr 2005, 20:26:18)

Avere interfacce atomizzate e' una linea di pensiero che dovrebbe aumentare la intercambiuabilita' degli oggetti. Volendo essere molto sintetici, se semplifico, cioe' indebolisco le interfacce, ho una sorta di "tipizzazione dinamica alla buona" che pero' e' sempre controllabile dal compilatore. Progettare cosi' e' durissima secondo me, ma il framework risultante e' sicuramente piu' flessibile. Che cos'e' Nice? Cosa vuol dire NDD? Ti va di spiegarlo e/o di fare un mini articolo su questo meccanismo?

gabriele renzi (23 apr 2005, 12:53:53)

bell'articolo, ma ho una controriflessione da fare, relativa all'ultima parte dell'articolo. Viene suggerito che le interfacce debbano essere piccole, facili da implementare e che ciò riduca l'accoppiamento, ma io non ne sono del tutto convinto. Infatti ho l'impressione che tale approccio porti ad una taxomania (per dirla con Meyer) che ben poco aggiunge alla validità della libreria o applicazione, ma che complica la struttura e divide artificialmente concetti che andrebbero uniti. Ad esempio, per un metodo che usa getColoreOcchi() di una classe Persona, ha davvero senso introdurre una interfaccia IOcchiColorati piuttosto che lasciare un parametro Persona? Secondo me in un caso in cui sia *necessaria* una microinterfaccia, perché non si vuole scrivere una intera gerarchia di adapter, o perché non si possono adattare tutti gli elementi software da usare, la scelta migliore e affidarsi alla reflection, invocando dinamicamente i metodi ed ottenendo una sorta di duck typing. Oppure usare Nice che ha il MMD :) (Noto anche che: sebbene apprezzi i meccanismi di adapting in python come sistema unificato di conversione tra tipi/protocolli, non mi piace l'idea che diventino una sorta di type check, ma sono gusti :)