Dimarts 20 i Dijous 22 de Novembre
Per rebre una mica de resposta, els hem ensenyat, als de AmalgamaOnline, les coses que ja pot fer el cor del nostre sistema. Ens han dit, com esperavem, que calen més coses al sistema de subscripcions. Per un costat volen que els usuaris, a part de temes, puguin subscriure's als seus autors preferits, de forma que siguin notificats quan aquest publiqui una nova obra.
També ens han dit que volen oferir nous apartats a la web de l'editorial, anomenats canals temàtics, que ofereixin noticies especialitzades per temes i autors concrets. Nosaltres els hi hem comentat l'existència dels agregadors RSS i ens han dit que pot ser bo tenir-los.
Per últim, ens han comentat que una altra forma de negoci podria ser enviar avisos per SMS d'aquestes mateixes novetats en comptes d'enviar-les per mail, o sigui que hem de donar l'opció als usuaris d'escollir entre aquestes dues formes de notificació.
Ara que el mòdul de negoci està madur hem incorporat més gent a l'equip per implementar el módul d'aplicació. Els nous no estan acostumats a la nostra metodologia. Hem pensat que seria bona idea que els hi fessiu una guia pas a pas del que aneu fent i dels problemes que trobeu en aquesta iteració. Els hi servirà de exemple de com treballeu.
El patrò observer serveix per solucionar el següent problema: Tenim un conjunt de classes (observadores) els objectes de les quals necessiten actualitzar el seu estat quan un altre objecte pertanyent a un altre conjunt de classes (subjectes o observables) rep un estímul concret. Ara bé, tant el conjunt de classes que observen com el conjunt de classes observables, és una cosa que canviarà amb al temps y no volem acoblament entre elles.
La solució a aquest problema, és definir un parell de classes base que s'encarreguin, per un costat d'associar (subscriure) els observadors d'un observable i d'enviar-lis una notificació d'actualització. Per un altre, una interficie comuna a tots els observadors, per poder ser notificats. La interfície dels observadors l'implementarà cadascú com li convingui.
El patro strategy soluciona el següent problema: Un aspecte del comportament d'un objecte d'una classe (classe context) pot ser diferent segons els casos. Diem que l'objecte té diverses estratègies o polítiques disponibles per afrontar una tasca. Això ho podem resoldre amb un control de fluxe condicional. El problema és si volem deixar oberta la possibilitat de que hi hagin més alternatives. Si ens interesa independitzar el codi del context de les estrategies alternatives disponibles llavors la solució es l'estràtegy.
Imagineu un campionat d'algorismes d'escacs. Teniu la classe jugador (contexte) cadascun dels quals fa servir un algorisme per decidir la següent jugada. No sabem quants algorismes entraran a concurs, o sigui que no podem solucionar-ho amb un 'si ets el jugador 1 fes servir la estrategia dels alumnes de la Pompeu...'.
La solució que ofereix el patrò strategy és definir una classe per cada estrategia amb un mètode per cada aspecte del comportament que en depengui. Aquests mètodes es defineixen a una classe abstracta, que serà la que manegarà el context. Si afegim una estratègia nova no caldrà canviar el codi de la classe context que simplement farà servir la interficie general.
Perdent el contexteLa interfície de les estratègies ha de ser suficient per que l'estrategia tingui tota la informació necessaria del contexte. Per exemple, necessitarem el telefon o l'email de l'usuari. Normalment el que es fa es passar el contexte com a paràmetre, tot i que a vegades, si és prou general, només passem la informació que necessitem.