Capitolo sui Design Pattern

[m1gwings]

Paragrafi da scrivere:

• [x] Pattern creazionali (by @francescogemma )
• [x] Pattern comportamentali (by @francescogemma )
• [x] Pattern strutturali (by @francescogemma )

[jackorse]

Forse ho interpretato male io questa frase https://github.com/m1gwings/ing-sw-cheatsheet/blob/ca2500502447c4bbbfebdff80bc0af5a0dd3a505/design-pattern.md?plain=1#L689 ma non credo che nello State pattern la transizione di stato debba avvenire necessariamente in seguito all'invocazione di un metodo dello State. Penso che possa anche essere richiesta direttamente dal Context, similmente a come avviene nello Strategy. Nel TdE del 16 luglio 2019 ci sono due stati di privacy per gestire delle richieste di localizzazione e, se ho capito bene, il cambiamento di stato avviene esclusivamente su richiesta dell'utente.

[m1gwings]

Sinceramente so poco e nulla sui pattern e non posso argomentare citando fonti autorevoli dato che non ne conosco e non ho molto tempo 😆. Credo che in generale la definizione delle caratteristiche di un determinato pattern cambi leggermente da autore ad autore, quindi cerco di spiegarti la mia interpretazione. Nella mia interpretazione lo State permette di implementare un automa a stati finiti (o più precisamente un trasduttore a stati finiti, dato che i metodi dello State in generale possono restituire qulcosa). Quindi l'utente invocando i metodi è come se fornisse un simbolo in ingresso all'automa che cambia il suo stato di conseguenza in base allo stato di partenza ed al metodo invocato. Per modellare un automa non è mai necessario che l'utente modifichi direttamente lo stato. Quello nella soluzione del TdE, è sicuramente Strategy (nel senso che togliendo il fatto che ci sia la parola State, implementando uno Strategy si ottiene la stessa struttura); poi dando una definizione di State alternativa alla mia, quello potrebbe risultare anche uno State. Si tratta fondamentalmente di una classe che cambia il suo comportamento a runtime e che non ha molto senso modellare mediante un automa a stati finiti. Ora, il motivo per cui sono critico di questa definizione alternativa di State è che consegue che tutti gli Strategy sono State e non mi sembra molto appropriato. Nella soluzione credo abbiano usato State solo perché nel testo c'era la parola "stato". Ma anche nell'esempio su Strategy delle casse, dove ci sono casse che avvelenano, casse che curano, etc. si potrebbe argomentare che le casse si trovano in "stati" diversi e quindi, secondo la definizione alternativa, anche quello risulterebbe uno State. In conclusione, secondo me, discernere tra Strategy e State in base al fatto che nel testo si parli di "stato" o meno non mi sembra funzionale, dato che cosa sia "stato" e cosa non lo sia è abbsastanza interpretabile (a meno che non si faccia riferimento a formalismi come gli automi a stati finiti). Quindi per ora lascerei questa definizione di State, anche perché in quel TdE, se qualcuno avesse usato Strategy, non credo gli avrebbero tolto dei punti dato che il codice risultante (salvo il nome dei metodi) sarebbe stato lo stesso.

[jackorse]

Chiaro, grazie mille.

anche perché in quel TdE, se qualcuno avesse usato Strategy, non credo gli avrebbero tolto dei punti dato che il codice risultante (salvo il nome dei metodi) sarebbe stato lo stesso.

Si, anche secondo me.

[m1gwings]

Di nulla 😄