Vai alla ricerca.
extremeprogramming-it · Discussion of Extreme Programming practices and principles (Italian)

Informazioni sul Gruppo

  • Iscritti: 688
  • Categoria: Programmazione
  • Data di creazione: Aug 10, 2000
  • Lingua: Italiano
? Già Iscritto? Entra su Yahoo!

Suggerimenti

Lo sapevi che...
Puoi cercare nel gruppo tutti i messaggi inviati.

Messaggi

  Messaggi Aiuto
Avanzata
Messaggi 10975 - 11004 di 11825   Più vecchio  |  < Meno recente  |  Più recente >  |  Più nuovo
Messaggi 10975 - 11004 di 11825   Più vecchio  |  < Meno recente  |  Più recente >  |  Più nuovo
Messaggi: Mostra riassunti messaggi Disponi per data ^  
#10975 Da: Uberto Barbini <uberto.gama@...>
Data: Lun 18 Giu 2012 8:40 pm
Oggetto: Re: [xp-it] Lettura OOD della domenica
ubertob
Invia email Invia email
 
Da un lato hai ragione, dall'altro sono abituato a ragione sul design guardando le interfacce, mentre con ruby mi pare tutto sempre un po' disordinato. :)

Forse sono solo io, pero' in Groovy apprezzo molto questa cosa di usare le Interfacce quando voglio e restare completamente dinamico quando voglio.

ciao

Uberto

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


Premesso che non sono un esperto di Ruby la cosa che mi viene da dire è che avendo delle interfacce "implicite" (cosa che è molto differente da non averle perché se sbagli, i test dovrebbero dirtelo...) il grado di disaccoppiamento è sicuramente maggiore perché nessuno richiede che gli oggetti che implementano un protocollo debbano condividere nulla. Capisco che in situazione diverse uno possa avere preferenze per uno stile "statico" verso un tipo "dinamico". Potrebbe anche essere che avere le interfacce implicite sia piu' difficile da capire ma penso anche che sia molto piu' flessibile; come al solito si tratta di un problema ingegneristico.

Indrit   


From: Uberto Barbini <uberto.gama@...>
To: extremeprogramming-it@yahoogroups.com
Sent: Monday, June 18, 2012 3:21 PM
Subject: Re: [xp-it] Lettura OOD della domenica

 


2012/6/18 Giorgio Sironi <piccoloprincipeazzurro@...>


2012/6/18 Uberto Barbini <uberto.gama@...>
 
On 18 Jun 2012, at 05:59, Matteo Vaccari <vaccari@...> wrote:

Un oggetto in Ruby ha comunque una o più interfacce definite implicitamente dai metodi che espone.  Corrispondono + o - ai "protocolli" in gergo smalltalk.

Appunto il problema è tutto nel "implicitamente". I protocolli in objC sono espliciti, averli impliciti mi pare che renda tutto più complicato.
Soprattuttto i protocolli dovrebbero stare vicino alla classe che li utilizza, non a quella che gli implementa.
Dico questo da ammiratore ma principiante in Ruby, a volte mi manca non poter essere più preciso nell esprimere i protocolli tra due oggetti.

Se si tratta di esprimere, mi sembra si possa comunque definire un modulo (da includere nella classe che implementa), contenente un insieme di metodi che rende esplicita l'interfaccia e la cui implementazione è solo:
    raise YourNotImplementedError
ma non ci sono particolari controlli a tempo di "compilazione".


