Qualcuno ha letto questo libro?

Me ne parlava molto bene un manager, pare che faccia anche parte dei
corsi di MBA.

Ho gia' una lunga coda di cose da leggere... mi chiedevo come si
inserisce in una prospettiva Agile.

ciao

Uberto

 

Veramente nelle CRC non credo vadano defini i ruoli nella parte "responsabilita'", ma in quella collaborazioni.

SRP in realta' non c'entra tanto col numero di responsablita' ma col fatto che ogni classe ha una sola ragione per cambiare.
Se le 2-3 resp sottintendono alla stessa ragione ok, altrimenti mica tanto. :)

Tutto quello che hai detto.  Anche all'epoca si era risposto che SRP significa "single reason to change".  Ma mi pare che come lo spiega Nat sia più chiaro :)

Secondo me in definitiva e' una questione di prospettiva.
La donna delle pulizie ha una responsabilita' verso il suo capo: "pulire l'ufficio tutti i giorni dopo le 6".
Pero' ha tante responsabilita' tecniche: vuotare i cestini, ma non buttare i fogliettini della kanban e pulire la whiteboard del burndown. Pulire pavimenti e scrivanie ma non spostare i computer, ecc.

ciao

Uberto

 

Non so se ho capito che cosa dici.  Quello che volevo dire io è che il codice di produzione e quello di test dovrebbero avere forma diversa.  Un altro esempio:

class Greeter {

static String HELLO = "Hello, ";

String sayHello(String name) {

 return HELLO + name;

}

}

@Test public void testHello() {

  String name = "pippo";

  assertEquals(HELLO + name, new Greeter().sayHello(name));

} 

Il test qui sopra mi da ben poca confidenza.  Il test è uguale all'algoritmo di produzione.  Invece quello qui sotto:

@Test public void testHello() {

  assertEquals("Hello, pippo", new Greeter().sayHello("pippo"));

} 

si capisce che cosa mi aspetto.  Mi da molta più confidenza.

> Secondo me in definitiva e' una questione di prospettiva.
>
> Uberto
>

Uberto, le affermazioni "SRP va preso come inspirazione" o "SRP va interpretato
come le quartine di nostradamus" le vedi compatibili/congruenti col commento che
hai postato oppure no ?

Qui una mia riflessione.

Leggendo la documentazione originale dei SOLID trovo esempi pratici di codice.
Certo sono in C++ e si riferiscono a un problema specifico.
Per applicarli con un altro linguaggio a un altro problema sono necessari dei
cambiamenti.
Da qui la ragione della definizione astratta dei principi che pero trovano al
sua applicazione ben definita e precisa a livello di singole righe codice,
singoli statement o dichiarazione di singoli argomenti o membri.



> Io lo interpreto come un discorso di granularità.
> La responsabilità di cui parla Nat è quella di gestire ...
> ...
> Secondo voi, sto dicendo cose sensate o il caldo sta avendo i suoi
> effetti?
> Ciao
> Trink0


Marco la discussione sul gruppo di google sta proseguendo e Nat é ancora vivo e
vegeto, perché non chiedere direttamente a lui invece che provare una
interpretazione (qualora si abbiano dei dubbi) ?
O magari anche direttamente a Bob Marti?


Luca



--- In extremeprogramming-it@yahoogroups.com, marco trincardi <iltrink0@...> ha
scritto:
>
> Io lo interpreto come un discorso di granularità.
> La responsabilità di cui parla Nat è quella di gestire la comunicazione con
> alcuni vincoli, in questo rientra spedire un messaggio, leggerlo, validarlo
> etc etc.
> Quindi la "Single Reason to change" è il cambiamento del protocollo o dei
> vincoli sottostanti.
> Se invece, portando all'estremo il discorso, interpretassimo SRP come una
> singola azione (responsabilità) ci troveremmo ad avere un oggetto Send, uno
> Recive, uno Validate etc etc, con la logica del protocollo dispersa in N
> oggetti "coupled" tra loro.
> In questo caso, il cambiamento del protocollo avrebbe un'impatto molto più
> ampio sul sistema.
>
> Secondo voi, sto dicendo cose sensate o il caldo sta avendo i suoi effetti?
> :)
>
> Ciao
> Trink0
>
> Inviato da iPad
>
> Il giorno 21/giu/2012, alle ore 16:59, Uberto Barbini <uberto.gama@...>
> ha scritto:
>
>
>
>
>  Veramente nelle CRC non credo vadano defini i ruoli nella parte
> >> "responsabilita'", ma in quella collaborazioni.
> >>
> >> SRP in realta' non c'entra tanto col numero di responsablita' ma col
> >> fatto che ogni classe ha una sola ragione per cambiare.
> >> Se le 2-3 resp sottintendono alla stessa ragione ok, altrimenti mica
> >> tanto. :)
> >>
> >
> > Tutto quello che hai detto.  Anche all'epoca si era risposto che SRP
> > significa "single reason to change".  Ma mi pare che come lo spiega Nat sia
> > più chiaro :)
> >
>
> Secondo me in definitiva e' una questione di prospettiva.
> La donna delle pulizie ha una responsabilita' verso il suo capo: "pulire
> l'ufficio tutti i giorni dopo le 6".
> Pero' ha tante responsabilita' tecniche: vuotare i cestini, ma non buttare
> i fogliettini della kanban e pulire la whiteboard del burndown. Pulire
> pavimenti e scrivanie ma non spostare i computer, ecc.
>
> ciao
>
> Uberto
>

 

