comunque, io ogni tanto faccio un salto sul tuo blog, seguiro’ gli sviluppi : )

ciao

Carlo

D’accordo anche con l’applicazione di nuovi requisiti “a sorpresa” come test della bontà del design.

Belli i tuoi contributi al checkout!! Ne aggiungo uno anch’io:

“Il risultato non deve essere semplicemente il numero del totale, ma deve essere una lista di tutti i prodotti con i loro prezzi, con l’indicazione di tutti gli sconti applicati”.

(Spoiler) Dal punto di vista del design, se uno ha introdotto prima un “collecting parameter” che tiene traccia del totale, implementare questo nuovo requisito impatta solo il collecting parameter, mentre le altre classi (quasi) non vengono toccate. Questo collecting parameter prende chiaramente il ruolo di Scontrino.

due consigli (non richiesti, ma ok : )

– capisco che introdurre vincoli (es. “non potete usare get”) a volte spinge a generare soluzioni inusuali, pero’ i vincoli artificiali sarebbero da evitare ove possibile (anche perche’ riducendo lo spazio del progettista si riduce anche la discussione delle alternative)

– sarebbe poi carino provare a vedere come si comportano le diverse soluzioni di fronte a cambiamenti nei requisiti (non note a priori, altrimenti…). Questo e’ in genere piu’ interessante rispetto ad un confronto del tipo “il mio e’ piu’ open/closed del tuo” che ogni tanto vedo in giro (peraltro in genere non viene identificato il subset di estensioni per cui il sistema risulta davvero “open”).

Volendo contribuire subito : ), ed avendo lavorato ad alcuni sistemi di cassa per un paio di clienti diversi, propongo qualche variante ai requisiti del problema #2, giusto per vedere la flessibilita’ delle soluzioni trovate:

a) ogni 3 prodotti, il piu’ economico e’ gratis. Nel caso di acquisto di N > 3 prodotti, la scelta puo’ essere mirata a favore del negoziante (tipicamente) o del cliente.

b) sconti cross-product, ovvero: ogni N prodotti di tipo A acquistati, M prodotti di tipo B sono gratis (o scontati di X%).

c) [difficile, ma real-world] le regole del caso (b) possono sovrapporsi, e va trovata la soluzione complessiva piu’ favorevole per il cliente. Nel caso piu’ elementare (e raro)
N1 A => M1 B gratis
N2 B => M2 A gratis
Se compro K1 prodotti A e K2 prodotti B, come vanno prezzati?
(ovviamente i casi reali sono + complessi, le sovrapposizioni non sono mai del tipo simmetrico dato sopra, ma ok, una buona soluzione dovrebbe gestire tutti i casi).

Sarebbe divertente vedere quanto codice (e quanta “struttura”) si salva di fronte ad ogni modifica, e quanto i vincoli artificiali abbiano migliorato o peggiorato la flessibilita’ del design…

ciao

Carlo

Grazie per il tuo commento. Io il FizzBuzz lo vedo un po’ come uno strumento per illustrare alcune tecniche di design.

Più che soluzioni al FizzBuzz :-) mi piacerebbe vedere contributi a una “biblioteca” di problemi di design… (hint! hint!)

Matteo

ottima iniziativa comunque : )