Mi sfugge quale vantaggio avrei da questo ExceptionfulModule.
Piuttosto a costo di essere pedante e antiidiomatico potrei controllare nella classe che lo usa che il mio oggetto cammini e nuoti come una papera prima di assumere che sia una papera (intendo col respond_to?).
Ovviamente non l'ho mai fatto in Ruby ma posso immaginare aggiungere questo controllo usando una cosa tipo questa:
http://people.freebsd.org/~eivind/ruby/types/README
(pero' non per verificare la classe ma il protocollo)


Btw in questo momento il mio linguaggio preferito sta diventando Groovy (specie la 2.x) proprio per questa flessibilita' nel poter specificare tipi statici e dinamici all'occorrenza (unito alla potenza come metaprogramming e functional style).

ciao

Uberto






#10976 Da: Uberto Barbini <uberto.gama@...>
Data: Mar 19 Giu 2012 9:57 am
Oggetto: Software estimation: demystifying the black art - Steve McConnell
ubertob
Invia email Invia email
 
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

#10977 Da: Antonio Carpentieri <a.carpe@...>
Data: Mar 19 Giu 2012 10:14 am
Oggetto: Re: [xp-it] Software estimation: demystifying the black art - Steve McConnell
acsilk
Invia email Invia email
 
L'ho letto 3 anni fa, nella prima parte del libro spiega cosa sono le stime e come dovrebbero essere usate introducendo concetti come il cono d'incertezza poi offre una carrellata su diverse tecniche di stima.

Secondo me è più importante la parte introduttiva più che le tecniche in se.

Ciao,
A  

2012/6/19 Uberto Barbini <uberto.gama@...>
 

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



#10978 Da: Matteo Vaccari <vaccari@...>
Data: Gio 21 Giu 2012 2:36 pm
Oggetto: Fwd: [GOOS] SRP vs Roles and Responsibilities
matteo_vaccari
Invia email Invia email
 

Vi mando una copia di un messaggio passato sulla mailing list del GOOS.  Quando abbiamo fatto l'esercizio con le CRC cards al Milano XPUG, avevo detto che una classe doveva avere 2-5 responsabilità (mi pare.)  Qualcuno ha chiesto come mai non una sola, in aderenza al Single Responsibility Principle.   Domanda pertinente!  La risposta che Nat Pryce da' qui sotto mi pare illuminante.

Matteo
---------- Forwarded message ----------
From: Nat Pryce <...>
Date: Tue, Jun 19, 2012 at 9:03 AM
Subject: Re: [GOOS] SRP vs Roles and Responsibilities
To: "growing-object-oriented-software@googlegroups.com" <growing-object-oriented-software@googlegroups.com>

On 19 Jun 2012, at 07:08, Nikolay Sturm <...> wrote:
> Hi,
>
> I am rereading GOOS in our company's book club atm and one question
> neither of us could make sense of was the relationship between the
> Single Responsibility Principle and the notion of objects as
> implementations of one or many roles, with each having one or many
> responsibilities.
>
> At 1st, 2nd and 3rd thought, these ideas seem to be opposed to each
> other. How do I get them into a coherent picture? Thoughts anyone?
>
> cheers,
>
> Nikolay

The word "responsibility" is being slightly differently in the two
uses.  SRP is about responsibilities in the system. We were talking
about the responsibilities of correctly playing a role in a protocol
between objects.
For example, suppose we have a system that communicates over a network
but must not send messages faster than some maximum rate. Our system
needs to rate limit the sending of messages. We would want to
implement the rate limiting responsibility in one class -- not have it
intermingled with formatting the contents of messages or transmitting
them over the wire -- and compose it into the system. But a class that
performs rate limiting must collaborate with other objects: play roles
in protocols between objects. It must be able to send and receive
messages via some lower layer transport and request and receive timer
callbacks. To play those roles correctly it must follow certain rules
-- that is, it has a responsibility to send correct requests &
responses to its peers and respond appropriately to correct requests &
responses it receives from them. For example, it might not be allowed
send a zero length message or send a message to a wildcard address,
and it must announce a "stop sending" notification if the rate limit
has been reached and a "start sending" notification when peers can
send messages again.
www.natpryce.com


#10979 Da: Uberto Barbini <uberto.gama@...>
Data: Gio 21 Giu 2012 2:47 pm
Oggetto: Re: [xp-it] Fwd: [GOOS] SRP vs Roles and Responsibilities
ubertob
Invia email Invia email
 
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. :)

ciao

Uberto

On Thu, Jun 21, 2012 at 3:36 PM, Matteo Vaccari <vaccari@...> wrote:



Vi mando una copia di un messaggio passato sulla mailing list del GOOS.  Quando abbiamo fatto l'esercizio con le CRC cards al Milano XPUG, avevo detto che una classe doveva avere 2-5 responsabilità (mi pare.)  Qualcuno ha chiesto come mai non una sola, in aderenza al Single Responsibility Principle.   Domanda pertinente!  La risposta che Nat Pryce da' qui sotto mi pare illuminante.