> Secondo me in definitiva e' una questione di prospettiva.
>
> Uberto
>

Uberto, le affermazioni "SRP va preso come inspirazione" o "SRP va interpretato come le quartine di nostradamus" le vedi compatibili/congruenti col commento che hai postato oppure no ?

Qui una mia riflessione.

Leggendo la documentazione originale dei SOLID trovo esempi pratici di codice. Certo sono in C++ e si riferiscono a un problema specifico.
Per applicarli con un altro linguaggio a un altro problema sono necessari dei cambiamenti.
Da qui la ragione della definizione astratta dei principi che pero trovano al sua applicazione ben definita e precisa a livello di singole righe codice, singoli statement o dichiarazione di singoli argomenti o membri.

> Io lo interpreto come un discorso di granularità.
> La responsabilità di cui parla Nat è quella di gestire ...
> ...
> Secondo voi, sto dicendo cose sensate o il caldo sta avendo i suoi
> effetti?
> Ciao
> Trink0

Marco la discussione sul gruppo di google sta proseguendo e Nat é ancora vivo e vegeto, perché non chiedere direttamente a lui invece che provare una interpretazione (qualora si abbiano dei dubbi) ?
O magari anche direttamente a Bob Marti?

2012/6/21 lucaminudel <luca.minudel@...>:
>
>> Secondo me in definitiva e' una questione di prospettiva.
>>
>> Uberto
>>
>
> Uberto, le affermazioni "SRP va preso come inspirazione" o "SRP va
interpretato come le quartine di nostradamus" le vedi compatibili/congruenti col
commento che hai postato oppure no ?

versione breve:
no

versione lunga:
vieni qui che ne discutiamo dietro ad una pinta o due. :)

> Leggendo la documentazione originale dei SOLID trovo esempi pratici di codice.
Certo sono in C++ e si riferiscono a un problema specifico.
> Per applicarli con un altro linguaggio a un altro problema sono necessari dei
cambiamenti.
> Da qui la ragione della definizione astratta dei principi che pero trovano al
sua applicazione ben definita e precisa a livello di singole righe codice,
singoli statement o dichiarazione di singoli argomenti o membri.

non voglio difendere qui SOLID.
Pero' mentre alcune cose sicuramente vanno adattate al linguaggio, i
principi in generale restano validi per qualsiasi linguaggio OOP IMHO.

ciao

Uberto

 

2012/6/22 Indrit Selimi <indritselimi@...>

software_principle = "credo che tu possa + o - inserire qualsiasi affermazione sullo sviluppo del software qua e ci sarà sempre qualcuno che si troverà + o - d'accordo con la frase sotto"  

"le affermazioni "#{software_principle} va preso come inspirazione" o "#{software_principle} va interpretato come le quartine di nostradamus"... ?"

le quartine di nostradamus le puoi interpretare come vuoi, ora io non credo che i principi del software siano spazzatura che vuol dire tutto e niente.

E' vero che per qualsiasi cosa c'e' chi pensa A e chi il contrario di A, ma cio' non significa che la teoria della terra piatta sia sullo stesso livello della teoria della relativita' di Einstein.

Se chiedi a persone che regolarmente deliverano software in contesti anche difficili, e che godono di stima e rispetto, ti accorgerai che c'e' una notevole convergenza di vedute sui principi, anche se magari non sui dettagli. :)


ciao

Uberto

Trink0,

in base a quanto ho capito, Nat dice che la SRP é riferita ai messaggi a cui una
classe risponde (i membri della sua interfaccia pubblica) mentre i Ruoli si
riferiscono ai Peer e Internal della classe (cioé gli altri oggitti da cui
dipende la sua implementazione le sue dipendenze interne).

Peer e Internal sono definiti nel libro GOOS che quindi serve leggere per capire
quello che Nat e Steve intendono (confesso che dopo averlo letto nel libro ho
dovuto fare in fiume di domande nel newsgrupp per arrivare a capire cosa
significavano).


