From 558c4e941558735254d4f62a72d2a3afed537fb2 Mon Sep 17 00:00:00 2001 From: Livio Date: Wed, 24 Jan 2024 22:54:37 +0100 Subject: [PATCH 01/59] docs: #79 Inizio capitolo Design Patterns --- docs/it/design-pattern.md | 52 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 52 insertions(+) create mode 100644 docs/it/design-pattern.md diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md new file mode 100644 index 00000000..c6181a71 --- /dev/null +++ b/docs/it/design-pattern.md @@ -0,0 +1,52 @@ +## Design Patterns + +Il concetto di Design Patterns è definizione su [Wikipedia](https://it.wikipedia.org/) è una soluzione generale ad un problema di progettazione ricorrente e deriva dallo stesso concetto esistente in architettura.\ +Questo concetto è comparso la prima volta nel libro [Design Patterns - Elementi per il riuso di software ad oggetti](https://it.wikipedia.org/wiki/Design_Patterns) i cui autori , detti la [Gang of Four](https://it.wikipedia.org/wiki/Gang_of_Four_scrittori) , sono 4 importanti autori del panorama informatico internazionale Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides. + +Per capire meglio il concetto possiamo dire che ogni design pattern identifica un problema generalizzato da risolvere e gli associa una soluzione; Questo generalmente tramite , ad esempio, uno schema UML che la descrive e aiuta sensibilmente a capirla.\ +In generale Design patterns e Programmazione ad oggetti sono strettamente legati poiché sia il libro che pagine internet che ne parlano sono descritti con l'utilizzo di oggetti.\ +Questo non vuol dire che ad esempio nella programmazione funzionale non vengano utilizzati ma naturalmente necessitano di strutture differenti tanto è vero che alcuni Design Patterns sono più facilmente implementabili con quest'ultimo paradigma. + +Internet ha molte risorse sull'argomento anche valide , fra queste possiamo consigliare: + +- [Refactoring Guru](https://refactoring.guru/design-patterns/) molto dettagliato e che spiega nel dettaglio ogni Design Pattern con esempi anche in codice acquistabili separatamente in tutti i linguaggi. +- [Il canale Youtube di Christopher Okhravi](https://www.youtube.com/@ChristopherOkhravi) +- [Design Patterns su Wikipedia Italiano](https://it.wikipedia.org/wiki/Design_pattern) +- [Design Patterns su Wikipedia Inglese](https://en.wikipedia.org/wiki/Design_pattern) + +Il libro della Gang of four identifica un elenco iniziale di design pattern ognuno dei quali ha un nome che richiama il problema generico che andrà a risolvere. +Generalmente un programmatore che sta sviluppando una certa parte di codice per implementare una o più funzionalità potrebbe "riconoscere" un design pattern al problema specifico che si sta cercando di risolvere e potrebbe anche non utilizzarlo ma l'utilizzo dello stesso può portare ad una serie di vantaggi. +I principali vantaggi di questo utilizzo sono: + +1. Facilità di riuso e test del software +2. Miglior comprensione del codice +3. Sono soluzioni provate e testate + +In particolare: \ +Facilità di riuso perché la creazione di più classi che possono spezzare logicamente il proprio problema implica la possibilità di utilizzare queste logiche in altri contesti o addirittura nello stesso prodotto che si sta sviluppando. Questo spezzare logicamente implica anche la facilità di test soprattutto automatici migliorando la qualità del software +Miglior comprensione del codice perché essendo conosciuti e avendo un nome è possibile riconoscerli (più o meno) facilmente da più persone. +Sono soluzioni provate e testate e quindi se riconosciamo il problema e applichiamo la soluzione siamo sicuri che funzionano + +Naturalmente , come ogni cosa esistente , ha anche dei svantaggi tra cui: + +1. Possono generare parti di codice più complicate, questo perchè ci possono essere casi in cui si può evitare di utilizzarli se il codice esistente ad esempio è semplice +2. In determinati casi minore comprensione del codice anche per il discorso del punto precedente e del fatto che la verità che ci sono programmatori che non li conoscono. +3. + +**Come sempre se la domanda è meglio utilizzarli o no la risposta è , naturalmente , dipende dal contesto.** + +Il libro sui Design Patterns della Gang of four suddivide i Design Pattern in 3 categorie: + +1. Patterns creazionali +2. Patterns strutturali +3. Patterns comportamentali + +Oltre al libro in questione ne sono stati introdotti altri che vedremo successivamente. + +## Patterns creazionali + +## Patterns strutturali + +## Patterns comportamentali + +## Altri pattern From 06756f0b671e28552ff6637e3665367dde905f7f Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Sat, 27 Jan 2024 15:32:28 +0100 Subject: [PATCH 02/59] chore: rimosso piramide.png --- docs/it/testing/piramide.png | Bin 4532 -> 0 bytes 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 docs/it/testing/piramide.png diff --git a/docs/it/testing/piramide.png b/docs/it/testing/piramide.png deleted file mode 100644 index 21b391997ecdb287c7c674af7924c4b43f0e0fe4..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 4532 zcmd6rS6EZs(#HdY7^DTFLJ$NY^cH#*h;NkMLT{QN1OX{ZM^p?*6RDy19;62d9n7nu z5D-BSr5UA&2+|R$C!V|S;=4cl+0Qd;X75>RU#wa4`|o%QGkx~6d}jdw0K1_93Jm}- z(uWL@U?APxmE=~Y8=wc$6bS${C9@u3nd!dJEd#VE01z$)07OOu00;C?>(_0hdEfrh5n&U`(4?hL!;)(R^D0DyEGqL9|1 zQ){y!`R8_z-)v4&D5F4gnK4b%Qd z?r|~lH;hywQcAxD@sx&%N*Od~KGlbqlw@HI7MFzZepama%?AF|=6W&o3AtCwn9Xz}LY}oq9Gmd?pwP!|y zxj{Ml8`J9#hNOnz`#o60&tpkE;KCEi=;!qySPRRb4d9cObqg`7 z-n{jMz$g|k`?_N4oj2RSk-ypG-XUT2UK-UUT>}^kYa}?I*G6vKvs^hi$-!t!^N|SF zQQ)P~1_^4t+d0b17#UG3ze?`>8!d}|C;^HNNLF-|3FtT06xZNi?S8e~Z7R07aQNu~ zp9`P0&E1)-Jhu!e3&{nhQ_j((wTKZCCEpYz_6|8rVETu}u z^S8n47FHzFw773ir_y5#Q2>5^+h>o3(i-pFRwNoY33uM8!}$;(XThk%(oMgdwa+XPafu{3yKs zg)-i16;bU!ro6C3yufaiMwqMyHZSKT1o^ya2Fh!UJ4+=xe|{!n)!f^G7S*4=i@vO5 z`N1yK+aMvyz8s~c`Q%HrG|V#xQoVccbz5w?Z%;s{LyNI>R6kuH~sN5xQU4W0`q|6xupb88^uL|r@G$0_PF z@Xge~*f;u$+UcLE&1S+xtc{kVWBxpNiDZkLwi~Dcnui}(@3=h3HuQI`oNm9g&B8%y zuJF4r(^{dMJMWD5+#z>WJP|-yP$P%hniEEWzdwB)Qw!fbPtkB6{b*V({^_MzR&TI8 zr7KV>{o@V84cJ6*7qC&9Uf!9e_q!C6XxFuF;4hiL+ex)k-B2Wx)~7#X&wzr>sGQaV zTRi6v-0zxh`gxC;BzcFJ>xj3Hv+FI^vI;_u{2a&+{P5wbAtDxk4p=EXGFFv!r&<)= z=QC{9g{qZFm6Xdm{pO4KK}-EP;m~#(b&Z0qyU{-=I!Hs{!)oXIi?;$mlt5dV z{d>ua_-iL$vI6pUha=QzueseVC{SR7y;yl&ixOUyBqq-E$jvo1vyaiZQDfo-;A4q+ zqq37~q0jA+r5&up^JPO$(ECEOJ8!QC7ALIz_(y!t)4AVPhQ+#xt><$K_{+zrmqhF> zYBX^sxLY2g?LtW1>=22(J41DkFp;mvDt9%qH~7=bJ;kW-tJkk@w?O{P4IApmVNafR z#8=s;+J&arWP?{nSo4Q}-gyg{!}7iiB}+IQr549b%t%=4m>LJQ=g<8-CKO&^m)D>;Ff*VrXGU4Y0BQLo*59D#liYO zw6^q$)nkPnW-$PwOk(0JAMYyz&^`Z^@5mkg$lPN5&*lD~&Ns&G{@{!@!>1VL+f#bf zpR~b-WAx4(sP!IWAnVO4;$t}+%E}M9N6IqYAD=|Dza2~XDk}#(`S+|Z|0M>uFPB#h z1Y*&4rIUx*b+A_hGj9X#P=9p4(AOT0n6mt`A7|H*#WWGsTkHVH2^gJ{fCuEocaW0v_@MeL6+apdprN;BfV^XcD zsLKyPt=?q6M~H`uCd1mrGi!nJ-|8`cp(T*Xl05rmsY17NTXXWRu9~P!jx<3`tp*#FH z`)@zcCeu9+Lox#FPF*aV_bokS=_i=R2WBuoTJ-Jwc2n|lhPD2j7_TqHG*AL5dyzMq z^i>A$dE>{N+j(uX4S8y`1nWolOO(r?QMMXHI*k)l(h|^epL$eSTxoC~TAtQ4XKEah z|GFjzo?&nk$CZzP$To@vusrmD7)g82k%%b6=-EY` zkTmpA&idJsZVz*7FOA`!ML zUmm^I(ag^D&O?SXcZ%`_VyL^;HCk=?{AQcC@~}PHY%31>_QzZW9*i-5X&3y}N8CYv=>i zCU9Uo@mE;A+;U1=v2C07_CZV4{kiooHeuvk(QWNAXuzj6KMQV7HKvLxwIQm z68I>v7YqY2st=GkwnQa!b>ASs5-J$!d<8rML#6Iu#VGNh68Q548@%|HCP&m8t|52X zD2uIpltuarjo+klfe|k4c{5wXW)QuVtHcQ(Dg=N*u;{e%zo)R%K^f3YJo}vysANGs zA9LxLtrRE)yS5RBl#mQp%AlEpEQK#x7&kT`C197}q3KB=OGO@N1cd}DA-BmRujIi{ zEI~LKiVxlYm_7jHxrmDQ`7dLYkb^E#_Pa%*6HDq;yJXYG@X?zF2n^etr};4m}zZntDHW6id^NvZ%J% zu+;BUw1%oJyO+=5?cTI*Xh^nDm8NhHlDiet+zahg}Rw#7aYEqHa0{grA+Yw+Rj5?k+k= z^?3RV(BBC17t<$6|MNK6>WlF|EMg8~<<&n4xKR+Kifd2RF>Z$X5eT<2;61J92j-SfUQ|?t|K1@yhXx%8>!^8jC8c;wiWpas3Fj-x= zSLH1q_|oRGwL%OnILaXP7`%c$iK^rNCM+*+Sh91IRDoJvXRfR!H9 z1%AqO{HgrC)VwbENS9*#EUKs+N6pAl|5petW!JgL8)ZS&LCPp+1dBU$o5}_yR)|^2 z+w}&ap8w=0nl2=m7TtkJW=TWu6(fmZmx4Ou6V;Px(pCPJ0Z08TRf=VFA_%z{ojWKg z-u&9rc|yiavp~g8E43?k96N?7%J<3bae-B2iFDL?lZ|v6@1<{I9K^BP7~I>qqaSlcZ$nIg z{py!it{~tcFDhnnFgo8CazHk^&ZT_^0#l3oTWwdLY8L#}H>iFa1fJ$jjlPZbR*c1@ zAPJBE3Zi#HJFUUm<{OD+{nS_SK$Th?WKiS35(<@bdxXwJoiBOx1aaJKs&R^>zeuDC z{{8s8c7KwIoB7HN|KMB0qXfyF`G63>q7Tod%~=a_{a4}^M=@zt?eWMyL9Q1%h~6l? zZ1BG#;o;T8M?7HuRyo&@RRQ|14bi}B_JMBLKzGes_uT0QpomaVlT|>-Dk7{AYMKg4 rnkwqj2!tjAf!A5i{67gker}$)u>U_{`<8_iJpo{N%?wq46@&i|4R9=i From 3a97905c284c5a02f2f8c413b1e22dbc3d81e624 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Sat, 27 Jan 2024 15:34:04 +0100 Subject: [PATCH 03/59] chore: rimosso piramide.png --- docs/it/testing/piramide.png | Bin 4532 -> 0 bytes 1 file changed, 0 insertions(+), 0 deletions(-) delete mode 100644 docs/it/testing/piramide.png diff --git a/docs/it/testing/piramide.png b/docs/it/testing/piramide.png deleted file mode 100644 index 21b391997ecdb287c7c674af7924c4b43f0e0fe4..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 4532 zcmd6rS6EZs(#HdY7^DTFLJ$NY^cH#*h;NkMLT{QN1OX{ZM^p?*6RDy19;62d9n7nu z5D-BSr5UA&2+|R$C!V|S;=4cl+0Qd;X75>RU#wa4`|o%QGkx~6d}jdw0K1_93Jm}- z(uWL@U?APxmE=~Y8=wc$6bS${C9@u3nd!dJEd#VE01z$)07OOu00;C?>(_0hdEfrh5n&U`(4?hL!;)(R^D0DyEGqL9|1 zQ){y!`R8_z-)v4&D5F4gnK4b%Qd z?r|~lH;hywQcAxD@sx&%N*Od~KGlbqlw@HI7MFzZepama%?AF|=6W&o3AtCwn9Xz}LY}oq9Gmd?pwP!|y zxj{Ml8`J9#hNOnz`#o60&tpkE;KCEi=;!qySPRRb4d9cObqg`7 z-n{jMz$g|k`?_N4oj2RSk-ypG-XUT2UK-UUT>}^kYa}?I*G6vKvs^hi$-!t!^N|SF zQQ)P~1_^4t+d0b17#UG3ze?`>8!d}|C;^HNNLF-|3FtT06xZNi?S8e~Z7R07aQNu~ zp9`P0&E1)-Jhu!e3&{nhQ_j((wTKZCCEpYz_6|8rVETu}u z^S8n47FHzFw773ir_y5#Q2>5^+h>o3(i-pFRwNoY33uM8!}$;(XThk%(oMgdwa+XPafu{3yKs zg)-i16;bU!ro6C3yufaiMwqMyHZSKT1o^ya2Fh!UJ4+=xe|{!n)!f^G7S*4=i@vO5 z`N1yK+aMvyz8s~c`Q%HrG|V#xQoVccbz5w?Z%;s{LyNI>R6kuH~sN5xQU4W0`q|6xupb88^uL|r@G$0_PF z@Xge~*f;u$+UcLE&1S+xtc{kVWBxpNiDZkLwi~Dcnui}(@3=h3HuQI`oNm9g&B8%y zuJF4r(^{dMJMWD5+#z>WJP|-yP$P%hniEEWzdwB)Qw!fbPtkB6{b*V({^_MzR&TI8 zr7KV>{o@V84cJ6*7qC&9Uf!9e_q!C6XxFuF;4hiL+ex)k-B2Wx)~7#X&wzr>sGQaV zTRi6v-0zxh`gxC;BzcFJ>xj3Hv+FI^vI;_u{2a&+{P5wbAtDxk4p=EXGFFv!r&<)= z=QC{9g{qZFm6Xdm{pO4KK}-EP;m~#(b&Z0qyU{-=I!Hs{!)oXIi?;$mlt5dV z{d>ua_-iL$vI6pUha=QzueseVC{SR7y;yl&ixOUyBqq-E$jvo1vyaiZQDfo-;A4q+ zqq37~q0jA+r5&up^JPO$(ECEOJ8!QC7ALIz_(y!t)4AVPhQ+#xt><$K_{+zrmqhF> zYBX^sxLY2g?LtW1>=22(J41DkFp;mvDt9%qH~7=bJ;kW-tJkk@w?O{P4IApmVNafR z#8=s;+J&arWP?{nSo4Q}-gyg{!}7iiB}+IQr549b%t%=4m>LJQ=g<8-CKO&^m)D>;Ff*VrXGU4Y0BQLo*59D#liYO zw6^q$)nkPnW-$PwOk(0JAMYyz&^`Z^@5mkg$lPN5&*lD~&Ns&G{@{!@!>1VL+f#bf zpR~b-WAx4(sP!IWAnVO4;$t}+%E}M9N6IqYAD=|Dza2~XDk}#(`S+|Z|0M>uFPB#h z1Y*&4rIUx*b+A_hGj9X#P=9p4(AOT0n6mt`A7|H*#WWGsTkHVH2^gJ{fCuEocaW0v_@MeL6+apdprN;BfV^XcD zsLKyPt=?q6M~H`uCd1mrGi!nJ-|8`cp(T*Xl05rmsY17NTXXWRu9~P!jx<3`tp*#FH z`)@zcCeu9+Lox#FPF*aV_bokS=_i=R2WBuoTJ-Jwc2n|lhPD2j7_TqHG*AL5dyzMq z^i>A$dE>{N+j(uX4S8y`1nWolOO(r?QMMXHI*k)l(h|^epL$eSTxoC~TAtQ4XKEah z|GFjzo?&nk$CZzP$To@vusrmD7)g82k%%b6=-EY` zkTmpA&idJsZVz*7FOA`!ML zUmm^I(ag^D&O?SXcZ%`_VyL^;HCk=?{AQcC@~}PHY%31>_QzZW9*i-5X&3y}N8CYv=>i zCU9Uo@mE;A+;U1=v2C07_CZV4{kiooHeuvk(QWNAXuzj6KMQV7HKvLxwIQm z68I>v7YqY2st=GkwnQa!b>ASs5-J$!d<8rML#6Iu#VGNh68Q548@%|HCP&m8t|52X zD2uIpltuarjo+klfe|k4c{5wXW)QuVtHcQ(Dg=N*u;{e%zo)R%K^f3YJo}vysANGs zA9LxLtrRE)yS5RBl#mQp%AlEpEQK#x7&kT`C197}q3KB=OGO@N1cd}DA-BmRujIi{ zEI~LKiVxlYm_7jHxrmDQ`7dLYkb^E#_Pa%*6HDq;yJXYG@X?zF2n^etr};4m}zZntDHW6id^NvZ%J% zu+;BUw1%oJyO+=5?cTI*Xh^nDm8NhHlDiet+zahg}Rw#7aYEqHa0{grA+Yw+Rj5?k+k= z^?3RV(BBC17t<$6|MNK6>WlF|EMg8~<<&n4xKR+Kifd2RF>Z$X5eT<2;61J92j-SfUQ|?t|K1@yhXx%8>!^8jC8c;wiWpas3Fj-x= zSLH1q_|oRGwL%OnILaXP7`%c$iK^rNCM+*+Sh91IRDoJvXRfR!H9 z1%AqO{HgrC)VwbENS9*#EUKs+N6pAl|5petW!JgL8)ZS&LCPp+1dBU$o5}_yR)|^2 z+w}&ap8w=0nl2=m7TtkJW=TWu6(fmZmx4Ou6V;Px(pCPJ0Z08TRf=VFA_%z{ojWKg z-u&9rc|yiavp~g8E43?k96N?7%J<3bae-B2iFDL?lZ|v6@1<{I9K^BP7~I>qqaSlcZ$nIg z{py!it{~tcFDhnnFgo8CazHk^&ZT_^0#l3oTWwdLY8L#}H>iFa1fJ$jjlPZbR*c1@ zAPJBE3Zi#HJFUUm<{OD+{nS_SK$Th?WKiS35(<@bdxXwJoiBOx1aaJKs&R^>zeuDC z{{8s8c7KwIoB7HN|KMB0qXfyF`G63>q7Tod%~=a_{a4}^M=@zt?eWMyL9Q1%h~6l? zZ1BG#;o;T8M?7HuRyo&@RRQ|14bi}B_JMBLKzGes_uT0QpomaVlT|>-Dk7{AYMKg4 rnkwqj2!tjAf!A5i{67gker}$)u>U_{`<8_iJpo{N%?wq46@&i|4R9=i From 1018d732d2d6e99a87f9e047ac3659c10c0e6de2 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Sat, 27 Jan 2024 15:51:31 +0100 Subject: [PATCH 04/59] chore: riviste alcune porzioni di contenuto + aggiunte note --- docs/it/design-pattern.md | 25 +++++++++++++++---------- 1 file changed, 15 insertions(+), 10 deletions(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index c6181a71..38eaaa23 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -1,7 +1,9 @@ ## Design Patterns -Il concetto di Design Patterns è definizione su [Wikipedia](https://it.wikipedia.org/) è una soluzione generale ad un problema di progettazione ricorrente e deriva dallo stesso concetto esistente in architettura.\ -Questo concetto è comparso la prima volta nel libro [Design Patterns - Elementi per il riuso di software ad oggetti](https://it.wikipedia.org/wiki/Design_Patterns) i cui autori , detti la [Gang of Four](https://it.wikipedia.org/wiki/Gang_of_Four_scrittori) , sono 4 importanti autori del panorama informatico internazionale Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides. +Il concetto di Design Patterns è definito su [Wikipedia](https://it.wikipedia.org/wiki/Design_pattern) come: +> Una soluzione progettuale generale ad un problema ricorrente. + +Questo concetto, derivante da un concetto similare esistente in architettura, è comparso per la prima volta nel libro [Design Patterns - Elementi per il riuso di software ad oggetti](https://it.wikipedia.org/wiki/Design_Patterns) i cui autori, detti [Gang of Four](https://it.wikipedia.org/wiki/Gang_of_Four_(scrittori)), sono 4 importanti autori del panorama informatico internazionale: Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides. Per capire meglio il concetto possiamo dire che ogni design pattern identifica un problema generalizzato da risolvere e gli associa una soluzione; Questo generalmente tramite , ad esempio, uno schema UML che la descrive e aiuta sensibilmente a capirla.\ In generale Design patterns e Programmazione ad oggetti sono strettamente legati poiché sia il libro che pagine internet che ne parlano sono descritti con l'utilizzo di oggetti.\ @@ -18,14 +20,9 @@ Il libro della Gang of four identifica un elenco iniziale di design pattern ognu Generalmente un programmatore che sta sviluppando una certa parte di codice per implementare una o più funzionalità potrebbe "riconoscere" un design pattern al problema specifico che si sta cercando di risolvere e potrebbe anche non utilizzarlo ma l'utilizzo dello stesso può portare ad una serie di vantaggi. I principali vantaggi di questo utilizzo sono: -1. Facilità di riuso e test del software -2. Miglior comprensione del codice -3. Sono soluzioni provate e testate - -In particolare: \ -Facilità di riuso perché la creazione di più classi che possono spezzare logicamente il proprio problema implica la possibilità di utilizzare queste logiche in altri contesti o addirittura nello stesso prodotto che si sta sviluppando. Questo spezzare logicamente implica anche la facilità di test soprattutto automatici migliorando la qualità del software -Miglior comprensione del codice perché essendo conosciuti e avendo un nome è possibile riconoscerli (più o meno) facilmente da più persone. -Sono soluzioni provate e testate e quindi se riconosciamo il problema e applichiamo la soluzione siamo sicuri che funzionano +- **Facilità di riuso e test del software**: la creazione di più classi che possono spezzare logicamente il proprio problema implica la possibilità di utilizzare queste logiche in altri contesti o addirittura nello stesso prodotto che si sta sviluppando. Questo spezzare logicamente implica anche la facilità di test soprattutto automatici migliorando la qualità del software. +- **Miglior comprensione del codice**: essendo conosciuti e avendo un nome è possibile riconoscerli (più o meno) facilmente da più persone. +- **Soluzioni provate e testate**: se riconosciamo il problema e applichiamo la soluzione siamo sicuri che funzionano. Naturalmente , come ogni cosa esistente , ha anche dei svantaggi tra cui: @@ -50,3 +47,11 @@ Oltre al libro in questione ne sono stati introdotti altri che vedremo successiv ## Patterns comportamentali ## Altri pattern + + +# Note e appunti + +- Spingere di più sul concetto che i Design Pattern siano delle soluzioni _tipo_ a problemi _tipo_ ma che non sempre la situazione sarà così lineare da permetterci in primis di comprendere il problema che stiamo affrontando e inoltre non è detto che la soluzione sia ottimale in termini di, ma non solo: performance, tempi di sviluppo, armonia con altre scelte architetturali, esperienza del team. +- In linea con quanto sopra: Non tutti i dev di un team potrebbero essere in grado di adottare i design pattern nella maniera corretta e, come ogni standard, se non rispettato può portare più problemi che benefici. +- Importante delineare il fatto che spesso i Design Pattern, come altri concetti e best practise del software, siano astrazioni applicative e molti dei concetti rappresentati dai pattern possano essere ritrovati sia a livelli di astrazione più alti (Architettura e addirittura Infrastruttura) o più bassi (Singole righe di codice o singole funzioni). +- Come linea generale eviteremo di listare i design pattern in maniera accademica in quanto il libro sarà un incipit a un futuro approfondimento, ma ci concentreremo sui perché della loro nascita e del loro utilizzo, le principali dinamiche e i principali concetti attorno ad essi, e i pro e i contro generali. \ No newline at end of file From 0004e20829caf8d0957bc082fc7d373f13200d91 Mon Sep 17 00:00:00 2001 From: Livio74 Date: Sun, 4 Feb 2024 22:11:34 +0100 Subject: [PATCH 05/59] chore: completamento Inizio capitolo Design Patterns --- docs/it/design-pattern.md | 91 +++++++++++++++++++++++++++++++++------ 1 file changed, 77 insertions(+), 14 deletions(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 38eaaa23..1f532f80 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -1,57 +1,120 @@ ## Design Patterns Il concetto di Design Patterns è definito su [Wikipedia](https://it.wikipedia.org/wiki/Design_pattern) come: + > Una soluzione progettuale generale ad un problema ricorrente. -Questo concetto, derivante da un concetto similare esistente in architettura, è comparso per la prima volta nel libro [Design Patterns - Elementi per il riuso di software ad oggetti](https://it.wikipedia.org/wiki/Design_Patterns) i cui autori, detti [Gang of Four](https://it.wikipedia.org/wiki/Gang_of_Four_(scrittori)), sono 4 importanti autori del panorama informatico internazionale: Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides. +Questo concetto, derivante da quello similare esistente in architettura, è comparso per la prima volta nel libro [Design Patterns - Elementi per il riuso di software ad oggetti](https://it.wikipedia.org/wiki/Design_Patterns) i cui autori, detti [Gang of Four](), sono 4 importanti autori del panorama informatico internazionale: Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides. Per capire meglio il concetto possiamo dire che ogni design pattern identifica un problema generalizzato da risolvere e gli associa una soluzione; Questo generalmente tramite , ad esempio, uno schema UML che la descrive e aiuta sensibilmente a capirla.\ In generale Design patterns e Programmazione ad oggetti sono strettamente legati poiché sia il libro che pagine internet che ne parlano sono descritti con l'utilizzo di oggetti.\ Questo non vuol dire che ad esempio nella programmazione funzionale non vengano utilizzati ma naturalmente necessitano di strutture differenti tanto è vero che alcuni Design Patterns sono più facilmente implementabili con quest'ultimo paradigma. -Internet ha molte risorse sull'argomento anche valide , fra queste possiamo consigliare: +Internet ha molte risorse valide sull'argomento, fra queste possiamo citare: -- [Refactoring Guru](https://refactoring.guru/design-patterns/) molto dettagliato e che spiega nel dettaglio ogni Design Pattern con esempi anche in codice acquistabili separatamente in tutti i linguaggi. +- [Refactoring Guru](https://refactoring.guru/design-patterns/) molto dettagliato e che spiega ogni Design Pattern evidenziando di ognuno vantaggi e svantaggi e confrontandoli con gli altri. Sono presenti esempi in codice acquistabili separatamente in tutti i linguaggi. - [Il canale Youtube di Christopher Okhravi](https://www.youtube.com/@ChristopherOkhravi) - [Design Patterns su Wikipedia Italiano](https://it.wikipedia.org/wiki/Design_pattern) - [Design Patterns su Wikipedia Inglese](https://en.wikipedia.org/wiki/Design_pattern) Il libro della Gang of four identifica un elenco iniziale di design pattern ognuno dei quali ha un nome che richiama il problema generico che andrà a risolvere. -Generalmente un programmatore che sta sviluppando una certa parte di codice per implementare una o più funzionalità potrebbe "riconoscere" un design pattern al problema specifico che si sta cercando di risolvere e potrebbe anche non utilizzarlo ma l'utilizzo dello stesso può portare ad una serie di vantaggi. +Generalmente un programmatore che sta sviluppando una certa parte di codice per implementare una o più funzionalità potrebbe "riconoscere" un design pattern durante l'analisi di un problema specifico che si sta cercando di risolvere.\ +Si potrebbe quindi effettuare un refactoring oppure anche non utilizzarlo ma l'utilizzo dello stesso può portare ad una serie di vantaggi. I principali vantaggi di questo utilizzo sono: - **Facilità di riuso e test del software**: la creazione di più classi che possono spezzare logicamente il proprio problema implica la possibilità di utilizzare queste logiche in altri contesti o addirittura nello stesso prodotto che si sta sviluppando. Questo spezzare logicamente implica anche la facilità di test soprattutto automatici migliorando la qualità del software. - **Miglior comprensione del codice**: essendo conosciuti e avendo un nome è possibile riconoscerli (più o meno) facilmente da più persone. - **Soluzioni provate e testate**: se riconosciamo il problema e applichiamo la soluzione siamo sicuri che funzionano. -Naturalmente , come ogni cosa esistente , ha anche dei svantaggi tra cui: +Naturalmente, come ogni cosa esistente, ha anche dei svantaggi tra cui: + +1. Possono generare parti di codice più complicate, questo perchè ci possono essere casi in cui si può evitare di utilizzarli se il codice esistente ad esempio è semplice. +2. In determinati casi minore comprensione del codice anche per il discorso del punto precedente e del fatto che la verità è che ci sono programmatori che non li conoscono. +3. L'adozione di un design pattern può anche comportare svantaggi come ad esempio il peggioramento delle prestazioni perché la logica tende ad essere più complessa. + +**Come sempre se la domanda è: meglio utilizzarli o no? La risposta è , naturalmente , dipende dal contesto.** + +In generale dato un problema non sempre è semplice attribuirgli, se esiste, un design pattern che lo "riconosca"; a volte infatti il limite fra uno o l'altro non è sempre definito quindi si può entrare ad esempio scomponendo il problema più complesso (Divide et impera) in altri più semplici per i quali si potrebbero riconoscere dei pattern specifici.\ +A volte invece questa scomposizione non è possibile e , nel caso , si può comunque fare il refactoring scegliendo quello più simile o anche quello più conveniente. + +**E' importante sottolineare che non ci sono dei vincoli stringenti che ne impongono l'utilizzo;** \ +E' possibile applicarli oppure no, si possono mescolare a piacere, chiaramente una aderenza maggiore implica la facilità di riconoscerli da parte di altri programmatori che conoscono l'argomento. -1. Possono generare parti di codice più complicate, questo perchè ci possono essere casi in cui si può evitare di utilizzarli se il codice esistente ad esempio è semplice -2. In determinati casi minore comprensione del codice anche per il discorso del punto precedente e del fatto che la verità che ci sono programmatori che non li conoscono. -3. +Generalmente dopo un refactoring, la nostra applicazione sarà più aderente ai [principi di sviluppo software SOLID](https://it.wikipedia.org/wiki/SOLID) il che implica appunto il principalmente il primo dei vantaggi elencati soprattutto il riuso e la facilità di test.\ +Come viene definito nel design pattern possiamo definire il design pattern vero e proprio che ne demarca i suoi confini ed il client che definisce tutta la parte esterna ad esso che vi interagisce.\ +Il vantaggio principale dell'utilizzo implica che le modifiche apportate tendono a non cambiare sensibilmente il client. -**Come sempre se la domanda è meglio utilizzarli o no la risposta è , naturalmente , dipende dal contesto.** +Nel nostro libro li definiremo brevemente evitando di listarli in maniera accademica; il libro sarà un incipit a un futuro approfondimento, in quanto esistono numerose risorse, come già detto, che ne spiegano i dettagli per cui vi rimandiamo ad esse nel caso vogliate saperne qualcosa di più. -Il libro sui Design Patterns della Gang of four suddivide i Design Pattern in 3 categorie: +Oltre al libro sui Design Patterns in questione ne sono stati introdotti altri che vedremo successivamente.\ +Il libro della Gang of Four (GOF) suddivide i Design Pattern in 3 categorie: 1. Patterns creazionali 2. Patterns strutturali 3. Patterns comportamentali -Oltre al libro in questione ne sono stati introdotti altri che vedremo successivamente. - ## Patterns creazionali +I Patterns creazionali definiscono uno schema progettuale che in particolare si concentra sulla creazione degli oggetti che concorrono a risolvere un determinato problema. +In questo contesto indichiamo generalmente come prodotti gli oggetti creati utilizzando un oggetto generalmente denominato Factory (fabbrica) che , al suo interno , ne definisce la logica di costruzione che quindi risulta isolata dall'esterno. +Le altre tipologie definite dalla GOF, che sono la strutturale e la comportamentale, si distiguono da questa perché presuppogono già l'esistenza di tutti gli oggetti coinvonti. + +I pattern creazionali definiti dalla GOF sono: + +- Factory Method : definisce , nella classe Factory, uno o più metodi detti appunto factory methods che creano i nostri oggetti prodotto. +- Abstract Factory : serve a creare famiglie (possibilmente) fisse di oggetti prodotto sempre utilizzando una interfaccia/classe chiamata appunto Abstract factory dove anche gli oggetti prodotto sono generici (anch'essi utilizzano una interfaccia o classe astratta). +- Builder : definisce una particolare classe factory che crea oggetti complessi e viene utilizzato quando gli oggetti sono generalmente composti da altri oggetti creando anch'essi. +- Prototype : permette di costruire oggetti clonando oggetti già esistenti. Javascript utilizza proprio il concetto di prototype per estendere gli oggetti (parliamo proprio degli oggetti e non delle classi che sono state introdotte successivamente). +- Singleton : permette di costruire un oggetto garantendo che ne esista una sola istanza + +Come già detto i confini non sono ben definiti per cui, ad esempio, un oggetto complesso potrebbe essere creato tramite un builder e, se una parte dovesse richiedere una clonazione con un successivo raffinamento, sarà necessario utilizzare anche un Prototype che si occupa appunto della parte di clonazione. +Se non ci fosse la possibilità di effettuare una separazione netta si potrebbe utilizzare il Builder o il Prototype. + ## Patterns strutturali +I Patterns strutturali definiscono uno schema progettuale che in particolare risolvono problematiche inerenti alla struttura degli oggetti in modo che la soluzione sia flessibile ed efficiente; capiremo meglio questo concetto andando a vedere brevemente tutti i design pattern appartenenti a questa categoria. + +I pattern strutturali definiti dalla GOF sono: + +- Adapter: Un adapter è un pattern che traduce delle chiamate di una interfaccia alle chiamate di un'altra. Fornisce una soluzione astratta al problema della interoperabilità fra interfacce. Nella vita reale abbiamo ad esempi gli adattatori delle spine. +- Bridge: è un design pattern che separa una astrazione dalla sua separazione. Questo avviene separando l'interfaccia dalla sua implementazione potendo ad esempio cambiare facilmente l'implementazione. Un esempio molto utilizzato è il JDBC o in generale i driver dei database. +- Decorator: è un pattern che permette di aggiungere funzionalità attraverso il wrapping , cioè incapsulando un oggetto esistente. + Di conseguenza il nuovo oggetto potrà avere alcune funzionalità (non è detto tutte) dell'oggetto incapsulato e la nuova funzionalità aggiunta al suo interno. +- Façade: è un modo per semplificare un insieme di sottosistemi che formano un sistema complesso. Tramite questa semplificazione fornita attraverso una o più classi (poche) cosiddetta di facciata è possibile utilizzare le funzionalità più utili. +- Flyweight: permette di suddividere un oggetto che ha alcuni dei membri ripetibili in 2 parti una con parti che non si ripetono ed un gruppo di membri che insieme tendono a ripetersi. Questo meccanismo tende a limitare (e ottimizzare) l'occupazione di memoria questo perché ogni parte ripetuta viene memorizzata una sola volta. +- Proxy: si interpone ad un oggetto (di solito di servizio) e interagisce con esso utilizzando la stessa intefaccia. Un esempio sono i Proxy server che possono mandare il messaggio richiesto verso i server web veri e propri impedendo ad esempio l'accesso ad alcuni potenzialmente pericolosi. + +come si vede in ognuno di essi compare una struttura davanti al nostro client che può variare in ogni design pattern. Ad esempio nell'adapter la struttura cambia l'interfaccia (in quanto struttura della classe), nel Bridge cambia l'implementazione , nel Facade cambia ancora l'interfaccia che risulta più semplice + ## Patterns comportamentali +I Patterns strutturali definiscono uno schema progettuale che in particolare risolve problematiche di comportamento degli oggetti definiti nel pattern. Generalmente questo comportamento si riflette in particolare sugli algoritmi e sulle responsabilità degli oggetti stessi. + +I pattern comportamentali definiti dalla GOF sono: + +- Chain of responsibility: Il pattern permette di separare gli oggetti che invocano richieste, dagli oggetti che le gestiscono. In pratica viene definita una catena di oggetti dove la richiesta viene propagata finchè uno di essi che viene implementato non decide di gestirla. Ogni elemento della catena viene chiamato handler. +- Command: permette di isolare il codice che esegue una azione più o meno complessa dal client che la esegue oppure prendere una richiesta , memorizzarla in modo che possa essere eseguita in un secondo momento ad esempio dopo un certo evento. +- Iterator: permette di visitare tutti gli elementi di una altro oggetto , detto contenitore , senza dipendere dalla struttura interna di esso. + Un esempio tipico può essere il cursore per la lettura di una datasource. +- Mediator: incapsula l'interazione fra i vari oggetti di un loro insieme facendo in modo che la comunicazione col client venga gestita sempre da una unica entità favorendo il disaccoppiamento fra gli oggetti stessi. +- Memento: si occupa di memorizzare lo stato corrente di un altro oggetto detto Originator cercando di non violare l'incapsulamento. Può essere utile nei casi in cui si possa avere uno storico dell'oggetto stesso richiedendo al Memento il ripristino di uno stato precedente. (Il cosiddetto Undo/Redo) +- Observer: è una struttura formata da un Observer che osserva un cambiamento di stato di un Soggetto che possiamo definire Observable (Osservabile o Osservato) che fa appunto accadere quando lo stato all'interno di esso cambia. Esistono Librerie con RxJS si basano principalmente su questo pattern. Quando l'Observable cambia stato tutti gli Observer registrati ricevono l'informazione del cambiamento. +- State: è di fatto riconducibile ad un diagramma a stati finiti; consente ad un oggetto di modificare il proprio comportamento al cambiamento (ed in base) al suo stato interno. +- Strategy: permette di scegliere più comportamenti di un algoritmo (generalmente una variante di esso) a runtime associandolo (incapsulandolo) in una singola classe che lo implementa +- Template method: E' generalmente un metodo che implementa lo scheletro di un algorirmo e al suo interno possono essere chiamate parti (generalmente step) utilizzando la sovrascrittura dei passi senza dover cambiare la struttura del client chiamante. +- Visitor: in esso si separa una struttura dati dalla logica di attraversamento (visita) dell'algoritmo di visita e quindi dalle operazioni fatte su di essa. Gli algoritmi di visita possono cambiare senza cambiare la struttura del client. + ## Altri pattern +Come già detto la Gang of four ha iniziato a definirli e successivamente sulla loro falsa riga ne sono stati individuati altri che descriveremo brevemente di seguito. +Client/Server: è un pattern cosiddetto architetturale poichè può essere ad esempio l'architettura del prodotto che si vuole sviluppare. Esistono due "componenti" il client che effettua richieste ed il server che le riceve e risponde ad uno o più client.\ +Esempio classico sono quasi tutti i server di database che ad ogni richiesta , ad esempio di esecuzione di una query , rispondono con i risultati. +Model-View-Controller: è un pattern dove definiamo due entità separate il model che è la nostra entità che vogliamo rappresentare e contiene i suoi dati , il view che dice come mostrarla all'utente esterno e ne permette l'interazione; infine il Controller che effettua le interazioni fra i due. -# Note e appunti +# Note e appunti (Da eliminare a fine stesura) - Spingere di più sul concetto che i Design Pattern siano delle soluzioni _tipo_ a problemi _tipo_ ma che non sempre la situazione sarà così lineare da permetterci in primis di comprendere il problema che stiamo affrontando e inoltre non è detto che la soluzione sia ottimale in termini di, ma non solo: performance, tempi di sviluppo, armonia con altre scelte architetturali, esperienza del team. - In linea con quanto sopra: Non tutti i dev di un team potrebbero essere in grado di adottare i design pattern nella maniera corretta e, come ogni standard, se non rispettato può portare più problemi che benefici. - Importante delineare il fatto che spesso i Design Pattern, come altri concetti e best practise del software, siano astrazioni applicative e molti dei concetti rappresentati dai pattern possano essere ritrovati sia a livelli di astrazione più alti (Architettura e addirittura Infrastruttura) o più bassi (Singole righe di codice o singole funzioni). -- Come linea generale eviteremo di listare i design pattern in maniera accademica in quanto il libro sarà un incipit a un futuro approfondimento, ma ci concentreremo sui perché della loro nascita e del loro utilizzo, le principali dinamiche e i principali concetti attorno ad essi, e i pro e i contro generali. \ No newline at end of file +- (Già citato in una frase) Come linea generale eviteremo di listare i design pattern in maniera accademica in quanto il libro sarà un incipit a un futuro approfondimento, ma ci concentreremo sui perché della loro nascita e del loro utilizzo, le principali dinamiche e i principali concetti attorno ad essi, e i pro e i contro generali. +- I concetti SOLID sono una parte a se stante di una certa importanza nella programmazione , bisogna capire se parlarne qui o in altre parti per poi farne riferimento. From 7514232606a95094dca195a7efcd26a2b23efbfc Mon Sep 17 00:00:00 2001 From: Livio74 Date: Sun, 4 Feb 2024 22:25:05 +0100 Subject: [PATCH 06/59] chore: dependency Injection --- docs/it/design-pattern.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 1f532f80..6e9f5df7 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -110,6 +110,12 @@ Come già detto la Gang of four ha iniziato a definirli e successivamente sulla Client/Server: è un pattern cosiddetto architetturale poichè può essere ad esempio l'architettura del prodotto che si vuole sviluppare. Esistono due "componenti" il client che effettua richieste ed il server che le riceve e risponde ad uno o più client.\ Esempio classico sono quasi tutti i server di database che ad ogni richiesta , ad esempio di esecuzione di una query , rispondono con i risultati. Model-View-Controller: è un pattern dove definiamo due entità separate il model che è la nostra entità che vogliamo rappresentare e contiene i suoi dati , il view che dice come mostrarla all'utente esterno e ne permette l'interazione; infine il Controller che effettua le interazioni fra i due. +Dependency Injection: E' un pattern che permette di iniettare una dipendenza in una classe attraverso l'Inversion of control. Questo viene fatto iniettando una interfaccia o una classe astratta in modo da poter cambiare la sua implementazione in qualsiasi momento.\ +Abbiamo 3 tipi di iniezioni: + +- Injection nel costruttore +- Injection tramite setter +- Injection tramite interfaccia # Note e appunti (Da eliminare a fine stesura) From f4e1515b759be9194581f1838b033a91983cf5f6 Mon Sep 17 00:00:00 2001 From: Livio74 Date: Sun, 4 Feb 2024 22:27:01 +0100 Subject: [PATCH 07/59] chore: dependency Injection --- docs/it/design-pattern.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 6e9f5df7..c51e5629 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -107,10 +107,10 @@ I pattern comportamentali definiti dalla GOF sono: ## Altri pattern Come già detto la Gang of four ha iniziato a definirli e successivamente sulla loro falsa riga ne sono stati individuati altri che descriveremo brevemente di seguito. -Client/Server: è un pattern cosiddetto architetturale poichè può essere ad esempio l'architettura del prodotto che si vuole sviluppare. Esistono due "componenti" il client che effettua richieste ed il server che le riceve e risponde ad uno o più client.\ +- Client/Server: è un pattern cosiddetto architetturale poichè può essere ad esempio l'architettura del prodotto che si vuole sviluppare. Esistono due "componenti" il client che effettua richieste ed il server che le riceve e risponde ad uno o più client.\ Esempio classico sono quasi tutti i server di database che ad ogni richiesta , ad esempio di esecuzione di una query , rispondono con i risultati. -Model-View-Controller: è un pattern dove definiamo due entità separate il model che è la nostra entità che vogliamo rappresentare e contiene i suoi dati , il view che dice come mostrarla all'utente esterno e ne permette l'interazione; infine il Controller che effettua le interazioni fra i due. -Dependency Injection: E' un pattern che permette di iniettare una dipendenza in una classe attraverso l'Inversion of control. Questo viene fatto iniettando una interfaccia o una classe astratta in modo da poter cambiare la sua implementazione in qualsiasi momento.\ +- Model-View-Controller: è un pattern dove definiamo due entità separate il model che è la nostra entità che vogliamo rappresentare e contiene i suoi dati , il view che dice come mostrarla all'utente esterno e ne permette l'interazione; infine il Controller che effettua le interazioni fra i due. +- Dependency Injection: E' un pattern che permette di iniettare una dipendenza in una classe attraverso l'Inversion of control. Questo viene fatto iniettando una interfaccia o una classe astratta in modo da poter cambiare la sua implementazione in qualsiasi momento.\ Abbiamo 3 tipi di iniezioni: - Injection nel costruttore From 4df0fdadccfb0fc9819c7bb2291f95a971a80d87 Mon Sep 17 00:00:00 2001 From: Livio74 Date: Sun, 4 Feb 2024 22:29:17 +0100 Subject: [PATCH 08/59] chore: dependency Injection --- docs/it/design-pattern.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index c51e5629..0f3e8653 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -107,15 +107,16 @@ I pattern comportamentali definiti dalla GOF sono: ## Altri pattern Come già detto la Gang of four ha iniziato a definirli e successivamente sulla loro falsa riga ne sono stati individuati altri che descriveremo brevemente di seguito. + - Client/Server: è un pattern cosiddetto architetturale poichè può essere ad esempio l'architettura del prodotto che si vuole sviluppare. Esistono due "componenti" il client che effettua richieste ed il server che le riceve e risponde ad uno o più client.\ -Esempio classico sono quasi tutti i server di database che ad ogni richiesta , ad esempio di esecuzione di una query , rispondono con i risultati. + Esempio classico sono quasi tutti i server di database che ad ogni richiesta , ad esempio di esecuzione di una query , rispondono con i risultati. - Model-View-Controller: è un pattern dove definiamo due entità separate il model che è la nostra entità che vogliamo rappresentare e contiene i suoi dati , il view che dice come mostrarla all'utente esterno e ne permette l'interazione; infine il Controller che effettua le interazioni fra i due. - Dependency Injection: E' un pattern che permette di iniettare una dipendenza in una classe attraverso l'Inversion of control. Questo viene fatto iniettando una interfaccia o una classe astratta in modo da poter cambiare la sua implementazione in qualsiasi momento.\ -Abbiamo 3 tipi di iniezioni: + Abbiamo 3 tipi di iniezioni: -- Injection nel costruttore -- Injection tramite setter -- Injection tramite interfaccia + - Injection nel costruttore + - Injection tramite setter + - Injection tramite interfaccia # Note e appunti (Da eliminare a fine stesura) From 2ff61e64d7eeabd9cdb7c809098b2eed8df73179 Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Tue, 6 Feb 2024 09:12:46 +0100 Subject: [PATCH 09/59] feat: aggiustamenti dei primi paragrafi --- docs/it/design-pattern.md | 51 +++++++++++++++++++-------------------- 1 file changed, 25 insertions(+), 26 deletions(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 0f3e8653..a659290f 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -4,11 +4,12 @@ Il concetto di Design Patterns è definito su [Wikipedia](https://it.wikipedia.o > Una soluzione progettuale generale ad un problema ricorrente. -Questo concetto, derivante da quello similare esistente in architettura, è comparso per la prima volta nel libro [Design Patterns - Elementi per il riuso di software ad oggetti](https://it.wikipedia.org/wiki/Design_Patterns) i cui autori, detti [Gang of Four](), sono 4 importanti autori del panorama informatico internazionale: Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides. +Questo concetto, derivante da quello similare esistente in architettura, è comparso per la prima volta nel libro [Design Patterns - Elementi per il riuso di software ad oggetti](https://it.wikipedia.org/wiki/Design_Patterns) i cui autori, detti [Gang of Four](), sono 4 importanti figure del panorama informatico internazionale: Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides. -Per capire meglio il concetto possiamo dire che ogni design pattern identifica un problema generalizzato da risolvere e gli associa una soluzione; Questo generalmente tramite , ad esempio, uno schema UML che la descrive e aiuta sensibilmente a capirla.\ -In generale Design patterns e Programmazione ad oggetti sono strettamente legati poiché sia il libro che pagine internet che ne parlano sono descritti con l'utilizzo di oggetti.\ -Questo non vuol dire che ad esempio nella programmazione funzionale non vengano utilizzati ma naturalmente necessitano di strutture differenti tanto è vero che alcuni Design Patterns sono più facilmente implementabili con quest'ultimo paradigma. +Per capire meglio il concetto possiamo dire che ogni design pattern identifica un problema generalizzato da risolvere e associa ad esso una soluzione; Questo generalmente tramite uno schema UML che la descrive e aiuta sensibilmente a capirla. + +In generale, design patterns e programmazione ad oggetti sono strettamente legati poiché spesso i primi vengono descritti e spiegati utilizzando di oggetti. +Questo non vuol dire che, ad esempio, nella programmazione funzionale non vengano utilizzati, ma naturalmente necessitano di strutture differenti; in alcuni casi, a dire il vero, alcuni Design Patterns sono più facilmente implementabili con quest'ultimo paradigma. Internet ha molte risorse valide sull'argomento, fra queste possiamo citare: @@ -17,25 +18,23 @@ Internet ha molte risorse valide sull'argomento, fra queste possiamo citare: - [Design Patterns su Wikipedia Italiano](https://it.wikipedia.org/wiki/Design_pattern) - [Design Patterns su Wikipedia Inglese](https://en.wikipedia.org/wiki/Design_pattern) -Il libro della Gang of four identifica un elenco iniziale di design pattern ognuno dei quali ha un nome che richiama il problema generico che andrà a risolvere. -Generalmente un programmatore che sta sviluppando una certa parte di codice per implementare una o più funzionalità potrebbe "riconoscere" un design pattern durante l'analisi di un problema specifico che si sta cercando di risolvere.\ -Si potrebbe quindi effettuare un refactoring oppure anche non utilizzarlo ma l'utilizzo dello stesso può portare ad una serie di vantaggi. -I principali vantaggi di questo utilizzo sono: +Il libro della Gang of Four identifica un elenco iniziale di design pattern, ognuno dei quali ha un nome che identifica la soluzione al problema generico che andrà a risolvere. +Generalmente chi sta sviluppando una certa porzione di codice per implementare una o più funzionalità potrebbe "riconoscere" un design pattern durante l'analisi di un problema specifico che si sta cercando di risolvere e decidere di applicarlo, ottenendo una serie di vantaggi, tra cui: -- **Facilità di riuso e test del software**: la creazione di più classi che possono spezzare logicamente il proprio problema implica la possibilità di utilizzare queste logiche in altri contesti o addirittura nello stesso prodotto che si sta sviluppando. Questo spezzare logicamente implica anche la facilità di test soprattutto automatici migliorando la qualità del software. -- **Miglior comprensione del codice**: essendo conosciuti e avendo un nome è possibile riconoscerli (più o meno) facilmente da più persone. -- **Soluzioni provate e testate**: se riconosciamo il problema e applichiamo la soluzione siamo sicuri che funzionano. +- **Facilità di riuso e test del software**: Ogni design pattern è stato studiato e catalogato di modo da essere una soluzione pressoché universale ad ogni problema analogo a quello descritto, di conseguenza è possibile riutilizzare una implementazione in più punti del proprio codice. Inoltre, questi pattern sono solitamente accompagnati da suggerimenti e metodologie per il loro testing, il che rende il processo di scrittura dei test automatizzati più semplice ed efficace. +- **Miglior comprensione del codice**: Essendo conosciuti e avendo un nome inequivocabile, è possibile riconoscere i design pattern e creare un linguaggio comune quando si documenta e sviluppa il software. +- **Soluzioni provate e testate**: Nascendo dall'esperienza congiunta di più sviluppatori, e avvalorati nel corso degli anni, i design pattern difficilmente nascondono delle sorprese, e la loro adozione può garantire una soluzione _battle-tested_ e dimostrata ad un problema specifico. -Naturalmente, come ogni cosa esistente, ha anche dei svantaggi tra cui: +Naturalmente, come ogni cosa nel mondo del software, i design pattern comportano degli svantaggi, tra cui: -1. Possono generare parti di codice più complicate, questo perchè ci possono essere casi in cui si può evitare di utilizzarli se il codice esistente ad esempio è semplice. -2. In determinati casi minore comprensione del codice anche per il discorso del punto precedente e del fatto che la verità è che ci sono programmatori che non li conoscono. -3. L'adozione di un design pattern può anche comportare svantaggi come ad esempio il peggioramento delle prestazioni perché la logica tende ad essere più complessa. +1. Possono generare parti di codice più complicate. Una porzione di codice intelligibile e senza logiche complesse potrebbe beneficiare dal non utilizzo dei design pattern, che ne complicherebbero la struttura. +2. Per essere applicati alla lettera, i design pattern necessitano che chi li adotti accetti determinate assunzioni, ma è verosimile che chi sviluppa da poco tempo possa non conoscerli e trovarsi in difficoltà nella lettura e analisi del codice. +3. Le prestazioni spesso non coincidono con l'adozione di design pattern, in quanto lo scopo di questi ultimi è di risolvere un problema, non necessariamente in maniera ottimizzata. -**Come sempre se la domanda è: meglio utilizzarli o no? La risposta è , naturalmente , dipende dal contesto.** +**Come sempre se la domanda è: meglio utilizzarli o no? La risposta è, naturalmente, dipende dal contesto.** In generale dato un problema non sempre è semplice attribuirgli, se esiste, un design pattern che lo "riconosca"; a volte infatti il limite fra uno o l'altro non è sempre definito quindi si può entrare ad esempio scomponendo il problema più complesso (Divide et impera) in altri più semplici per i quali si potrebbero riconoscere dei pattern specifici.\ -A volte invece questa scomposizione non è possibile e , nel caso , si può comunque fare il refactoring scegliendo quello più simile o anche quello più conveniente. +A volte invece questa scomposizione non è possibile e, nel caso, si può comunque fare il refactoring scegliendo quello più simile o anche quello più conveniente. **E' importante sottolineare che non ci sono dei vincoli stringenti che ne impongono l'utilizzo;** \ E' possibile applicarli oppure no, si possono mescolare a piacere, chiaramente una aderenza maggiore implica la facilità di riconoscerli da parte di altri programmatori che conoscono l'argomento. @@ -56,12 +55,12 @@ Il libro della Gang of Four (GOF) suddivide i Design Pattern in 3 categorie: ## Patterns creazionali I Patterns creazionali definiscono uno schema progettuale che in particolare si concentra sulla creazione degli oggetti che concorrono a risolvere un determinato problema. -In questo contesto indichiamo generalmente come prodotti gli oggetti creati utilizzando un oggetto generalmente denominato Factory (fabbrica) che , al suo interno , ne definisce la logica di costruzione che quindi risulta isolata dall'esterno. +In questo contesto indichiamo generalmente come prodotti gli oggetti creati utilizzando un oggetto generalmente denominato Factory (fabbrica) che, al suo interno, ne definisce la logica di costruzione che quindi risulta isolata dall'esterno. Le altre tipologie definite dalla GOF, che sono la strutturale e la comportamentale, si distiguono da questa perché presuppogono già l'esistenza di tutti gli oggetti coinvonti. I pattern creazionali definiti dalla GOF sono: -- Factory Method : definisce , nella classe Factory, uno o più metodi detti appunto factory methods che creano i nostri oggetti prodotto. +- Factory Method : definisce, nella classe Factory, uno o più metodi detti appunto factory methods che creano i nostri oggetti prodotto. - Abstract Factory : serve a creare famiglie (possibilmente) fisse di oggetti prodotto sempre utilizzando una interfaccia/classe chiamata appunto Abstract factory dove anche gli oggetti prodotto sono generici (anch'essi utilizzano una interfaccia o classe astratta). - Builder : definisce una particolare classe factory che crea oggetti complessi e viene utilizzato quando gli oggetti sono generalmente composti da altri oggetti creando anch'essi. - Prototype : permette di costruire oggetti clonando oggetti già esistenti. Javascript utilizza proprio il concetto di prototype per estendere gli oggetti (parliamo proprio degli oggetti e non delle classi che sono state introdotte successivamente). @@ -78,13 +77,13 @@ I pattern strutturali definiti dalla GOF sono: - Adapter: Un adapter è un pattern che traduce delle chiamate di una interfaccia alle chiamate di un'altra. Fornisce una soluzione astratta al problema della interoperabilità fra interfacce. Nella vita reale abbiamo ad esempi gli adattatori delle spine. - Bridge: è un design pattern che separa una astrazione dalla sua separazione. Questo avviene separando l'interfaccia dalla sua implementazione potendo ad esempio cambiare facilmente l'implementazione. Un esempio molto utilizzato è il JDBC o in generale i driver dei database. -- Decorator: è un pattern che permette di aggiungere funzionalità attraverso il wrapping , cioè incapsulando un oggetto esistente. +- Decorator: è un pattern che permette di aggiungere funzionalità attraverso il wrapping, cioè incapsulando un oggetto esistente. Di conseguenza il nuovo oggetto potrà avere alcune funzionalità (non è detto tutte) dell'oggetto incapsulato e la nuova funzionalità aggiunta al suo interno. - Façade: è un modo per semplificare un insieme di sottosistemi che formano un sistema complesso. Tramite questa semplificazione fornita attraverso una o più classi (poche) cosiddetta di facciata è possibile utilizzare le funzionalità più utili. - Flyweight: permette di suddividere un oggetto che ha alcuni dei membri ripetibili in 2 parti una con parti che non si ripetono ed un gruppo di membri che insieme tendono a ripetersi. Questo meccanismo tende a limitare (e ottimizzare) l'occupazione di memoria questo perché ogni parte ripetuta viene memorizzata una sola volta. - Proxy: si interpone ad un oggetto (di solito di servizio) e interagisce con esso utilizzando la stessa intefaccia. Un esempio sono i Proxy server che possono mandare il messaggio richiesto verso i server web veri e propri impedendo ad esempio l'accesso ad alcuni potenzialmente pericolosi. -come si vede in ognuno di essi compare una struttura davanti al nostro client che può variare in ogni design pattern. Ad esempio nell'adapter la struttura cambia l'interfaccia (in quanto struttura della classe), nel Bridge cambia l'implementazione , nel Facade cambia ancora l'interfaccia che risulta più semplice +come si vede in ognuno di essi compare una struttura davanti al nostro client che può variare in ogni design pattern. Ad esempio nell'adapter la struttura cambia l'interfaccia (in quanto struttura della classe), nel Bridge cambia l'implementazione, nel Facade cambia ancora l'interfaccia che risulta più semplice ## Patterns comportamentali @@ -93,8 +92,8 @@ I Patterns strutturali definiscono uno schema progettuale che in particolare ris I pattern comportamentali definiti dalla GOF sono: - Chain of responsibility: Il pattern permette di separare gli oggetti che invocano richieste, dagli oggetti che le gestiscono. In pratica viene definita una catena di oggetti dove la richiesta viene propagata finchè uno di essi che viene implementato non decide di gestirla. Ogni elemento della catena viene chiamato handler. -- Command: permette di isolare il codice che esegue una azione più o meno complessa dal client che la esegue oppure prendere una richiesta , memorizzarla in modo che possa essere eseguita in un secondo momento ad esempio dopo un certo evento. -- Iterator: permette di visitare tutti gli elementi di una altro oggetto , detto contenitore , senza dipendere dalla struttura interna di esso. +- Command: permette di isolare il codice che esegue una azione più o meno complessa dal client che la esegue oppure prendere una richiesta, memorizzarla in modo che possa essere eseguita in un secondo momento ad esempio dopo un certo evento. +- Iterator: permette di visitare tutti gli elementi di una altro oggetto, detto contenitore, senza dipendere dalla struttura interna di esso. Un esempio tipico può essere il cursore per la lettura di una datasource. - Mediator: incapsula l'interazione fra i vari oggetti di un loro insieme facendo in modo che la comunicazione col client venga gestita sempre da una unica entità favorendo il disaccoppiamento fra gli oggetti stessi. - Memento: si occupa di memorizzare lo stato corrente di un altro oggetto detto Originator cercando di non violare l'incapsulamento. Può essere utile nei casi in cui si possa avere uno storico dell'oggetto stesso richiedendo al Memento il ripristino di uno stato precedente. (Il cosiddetto Undo/Redo) @@ -109,8 +108,8 @@ I pattern comportamentali definiti dalla GOF sono: Come già detto la Gang of four ha iniziato a definirli e successivamente sulla loro falsa riga ne sono stati individuati altri che descriveremo brevemente di seguito. - Client/Server: è un pattern cosiddetto architetturale poichè può essere ad esempio l'architettura del prodotto che si vuole sviluppare. Esistono due "componenti" il client che effettua richieste ed il server che le riceve e risponde ad uno o più client.\ - Esempio classico sono quasi tutti i server di database che ad ogni richiesta , ad esempio di esecuzione di una query , rispondono con i risultati. -- Model-View-Controller: è un pattern dove definiamo due entità separate il model che è la nostra entità che vogliamo rappresentare e contiene i suoi dati , il view che dice come mostrarla all'utente esterno e ne permette l'interazione; infine il Controller che effettua le interazioni fra i due. + Esempio classico sono quasi tutti i server di database che ad ogni richiesta, ad esempio di esecuzione di una query, rispondono con i risultati. +- Model-View-Controller: è un pattern dove definiamo due entità separate il model che è la nostra entità che vogliamo rappresentare e contiene i suoi dati, il view che dice come mostrarla all'utente esterno e ne permette l'interazione; infine il Controller che effettua le interazioni fra i due. - Dependency Injection: E' un pattern che permette di iniettare una dipendenza in una classe attraverso l'Inversion of control. Questo viene fatto iniettando una interfaccia o una classe astratta in modo da poter cambiare la sua implementazione in qualsiasi momento.\ Abbiamo 3 tipi di iniezioni: @@ -124,4 +123,4 @@ Come già detto la Gang of four ha iniziato a definirli e successivamente sulla - In linea con quanto sopra: Non tutti i dev di un team potrebbero essere in grado di adottare i design pattern nella maniera corretta e, come ogni standard, se non rispettato può portare più problemi che benefici. - Importante delineare il fatto che spesso i Design Pattern, come altri concetti e best practise del software, siano astrazioni applicative e molti dei concetti rappresentati dai pattern possano essere ritrovati sia a livelli di astrazione più alti (Architettura e addirittura Infrastruttura) o più bassi (Singole righe di codice o singole funzioni). - (Già citato in una frase) Come linea generale eviteremo di listare i design pattern in maniera accademica in quanto il libro sarà un incipit a un futuro approfondimento, ma ci concentreremo sui perché della loro nascita e del loro utilizzo, le principali dinamiche e i principali concetti attorno ad essi, e i pro e i contro generali. -- I concetti SOLID sono una parte a se stante di una certa importanza nella programmazione , bisogna capire se parlarne qui o in altre parti per poi farne riferimento. +- I concetti SOLID sono una parte a se stante di una certa importanza nella programmazione, bisogna capire se parlarne qui o in altre parti per poi farne riferimento. From 15abf4b09fe7cde3d1dcf598b6afc3afe47762a6 Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Thu, 15 Feb 2024 15:45:02 +0100 Subject: [PATCH 10/59] Correzione su uso UML Co-authored-by: Serena Sensini --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index a659290f..293bb3e5 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -6,7 +6,7 @@ Il concetto di Design Patterns è definito su [Wikipedia](https://it.wikipedia.o Questo concetto, derivante da quello similare esistente in architettura, è comparso per la prima volta nel libro [Design Patterns - Elementi per il riuso di software ad oggetti](https://it.wikipedia.org/wiki/Design_Patterns) i cui autori, detti [Gang of Four](), sono 4 importanti figure del panorama informatico internazionale: Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides. -Per capire meglio il concetto possiamo dire che ogni design pattern identifica un problema generalizzato da risolvere e associa ad esso una soluzione; Questo generalmente tramite uno schema UML che la descrive e aiuta sensibilmente a capirla. +Per capire meglio il concetto possiamo dire che ogni design pattern identifica un problema generalizzato da risolvere e associa ad esso una soluzione; questo generalmente viene rappresentato tramite uno schema UML, di supporto per comprendere meglio quanto proposto. In generale, design patterns e programmazione ad oggetti sono strettamente legati poiché spesso i primi vengono descritti e spiegati utilizzando di oggetti. Questo non vuol dire che, ad esempio, nella programmazione funzionale non vengano utilizzati, ma naturalmente necessitano di strutture differenti; in alcuni casi, a dire il vero, alcuni Design Patterns sono più facilmente implementabili con quest'ultimo paradigma. From 03e4e4631193fe32bb0486696d960ba3e70424bf Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Thu, 15 Feb 2024 17:18:14 +0100 Subject: [PATCH 11/59] sul sito Refactoring Guru Co-authored-by: Serena Sensini --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 293bb3e5..1a96b000 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -13,7 +13,7 @@ Questo non vuol dire che, ad esempio, nella programmazione funzionale non vengan Internet ha molte risorse valide sull'argomento, fra queste possiamo citare: -- [Refactoring Guru](https://refactoring.guru/design-patterns/) molto dettagliato e che spiega ogni Design Pattern evidenziando di ognuno vantaggi e svantaggi e confrontandoli con gli altri. Sono presenti esempi in codice acquistabili separatamente in tutti i linguaggi. +- [Refactoring Guru](https://refactoring.guru/design-patterns/) un sito molto dettagliato e che spiega i diversi Design Pattern evidenziando per ognuno vantaggi e svantaggi e confrontandoli con gli altri. Sono presenti esempi in codice acquistabili separatamente in tutti i linguaggi. - [Il canale Youtube di Christopher Okhravi](https://www.youtube.com/@ChristopherOkhravi) - [Design Patterns su Wikipedia Italiano](https://it.wikipedia.org/wiki/Design_pattern) - [Design Patterns su Wikipedia Inglese](https://en.wikipedia.org/wiki/Design_pattern) From d1689570caad1840c92b75988899748b7b99035c Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Thu, 15 Feb 2024 17:22:38 +0100 Subject: [PATCH 12/59] correzione di forma Co-authored-by: Serena Sensini --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 1a96b000..30db3620 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -22,7 +22,7 @@ Il libro della Gang of Four identifica un elenco iniziale di design pattern, ogn Generalmente chi sta sviluppando una certa porzione di codice per implementare una o più funzionalità potrebbe "riconoscere" un design pattern durante l'analisi di un problema specifico che si sta cercando di risolvere e decidere di applicarlo, ottenendo una serie di vantaggi, tra cui: - **Facilità di riuso e test del software**: Ogni design pattern è stato studiato e catalogato di modo da essere una soluzione pressoché universale ad ogni problema analogo a quello descritto, di conseguenza è possibile riutilizzare una implementazione in più punti del proprio codice. Inoltre, questi pattern sono solitamente accompagnati da suggerimenti e metodologie per il loro testing, il che rende il processo di scrittura dei test automatizzati più semplice ed efficace. -- **Miglior comprensione del codice**: Essendo conosciuti e avendo un nome inequivocabile, è possibile riconoscere i design pattern e creare un linguaggio comune quando si documenta e sviluppa il software. +- **Miglior comprensione del codice**: essendo conosciuti e avendo un nome inequivocabile, è possibile riconoscere i design pattern e creare un linguaggio comune quando si documenta e sviluppa il software. - **Soluzioni provate e testate**: Nascendo dall'esperienza congiunta di più sviluppatori, e avvalorati nel corso degli anni, i design pattern difficilmente nascondono delle sorprese, e la loro adozione può garantire una soluzione _battle-tested_ e dimostrata ad un problema specifico. Naturalmente, come ogni cosa nel mondo del software, i design pattern comportano degli svantaggi, tra cui: From 4b707845226219556d1d53e88ceb6a8a645c8887 Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Thu, 15 Feb 2024 17:22:57 +0100 Subject: [PATCH 13/59] Correzione di forma Co-authored-by: Serena Sensini --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 30db3620..48b568b5 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -110,7 +110,7 @@ Come già detto la Gang of four ha iniziato a definirli e successivamente sulla - Client/Server: è un pattern cosiddetto architetturale poichè può essere ad esempio l'architettura del prodotto che si vuole sviluppare. Esistono due "componenti" il client che effettua richieste ed il server che le riceve e risponde ad uno o più client.\ Esempio classico sono quasi tutti i server di database che ad ogni richiesta, ad esempio di esecuzione di una query, rispondono con i risultati. - Model-View-Controller: è un pattern dove definiamo due entità separate il model che è la nostra entità che vogliamo rappresentare e contiene i suoi dati, il view che dice come mostrarla all'utente esterno e ne permette l'interazione; infine il Controller che effettua le interazioni fra i due. -- Dependency Injection: E' un pattern che permette di iniettare una dipendenza in una classe attraverso l'Inversion of control. Questo viene fatto iniettando una interfaccia o una classe astratta in modo da poter cambiare la sua implementazione in qualsiasi momento.\ +- Dependency Injection: è un pattern che permette di iniettare una dipendenza in una classe attraverso l'Inversion of control. Questo viene fatto iniettando un'interfaccia o una classe astratta in modo da poter cambiare la sua implementazione in qualsiasi momento.\ Abbiamo 3 tipi di iniezioni: - Injection nel costruttore From ce6ba33fc34fb575fd882f3c2839ebaf4d4afac4 Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Thu, 15 Feb 2024 17:23:09 +0100 Subject: [PATCH 14/59] Correzione di forma Co-authored-by: Serena Sensini --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 48b568b5..48df97ca 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -120,7 +120,7 @@ Come già detto la Gang of four ha iniziato a definirli e successivamente sulla # Note e appunti (Da eliminare a fine stesura) - Spingere di più sul concetto che i Design Pattern siano delle soluzioni _tipo_ a problemi _tipo_ ma che non sempre la situazione sarà così lineare da permetterci in primis di comprendere il problema che stiamo affrontando e inoltre non è detto che la soluzione sia ottimale in termini di, ma non solo: performance, tempi di sviluppo, armonia con altre scelte architetturali, esperienza del team. -- In linea con quanto sopra: Non tutti i dev di un team potrebbero essere in grado di adottare i design pattern nella maniera corretta e, come ogni standard, se non rispettato può portare più problemi che benefici. +- In linea con quanto sopra: non tutti i/le dev di un team potrebbero essere in grado di adottare i design pattern nella maniera corretta e, come ogni standard, se non rispettato può portare più problemi che benefici. - Importante delineare il fatto che spesso i Design Pattern, come altri concetti e best practise del software, siano astrazioni applicative e molti dei concetti rappresentati dai pattern possano essere ritrovati sia a livelli di astrazione più alti (Architettura e addirittura Infrastruttura) o più bassi (Singole righe di codice o singole funzioni). - (Già citato in una frase) Come linea generale eviteremo di listare i design pattern in maniera accademica in quanto il libro sarà un incipit a un futuro approfondimento, ma ci concentreremo sui perché della loro nascita e del loro utilizzo, le principali dinamiche e i principali concetti attorno ad essi, e i pro e i contro generali. - I concetti SOLID sono una parte a se stante di una certa importanza nella programmazione, bisogna capire se parlarne qui o in altre parti per poi farne riferimento. From ff72a87b37f7e2e4346dbf5bb2856da2ee34f054 Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Thu, 15 Feb 2024 17:23:24 +0100 Subject: [PATCH 15/59] Correzione di forma Co-authored-by: Serena Sensini --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 48df97ca..21fb036a 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -121,6 +121,6 @@ Come già detto la Gang of four ha iniziato a definirli e successivamente sulla - Spingere di più sul concetto che i Design Pattern siano delle soluzioni _tipo_ a problemi _tipo_ ma che non sempre la situazione sarà così lineare da permetterci in primis di comprendere il problema che stiamo affrontando e inoltre non è detto che la soluzione sia ottimale in termini di, ma non solo: performance, tempi di sviluppo, armonia con altre scelte architetturali, esperienza del team. - In linea con quanto sopra: non tutti i/le dev di un team potrebbero essere in grado di adottare i design pattern nella maniera corretta e, come ogni standard, se non rispettato può portare più problemi che benefici. -- Importante delineare il fatto che spesso i Design Pattern, come altri concetti e best practise del software, siano astrazioni applicative e molti dei concetti rappresentati dai pattern possano essere ritrovati sia a livelli di astrazione più alti (Architettura e addirittura Infrastruttura) o più bassi (Singole righe di codice o singole funzioni). +- Importante delineare il fatto che spesso i Design Pattern, come altri concetti e best practice del software, siano astrazioni applicative e molti dei concetti rappresentati dai pattern possano essere ritrovati sia a livelli di astrazione più alti (architettura e addirittura Infrastruttura) o più bassi (singole righe di codice o singole funzioni). - (Già citato in una frase) Come linea generale eviteremo di listare i design pattern in maniera accademica in quanto il libro sarà un incipit a un futuro approfondimento, ma ci concentreremo sui perché della loro nascita e del loro utilizzo, le principali dinamiche e i principali concetti attorno ad essi, e i pro e i contro generali. - I concetti SOLID sono una parte a se stante di una certa importanza nella programmazione, bisogna capire se parlarne qui o in altre parti per poi farne riferimento. From 54135b10e8d1505003a2ead850851c4ced8cae3b Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Thu, 15 Feb 2024 17:24:33 +0100 Subject: [PATCH 16/59] =?UTF-8?q?Correzione=20sulla=20Facilit=C3=A0=20di?= =?UTF-8?q?=20riuso=20e=20test=20del=20software?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Serena Sensini --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 21fb036a..944c04a5 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -21,7 +21,7 @@ Internet ha molte risorse valide sull'argomento, fra queste possiamo citare: Il libro della Gang of Four identifica un elenco iniziale di design pattern, ognuno dei quali ha un nome che identifica la soluzione al problema generico che andrà a risolvere. Generalmente chi sta sviluppando una certa porzione di codice per implementare una o più funzionalità potrebbe "riconoscere" un design pattern durante l'analisi di un problema specifico che si sta cercando di risolvere e decidere di applicarlo, ottenendo una serie di vantaggi, tra cui: -- **Facilità di riuso e test del software**: Ogni design pattern è stato studiato e catalogato di modo da essere una soluzione pressoché universale ad ogni problema analogo a quello descritto, di conseguenza è possibile riutilizzare una implementazione in più punti del proprio codice. Inoltre, questi pattern sono solitamente accompagnati da suggerimenti e metodologie per il loro testing, il che rende il processo di scrittura dei test automatizzati più semplice ed efficace. +- **Facilità di riuso e test del software**: ogni design pattern è stato studiato e catalogato di modo da essere una soluzione (quasi) universale ad ogni problema analogo a quello descritto; di conseguenza è possibile utilizzare un'implementazione simile in diverse porzioni di codice. All'interno della letteratura, questi pattern sono solitamente accompagnati da suggerimenti e metodologie per eseguire del testing, il che rende il processo di scrittura dei test automatizzati più semplice ed efficace. - **Miglior comprensione del codice**: essendo conosciuti e avendo un nome inequivocabile, è possibile riconoscere i design pattern e creare un linguaggio comune quando si documenta e sviluppa il software. - **Soluzioni provate e testate**: Nascendo dall'esperienza congiunta di più sviluppatori, e avvalorati nel corso degli anni, i design pattern difficilmente nascondono delle sorprese, e la loro adozione può garantire una soluzione _battle-tested_ e dimostrata ad un problema specifico. From 500655b16578416a032773dd4fb3958f39d33ae5 Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Thu, 15 Feb 2024 17:30:04 +0100 Subject: [PATCH 17/59] Correzione di forma Co-authored-by: Serena Sensini --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 944c04a5..4fee07a4 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -123,4 +123,4 @@ Come già detto la Gang of four ha iniziato a definirli e successivamente sulla - In linea con quanto sopra: non tutti i/le dev di un team potrebbero essere in grado di adottare i design pattern nella maniera corretta e, come ogni standard, se non rispettato può portare più problemi che benefici. - Importante delineare il fatto che spesso i Design Pattern, come altri concetti e best practice del software, siano astrazioni applicative e molti dei concetti rappresentati dai pattern possano essere ritrovati sia a livelli di astrazione più alti (architettura e addirittura Infrastruttura) o più bassi (singole righe di codice o singole funzioni). - (Già citato in una frase) Come linea generale eviteremo di listare i design pattern in maniera accademica in quanto il libro sarà un incipit a un futuro approfondimento, ma ci concentreremo sui perché della loro nascita e del loro utilizzo, le principali dinamiche e i principali concetti attorno ad essi, e i pro e i contro generali. -- I concetti SOLID sono una parte a se stante di una certa importanza nella programmazione, bisogna capire se parlarne qui o in altre parti per poi farne riferimento. +- I concetti SOLID sono una parte a sé stante di una certa importanza nella programmazione, bisogna capire se parlarne qui o in altre parti per poi farne riferimento. From 6288a7f7735e988d0cb88dc3c73be48fd848ea66 Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Sun, 10 Mar 2024 21:15:21 +0100 Subject: [PATCH 18/59] Spesso design pattern e programmazione ad oggetti sono strettamente legati Co-authored-by: Serena Sensini --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 4fee07a4..754040d1 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -8,7 +8,7 @@ Questo concetto, derivante da quello similare esistente in architettura, è comp Per capire meglio il concetto possiamo dire che ogni design pattern identifica un problema generalizzato da risolvere e associa ad esso una soluzione; questo generalmente viene rappresentato tramite uno schema UML, di supporto per comprendere meglio quanto proposto. -In generale, design patterns e programmazione ad oggetti sono strettamente legati poiché spesso i primi vengono descritti e spiegati utilizzando di oggetti. +Spesso design pattern e programmazione ad oggetti sono strettamente legati poiché i primi vengono descritti e spiegati utilizzando gli oggetti. Questo non vuol dire che, ad esempio, nella programmazione funzionale non vengano utilizzati, ma naturalmente necessitano di strutture differenti; in alcuni casi, a dire il vero, alcuni Design Patterns sono più facilmente implementabili con quest'ultimo paradigma. Internet ha molte risorse valide sull'argomento, fra queste possiamo citare: From e0cc1b23fb143c8d81c24b2858647453aa8b8d01 Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Sun, 10 Mar 2024 21:20:19 +0100 Subject: [PATCH 19/59] aggiorna frase sulle soluzioni provate e testate Co-authored-by: Serena Sensini --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 754040d1..4e6b8eca 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -23,7 +23,7 @@ Generalmente chi sta sviluppando una certa porzione di codice per implementare u - **Facilità di riuso e test del software**: ogni design pattern è stato studiato e catalogato di modo da essere una soluzione (quasi) universale ad ogni problema analogo a quello descritto; di conseguenza è possibile utilizzare un'implementazione simile in diverse porzioni di codice. All'interno della letteratura, questi pattern sono solitamente accompagnati da suggerimenti e metodologie per eseguire del testing, il che rende il processo di scrittura dei test automatizzati più semplice ed efficace. - **Miglior comprensione del codice**: essendo conosciuti e avendo un nome inequivocabile, è possibile riconoscere i design pattern e creare un linguaggio comune quando si documenta e sviluppa il software. -- **Soluzioni provate e testate**: Nascendo dall'esperienza congiunta di più sviluppatori, e avvalorati nel corso degli anni, i design pattern difficilmente nascondono delle sorprese, e la loro adozione può garantire una soluzione _battle-tested_ e dimostrata ad un problema specifico. +- **Soluzioni provate e testate**: essendo frutto dell'esperienza congiunta di più persone che sviluppano, e avvalorati da diversi casi d'uso nel corso degli anni, i design pattern difficilmente nascondono delle sorprese, e la loro adozione può garantire una soluzione _battle-tested_ e dimostrata rispetto ad un problema specifico. Naturalmente, come ogni cosa nel mondo del software, i design pattern comportano degli svantaggi, tra cui: From 309181c6190a5881db9ee6518e6b93cef0df8f6b Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Sun, 10 Mar 2024 21:27:33 +0100 Subject: [PATCH 20/59] sintesi migliore sulla comprensione dei design pattern Co-authored-by: Serena Sensini --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 4e6b8eca..c42c50f8 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -28,7 +28,7 @@ Generalmente chi sta sviluppando una certa porzione di codice per implementare u Naturalmente, come ogni cosa nel mondo del software, i design pattern comportano degli svantaggi, tra cui: 1. Possono generare parti di codice più complicate. Una porzione di codice intelligibile e senza logiche complesse potrebbe beneficiare dal non utilizzo dei design pattern, che ne complicherebbero la struttura. -2. Per essere applicati alla lettera, i design pattern necessitano che chi li adotti accetti determinate assunzioni, ma è verosimile che chi sviluppa da poco tempo possa non conoscerli e trovarsi in difficoltà nella lettura e analisi del codice. +2. Per essere applicati nel modo migliore, i design pattern necessitano la conoscenza di alcune assunzioni, che però si maturano spesso tramite l'esperienza e la letteratura. 3. Le prestazioni spesso non coincidono con l'adozione di design pattern, in quanto lo scopo di questi ultimi è di risolvere un problema, non necessariamente in maniera ottimizzata. **Come sempre se la domanda è: meglio utilizzarli o no? La risposta è, naturalmente, dipende dal contesto.** From 83649af889bda04fa6792b24c469009a5d8850f2 Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Sun, 10 Mar 2024 21:28:06 +0100 Subject: [PATCH 21/59] meglio utilizzarli o no? Co-authored-by: Serena Sensini --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index c42c50f8..4456f84d 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -31,7 +31,7 @@ Naturalmente, come ogni cosa nel mondo del software, i design pattern comportano 2. Per essere applicati nel modo migliore, i design pattern necessitano la conoscenza di alcune assunzioni, che però si maturano spesso tramite l'esperienza e la letteratura. 3. Le prestazioni spesso non coincidono con l'adozione di design pattern, in quanto lo scopo di questi ultimi è di risolvere un problema, non necessariamente in maniera ottimizzata. -**Come sempre se la domanda è: meglio utilizzarli o no? La risposta è, naturalmente, dipende dal contesto.** +**Come sempre se la domanda è: meglio utilizzarli o no? La risposta è, naturalmente, che dipende dal contesto.** In generale dato un problema non sempre è semplice attribuirgli, se esiste, un design pattern che lo "riconosca"; a volte infatti il limite fra uno o l'altro non è sempre definito quindi si può entrare ad esempio scomponendo il problema più complesso (Divide et impera) in altri più semplici per i quali si potrebbero riconoscere dei pattern specifici.\ A volte invece questa scomposizione non è possibile e, nel caso, si può comunque fare il refactoring scegliendo quello più simile o anche quello più conveniente. From 32a1056eae7aa1230362574cb8bc127141d2815b Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Sun, 10 Mar 2024 21:34:13 +0100 Subject: [PATCH 22/59] =?UTF-8?q?=C3=88=20importante=20sottolineare=20che?= =?UTF-8?q?=20non=20ci=20sono=20dei=20vincoli=20stringenti=20che=20ne=20im?= =?UTF-8?q?pongono=20l'utilizzoUpdate=20docs/it/design-pattern.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Serena Sensini --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 4456f84d..301a2a0b 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -36,7 +36,7 @@ Naturalmente, come ogni cosa nel mondo del software, i design pattern comportano In generale dato un problema non sempre è semplice attribuirgli, se esiste, un design pattern che lo "riconosca"; a volte infatti il limite fra uno o l'altro non è sempre definito quindi si può entrare ad esempio scomponendo il problema più complesso (Divide et impera) in altri più semplici per i quali si potrebbero riconoscere dei pattern specifici.\ A volte invece questa scomposizione non è possibile e, nel caso, si può comunque fare il refactoring scegliendo quello più simile o anche quello più conveniente. -**E' importante sottolineare che non ci sono dei vincoli stringenti che ne impongono l'utilizzo;** \ +**È importante sottolineare che non ci sono dei vincoli stringenti che ne impongono l'utilizzo;** \ E' possibile applicarli oppure no, si possono mescolare a piacere, chiaramente una aderenza maggiore implica la facilità di riconoscerli da parte di altri programmatori che conoscono l'argomento. Generalmente dopo un refactoring, la nostra applicazione sarà più aderente ai [principi di sviluppo software SOLID](https://it.wikipedia.org/wiki/SOLID) il che implica appunto il principalmente il primo dei vantaggi elencati soprattutto il riuso e la facilità di test.\ From 3162d4a0715bdbc1490778336e49436c4f778906 Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Sun, 10 Mar 2024 21:35:00 +0100 Subject: [PATCH 23/59] =?UTF-8?q?=C3=A8=20possibile=20applicarli=20singola?= =?UTF-8?q?rmente,=20oppure=20applicarne=20pi=C3=B9=20di=20uno?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Serena Sensini --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 301a2a0b..0da0abd6 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -37,7 +37,7 @@ In generale dato un problema non sempre è semplice attribuirgli, se esiste, un A volte invece questa scomposizione non è possibile e, nel caso, si può comunque fare il refactoring scegliendo quello più simile o anche quello più conveniente. **È importante sottolineare che non ci sono dei vincoli stringenti che ne impongono l'utilizzo;** \ -E' possibile applicarli oppure no, si possono mescolare a piacere, chiaramente una aderenza maggiore implica la facilità di riconoscerli da parte di altri programmatori che conoscono l'argomento. +è possibile applicarli singolarmente, oppure applicarne più di uno; chiaramente una aderenza maggiore implica la facilità nel riconoscerli da parte di altri/e dev che conoscono l'argomento. Generalmente dopo un refactoring, la nostra applicazione sarà più aderente ai [principi di sviluppo software SOLID](https://it.wikipedia.org/wiki/SOLID) il che implica appunto il principalmente il primo dei vantaggi elencati soprattutto il riuso e la facilità di test.\ Come viene definito nel design pattern possiamo definire il design pattern vero e proprio che ne demarca i suoi confini ed il client che definisce tutta la parte esterna ad esso che vi interagisce.\ From 9b685e41dbf9dd8b05f92174b105538259ef682e Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Sun, 10 Mar 2024 21:36:07 +0100 Subject: [PATCH 24/59] update Principi SOLID Co-authored-by: Serena Sensini --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 0da0abd6..08c35040 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -39,7 +39,7 @@ A volte invece questa scomposizione non è possibile e, nel caso, si può comunq **È importante sottolineare che non ci sono dei vincoli stringenti che ne impongono l'utilizzo;** \ è possibile applicarli singolarmente, oppure applicarne più di uno; chiaramente una aderenza maggiore implica la facilità nel riconoscerli da parte di altri/e dev che conoscono l'argomento. -Generalmente dopo un refactoring, la nostra applicazione sarà più aderente ai [principi di sviluppo software SOLID](https://it.wikipedia.org/wiki/SOLID) il che implica appunto il principalmente il primo dei vantaggi elencati soprattutto il riuso e la facilità di test.\ +Generalmente dopo un refactoring, la nostra applicazione sarà più aderente ai [principi di sviluppo software SOLID](https://it.wikipedia.org/wiki/SOLID) il che implica il riuso e la facilità di test, come accennato in precedenza.\ Come viene definito nel design pattern possiamo definire il design pattern vero e proprio che ne demarca i suoi confini ed il client che definisce tutta la parte esterna ad esso che vi interagisce.\ Il vantaggio principale dell'utilizzo implica che le modifiche apportate tendono a non cambiare sensibilmente il client. From cbf6bfae872f9ce9ff843b6c7e9f0c3620a18e17 Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Sat, 16 Mar 2024 10:53:02 +0100 Subject: [PATCH 25/59] In questo libro li definiremo brevemente evitando di listarli in maniera accademica Co-authored-by: Serena Sensini --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 08c35040..201df22a 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -43,7 +43,7 @@ Generalmente dopo un refactoring, la nostra applicazione sarà più aderente ai Come viene definito nel design pattern possiamo definire il design pattern vero e proprio che ne demarca i suoi confini ed il client che definisce tutta la parte esterna ad esso che vi interagisce.\ Il vantaggio principale dell'utilizzo implica che le modifiche apportate tendono a non cambiare sensibilmente il client. -Nel nostro libro li definiremo brevemente evitando di listarli in maniera accademica; il libro sarà un incipit a un futuro approfondimento, in quanto esistono numerose risorse, come già detto, che ne spiegano i dettagli per cui vi rimandiamo ad esse nel caso vogliate saperne qualcosa di più. +In questo libro li definiremo brevemente evitando di listarli in maniera accademica; questo capitolo sarà infatti un modo per approcciarsi al tema e approfondire successivamente, grazie anche all'esistenza di numerose risorse, che li dettagliano in maniera più puntuale. Oltre al libro sui Design Patterns in questione ne sono stati introdotti altri che vedremo successivamente.\ Il libro della Gang of Four (GOF) suddivide i Design Pattern in 3 categorie: From 9167432e32b63a5064454a956c02b5d88596f627 Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Sat, 16 Mar 2024 10:56:28 +0100 Subject: [PATCH 26/59] Le altre tipologie definite dalla GOF ... Co-authored-by: Serena Sensini --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 201df22a..a1da9637 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -56,7 +56,7 @@ Il libro della Gang of Four (GOF) suddivide i Design Pattern in 3 categorie: I Patterns creazionali definiscono uno schema progettuale che in particolare si concentra sulla creazione degli oggetti che concorrono a risolvere un determinato problema. In questo contesto indichiamo generalmente come prodotti gli oggetti creati utilizzando un oggetto generalmente denominato Factory (fabbrica) che, al suo interno, ne definisce la logica di costruzione che quindi risulta isolata dall'esterno. -Le altre tipologie definite dalla GOF, che sono la strutturale e la comportamentale, si distiguono da questa perché presuppogono già l'esistenza di tutti gli oggetti coinvonti. +Le altre tipologie definite dalla GOF, che sono la strutturale e la comportamentale, si distiguono da questa perché presuppogono già l'esistenza di tutti gli oggetti coinvolti. I pattern creazionali definiti dalla GOF sono: From e357818bf147e7783b48a475a6836263a90f76b5 Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Sat, 16 Mar 2024 10:59:07 +0100 Subject: [PATCH 27/59] Abstract Factory Co-authored-by: Serena Sensini --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index a1da9637..5f1689bc 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -61,7 +61,7 @@ Le altre tipologie definite dalla GOF, che sono la strutturale e la comportament I pattern creazionali definiti dalla GOF sono: - Factory Method : definisce, nella classe Factory, uno o più metodi detti appunto factory methods che creano i nostri oggetti prodotto. -- Abstract Factory : serve a creare famiglie (possibilmente) fisse di oggetti prodotto sempre utilizzando una interfaccia/classe chiamata appunto Abstract factory dove anche gli oggetti prodotto sono generici (anch'essi utilizzano una interfaccia o classe astratta). +- Abstract Factory : serve a creare famiglie (possibilmente) fisse di oggetti "prodotto" sempre utilizzando una interfaccia/classe chiamata appunto Abstract factory dove anche gli oggetti "prodotto" sono generici (anch'essi utilizzano un'interfaccia o classe astratta). - Builder : definisce una particolare classe factory che crea oggetti complessi e viene utilizzato quando gli oggetti sono generalmente composti da altri oggetti creando anch'essi. - Prototype : permette di costruire oggetti clonando oggetti già esistenti. Javascript utilizza proprio il concetto di prototype per estendere gli oggetti (parliamo proprio degli oggetti e non delle classi che sono state introdotte successivamente). - Singleton : permette di costruire un oggetto garantendo che ne esista una sola istanza From 3311775d6fb98289cba25a56acdaaed0cfc61061 Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Sat, 16 Mar 2024 11:31:14 +0100 Subject: [PATCH 28/59] Builder Co-authored-by: Serena Sensini --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 5f1689bc..58e0f0f9 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -62,7 +62,7 @@ I pattern creazionali definiti dalla GOF sono: - Factory Method : definisce, nella classe Factory, uno o più metodi detti appunto factory methods che creano i nostri oggetti prodotto. - Abstract Factory : serve a creare famiglie (possibilmente) fisse di oggetti "prodotto" sempre utilizzando una interfaccia/classe chiamata appunto Abstract factory dove anche gli oggetti "prodotto" sono generici (anch'essi utilizzano un'interfaccia o classe astratta). -- Builder : definisce una particolare classe factory che crea oggetti complessi e viene utilizzato quando gli oggetti sono generalmente composti da altri oggetti creando anch'essi. +- Builder : definisce una particolare classe factory che crea oggetti complessi e viene utilizzata quando gli oggetti sono generalmente composti da altri oggetti creando anch'essi. - Prototype : permette di costruire oggetti clonando oggetti già esistenti. Javascript utilizza proprio il concetto di prototype per estendere gli oggetti (parliamo proprio degli oggetti e non delle classi che sono state introdotte successivamente). - Singleton : permette di costruire un oggetto garantendo che ne esista una sola istanza From e7d10a8775202955d02108bc2556664c13321056 Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Sat, 16 Mar 2024 11:32:17 +0100 Subject: [PATCH 29/59] Prototype Co-authored-by: Serena Sensini --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 58e0f0f9..ce55bbe6 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -63,7 +63,7 @@ I pattern creazionali definiti dalla GOF sono: - Factory Method : definisce, nella classe Factory, uno o più metodi detti appunto factory methods che creano i nostri oggetti prodotto. - Abstract Factory : serve a creare famiglie (possibilmente) fisse di oggetti "prodotto" sempre utilizzando una interfaccia/classe chiamata appunto Abstract factory dove anche gli oggetti "prodotto" sono generici (anch'essi utilizzano un'interfaccia o classe astratta). - Builder : definisce una particolare classe factory che crea oggetti complessi e viene utilizzata quando gli oggetti sono generalmente composti da altri oggetti creando anch'essi. -- Prototype : permette di costruire oggetti clonando oggetti già esistenti. Javascript utilizza proprio il concetto di prototype per estendere gli oggetti (parliamo proprio degli oggetti e non delle classi che sono state introdotte successivamente). +- Prototype : permette di costruire oggetti clonando oggetti già esistenti. Per esempio, Javascript utilizza proprio il concetto di _prototype_ per estendere gli oggetti. Nota a margine: parliamo proprio degli oggetti e non delle classi che sono state introdotte successivamente. - Singleton : permette di costruire un oggetto garantendo che ne esista una sola istanza Come già detto i confini non sono ben definiti per cui, ad esempio, un oggetto complesso potrebbe essere creato tramite un builder e, se una parte dovesse richiedere una clonazione con un successivo raffinamento, sarà necessario utilizzare anche un Prototype che si occupa appunto della parte di clonazione. From 757b221f4513eb3123279eb090a152cf4cd7983b Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Sat, 16 Mar 2024 11:32:43 +0100 Subject: [PATCH 30/59] Singleton Co-authored-by: Serena Sensini --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index ce55bbe6..09139cfa 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -64,7 +64,7 @@ I pattern creazionali definiti dalla GOF sono: - Abstract Factory : serve a creare famiglie (possibilmente) fisse di oggetti "prodotto" sempre utilizzando una interfaccia/classe chiamata appunto Abstract factory dove anche gli oggetti "prodotto" sono generici (anch'essi utilizzano un'interfaccia o classe astratta). - Builder : definisce una particolare classe factory che crea oggetti complessi e viene utilizzata quando gli oggetti sono generalmente composti da altri oggetti creando anch'essi. - Prototype : permette di costruire oggetti clonando oggetti già esistenti. Per esempio, Javascript utilizza proprio il concetto di _prototype_ per estendere gli oggetti. Nota a margine: parliamo proprio degli oggetti e non delle classi che sono state introdotte successivamente. -- Singleton : permette di costruire un oggetto garantendo che ne esista una sola istanza +- Singleton : permette di costruire un oggetto garantendo che ne verrà creata una sola istanza Come già detto i confini non sono ben definiti per cui, ad esempio, un oggetto complesso potrebbe essere creato tramite un builder e, se una parte dovesse richiedere una clonazione con un successivo raffinamento, sarà necessario utilizzare anche un Prototype che si occupa appunto della parte di clonazione. Se non ci fosse la possibilità di effettuare una separazione netta si potrebbe utilizzare il Builder o il Prototype. From 5066b74200b272dde7e20cfc52300e0139a53cc3 Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Sat, 16 Mar 2024 11:33:39 +0100 Subject: [PATCH 31/59] Products and Factories Co-authored-by: Serena Sensini --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 09139cfa..d51a71aa 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -55,7 +55,7 @@ Il libro della Gang of Four (GOF) suddivide i Design Pattern in 3 categorie: ## Patterns creazionali I Patterns creazionali definiscono uno schema progettuale che in particolare si concentra sulla creazione degli oggetti che concorrono a risolvere un determinato problema. -In questo contesto indichiamo generalmente come prodotti gli oggetti creati utilizzando un oggetto generalmente denominato Factory (fabbrica) che, al suo interno, ne definisce la logica di costruzione che quindi risulta isolata dall'esterno. +In questo contesto indichiamo come _prodotti_ gli oggetti creati utilizzando un oggetto generalmente denominato Factory (tradotto in _fabbrica_) che, al suo interno, ne definisce la logica di costruzione, la quale risulta isolata dall'esterno. Le altre tipologie definite dalla GOF, che sono la strutturale e la comportamentale, si distiguono da questa perché presuppogono già l'esistenza di tutti gli oggetti coinvolti. I pattern creazionali definiti dalla GOF sono: From e012542b73e6b86c1e19a2fdea0110c11b9b255c Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Sat, 16 Mar 2024 11:36:56 +0100 Subject: [PATCH 32/59] =?UTF-8?q?In=20generale=20dato=20un=20problema=20no?= =?UTF-8?q?n=20sempre=20=C3=A8=20semplice=20attribuirgli=20un=20design=20p?= =?UTF-8?q?attern=20...?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Serena Sensini --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index d51a71aa..b432ab75 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -33,7 +33,7 @@ Naturalmente, come ogni cosa nel mondo del software, i design pattern comportano **Come sempre se la domanda è: meglio utilizzarli o no? La risposta è, naturalmente, che dipende dal contesto.** -In generale dato un problema non sempre è semplice attribuirgli, se esiste, un design pattern che lo "riconosca"; a volte infatti il limite fra uno o l'altro non è sempre definito quindi si può entrare ad esempio scomponendo il problema più complesso (Divide et impera) in altri più semplici per i quali si potrebbero riconoscere dei pattern specifici.\ +In generale dato un problema non sempre è semplice attribuirgli, se esiste, un design pattern che da applicare; a volte il limite di applicazione tra i diversi pattern è molto sottile. Per questa ragione, è consigliato scomporre un problema complesso in altri più piccoli, utilizzando il concetto del _divide et impera_, dove può essere più semplice individuare dei pattern specifici.\ A volte invece questa scomposizione non è possibile e, nel caso, si può comunque fare il refactoring scegliendo quello più simile o anche quello più conveniente. **È importante sottolineare che non ci sono dei vincoli stringenti che ne impongono l'utilizzo;** \ From 2a4628a9e52f5cdebb82bffde79bcf0477a6c841 Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Sat, 16 Mar 2024 11:40:14 +0100 Subject: [PATCH 33/59] Chain of responsibility Co-authored-by: Serena Sensini --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index b432ab75..868155a7 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -91,7 +91,7 @@ I Patterns strutturali definiscono uno schema progettuale che in particolare ris I pattern comportamentali definiti dalla GOF sono: -- Chain of responsibility: Il pattern permette di separare gli oggetti che invocano richieste, dagli oggetti che le gestiscono. In pratica viene definita una catena di oggetti dove la richiesta viene propagata finchè uno di essi che viene implementato non decide di gestirla. Ogni elemento della catena viene chiamato handler. +- Chain of responsibility: questo pattern permette di separare gli oggetti che invocano richieste dagli oggetti che le gestiscono. In pratica viene definita una catena di oggetti dove la richiesta viene propagata finchè uno di quelli implementati non decide di gestirla. Ogni elemento della catena viene chiamato _handler_. - Command: permette di isolare il codice che esegue una azione più o meno complessa dal client che la esegue oppure prendere una richiesta, memorizzarla in modo che possa essere eseguita in un secondo momento ad esempio dopo un certo evento. - Iterator: permette di visitare tutti gli elementi di una altro oggetto, detto contenitore, senza dipendere dalla struttura interna di esso. Un esempio tipico può essere il cursore per la lettura di una datasource. From a128f06ce46684cbc287a1a85fe30ea93851b1a0 Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Sat, 16 Mar 2024 11:40:41 +0100 Subject: [PATCH 34/59] Adapter Co-authored-by: Serena Sensini --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 868155a7..9bc94d86 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -75,7 +75,7 @@ I Patterns strutturali definiscono uno schema progettuale che in particolare ris I pattern strutturali definiti dalla GOF sono: -- Adapter: Un adapter è un pattern che traduce delle chiamate di una interfaccia alle chiamate di un'altra. Fornisce una soluzione astratta al problema della interoperabilità fra interfacce. Nella vita reale abbiamo ad esempi gli adattatori delle spine. +- Adapter: è un pattern che traduce le chiamate eseguite da una interfaccia in chiamate per la comunicazione con un'altra. Fornisce una soluzione astratta al problema della interoperabilità fra interfacce. Nella vita reale abbiamo ad esempi gli adattatori delle spine. - Bridge: è un design pattern che separa una astrazione dalla sua separazione. Questo avviene separando l'interfaccia dalla sua implementazione potendo ad esempio cambiare facilmente l'implementazione. Un esempio molto utilizzato è il JDBC o in generale i driver dei database. - Decorator: è un pattern che permette di aggiungere funzionalità attraverso il wrapping, cioè incapsulando un oggetto esistente. Di conseguenza il nuovo oggetto potrà avere alcune funzionalità (non è detto tutte) dell'oggetto incapsulato e la nuova funzionalità aggiunta al suo interno. From 53f728339dc5ea6a61d27ef99af4d0273d7e5f68 Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Sat, 16 Mar 2024 11:41:51 +0100 Subject: [PATCH 35/59] Iterator Co-authored-by: Serena Sensini --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 9bc94d86..531c1eac 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -93,7 +93,7 @@ I pattern comportamentali definiti dalla GOF sono: - Chain of responsibility: questo pattern permette di separare gli oggetti che invocano richieste dagli oggetti che le gestiscono. In pratica viene definita una catena di oggetti dove la richiesta viene propagata finchè uno di quelli implementati non decide di gestirla. Ogni elemento della catena viene chiamato _handler_. - Command: permette di isolare il codice che esegue una azione più o meno complessa dal client che la esegue oppure prendere una richiesta, memorizzarla in modo che possa essere eseguita in un secondo momento ad esempio dopo un certo evento. -- Iterator: permette di visitare tutti gli elementi di una altro oggetto, detto contenitore, senza dipendere dalla struttura interna di esso. +- Iterator: permette di visitare tutti gli elementi di un altro oggetto, detto contenitore, senza dipendere dalla struttura interna di esso. Un esempio tipico può essere il cursore per la lettura di una datasource. - Mediator: incapsula l'interazione fra i vari oggetti di un loro insieme facendo in modo che la comunicazione col client venga gestita sempre da una unica entità favorendo il disaccoppiamento fra gli oggetti stessi. - Memento: si occupa di memorizzare lo stato corrente di un altro oggetto detto Originator cercando di non violare l'incapsulamento. Può essere utile nei casi in cui si possa avere uno storico dell'oggetto stesso richiedendo al Memento il ripristino di uno stato precedente. (Il cosiddetto Undo/Redo) From 03e6c626130b412d90e33db307f8d2052957bba6 Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Sat, 16 Mar 2024 11:46:09 +0100 Subject: [PATCH 36/59] Come visibile compare una struttura davanti al nostro client ... Co-authored-by: Serena Sensini --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 531c1eac..7100df33 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -83,7 +83,7 @@ I pattern strutturali definiti dalla GOF sono: - Flyweight: permette di suddividere un oggetto che ha alcuni dei membri ripetibili in 2 parti una con parti che non si ripetono ed un gruppo di membri che insieme tendono a ripetersi. Questo meccanismo tende a limitare (e ottimizzare) l'occupazione di memoria questo perché ogni parte ripetuta viene memorizzata una sola volta. - Proxy: si interpone ad un oggetto (di solito di servizio) e interagisce con esso utilizzando la stessa intefaccia. Un esempio sono i Proxy server che possono mandare il messaggio richiesto verso i server web veri e propri impedendo ad esempio l'accesso ad alcuni potenzialmente pericolosi. -come si vede in ognuno di essi compare una struttura davanti al nostro client che può variare in ogni design pattern. Ad esempio nell'adapter la struttura cambia l'interfaccia (in quanto struttura della classe), nel Bridge cambia l'implementazione, nel Facade cambia ancora l'interfaccia che risulta più semplice +Come visibile (dove?), compare una struttura davanti al nostro client che può variare in ogni design pattern. Ad esempio, nell'adapter la struttura cambia l'interfaccia (in quanto struttura della classe), nel Bridge cambia l'implementazione, nel Facade cambia ancora l'interfaccia che risulta più semplice. ## Patterns comportamentali From 144f3665b1aaee08a2ce017a6ecb6217ce536cb3 Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Sat, 16 Mar 2024 11:47:42 +0100 Subject: [PATCH 37/59] Model-View-Controller Co-authored-by: Serena Sensini --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 7100df33..52212ea3 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -109,7 +109,7 @@ Come già detto la Gang of four ha iniziato a definirli e successivamente sulla - Client/Server: è un pattern cosiddetto architetturale poichè può essere ad esempio l'architettura del prodotto che si vuole sviluppare. Esistono due "componenti" il client che effettua richieste ed il server che le riceve e risponde ad uno o più client.\ Esempio classico sono quasi tutti i server di database che ad ogni richiesta, ad esempio di esecuzione di una query, rispondono con i risultati. -- Model-View-Controller: è un pattern dove definiamo due entità separate il model che è la nostra entità che vogliamo rappresentare e contiene i suoi dati, il view che dice come mostrarla all'utente esterno e ne permette l'interazione; infine il Controller che effettua le interazioni fra i due. +- Model-View-Controller: è un pattern dove definiamo due entità separate, una per il considdetto _model_, ossia l'entità che vogliamo rappresentare e che contiene i suoi dati, contestualmente al View, che definisce come mostrarla all'utente esterno e ne permette l'interazione; infine esiste il Controller che serve a descrivere le interazioni fra i due. - Dependency Injection: è un pattern che permette di iniettare una dipendenza in una classe attraverso l'Inversion of control. Questo viene fatto iniettando un'interfaccia o una classe astratta in modo da poter cambiare la sua implementazione in qualsiasi momento.\ Abbiamo 3 tipi di iniezioni: From 4549c22a8d3051ed25fcd6021be9fe3815454526 Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Tue, 26 Mar 2024 17:39:58 +0100 Subject: [PATCH 38/59] meglio utilizzare i pattern o no Co-authored-by: Michael Di Prisco --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 52212ea3..1277b0e8 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -31,7 +31,7 @@ Naturalmente, come ogni cosa nel mondo del software, i design pattern comportano 2. Per essere applicati nel modo migliore, i design pattern necessitano la conoscenza di alcune assunzioni, che però si maturano spesso tramite l'esperienza e la letteratura. 3. Le prestazioni spesso non coincidono con l'adozione di design pattern, in quanto lo scopo di questi ultimi è di risolvere un problema, non necessariamente in maniera ottimizzata. -**Come sempre se la domanda è: meglio utilizzarli o no? La risposta è, naturalmente, che dipende dal contesto.** +**Come sempre, alla domanda se sia meglio utilizzarli o no, risponderemo con un cauto: _dipende_.** In generale dato un problema non sempre è semplice attribuirgli, se esiste, un design pattern che da applicare; a volte il limite di applicazione tra i diversi pattern è molto sottile. Per questa ragione, è consigliato scomporre un problema complesso in altri più piccoli, utilizzando il concetto del _divide et impera_, dove può essere più semplice individuare dei pattern specifici.\ A volte invece questa scomposizione non è possibile e, nel caso, si può comunque fare il refactoring scegliendo quello più simile o anche quello più conveniente. From 64c716c99523386c298a702f923157a4b8d6f0cd Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Tue, 26 Mar 2024 17:41:59 +0100 Subject: [PATCH 39/59] scomposizione problemi Co-authored-by: Michael Di Prisco --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 1277b0e8..2e57bbf2 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -33,7 +33,7 @@ Naturalmente, come ogni cosa nel mondo del software, i design pattern comportano **Come sempre, alla domanda se sia meglio utilizzarli o no, risponderemo con un cauto: _dipende_.** -In generale dato un problema non sempre è semplice attribuirgli, se esiste, un design pattern che da applicare; a volte il limite di applicazione tra i diversi pattern è molto sottile. Per questa ragione, è consigliato scomporre un problema complesso in altri più piccoli, utilizzando il concetto del _divide et impera_, dove può essere più semplice individuare dei pattern specifici.\ +In generale, non è sempre facile attribuire ad un problema esistente un dato design pattern e applicarlo; a volte la soglia tra l'applicazione di un pattern e un altro può essere molto sottile. Per questa ragione, è consigliato scomporre un problema complesso in altri più piccoli, utilizzando la metodologia nota come _divide et impera_, che rende più semplice individuare dei pattern specifici per i singoli problemi scomposti. A volte invece questa scomposizione non è possibile e, nel caso, si può comunque fare il refactoring scegliendo quello più simile o anche quello più conveniente. **È importante sottolineare che non ci sono dei vincoli stringenti che ne impongono l'utilizzo;** \ From e724574bb27b1a1dadfa30ffb8e53d49b85bdf6b Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Tue, 26 Mar 2024 17:42:26 +0100 Subject: [PATCH 40/59] Pattern comportamentali Co-authored-by: Michael Di Prisco --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 2e57bbf2..a867ff2c 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -87,7 +87,7 @@ Come visibile (dove?), compare una struttura davanti al nostro client che può v ## Patterns comportamentali -I Patterns strutturali definiscono uno schema progettuale che in particolare risolve problematiche di comportamento degli oggetti definiti nel pattern. Generalmente questo comportamento si riflette in particolare sugli algoritmi e sulle responsabilità degli oggetti stessi. +I Pattern comportamentali definiscono uno schema progettuale che in particolare risolve problematiche di comportamento degli oggetti definiti nel pattern. Generalmente questo comportamento si riflette in particolare sugli algoritmi e sulle responsabilità degli oggetti stessi. I pattern comportamentali definiti dalla GOF sono: From d5c61a51deaf67c9b838fad32cb93fbc036cc8f7 Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Tue, 26 Mar 2024 17:43:38 +0100 Subject: [PATCH 41/59] Proxy ed esempi Co-authored-by: Michael Di Prisco --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index a867ff2c..1f84c11f 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -81,7 +81,7 @@ I pattern strutturali definiti dalla GOF sono: Di conseguenza il nuovo oggetto potrà avere alcune funzionalità (non è detto tutte) dell'oggetto incapsulato e la nuova funzionalità aggiunta al suo interno. - Façade: è un modo per semplificare un insieme di sottosistemi che formano un sistema complesso. Tramite questa semplificazione fornita attraverso una o più classi (poche) cosiddetta di facciata è possibile utilizzare le funzionalità più utili. - Flyweight: permette di suddividere un oggetto che ha alcuni dei membri ripetibili in 2 parti una con parti che non si ripetono ed un gruppo di membri che insieme tendono a ripetersi. Questo meccanismo tende a limitare (e ottimizzare) l'occupazione di memoria questo perché ogni parte ripetuta viene memorizzata una sola volta. -- Proxy: si interpone ad un oggetto (di solito di servizio) e interagisce con esso utilizzando la stessa intefaccia. Un esempio sono i Proxy server che possono mandare il messaggio richiesto verso i server web veri e propri impedendo ad esempio l'accesso ad alcuni potenzialmente pericolosi. +- Proxy: si interpone tra un oggetto (di solito di servizio) e il mondo esterno con cui comunica, utilizzando la stessa interfaccia, ma alterandone il comportamento. Un esempio sono i Proxy server che agiscono da intermezzo tra la propria macchina e il web, alterando e verificando ogni chiamata in ingresso e in uscita da essi, garantendo anonimato e un buon grado di sicurezza. Come visibile (dove?), compare una struttura davanti al nostro client che può variare in ogni design pattern. Ad esempio, nell'adapter la struttura cambia l'interfaccia (in quanto struttura della classe), nel Bridge cambia l'implementazione, nel Facade cambia ancora l'interfaccia che risulta più semplice. From c3c102006ae9b9ab6736cfb10f37b678f783894f Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Tue, 26 Mar 2024 17:44:48 +0100 Subject: [PATCH 42/59] Flyweight ed esempi Co-authored-by: Michael Di Prisco --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 1f84c11f..832dbf07 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -80,7 +80,7 @@ I pattern strutturali definiti dalla GOF sono: - Decorator: è un pattern che permette di aggiungere funzionalità attraverso il wrapping, cioè incapsulando un oggetto esistente. Di conseguenza il nuovo oggetto potrà avere alcune funzionalità (non è detto tutte) dell'oggetto incapsulato e la nuova funzionalità aggiunta al suo interno. - Façade: è un modo per semplificare un insieme di sottosistemi che formano un sistema complesso. Tramite questa semplificazione fornita attraverso una o più classi (poche) cosiddetta di facciata è possibile utilizzare le funzionalità più utili. -- Flyweight: permette di suddividere un oggetto che ha alcuni dei membri ripetibili in 2 parti una con parti che non si ripetono ed un gruppo di membri che insieme tendono a ripetersi. Questo meccanismo tende a limitare (e ottimizzare) l'occupazione di memoria questo perché ogni parte ripetuta viene memorizzata una sola volta. +- Flyweight: è un pattern che permette di ottimizzare l'utilizzo della memoria di un sistema tramite il riutilizzo di membri comuni tra molti oggetti, senza doverne istanziare costantemente di nuovi. Ad esempio, se ho la necessità di realizzare 1.000 oggetti della classe _Dog_ che, tramite un metodo _Move_, modificano la propria posizione, è molto più sensato separare la classe _Dog_ in due classi, _Dog_ e _MovingDog_, collezionando nella prima le informazioni _statiche_, come razza e nome, mentre nella seconda le informazioni di _stato_ o _dinamiche_, come la posizione. - Proxy: si interpone tra un oggetto (di solito di servizio) e il mondo esterno con cui comunica, utilizzando la stessa interfaccia, ma alterandone il comportamento. Un esempio sono i Proxy server che agiscono da intermezzo tra la propria macchina e il web, alterando e verificando ogni chiamata in ingresso e in uscita da essi, garantendo anonimato e un buon grado di sicurezza. Come visibile (dove?), compare una struttura davanti al nostro client che può variare in ogni design pattern. Ad esempio, nell'adapter la struttura cambia l'interfaccia (in quanto struttura della classe), nel Bridge cambia l'implementazione, nel Facade cambia ancora l'interfaccia che risulta più semplice. From 79157ec4e47494b0b85c2e2ec4a8a65fbad9b2a6 Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Tue, 26 Mar 2024 17:45:18 +0100 Subject: [PATCH 43/59] =?UTF-8?q?Fa=C3=A7ade?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Michael Di Prisco --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 832dbf07..88fe3b60 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -79,7 +79,7 @@ I pattern strutturali definiti dalla GOF sono: - Bridge: è un design pattern che separa una astrazione dalla sua separazione. Questo avviene separando l'interfaccia dalla sua implementazione potendo ad esempio cambiare facilmente l'implementazione. Un esempio molto utilizzato è il JDBC o in generale i driver dei database. - Decorator: è un pattern che permette di aggiungere funzionalità attraverso il wrapping, cioè incapsulando un oggetto esistente. Di conseguenza il nuovo oggetto potrà avere alcune funzionalità (non è detto tutte) dell'oggetto incapsulato e la nuova funzionalità aggiunta al suo interno. -- Façade: è un modo per semplificare un insieme di sottosistemi che formano un sistema complesso. Tramite questa semplificazione fornita attraverso una o più classi (poche) cosiddetta di facciata è possibile utilizzare le funzionalità più utili. +- Façade: è un pattern che permette la semplificazione di un insieme complesso di classi o parti di un sistema, tramite la creazione di classi _di facciata_ che espongano solo le funzionalità più utili. - Flyweight: è un pattern che permette di ottimizzare l'utilizzo della memoria di un sistema tramite il riutilizzo di membri comuni tra molti oggetti, senza doverne istanziare costantemente di nuovi. Ad esempio, se ho la necessità di realizzare 1.000 oggetti della classe _Dog_ che, tramite un metodo _Move_, modificano la propria posizione, è molto più sensato separare la classe _Dog_ in due classi, _Dog_ e _MovingDog_, collezionando nella prima le informazioni _statiche_, come razza e nome, mentre nella seconda le informazioni di _stato_ o _dinamiche_, come la posizione. - Proxy: si interpone tra un oggetto (di solito di servizio) e il mondo esterno con cui comunica, utilizzando la stessa interfaccia, ma alterandone il comportamento. Un esempio sono i Proxy server che agiscono da intermezzo tra la propria macchina e il web, alterando e verificando ogni chiamata in ingresso e in uscita da essi, garantendo anonimato e un buon grado di sicurezza. From bc98a90babd5bd07aa28c1decc7918ccba6aa51f Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Tue, 26 Mar 2024 17:45:49 +0100 Subject: [PATCH 44/59] Decorator Co-authored-by: Michael Di Prisco --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 88fe3b60..4dcdc4fc 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -78,7 +78,7 @@ I pattern strutturali definiti dalla GOF sono: - Adapter: è un pattern che traduce le chiamate eseguite da una interfaccia in chiamate per la comunicazione con un'altra. Fornisce una soluzione astratta al problema della interoperabilità fra interfacce. Nella vita reale abbiamo ad esempi gli adattatori delle spine. - Bridge: è un design pattern che separa una astrazione dalla sua separazione. Questo avviene separando l'interfaccia dalla sua implementazione potendo ad esempio cambiare facilmente l'implementazione. Un esempio molto utilizzato è il JDBC o in generale i driver dei database. - Decorator: è un pattern che permette di aggiungere funzionalità attraverso il wrapping, cioè incapsulando un oggetto esistente. - Di conseguenza il nuovo oggetto potrà avere alcune funzionalità (non è detto tutte) dell'oggetto incapsulato e la nuova funzionalità aggiunta al suo interno. + Di conseguenza il nuovo oggetto avrà sia le funzionalità dell'oggetto originale che le nuove funzionalità aggiunte tramite decoratore. - Façade: è un pattern che permette la semplificazione di un insieme complesso di classi o parti di un sistema, tramite la creazione di classi _di facciata_ che espongano solo le funzionalità più utili. - Flyweight: è un pattern che permette di ottimizzare l'utilizzo della memoria di un sistema tramite il riutilizzo di membri comuni tra molti oggetti, senza doverne istanziare costantemente di nuovi. Ad esempio, se ho la necessità di realizzare 1.000 oggetti della classe _Dog_ che, tramite un metodo _Move_, modificano la propria posizione, è molto più sensato separare la classe _Dog_ in due classi, _Dog_ e _MovingDog_, collezionando nella prima le informazioni _statiche_, come razza e nome, mentre nella seconda le informazioni di _stato_ o _dinamiche_, come la posizione. - Proxy: si interpone tra un oggetto (di solito di servizio) e il mondo esterno con cui comunica, utilizzando la stessa interfaccia, ma alterandone il comportamento. Un esempio sono i Proxy server che agiscono da intermezzo tra la propria macchina e il web, alterando e verificando ogni chiamata in ingresso e in uscita da essi, garantendo anonimato e un buon grado di sicurezza. From 51f06c7fa69f711d16077eab947726d472b6c5db Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Tue, 26 Mar 2024 17:48:11 +0100 Subject: [PATCH 45/59] Pattern strutturali Co-authored-by: Michael Di Prisco --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 4dcdc4fc..de75c099 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -71,7 +71,7 @@ Se non ci fosse la possibilità di effettuare una separazione netta si potrebbe ## Patterns strutturali -I Patterns strutturali definiscono uno schema progettuale che in particolare risolvono problematiche inerenti alla struttura degli oggetti in modo che la soluzione sia flessibile ed efficiente; capiremo meglio questo concetto andando a vedere brevemente tutti i design pattern appartenenti a questa categoria. +I Pattern strutturali definiscono uno schema progettuale atto a risolvere problematiche inerenti alla struttura degli oggetti, di modo da renderli flessibili ed efficienti; capiremo meglio questo concetto andando a vedere brevemente tutti i design pattern appartenenti a questa categoria. I pattern strutturali definiti dalla GOF sono: From fd7fda283f8fdaba964b57cdedfa9a7b7e63c8ed Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Tue, 26 Mar 2024 17:48:57 +0100 Subject: [PATCH 46/59] Esempio generico di costruzione oggetto Co-authored-by: Michael Di Prisco --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index de75c099..19a69a84 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -66,7 +66,7 @@ I pattern creazionali definiti dalla GOF sono: - Prototype : permette di costruire oggetti clonando oggetti già esistenti. Per esempio, Javascript utilizza proprio il concetto di _prototype_ per estendere gli oggetti. Nota a margine: parliamo proprio degli oggetti e non delle classi che sono state introdotte successivamente. - Singleton : permette di costruire un oggetto garantendo che ne verrà creata una sola istanza -Come già detto i confini non sono ben definiti per cui, ad esempio, un oggetto complesso potrebbe essere creato tramite un builder e, se una parte dovesse richiedere una clonazione con un successivo raffinamento, sarà necessario utilizzare anche un Prototype che si occupa appunto della parte di clonazione. +Come già detto i confini non sono ben definiti per cui, ad esempio, un oggetto complesso potrebbe essere creato tramite un builder e, se una parte dovesse richiedere una clonazione con un successivo raffinamento, sarà necessario utilizzare anche un Prototype che si occuperà della parte di clonazione. Se non ci fosse la possibilità di effettuare una separazione netta si potrebbe utilizzare il Builder o il Prototype. ## Patterns strutturali From 57346067224eef02d86e379b040a2d7e17ab8abc Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Tue, 26 Mar 2024 17:49:47 +0100 Subject: [PATCH 47/59] Builder Co-authored-by: Michael Di Prisco --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 19a69a84..89a26f88 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -62,7 +62,7 @@ I pattern creazionali definiti dalla GOF sono: - Factory Method : definisce, nella classe Factory, uno o più metodi detti appunto factory methods che creano i nostri oggetti prodotto. - Abstract Factory : serve a creare famiglie (possibilmente) fisse di oggetti "prodotto" sempre utilizzando una interfaccia/classe chiamata appunto Abstract factory dove anche gli oggetti "prodotto" sono generici (anch'essi utilizzano un'interfaccia o classe astratta). -- Builder : definisce una particolare classe factory che crea oggetti complessi e viene utilizzata quando gli oggetti sono generalmente composti da altri oggetti creando anch'essi. +- Builder : definisce una particolare classe factory che consente di costruire oggetti complessi step-by-step. È quindi possibile produrre diverse tipologie e rappresentazioni di un oggetto componendolo in base alle proprie necessità. - Prototype : permette di costruire oggetti clonando oggetti già esistenti. Per esempio, Javascript utilizza proprio il concetto di _prototype_ per estendere gli oggetti. Nota a margine: parliamo proprio degli oggetti e non delle classi che sono state introdotte successivamente. - Singleton : permette di costruire un oggetto garantendo che ne verrà creata una sola istanza From 2c21e2dbb38e3ee18ae67d02c53d474e2141094a Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Tue, 26 Mar 2024 17:50:05 +0100 Subject: [PATCH 48/59] Prototype Co-authored-by: Michael Di Prisco --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 89a26f88..15d9dd55 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -63,7 +63,7 @@ I pattern creazionali definiti dalla GOF sono: - Factory Method : definisce, nella classe Factory, uno o più metodi detti appunto factory methods che creano i nostri oggetti prodotto. - Abstract Factory : serve a creare famiglie (possibilmente) fisse di oggetti "prodotto" sempre utilizzando una interfaccia/classe chiamata appunto Abstract factory dove anche gli oggetti "prodotto" sono generici (anch'essi utilizzano un'interfaccia o classe astratta). - Builder : definisce una particolare classe factory che consente di costruire oggetti complessi step-by-step. È quindi possibile produrre diverse tipologie e rappresentazioni di un oggetto componendolo in base alle proprie necessità. -- Prototype : permette di costruire oggetti clonando oggetti già esistenti. Per esempio, Javascript utilizza proprio il concetto di _prototype_ per estendere gli oggetti. Nota a margine: parliamo proprio degli oggetti e non delle classi che sono state introdotte successivamente. +- Prototype : permette di costruire oggetti clonando oggetti già esistenti. Per esempio, JavaScript utilizza proprio il concetto di _prototype_ per estendere gli oggetti. Nota a margine: parliamo proprio degli oggetti e non delle classi che sono state introdotte successivamente. - Singleton : permette di costruire un oggetto garantendo che ne verrà creata una sola istanza Come già detto i confini non sono ben definiti per cui, ad esempio, un oggetto complesso potrebbe essere creato tramite un builder e, se una parte dovesse richiedere una clonazione con un successivo raffinamento, sarà necessario utilizzare anche un Prototype che si occuperà della parte di clonazione. From 7ee5a44f31cdf46271aab3b5bc47e5931a606a5d Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Sun, 7 Apr 2024 20:53:52 +0200 Subject: [PATCH 49/59] =?UTF-8?q?Pu=C3=B2=20portare=20ad=20aumentare=20la?= =?UTF-8?q?=20complessit=C3=A0=20del=20codice=20...?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Serena Sensini --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 15d9dd55..203f885f 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -27,7 +27,7 @@ Generalmente chi sta sviluppando una certa porzione di codice per implementare u Naturalmente, come ogni cosa nel mondo del software, i design pattern comportano degli svantaggi, tra cui: -1. Possono generare parti di codice più complicate. Una porzione di codice intelligibile e senza logiche complesse potrebbe beneficiare dal non utilizzo dei design pattern, che ne complicherebbero la struttura. +1. Può portare ad aumentare la complessità del codice, per cui andrebbero utilizzati con parsimonia per non creare sovrastrutture non necessarie. 2. Per essere applicati nel modo migliore, i design pattern necessitano la conoscenza di alcune assunzioni, che però si maturano spesso tramite l'esperienza e la letteratura. 3. Le prestazioni spesso non coincidono con l'adozione di design pattern, in quanto lo scopo di questi ultimi è di risolvere un problema, non necessariamente in maniera ottimizzata. From 5640cff38260660da7d8de07a1cd6dbcdfab8e9c Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Tue, 25 Jun 2024 21:30:41 +0200 Subject: [PATCH 50/59] Apply suggestions from code review Co-authored-by: Serena Sensini --- docs/it/design-pattern.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 203f885f..c97edae1 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -19,7 +19,7 @@ Internet ha molte risorse valide sull'argomento, fra queste possiamo citare: - [Design Patterns su Wikipedia Inglese](https://en.wikipedia.org/wiki/Design_pattern) Il libro della Gang of Four identifica un elenco iniziale di design pattern, ognuno dei quali ha un nome che identifica la soluzione al problema generico che andrà a risolvere. -Generalmente chi sta sviluppando una certa porzione di codice per implementare una o più funzionalità potrebbe "riconoscere" un design pattern durante l'analisi di un problema specifico che si sta cercando di risolvere e decidere di applicarlo, ottenendo una serie di vantaggi, tra cui: +Durante lo sviluppo, può essere semplice individuare e applicare un design pattern mentre si analizza un problema specifico, ottenendo una serie di vantaggi, tra cui: - **Facilità di riuso e test del software**: ogni design pattern è stato studiato e catalogato di modo da essere una soluzione (quasi) universale ad ogni problema analogo a quello descritto; di conseguenza è possibile utilizzare un'implementazione simile in diverse porzioni di codice. All'interno della letteratura, questi pattern sono solitamente accompagnati da suggerimenti e metodologie per eseguire del testing, il che rende il processo di scrittura dei test automatizzati più semplice ed efficace. - **Miglior comprensione del codice**: essendo conosciuti e avendo un nome inequivocabile, è possibile riconoscere i design pattern e creare un linguaggio comune quando si documenta e sviluppa il software. @@ -34,9 +34,8 @@ Naturalmente, come ogni cosa nel mondo del software, i design pattern comportano **Come sempre, alla domanda se sia meglio utilizzarli o no, risponderemo con un cauto: _dipende_.** In generale, non è sempre facile attribuire ad un problema esistente un dato design pattern e applicarlo; a volte la soglia tra l'applicazione di un pattern e un altro può essere molto sottile. Per questa ragione, è consigliato scomporre un problema complesso in altri più piccoli, utilizzando la metodologia nota come _divide et impera_, che rende più semplice individuare dei pattern specifici per i singoli problemi scomposti. -A volte invece questa scomposizione non è possibile e, nel caso, si può comunque fare il refactoring scegliendo quello più simile o anche quello più conveniente. +Non sempre, però, è possibile scomporre in questo modo un problema, e alle volte bisogna arrendersi alla impossibilità di applicare uno specifico pattern, adottando invece il puro buon senso e arrivando alla soluzione con gli strumenti che si hanno a disposizione. -**È importante sottolineare che non ci sono dei vincoli stringenti che ne impongono l'utilizzo;** \ è possibile applicarli singolarmente, oppure applicarne più di uno; chiaramente una aderenza maggiore implica la facilità nel riconoscerli da parte di altri/e dev che conoscono l'argomento. Generalmente dopo un refactoring, la nostra applicazione sarà più aderente ai [principi di sviluppo software SOLID](https://it.wikipedia.org/wiki/SOLID) il che implica il riuso e la facilità di test, come accennato in precedenza.\ @@ -75,8 +74,8 @@ I Pattern strutturali definiscono uno schema progettuale atto a risolvere proble I pattern strutturali definiti dalla GOF sono: -- Adapter: è un pattern che traduce le chiamate eseguite da una interfaccia in chiamate per la comunicazione con un'altra. Fornisce una soluzione astratta al problema della interoperabilità fra interfacce. Nella vita reale abbiamo ad esempi gli adattatori delle spine. -- Bridge: è un design pattern che separa una astrazione dalla sua separazione. Questo avviene separando l'interfaccia dalla sua implementazione potendo ad esempio cambiare facilmente l'implementazione. Un esempio molto utilizzato è il JDBC o in generale i driver dei database. +- Adapter: è un pattern che permette di interporre tra due interfacce che devono comunicare tra loro un _adattatore_, che traduce le chiamate in entrambe le direzioni nella maniera che ognuna di essere si aspetta. Fornisce una soluzione astratta al problema della interoperabilità fra interfacce. Nella vita reale abbiamo ad esempi gli adattatori delle spine. +- Bridge: è un design pattern strutturale che consente di dividere una classe di grandi dimensioni o un insieme di classi strettamente correlate in entità separate, astrazione e implementazione, che possono essere sviluppate indipendentemente l'una dall'altra. Solitamente questo pattern, per via del modo in cui è implementato, viene chiamato anche _composition-over-inheritance_. - Decorator: è un pattern che permette di aggiungere funzionalità attraverso il wrapping, cioè incapsulando un oggetto esistente. Di conseguenza il nuovo oggetto avrà sia le funzionalità dell'oggetto originale che le nuove funzionalità aggiunte tramite decoratore. - Façade: è un pattern che permette la semplificazione di un insieme complesso di classi o parti di un sistema, tramite la creazione di classi _di facciata_ che espongano solo le funzionalità più utili. From 15b0649597f154f6a81c0c35750db07fb66ffc2f Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Tue, 25 Jun 2024 21:31:13 +0200 Subject: [PATCH 51/59] Apply suggestions from code review Co-authored-by: Serena Sensini --- docs/it/design-pattern.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index c97edae1..ddf32f3c 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -96,15 +96,15 @@ I pattern comportamentali definiti dalla GOF sono: Un esempio tipico può essere il cursore per la lettura di una datasource. - Mediator: incapsula l'interazione fra i vari oggetti di un loro insieme facendo in modo che la comunicazione col client venga gestita sempre da una unica entità favorendo il disaccoppiamento fra gli oggetti stessi. - Memento: si occupa di memorizzare lo stato corrente di un altro oggetto detto Originator cercando di non violare l'incapsulamento. Può essere utile nei casi in cui si possa avere uno storico dell'oggetto stesso richiedendo al Memento il ripristino di uno stato precedente. (Il cosiddetto Undo/Redo) -- Observer: è una struttura formata da un Observer che osserva un cambiamento di stato di un Soggetto che possiamo definire Observable (Osservabile o Osservato) che fa appunto accadere quando lo stato all'interno di esso cambia. Esistono Librerie con RxJS si basano principalmente su questo pattern. Quando l'Observable cambia stato tutti gli Observer registrati ricevono l'informazione del cambiamento. +- Observer: è una struttura formata da un Observer che osserva un cambiamento di stato di un Subject (o Soggetto) che possiamo definire Observable (Osservabile o Osservato) che fa appunto accadere quando lo stato all'interno di esso cambia. Esistono Librerie con RxJS si basano principalmente su questo pattern. Quando l'Observable cambia stato tutti gli Observer registrati ricevono l'informazione del cambiamento. - State: è di fatto riconducibile ad un diagramma a stati finiti; consente ad un oggetto di modificare il proprio comportamento al cambiamento (ed in base) al suo stato interno. - Strategy: permette di scegliere più comportamenti di un algoritmo (generalmente una variante di esso) a runtime associandolo (incapsulandolo) in una singola classe che lo implementa -- Template method: E' generalmente un metodo che implementa lo scheletro di un algorirmo e al suo interno possono essere chiamate parti (generalmente step) utilizzando la sovrascrittura dei passi senza dover cambiare la struttura del client chiamante. +- Template method: è generalmente un metodo che implementa lo scheletro di un algorirmo e al suo interno possono essere chiamate parti (generalmente step) utilizzando la sovrascrittura dei passi senza dover cambiare la struttura del client chiamante. - Visitor: in esso si separa una struttura dati dalla logica di attraversamento (visita) dell'algoritmo di visita e quindi dalle operazioni fatte su di essa. Gli algoritmi di visita possono cambiare senza cambiare la struttura del client. ## Altri pattern -Come già detto la Gang of four ha iniziato a definirli e successivamente sulla loro falsa riga ne sono stati individuati altri che descriveremo brevemente di seguito. +Come già detto la Gang of Four ha iniziato a definirli e successivamente sulla loro falsa riga ne sono stati individuati altri che descriveremo brevemente di seguito. - Client/Server: è un pattern cosiddetto architetturale poichè può essere ad esempio l'architettura del prodotto che si vuole sviluppare. Esistono due "componenti" il client che effettua richieste ed il server che le riceve e risponde ad uno o più client.\ Esempio classico sono quasi tutti i server di database che ad ogni richiesta, ad esempio di esecuzione di una query, rispondono con i risultati. From ae547b37b9e53ceb509f5f95dda55fc9fad3099d Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Tue, 25 Jun 2024 21:32:19 +0200 Subject: [PATCH 52/59] Apply suggestions from code review --- docs/it/design-pattern.md | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index ddf32f3c..c2919572 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -82,7 +82,6 @@ I pattern strutturali definiti dalla GOF sono: - Flyweight: è un pattern che permette di ottimizzare l'utilizzo della memoria di un sistema tramite il riutilizzo di membri comuni tra molti oggetti, senza doverne istanziare costantemente di nuovi. Ad esempio, se ho la necessità di realizzare 1.000 oggetti della classe _Dog_ che, tramite un metodo _Move_, modificano la propria posizione, è molto più sensato separare la classe _Dog_ in due classi, _Dog_ e _MovingDog_, collezionando nella prima le informazioni _statiche_, come razza e nome, mentre nella seconda le informazioni di _stato_ o _dinamiche_, come la posizione. - Proxy: si interpone tra un oggetto (di solito di servizio) e il mondo esterno con cui comunica, utilizzando la stessa interfaccia, ma alterandone il comportamento. Un esempio sono i Proxy server che agiscono da intermezzo tra la propria macchina e il web, alterando e verificando ogni chiamata in ingresso e in uscita da essi, garantendo anonimato e un buon grado di sicurezza. -Come visibile (dove?), compare una struttura davanti al nostro client che può variare in ogni design pattern. Ad esempio, nell'adapter la struttura cambia l'interfaccia (in quanto struttura della classe), nel Bridge cambia l'implementazione, nel Facade cambia ancora l'interfaccia che risulta più semplice. ## Patterns comportamentali From 06d7b0a72eba99a091a39ec543a2981d071840c9 Mon Sep 17 00:00:00 2001 From: Livio74 Date: Sat, 24 Aug 2024 18:34:11 +0200 Subject: [PATCH 53/59] eliminata frase come concordato con Serena e Michael --- docs/it/design-pattern.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index c2919572..8507ba19 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -39,8 +39,6 @@ Non sempre, però, è possibile scomporre in questo modo un problema, e alle vol è possibile applicarli singolarmente, oppure applicarne più di uno; chiaramente una aderenza maggiore implica la facilità nel riconoscerli da parte di altri/e dev che conoscono l'argomento. Generalmente dopo un refactoring, la nostra applicazione sarà più aderente ai [principi di sviluppo software SOLID](https://it.wikipedia.org/wiki/SOLID) il che implica il riuso e la facilità di test, come accennato in precedenza.\ -Come viene definito nel design pattern possiamo definire il design pattern vero e proprio che ne demarca i suoi confini ed il client che definisce tutta la parte esterna ad esso che vi interagisce.\ -Il vantaggio principale dell'utilizzo implica che le modifiche apportate tendono a non cambiare sensibilmente il client. In questo libro li definiremo brevemente evitando di listarli in maniera accademica; questo capitolo sarà infatti un modo per approcciarsi al tema e approfondire successivamente, grazie anche all'esistenza di numerose risorse, che li dettagliano in maniera più puntuale. From d20784e313bbf8ebf3e8955ee83227c06c1f8493 Mon Sep 17 00:00:00 2001 From: Livio74 Date: Sat, 24 Aug 2024 19:12:19 +0200 Subject: [PATCH 54/59] Aggiunta esempio dal sito Refactoring Guru --- docs/it/design-pattern.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 8507ba19..67a5e7ba 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -65,6 +65,7 @@ I pattern creazionali definiti dalla GOF sono: Come già detto i confini non sono ben definiti per cui, ad esempio, un oggetto complesso potrebbe essere creato tramite un builder e, se una parte dovesse richiedere una clonazione con un successivo raffinamento, sarà necessario utilizzare anche un Prototype che si occuperà della parte di clonazione. Se non ci fosse la possibilità di effettuare una separazione netta si potrebbe utilizzare il Builder o il Prototype. +Per spiegare meglio questi concetti si possono vedere gli esempi presenti sul sito di Refactoring Guru in particolare su [Builder](https://refactoring.guru/design-patterns/builder) e [Prototype](https://refactoring.guru/design-patterns/prototype) ## Patterns strutturali From ec3e3319619fa1abc2d3fc38e699527c391e7c58 Mon Sep 17 00:00:00 2001 From: Livio74 Date: Sat, 24 Aug 2024 19:13:50 +0200 Subject: [PATCH 55/59] far sparire la lista degli appunti sotto --- docs/it/design-pattern.md | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 67a5e7ba..28e4fe92 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -112,12 +112,4 @@ Come già detto la Gang of Four ha iniziato a definirli e successivamente sulla - Injection nel costruttore - Injection tramite setter - - Injection tramite interfaccia - -# Note e appunti (Da eliminare a fine stesura) - -- Spingere di più sul concetto che i Design Pattern siano delle soluzioni _tipo_ a problemi _tipo_ ma che non sempre la situazione sarà così lineare da permetterci in primis di comprendere il problema che stiamo affrontando e inoltre non è detto che la soluzione sia ottimale in termini di, ma non solo: performance, tempi di sviluppo, armonia con altre scelte architetturali, esperienza del team. -- In linea con quanto sopra: non tutti i/le dev di un team potrebbero essere in grado di adottare i design pattern nella maniera corretta e, come ogni standard, se non rispettato può portare più problemi che benefici. -- Importante delineare il fatto che spesso i Design Pattern, come altri concetti e best practice del software, siano astrazioni applicative e molti dei concetti rappresentati dai pattern possano essere ritrovati sia a livelli di astrazione più alti (architettura e addirittura Infrastruttura) o più bassi (singole righe di codice o singole funzioni). -- (Già citato in una frase) Come linea generale eviteremo di listare i design pattern in maniera accademica in quanto il libro sarà un incipit a un futuro approfondimento, ma ci concentreremo sui perché della loro nascita e del loro utilizzo, le principali dinamiche e i principali concetti attorno ad essi, e i pro e i contro generali. -- I concetti SOLID sono una parte a sé stante di una certa importanza nella programmazione, bisogna capire se parlarne qui o in altre parti per poi farne riferimento. + - Injection tramite interfaccia \ No newline at end of file From 5ca6ae6b205cf665c244d396ee4b59eefcd3e3bc Mon Sep 17 00:00:00 2001 From: Livio74 Date: Sat, 24 Aug 2024 19:20:36 +0200 Subject: [PATCH 56/59] frase di riassunto in fondo come da accordi con Michael --- docs/it/design-pattern.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 28e4fe92..dc1bdb2e 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -40,8 +40,6 @@ Non sempre, però, è possibile scomporre in questo modo un problema, e alle vol Generalmente dopo un refactoring, la nostra applicazione sarà più aderente ai [principi di sviluppo software SOLID](https://it.wikipedia.org/wiki/SOLID) il che implica il riuso e la facilità di test, come accennato in precedenza.\ -In questo libro li definiremo brevemente evitando di listarli in maniera accademica; questo capitolo sarà infatti un modo per approcciarsi al tema e approfondire successivamente, grazie anche all'esistenza di numerose risorse, che li dettagliano in maniera più puntuale. - Oltre al libro sui Design Patterns in questione ne sono stati introdotti altri che vedremo successivamente.\ Il libro della Gang of Four (GOF) suddivide i Design Pattern in 3 categorie: @@ -112,4 +110,6 @@ Come già detto la Gang of Four ha iniziato a definirli e successivamente sulla - Injection nel costruttore - Injection tramite setter - - Injection tramite interfaccia \ No newline at end of file + - Injection tramite interfaccia + +In questo libro li abbiamo definiti brevemente evitando di descriverli in maniera accademica; questo capitolo è infatti un modo per approcciarsi al tema e approfondire successivamente, grazie anche all'esistenza di numerose risorse, che li dettagliano in maniera più puntuale come quelle che abbiamo già elencato. From f10e0a6399d6fd74e4e435c7b6a33dfca593d112 Mon Sep 17 00:00:00 2001 From: Livio74 Date: Sat, 24 Aug 2024 19:31:55 +0200 Subject: [PATCH 57/59] Facciamo riferimento al Sito Refactoring Guru --- docs/it/design-pattern.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index dc1bdb2e..584d7413 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -13,11 +13,12 @@ Questo non vuol dire che, ad esempio, nella programmazione funzionale non vengan Internet ha molte risorse valide sull'argomento, fra queste possiamo citare: -- [Refactoring Guru](https://refactoring.guru/design-patterns/) un sito molto dettagliato e che spiega i diversi Design Pattern evidenziando per ognuno vantaggi e svantaggi e confrontandoli con gli altri. Sono presenti esempi in codice acquistabili separatamente in tutti i linguaggi. - [Il canale Youtube di Christopher Okhravi](https://www.youtube.com/@ChristopherOkhravi) - [Design Patterns su Wikipedia Italiano](https://it.wikipedia.org/wiki/Design_pattern) - [Design Patterns su Wikipedia Inglese](https://en.wikipedia.org/wiki/Design_pattern) +Per illustrarli meglio vorremmo fare soprattutto riferimento a [Refactoring Guru](https://refactoring.guru/design-patterns/) un sito molto dettagliato e che spiega i diversi Design Pattern evidenziando per ognuno vantaggi e svantaggi, mostrando esempi molto esplicativi e confrontandoli con gli altri. Sono presenti esempi in codice acquistabili separatamente in tutti i linguaggi. + Il libro della Gang of Four identifica un elenco iniziale di design pattern, ognuno dei quali ha un nome che identifica la soluzione al problema generico che andrà a risolvere. Durante lo sviluppo, può essere semplice individuare e applicare un design pattern mentre si analizza un problema specifico, ottenendo una serie di vantaggi, tra cui: @@ -49,7 +50,7 @@ Il libro della Gang of Four (GOF) suddivide i Design Pattern in 3 categorie: ## Patterns creazionali -I Patterns creazionali definiscono uno schema progettuale che in particolare si concentra sulla creazione degli oggetti che concorrono a risolvere un determinato problema. +I [Patterns creazionali](https://refactoring.guru/design-patterns/creational-patterns) definiscono uno schema progettuale che in particolare si concentra sulla creazione degli oggetti che concorrono a risolvere un determinato problema. In questo contesto indichiamo come _prodotti_ gli oggetti creati utilizzando un oggetto generalmente denominato Factory (tradotto in _fabbrica_) che, al suo interno, ne definisce la logica di costruzione, la quale risulta isolata dall'esterno. Le altre tipologie definite dalla GOF, che sono la strutturale e la comportamentale, si distiguono da questa perché presuppogono già l'esistenza di tutti gli oggetti coinvolti. @@ -67,7 +68,7 @@ Per spiegare meglio questi concetti si possono vedere gli esempi presenti sul si ## Patterns strutturali -I Pattern strutturali definiscono uno schema progettuale atto a risolvere problematiche inerenti alla struttura degli oggetti, di modo da renderli flessibili ed efficienti; capiremo meglio questo concetto andando a vedere brevemente tutti i design pattern appartenenti a questa categoria. +I [Pattern strutturali](https://refactoring.guru/design-patterns/structural-patterns) definiscono uno schema progettuale atto a risolvere problematiche inerenti alla struttura degli oggetti, di modo da renderli flessibili ed efficienti; capiremo meglio questo concetto andando a vedere brevemente tutti i design pattern appartenenti a questa categoria. I pattern strutturali definiti dalla GOF sono: @@ -82,7 +83,7 @@ I pattern strutturali definiti dalla GOF sono: ## Patterns comportamentali -I Pattern comportamentali definiscono uno schema progettuale che in particolare risolve problematiche di comportamento degli oggetti definiti nel pattern. Generalmente questo comportamento si riflette in particolare sugli algoritmi e sulle responsabilità degli oggetti stessi. +I [Pattern comportamentali](https://refactoring.guru/design-patterns/behavioral-patterns) definiscono uno schema progettuale che in particolare risolve problematiche di comportamento degli oggetti definiti nel pattern. Generalmente questo comportamento si riflette in particolare sugli algoritmi e sulle responsabilità degli oggetti stessi. I pattern comportamentali definiti dalla GOF sono: From 48b128ec924a32eb0714ac88581e3cc2d6f8d2ae Mon Sep 17 00:00:00 2001 From: Livio Francisconi <90481242+Livio74@users.noreply.github.com> Date: Fri, 6 Sep 2024 15:06:17 +0200 Subject: [PATCH 58/59] Introduzione all'argomento e riferimento a Refactoring Guru Co-authored-by: Michael Di Prisco --- docs/it/design-pattern.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 584d7413..886f7d7a 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -17,7 +17,7 @@ Internet ha molte risorse valide sull'argomento, fra queste possiamo citare: - [Design Patterns su Wikipedia Italiano](https://it.wikipedia.org/wiki/Design_pattern) - [Design Patterns su Wikipedia Inglese](https://en.wikipedia.org/wiki/Design_pattern) -Per illustrarli meglio vorremmo fare soprattutto riferimento a [Refactoring Guru](https://refactoring.guru/design-patterns/) un sito molto dettagliato e che spiega i diversi Design Pattern evidenziando per ognuno vantaggi e svantaggi, mostrando esempi molto esplicativi e confrontandoli con gli altri. Sono presenti esempi in codice acquistabili separatamente in tutti i linguaggi. +Questo capitolo ha come intento l'introduzione all'argomento, e non ha la presunzione di coprire ogni aspetto dei Design Pattern. Suggeriamo di affiancare la lettura alla navigazione del sito [Refactoring Guru](https://refactoring.guru/design-patterns/), che spiega i diversi Design Pattern evidenziando per ognuno vantaggi e svantaggi, mostrando esempi pratici ed esplicativi. Sono inoltre presenti esempi di codice acquistabili in vari linguaggi. Il libro della Gang of Four identifica un elenco iniziale di design pattern, ognuno dei quali ha un nome che identifica la soluzione al problema generico che andrà a risolvere. Durante lo sviluppo, può essere semplice individuare e applicare un design pattern mentre si analizza un problema specifico, ottenendo una serie di vantaggi, tra cui: From f54f47415d2036da558638534a90a5c6de328b3b Mon Sep 17 00:00:00 2001 From: Michael Di Prisco Date: Mon, 16 Sep 2024 21:37:57 +0200 Subject: [PATCH 59/59] Apply suggestions from code review --- docs/it/design-pattern.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/docs/it/design-pattern.md b/docs/it/design-pattern.md index 886f7d7a..dad22aed 100644 --- a/docs/it/design-pattern.md +++ b/docs/it/design-pattern.md @@ -50,7 +50,7 @@ Il libro della Gang of Four (GOF) suddivide i Design Pattern in 3 categorie: ## Patterns creazionali -I [Patterns creazionali](https://refactoring.guru/design-patterns/creational-patterns) definiscono uno schema progettuale che in particolare si concentra sulla creazione degli oggetti che concorrono a risolvere un determinato problema. +I [Pattern creazionali](https://refactoring.guru/design-patterns/creational-patterns) definiscono uno schema progettuale che in particolare si concentra sulla creazione degli oggetti che concorrono a risolvere un determinato problema. In questo contesto indichiamo come _prodotti_ gli oggetti creati utilizzando un oggetto generalmente denominato Factory (tradotto in _fabbrica_) che, al suo interno, ne definisce la logica di costruzione, la quale risulta isolata dall'esterno. Le altre tipologie definite dalla GOF, che sono la strutturale e la comportamentale, si distiguono da questa perché presuppogono già l'esistenza di tutti gli oggetti coinvolti. @@ -64,7 +64,6 @@ I pattern creazionali definiti dalla GOF sono: Come già detto i confini non sono ben definiti per cui, ad esempio, un oggetto complesso potrebbe essere creato tramite un builder e, se una parte dovesse richiedere una clonazione con un successivo raffinamento, sarà necessario utilizzare anche un Prototype che si occuperà della parte di clonazione. Se non ci fosse la possibilità di effettuare una separazione netta si potrebbe utilizzare il Builder o il Prototype. -Per spiegare meglio questi concetti si possono vedere gli esempi presenti sul sito di Refactoring Guru in particolare su [Builder](https://refactoring.guru/design-patterns/builder) e [Prototype](https://refactoring.guru/design-patterns/prototype) ## Patterns strutturali