Matteo
---------- Forwarded message ----------
From: Nat Pryce <...>
Date: Tue, Jun 19, 2012 at 9:03 AM
Subject: Re: [GOOS] SRP vs Roles and Responsibilities
To: "growing-object-oriented-software@googlegroups.com" <growing-object-oriented-software@googlegroups.com>


On 19 Jun 2012, at 07:08, Nikolay Sturm <...> wrote:
> Hi,
>
> I am rereading GOOS in our company's book club atm and one question
> neither of us could make sense of was the relationship between the
> Single Responsibility Principle and the notion of objects as
> implementations of one or many roles, with each having one or many
> responsibilities.
>
> At 1st, 2nd and 3rd thought, these ideas seem to be opposed to each
> other. How do I get them into a coherent picture? Thoughts anyone?
>
> cheers,
>
> Nikolay

The word "responsibility" is being slightly differently in the two
uses.  SRP is about responsibilities in the system. We were talking
about the responsibilities of correctly playing a role in a protocol
between objects.
For example, suppose we have a system that communicates over a network
but must not send messages faster than some maximum rate. Our system
needs to rate limit the sending of messages. We would want to
implement the rate limiting responsibility in one class -- not have it
intermingled with formatting the contents of messages or transmitting
them over the wire -- and compose it into the system. But a class that
performs rate limiting must collaborate with other objects: play roles
in protocols between objects. It must be able to send and receive
messages via some lower layer transport and request and receive timer
callbacks. To play those roles correctly it must follow certain rules
-- that is, it has a responsibility to send correct requests &
responses to its peers and respond appropriately to correct requests &
responses it receives from them. For example, it might not be allowed
send a zero length message or send a message to a wildcard address,
and it must announce a "stop sending" notification if the rate limit
has been reached and a "start sending" notification when peers can
send messages again.
www.natpryce.com





#10980 Da: Matteo Vaccari <vaccari@...>
Data: Gio 21 Giu 2012 2:51 pm
Oggetto: Re: [xp-it] Fwd: [GOOS] SRP vs Roles and Responsibilities
matteo_vaccari
Invia email Invia email
 


On Thu, Jun 21, 2012 at 4:47 PM, Uberto Barbini <uberto.gama@...> wrote:


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 :)

Ciao

Matteo


ciao

Uberto


On Thu, Jun 21, 2012 at 3:36 PM, Matteo Vaccari <vaccari@...> wrote:



Vi mando una copia di un messaggio passato sulla mailing list del GOOS.  Quando abbiamo fatto l'esercizio con le CRC cards al Milano XPUG, avevo detto che una classe doveva avere 2-5 responsabilità (mi pare.)  Qualcuno ha chiesto come mai non una sola, in aderenza al Single Responsibility Principle.   Domanda pertinente!  La risposta che Nat Pryce da' qui sotto mi pare illuminante.

Matteo
---------- Forwarded message ----------
From: Nat Pryce <...>
Date: Tue, Jun 19, 2012 at 9:03 AM
Subject: Re: [GOOS] SRP vs Roles and Responsibilities
To: "growing-object-oriented-software@googlegroups.com" <growing-object-oriented-software@googlegroups.com>


On 19 Jun 2012, at 07:08, Nikolay Sturm <...> wrote:
> Hi,
>
> I am rereading GOOS in our company's book club atm and one question
> neither of us could make sense of was the relationship between the
> Single Responsibility Principle and the notion of objects as
> implementations of one or many roles, with each having one or many
> responsibilities.
>
> At 1st, 2nd and 3rd thought, these ideas seem to be opposed to each
> other. How do I get them into a coherent picture? Thoughts anyone?
>
> cheers,
>
> Nikolay

