Sessió C1: Susbcripcions i notificacions
Objectius
- Evolucionar un sistema simple a "una mica complex", mantenint-lo "sota control"
- Decidir la navegabilitat més convenient entre associacions
- Dissenyar missatges amb molts nivells d'indireccions
Testejant amb stubs
En aquesta sessió, s'ens dona un component que simula una API d'un
servidor de correu sortint. Fitxer: MailStub.hxx.
Un "stub" o mock-up object (objecte simulat)
és un component de mentida que en substitueix
a un component real que no és convenient d'usar en els tests:
- perque és lent (crides remotes, accessos a bases de dades...) i faria l'execució de test poc àgil,
- perque és inconvenient (no volem enviar mails cada vegada que executem els testos),
- perque no tenim el sistema implementat encara, o
- perque, simplement, volem independitzar el nostre test de l'altre component.
Un stub comparteix la interfície amb l'objecte real i simula les seves respostes.
Normalment també ofereix al test una interficie adicional per comprovar que el nostre
component testejat ha interactuat amb el simulat de la forma esperada.
Patró singleton
Analitzeu el MailStub.hxx i fixeu-vos amb
- com implementem el patró Singleton en C++
- i com n'hem extret una classe base que podem reusar sempre
que necessitem guardar un log de missatges.
Tasques
- Passar tots els tests funcionals (tots són obligatoris)
fent desenvolupament dirigit pels tests (unitaris).
Aquesta sessió també teniu una guia,
però aquesta vegada menys detallada.
Aquest és el diagrama de classes simplificat del sistema resultant,
obviant les classes no implicades.
- [Opcional 1] Fer el diagrama de seqüència describint la situació que es dona quan associem un track a un estil que te dos usuaris subscrits.
- [Opcional 2] Passar la definició dels mètodes de les classes al seu corresponent .cxx.
Moure les definicions al cxx o no és una decisió de compromís (com moltes coses en programació):
per un cantó, amb diversos .cxx es triga menys a re-compilar,
per l'altre, quan extens o canvies la interficie cal modificar els dos fitxers.
Quan hi ha referències creuades, sovint no queda cap altre remei que separar-los.
Feu una ullada a la part de "Plantant el codi" que hi ha al capitol de C++ de teoria.
Separant hxx i cxx els headers també queden més llegibles de cara
a un usuari de la classe que ho vulgui veure-la com una caixa negra.