In base alla esperienza per me almeno l'80% delle violazioni, di SRP o degli
altri SOLID, che si trovano comunemente nel codice di produzione sono
identificabili in modo chiaro e univoco (un tool automatico potrebbe segnalarle)
a livello di statement, espressione, dichiarazione o linea di codice.
Un 10% richiede anche la comprensione le dominio e magari il restante 10% non
ammette una risposta facile chiara e condivisa.

Posso proporre degli snippet di codice di esempio o se qualcuno vuole proporli
possiamo confrotarci/verificare in pratica.


Luca


--- In extremeprogramming-it@yahoogroups.com, marco trincardi <iltrink0@...> ha
scritto:
>
> Ciao Luca,
>
> Grazie del suggerimento.
> Visto che stiamo discutendo di SRP anche in questa lista, tu come la vedi?
>
> Trink0
>
> Il giorno 21/giu/2012, alle ore 23:55, lucaminudel <luca.minudel@...>
> ha scritto:
>
>
>
> > Secondo me in definitiva e' una questione di prospettiva.
> >
> > Uberto
> >
>
> Uberto, le affermazioni "SRP va preso come inspirazione" o "SRP va
> interpretato come le quartine di nostradamus" le vedi
> compatibili/congruenti col commento che hai postato oppure no ?
>
> Qui una mia riflessione.
>
> Leggendo la documentazione originale dei SOLID trovo esempi pratici di
> codice. Certo sono in C++ e si riferiscono a un problema specifico.
> Per applicarli con un altro linguaggio a un altro problema sono necessari
> dei cambiamenti.
> Da qui la ragione della definizione astratta dei principi che pero trovano
> al sua applicazione ben definita e precisa a livello di singole righe
> codice, singoli statement o dichiarazione di singoli argomenti o membri.
>
> > Io lo interpreto come un discorso di granularità.
> > La responsabilità di cui parla Nat è quella di gestire ...
> > ...
> > Secondo voi, sto dicendo cose sensate o il caldo sta avendo i suoi
> > effetti?
> > Ciao
> > Trink0
>
> Marco la discussione sul gruppo di google sta proseguendo e Nat é ancora
> vivo e vegeto, perché non chiedere direttamente a lui invece che provare
> una interpretazione (qualora si abbiano dei dubbi) ?
> O magari anche direttamente a Bob Marti?
>

Provo a dire la mia.

Concordo con quanto Uberto dice sui *Principi* di disegno SOLID in relazione
alla probrammazione OO.
Che vale tanto per C++, JavaScript, Smalltalk, Ruby, Java e C# tra gli altri.
Anche il DIP come dice Uberto dove nei linguaggi dinamici (come Ruby o anche
JavaScript o Smalltalk)il concetto di protocollo sostituisce quello di
interfaccia e aggiungo che il concetto di dipendenza a compile-time svanisce con
i linguaggi dinamica ma resta e fa valere ancora il DIP le dipendenze a
run-time.

Se i Principi SOLID sono ancora validi per i linguaggi funzionali puri come
Erlang sinceramente non so e ho qualche dubbio, mentre di sicuro sono validi nel
misto OO-Funzionale (tipo C# con lambda e value object).




Sono invece valide per qualunque paradigma di programmazione OO, Funzionale o
procudeurale per esempio, le *Caratteristiche* o *Attributi* del buon disegno:
- Flessibile (non rigido) riesco a fare una modifica intervenendo localmente in
parti isolate del codice
- Robusto (non fragile) faccio una modifica del codice e questa incide solo
sulle parti strettamente/logicamente correlate del programma
- Riusabile (non immobile) riesco facilmente ad estrarre dal codice le
funzionalità per riutilizzarle


Altre *Caratteristiche* o *Attributi* del buon disegno valide per vari paridigmi
e equivalenti alla terna sopra sono quelle di:
- Basso accoppiamento: la dipendenza dei componenti software del sistema da
altri componenti software del sistema è bassa
- Alta coesione: i componenti software del sistema possono collaborare tra di
loro in svariate combinazioni per ottenere nuove funzionalità.


Queste *Caratteristiche* o *Attributi* sono collegate al *Principio* di buon
disegno di Modularitá che é valido per diversi paradigmi di programmazione:
- una definizione qui: http://en.wikipedia.org/wiki/Modular_programming
- un altra definizione qui:
http://books.google.se/books?id=oaBOuo4mId8C&lpg=PP1&hl=sv&pg=PA63#v=onepage&q&f\
=false (dal libro di Baldwin & Clark, 2000: Design rules: the power of
modularity)
- la definizione come la ho capita io
a) la possibilita di guardare al codice localmente e capire cosa fa e come senza
bisogno di capire cosa fanno le altre parti del sistema.
b) la possibilita di modificare/estendere locamente il codice
limitandosi ad avere conseguenze locali
c) la possibilita di realizzare alcune nuove funzioni implementando un nuovo
"modulo" e componendolo con gli altri moduli esistenti nel sistema