The word "responsibility" is being slightly differently in the two
uses.  SRP is about responsibilities in the system. We were talking
about the responsibilities of correctly playing a role in a protocol
between objects.
For example, suppose we have a system that communicates over a network
but must not send messages faster than some maximum rate. Our system
needs to rate limit the sending of messages. We would want to
implement the rate limiting responsibility in one class -- not have it
intermingled with formatting the contents of messages or transmitting
them over the wire -- and compose it into the system. But a class that
performs rate limiting must collaborate with other objects: play roles
in protocols between objects. It must be able to send and receive
messages via some lower layer transport and request and receive timer
callbacks. To play those roles correctly it must follow certain rules
-- that is, it has a responsibility to send correct requests &
responses to its peers and respond appropriately to correct requests &
responses it receives from them. For example, it might not be allowed
send a zero length message or send a message to a wildcard address,
and it must announce a "stop sending" notification if the rate limit
has been reached and a "start sending" notification when peers can
send messages again.
www.natpryce.com








#10981 Da: Uberto Barbini <uberto.gama@...>
Data: Gio 21 Giu 2012 2:58 pm
Oggetto: Re: [xp-it] Fwd: [GOOS] SRP vs Roles and Responsibilities
ubertob
Invia email Invia email
 

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

#10982 Da: Matteo Vaccari <vaccari@...>
Data: Gio 21 Giu 2012 3:10 pm
Oggetto: Re: [xp-it] Fwd: [GOOS] SRP vs Roles and Responsibilities
matteo_vaccari
Invia email Invia email
 


2012/6/21 Uberto Barbini <uberto.gama@...>



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.


Anche questa è una buona spiegazione :)


#10983 Da: Matteo Vaccari <vaccari@...>
Data: Gio 21 Giu 2012 3:49 pm
Oggetto: Re: [xp-it] Testare pattern CommandFactory in C#
matteo_vaccari
Invia email Invia email
 


2012/6/18 Martino Vallara <martino.vallara@...>


Matteo Vaccari <vaccari@...> ha scritto:

>2012/6/14 Martino Vallara <martino.vallara@...>
>
>>
>>
>> Il 14/06/2012 13:30, Matteo Vaccari ha scritto:
>>
>>
>>
>> Più che altro sarebbe un test che ti lascia un senso di inutilità.
>>
>> Non ho capito.... cosa c'è di più "utile" nel verificare che un
>sistema in
>> una certa condizione esegua l'azione giusta?
>> E' chiaro che il modo più semplice è "vedere\testare" quello che fa.
>Ma in
>> alcune situazione potrebbe essere molto dispendioso e complesso.
>>
>> Ma probabilmente volevi dire altro...
>
>
>Trovo poco utile scrivere un test del tipo
>
>assertEquals(map.get("pippo"), "pluto");
>
>per arrivare a scrivere il codice di produzione
>
>Map map = new HashMap();
>map.put("pippo", "pluto");
>
>Il codice di test è sostanzialmente uguale al codice di test, quindi
>viene
>meno il principio della "partita doppia" [0] per cui il codice di test
>dovrebbe essere una maniera diversa di dire le cose che dice il codice
>di
>produzione.  Nel tuo caso il codice che immagino sarebbe
>
>assertEquals(factory.build("pippo").getClass().getName(), "Pluto");
>
>per arrivare a scrivere il codice di produzione
>
>Command build(String name) {
>  if (name.equals("pippo")) {
>    return new Pluto();
>  } ...
>}
>
>Un test simile mi sembra comunque violare il principio della partita
>doppia.

In sostanza Ä— importante contrllare il comportamento che codice diverso. altrimenti aumenta la probabilità di fare dei falsi positivi. Giusto?

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.

Matteo


#10984 Da: marco trincardi <iltrink0@...>
Data: Gio 21 Giu 2012 4:44 pm
Oggetto: Re: [xp-it] Fwd: [GOOS] SRP vs Roles and Responsibilities
iltrink0
Invia email Invia email
 
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


#10985 Da: Martino Vallara <martino.vallara@...>
Data: Gio 21 Giu 2012 5:07 pm
Oggetto: Re: [xp-it] Testare pattern CommandFactory in C#
martino.vallara
Invia email Invia email
 
Il 21/06/2012 17:49, Matteo Vaccari ha scritto:
 

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.
Capito!
In quest'ottica i test che utilizzano un DSL sono da deprecare... ??

