Caricamento ...
Spiacenti, si è verificato un errore durante il caricamento del contenuto.

Re: [xp-it] Ogg: codemotion

Espandi messaggi
  • Indrit Selimi
    (scusatemi, su sto aifone non ci capisco nulla ;-) ) Matteo trovo molto interessanti i tuoi commenti sul Srp. Io sto studiando i video di Uncle Bob fra cui di
    Messaggio 1 di 31 , 4 apr 01:39
    Visualizza origine
    • 0 Allegato
      (scusatemi, su sto aifone non ci capisco nulla ;-) )

      Matteo trovo molto interessanti i tuoi commenti sul Srp. 
      Io sto studiando i video di Uncle Bob fra cui di recente anche
      quello sul SRP e sembra che lui spinga molto sulla coesione. 
      Siccome sono certo che hai visto il video presumo che tu ci abbia
      pensato sopra ed e' proprio questo che mi interessa molto (magari
      se ne parla al xpug?).
      Personalmente, i video mi stanno aiutando a capire alcuni
      aspetti che non avevo pienamente afferrato dai suoi libri.

      Indrit
      A
      On 04/apr/2012, at 10:28, Indrit Selimi <indritselimi@...> wrote:

       

      Ciao Matteo,

      I tuoi commenti sul srp e sul metodo di Uncle Bob l

      Indrit

      On 02/apr/2012, at 19:53, Matteo Vaccari <vaccari@...> wrote:

       



      2012/4/2 Piergiuliano Bossi <pgbossi@...>




      On Mon, Apr 2, 2012 at 3:55 AM, Matteo Vaccari <vaccari@...> wrote:




      2012/4/2 Giuseppe Vallarelli <giuseppevallarelli@...>


      Anche a me è piaciuto molto il talk di Matteo, peccato per la breve durata :-)
      ad ogni modo, Matteo quali sono i libri che consideri importanti e che sono stati
      "dimenticati" ?

      Oltre a XP Explained e XP Installed? :-)  Probabilmente OO Software Engineering di Jacobson, anche se le sue idee sono spiegate in maniera più accessibile in Applying UML And Patterns di Larman.  Ma non so ancora quale sia il percorso di libri migliore per imparare OO

      Concordo e aggiungo quanto segue:
      *) i SOLID di Uncle Bob, o meglio SDOL dal mio punto di vista, dai quali secondo me non si puo' prescindere; Clean Code e il libro nel quale ha descritto i principi li trovo meno potenti e piu' dispersivi
      *) "Smalltalk Best Practice Patterns" di Kent Beck (a prescindere dal linguaggio nel quale lavori); per certi versi anche i piu' recenti "Implementation Patterns" ma io ho trovato migliore il piu' datato "Smalltalk Best Practice Patterns"
      *) Pezzi di "Pragmatic Programmer" + Tell, Don't Ask (io lo uso un sacco per aprire gli occhi al programmatore procedurale)
      *) Tratti di DDD (Eric Evans)
      *) Tratti di GOOS (Freeman & Pryce)

      In realta' non so se questa roba e' "dimenticata" e dopotutto la domanda era per Matteo, ma visto che concordo su quanto scrive Matteo mi sono sentito in diritto di aggiungere altro materiale che io trovo essere in sintonia con quanto riportato sopra.

      Aggiungo che ho riscoperto un thread datato 2002 in cui Ralph Johnson spiega come Beck intende i pattern e la relazione tra la comunita' dei pattern e quella di XP (c'e' una sovrapposizione quasi assoluta). Ne consiglio caldamente la lettura per inquadrare meglio alcune delle cose che ho scritto: http://objectclub.jp/community/XP-jp/xp_relate/xp_patterns

      Grazie Giuliano.

      un'osservazione: per me quello che è un po' dimenticato dai dev in generale (con l'eccezione della comunità DDD) è l'idea che gli oggetti debbano rappresentare un "concetto" sensato.  Se ascolti Uncle Bob sembra che le classi nascano essenzialmente per gemmazione; quando una classe diventa troppo grossa si spostano alcuni metodi in una classe nuova.  Che può andare bene, ma si rischia di finire con classi tipo quelle di questa famosa vignetta:


      Inoltre, se tu continui a spingere sul pedale del SRP, arrivi ad avere oggetti con un solo metodo, che secondo me *non* è una buona idea.  Perché ti ritrovi con troppi oggetti poco coesi.  SRP spinge a ridurre l'accoppiamento, il che è OK, ma non c'è un altro principio dentro a SOLID che spinge ad aumentare la coesione, o così mi sembra.

      Che ne dite?

      Matteo



      =

      =
    • Martino Vallara
      ... Solo per capire, ma una sola responsabilità non coincide con un una sola ragione per cambiare ? Se cambia l unica responsabilità di quel codice il
      Messaggio 31 di 31 , 5 apr 01:52
      Visualizza origine
      • 0 Allegato
        Il 04/04/2012 17:36, Matteo Vaccari ha scritto:
         

        No, in effetti non ho ancora visto i video di Uncle Bob sui Solid, anche se ho molto apprezzato gli episodi 3-7.  Quello che ho detto è riferito a un fraintendimento comune, che SRP significa "una sola responsabilità" mentre invece dovrebbe significare "una sola ragione per cambiare".  Il che effettivamente è come la definisce Robert Martin, eccetto che il nome è fuorviante.

        Solo per capire, ma "una sola responsabilità" non coincide con un "una sola ragione per cambiare"?

        Se cambia "l'unica responsabilità" di quel codice il motivo di cambiamento è unico!?

        Se invece si considera che il codice deve cambiare "per esempio" per questioni di performance o altri motivi dovuti a requisiti non funzionali, allora è impossibile avere un unico motivo di cambiamento.

        Mi sbaglio, vero?




        -- 
        Martino Vallara
        martino.vallara@...
        http:\\martinovallara.blogspot.com
        http://twitter.com/martinovallara
      Il tuo messaggio è stato inviato correttamente e verrà recapitato a breve ai destinatari.