Ho descritto Caratteristiche/Attributi che posso chiamare anche Valori, ho
elencato Principi, restano le Pratiche di disegno.
Quelle che posso indicare sono specipiche ai linguaggi OO e sono collegate ai
principi SOLID e alcuni altri:
- la praticha del TDD (come descritta dal GOOS o da Kent Beck)
- i refactoring descrtitti nel libro Refactoring to Pattern
- i refactoring descrtitti nel libro Working effectively with legacy code




Concordate con la distinzione tra Caratteristiche/Attributi (valori), principi e
pratiche che ho descritto? E con la relazione tra principi e paradigmi di
programmazione?



Luca

--- In extremeprogramming-it@yahoogroups.com, Uberto Barbini <uberto.gama@...>
ha scritto:
>
> 2012/6/22 Giorgio Sironi <piccoloprincipeazzurro@...>
>
> >
> >
> > 2012/6/22 Uberto Barbini <uberto.gama@...>
> >
> >> **
> >>
> >> 012/6/22 Indrit Selimi <indritselimi@...>
> >>
> >>> software_principle = "credo che tu possa + o - inserire qualsiasi
> >>> affermazione sullo sviluppo del software qua e ci sarà sempre qualcuno che
> >>> si troverà + o - d'accordo con la frase sotto"
> >>>
> >>
> >> Se chiedi a persone che regolarmente deliverano software in contesti
> >> anche difficili, e che godono di stima e rispetto, ti accorgerai che c'e'
> >> una notevole convergenza di vedute sui principi, anche se magari non sui
> >> dettagli. :)
> >>
> >>
> > Potreste farmi un esempio di principio universale, condiviso cioè sia da
> > un programmatore web Ruby sia da un programmatore C++ embedded sia da un
> > programmatore Erlang?
> > Questo perché leggendo Alexander sto cercando di capire il concetto di
> > contesto.
> >
>
> Beh prendiamo SOLID per comodita'.
>
> E' nato in C++ quindi non credo ci siano dubbi li'.
> In Ruby le interfacce sono implicite ma a parte gli adattamenti che questo
> comporta non mi pare ci sia nessuno dei guru ruby che rinneghi SOLID.
> Non conosco Erlang e la sua comunita' ma dubito che qualcuno sia contro
> SOLID, almeno per la parte ad oggetti di Erlang.
>
> Penso che poi tutto SOLID deriva da un concetto che vale anche nel mondo
> funzionale, cioe' quello di minimizzare l'entropia nel codice... ma e' una
> cosa su cui sto lavorandoci solo da poco.
>
> ciao
>
> Uberto
>

> Se i Principi SOLID sono ancora validi per i linguaggi funzionali puri come
Erlang sinceramente non so

Non conosco Erlang, ma sicuramente in Haskell, cosi' come sono scritti
non hanno molto senso ma uno puo' ricavarne degli equivalenti.
Per esempio SRP si applica alle funzioni, OCP alle monadi e ISP ai tipi.

Non sono un esperto di nessun linguaggio funzionale, ma posso dire che
scrivendo programmini in Haskell e Clojure seguo delle specie di
meta-SOLID.

> Sono invece valide per qualunque paradigma di programmazione OO, Funzionale o
procudeurale per esempio, le *Caratteristiche* o *Attributi* del buon disegno:
> - Flessibile (non rigido) riesco a fare una modifica intervenendo localmente
in parti isolate del codice
> - Robusto (non fragile) faccio una modifica del codice e questa incide solo
sulle parti strettamente/logicamente correlate del programma
> - Riusabile (non immobile) riesco facilmente ad estrarre dal codice le
funzionalità per riutilizzarle
>
>
> Altre *Caratteristiche* o *Attributi* del buon disegno valide per vari
paridigmi e equivalenti alla terna sopra sono quelle di:
> - Basso accoppiamento: la dipendenza dei componenti software del sistema da
altri componenti software del sistema è bassa
> - Alta coesione: i componenti software del sistema possono collaborare tra di
loro in svariate combinazioni per ottenere nuove funzionalità.

E' questo a cui mi riferisco quando parlo di bassa entropia del
codice. Avere del codice che e' li' per una ragione precisa e non
spruzzato a muzzo.
:)

ciao

Uberto

Ho ripresentato le stesse slide del IAD2011 al Jug Brussels la
settimana scorsa, stavolta sono arrivato fino alla fine. :)
Se qualcuno e' interessato lo hanno filmato qui:
https://vimeo.com/45010048

Dopo il talk abbiamo discusso abbastanza con i presenti, e
personalmente sono sempre piu' convinto che saper usare entrambi gli
approcci OOP e FP aiuti molto.


ciao

Uberto