#10986 Da: Matteo Vaccari <vaccari@...>
Data: Gio 21 Giu 2012 5:14 pm
Oggetto: Re: [xp-it] Testare pattern CommandFactory in C#
matteo_vaccari
Invia email Invia email
 


2012/6/21 Martino Vallara <martino.vallara@...>


Il 21/06/2012 17:49, Matteo Vaccari ha scritto:
 

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.
Capito!
In quest'ottica i test che utilizzano un DSL sono da deprecare... ??

Per esempio?


#10987 Da: "lucaminudel" <luca.minudel@...>
Data: Gio 21 Giu 2012 9:54 pm
Oggetto: Fwd: [GOOS] SRP vs Roles and Responsibilities
lucaminudel
Invia email Invia email
 
> 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
>

#10988 Da: marco trincardi <iltrink0@...>
Data: Ven 22 Giu 2012 6:49 am
Oggetto: Re: [xp-it] Fwd: [GOOS] SRP vs Roles and Responsibilities
iltrink0
Invia email Invia email
 
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?


#10989 Da: Uberto Barbini <uberto.gama@...>
Data: Ven 22 Giu 2012 7:51 am
Oggetto: Re: [xp-it] Fwd: [GOOS] SRP vs Roles and Responsibilities
ubertob
Invia email Invia email
 


2012/6/21 marco trincardi <iltrink0@...>


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? :)

Si esatto Marco, la penso uguale.

Pero' questa differenza in granularita' penso sia gia' presente a livello semantico nella parola responsabilita'. Cioe' pensa quando dico alla donna delle pulizie "la tua responsabilita' e' di pulire l'ufficio" e' effettivamente una e una sola Responsabilita' (R maiuscola), pulire i cestini diventa una sua responsabilita' (r minuscola) di conseguenza o come dettaglio implementativo se vogliamo.
Per questo nella CRC ne vorrei avere solo una di responsabilita', ("pulire la stanza") come magari qualche spiegazione aggiuntiva (vuotare i cestini ma non toccare le carte sulle scrivanie) ma ben separate.
Se invece nella CRC scrivessi "vuotare i cestini, pulire i pavimenti, ecc. ecc." mancherebbe il senso di scrivere la carta.


ciao

Uberto

#10990 Da: Uberto Barbini <uberto.gama@...>
Data: Ven 22 Giu 2012 8:17 am
Oggetto: Re: [xp-it] Fwd: [GOOS] SRP vs Roles and Responsibilities
ubertob
Invia email Invia email
 
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

#10991 Da: Indrit Selimi <indritselimi@...>
Data: Ven 22 Giu 2012 9:18 am
Oggetto: Re: [xp-it] Fwd: [GOOS] SRP vs Roles and Responsibilities
indritselimi
Invia email Invia email
 
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"... ?"

Ovviamente nel software non  esistono delle verità assolute pero' questo non vuol dire che uno non possa farsi delle domande ed in qualche modo cercare di sintetizzare in un cosiddetto, principio, appunto. 

Ciao

Indrit



From: lucaminudel <luca.minudel@...>
To: extremeprogramming-it@yahoogroups.com
Sent: Thursday, June 21, 2012 11:54 PM
Subject: [xp-it] Fwd: [GOOS] SRP vs Roles and Responsibilities

 

> 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
>




#10992 Da: Uberto Barbini <uberto.gama@...>
Data: Ven 22 Giu 2012 9:25 am
Oggetto: Re: [xp-it] Fwd: [GOOS] SRP vs Roles and Responsibilities
ubertob
Invia email Invia email
 


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

#10993 Da: Indrit Selimi <indritselimi@...>
Data: Ven 22 Giu 2012 9:38 am
Oggetto: Re: [xp-it] Fwd: [GOOS] SRP vs Roles and Responsibilities
indritselimi
Invia email Invia email
 
E' proprio quello che intendevo. Grazie per avermi completato.

Ciao,

Indrit

On 22/giu/2012, at 11:25, Uberto Barbini <uberto.gama@...> wrote:

 



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

=

#10994 Da: Giorgio Sironi <piccoloprincipeazzurro@...>
Data: Ven 22 Giu 2012 1:53 pm
Oggetto: Re: [xp-it] Fwd: [GOOS] SRP vs Roles and Responsibilities
giorgiosiron...
Invia email Invia email
 
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.


--
Giorgio Sironi (@giorgiosironi)

#10995 Da: Uberto Barbini <uberto.gama@...>
Data: Ven 22 Giu 2012 2:23 pm
Oggetto: Re: [xp-it] Fwd: [GOOS] SRP vs Roles and Responsibilities
ubertob
Invia email Invia email
 


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



#10996 Da: Indrit Selimi <indritselimi@...>
Data: Ven 22 Giu 2012 4:16 pm
Oggetto: Re: [xp-it] Fwd: [GOOS] SRP vs Roles and Responsibilities
indritselimi
Invia email Invia email
 
Giorgio, tieni presente che (almeno da quanto ne so io) negli ultimi anni abbiamo visto molti linguaggi diversi ma nulla di rivoluzionario (nei linguaggi intendo, il TDD secondo me invece è stata una rivoluzione), si tratta sempre di derivazioni dalle teorie matematiche già note e definite nel secolo scorso( e sei proprio vogliamo un riferimento piu' tangibile, diciamo Turing). Come diceva qualcuno, quello che vediamo nell'evoluzione del software nel corso degli anni è una specie di 'spirale"... tutto cambia ma anche tutto parte dalla stessa origine e nel corso deli anni viene riproposto in una forma diversa.

Detto questo, ti ribalto la domanda:

Cosa trovi di cosi immensamente diverso fra i contesti che hai specificato prima?  

Ma temo che stiamo diventando un po' troppo off-topic, sorry.

Ciao,

Indrit



From: Giorgio Sironi <piccoloprincipeazzurro@...>
To: extremeprogramming-it@yahoogroups.com
Sent: Friday, June 22, 2012 3:53 PM
Subject: Re: [xp-it] Fwd: [GOOS] SRP vs Roles and Responsibilities

 
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.


--
Giorgio Sironi (@giorgiosironi)
http://giorgiosironi.blogspot.com/




#10997 Da: "lucaminudel" <luca.minudel@...>
Data: Sab 23 Giu 2012 8:07 pm
Oggetto: Fwd: [GOOS] SRP vs Roles and Responsibilities
lucaminudel
Invia email Invia email
 
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?
>

#10998 Da: "lucaminudel" <luca.minudel@...>
Data: Sab 23 Giu 2012 9:14 pm
Oggetto: Fwd: [GOOS] SRP vs Roles and Responsibilities
lucaminudel
Invia email Invia email
 
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
>

#10999 Da: Uberto Barbini <uberto.gama@...>
Data: Dom 24 Giu 2012 11:19 am
Oggetto: Re: [xp-it] Fwd: [GOOS] SRP vs Roles and Responsibilities
ubertob
Invia email Invia email
 
> 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

#11000 Da: Giorgio Vespucci <giorgio.vespucci@...>
Data: Lun 2 Lu 2012 11:44 am
Oggetto: [kata] FizzBuzz Extra Credit
freak7019
Invia email Invia email
 
Ciao a tutti
Insieme ad un collega ci stiamo cimentando nel FizzBuzz. la cui traccia ho preso da qui: http://nimblepros.com/media/36613/fizzbuzz%20kata.pdf
Volevamo passare agli Extra Credit, ma non siamo sicuri dei test che li esprimono.
Qualcuno di voi ha già implementato i test di questi Extra Credit?
Ad esempio, stante il requisito: Instead of numbers with a three in them, print "Fizz", l'assert sul numero 3 come diventa, "FizzFizz"?
Ovvero un Fizz perché il 3 è multiplo di sè stesso + un Fizz perchè contiene l'unica cifra 3?

Mi sento un po' stupido, pardon :)

Grazie
--
Giorgio Vespucci
giorgio [dot] vespucci [at] gmail [dot] com
Skype, Twitter, Slideshare: gvespucci
http://xpermanwalking.blogspot.com

#11001 Da: Andrea Francia <andrea@...>
Data: Lun 2 Lu 2012 12:41 pm
Oggetto: Re: [xp-it] [kata] FizzBuzz Extra Credit
andrea52b
Invia email Invia email
 
2012/7/2 Giorgio Vespucci <giorgio.vespucci@...>
Ad esempio, stante il requisito: Instead of numbers with a three in them, print "Fizz", l'assert sul numero 3 come diventa, "FizzFizz"?

Secondo me 3 rimane Fizz. Dato che é un kata non credo che sia così importante cosa scegli.
Per esercizio entrambi i casi sono buoni.

Se lo trasformi in FizzFizz vuol dire che devi riadattare un test presumibilmente già scritto, é una cosa che capita nella realtà (almeno a me).

Mi sento un po' stupido, pardon :) 
 
Il requisito é scritto male, non c'é un esempio, manca un caso limite che tu giustamente da analista hai trovato. In un caso reale sano avresti potuto chiedere chiarimenti al cliente e dopo aggiornare i requisiti. D'altra parte in alcune realtà dove ho lavorato, che però non erano sane, non avresti potuto chiedere!

In che linguaggio lo fai? Facci un screencast con ansi.io!

Ciao
--
Andrea Francia http://andreafrancia.it

#11002 Da: Giorgio Vespucci <giorgio.vespucci@...>
Data: Lun 2 Lu 2012 1:17 pm
Oggetto: Re: [xp-it] [kata] FizzBuzz Extra Credit
freak7019
Invia email Invia email
 
2012/7/2 Andrea Francia <andrea@...>

Secondo me 3 rimane Fizz. Dato che é un kata non credo che sia così importante cosa scegli.
Per esercizio entrambi i casi sono buoni.

Se lo trasformi in FizzFizz vuol dire che devi riadattare un test presumibilmente già scritto, é una cosa che capita nella realtà (almeno a me).
In effetti è la strada che avevamo preso: FizzFizz.

Il requisito é scritto male, non c'é un esempio, manca un caso limite che tu giustamente da analista hai trovato. In un caso reale sano avresti potuto chiedere chiarimenti al cliente e dopo aggiornare i requisiti. D'altra parte in alcune realtà dove ho lavorato, che però non erano sane, non avresti potuto chiedere!
Per quello chiedevo, per collimare un po' di tentativi nella community :)

In che linguaggio lo fai? Facci un screencast con ansi.io!
Lo stiamo facendo nel Plain Old Java :)
Stiamo andando mooooooolto a rilento perché ci stiamo soffermando sui refactoring possibili.
Per domani stiamo cercando di capire se un Chain Of Responsibility possa fare al caso nostro ed eliminare una condizione abbastanza fastidiosa. :)

Grazie
--
Giorgio Vespucci
giorgio [dot] vespucci [at] gmail [dot] com
Skype, Twitter, Slideshare: gvespucci
http://xpermanwalking.blogspot.com

#11003 Da: Giorgio Sironi <piccoloprincipeazzurro@...>
Data: Lun 2 Lu 2012 1:35 pm
Oggetto: Re: [xp-it] [kata] FizzBuzz Extra Credit
giorgiosiron...
Invia email Invia email
 
2012/7/2 Andrea Francia <andrea@...> 
Il requisito é scritto male, non c'é un esempio, manca un caso limite che tu giustamente da analista hai trovato. In un caso reale sano avresti potuto chiedere chiarimenti al cliente e dopo aggiornare i requisiti.

Come voi io non scriverei una linea in più finché non si capisce il significato. In effetti si potrebbe dire che l'interpretazione tramite conversazione col cliente è parte dell'esercizio. :)

--
Giorgio Sironi (@giorgiosironi)

#11004 Da: Uberto Barbini <uberto.gama@...>
Data: Ven 6 Lu 2012 3:58 pm
Oggetto: OOP and FP
ubertob
Invia email Invia email
 
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

Messaggi 10975 - 11004 di 11825   Più vecchio  |  < Meno recente  |  Più recente >  |  Più nuovo
Messaggi 10975 - 11004 di 11825   Più vecchio  |  < Meno recente  |  Più recente >  |  Più nuovo
Avanzata

Copyright ? 2010 Yahoo! Tutti i diritti riservati.
La Tua Privacy - Testo aggiornato - Condizioni generali di utilizzo del servizio - Linee guida - Aiuto

?