Sessió B1: Test Driven Development, C++, Accessors

Test Driven Development

Red-Green-Refactor: el mantra del TDD

El llibre de Kent Beck que explica TDD a base d'exemples.

Amazon permet llegir-ne algun capítol.

A la wiki, teniu una explicació de com heu aplicar TDD a les pràctiques i de com convinar-ho amb l'ús de Subversion

També us hem posat una metàfora molt il·lustrativa comparant el TDD amb l'art de l'escalada

Manual de Referències del C++

La web www.sgi.com té una bona guia de la STL

La web www.cplusplus.com té una bona referència dels 'streams' de la STL

Estàndard de noms i del codi

Els exemples que us donarem seguiran aquest estàndar. I el vostre codi també s'hi haurà d'ajustar.

• Nomenclatura estàndar: (UnaClasse, _unAtribut, variableLocal, unMetode).
• Noms de mètodes i variables auto-explicatius i sense abreviacions críptiques.
• Accessors no booleans de lectura amb unAtribut() i d'escriptura amb unAtribut(nouValor)
• Accesors booleans de lectura amb preguntes sobre l'estat o esència de l'objecte esCreativeCommons(), estaDescatalogat(), haCaducat(), etc. i d'escriptura amb imperatius cap l'objecte com ara siguesCreativeCommons(), descataloga(), caduca(), etc.
• Els mètodes dels testos seran una excepció a la regla de nomenclatura: farem servir el '_' per separar el que estem testejant, i les condicions en que ho fem. Exemple: testAfegeixArtista_quanElNomDArtistaJaExisteix().

Accessibilitat dels membres

• Tots els atributs private (o protected si està justificat)
• Escollir la visibilitat (private, protected o public) més restrictiva possible per els mètodes.

Implementant mètodes

• Mètodes curts, usant sortides ràpides en comptes d'if/elses aniuats (early exit)
• Els mètodes de consulta (getters), que no modifiquen l'estat (attributs) de l'objecte receptor els declararem sempre constants amb un const al final de la declaració

   ReturnType myMethod(parameters) const

  El compilador ens avisarà si dintre del mètode estiguèssim modificant els attributs o cridant mètodes no const.
• Els paràmetres que siguin objectes no bàsics es passaran com a referència per a no copiar-los. La referència serà constant si el receptor no requereix modificar l'objecte.

   void myMethod(const Type & object)

  Només podem cridar mètodes constants d'un objecte que rebem com a constant. El compilador ens assegura que passant un objecte com a paràmetre d'aquest mètode, no té efectes laterals sobre l'objecte passat.
• Els paràmetres o retorns que siguin bàsics no cal passar-los per referència, donat que té un cost similar passar una adreça de memòria que un tipus bàsic.

   float myMethod(int value)

• Feu servir referències constants per retornar objectes no bàsics que siguin membres.

  const Type & myMethod() const { return _member; }

• Feu servir cópia per retornar objectes no bàsics que es crein localment dins del propi mètode (a classe els anomenarem informalment getters per construcció).

  Type myMethod() { Type result; ...; return result; }

  La raó és que no podem retornar una referència a un objecte que deixarà d'existir quan sortim del mètode.
• Quan el pas per paràmetre o el retorn implica una transferència de la responsabilitat d'eliminar l'objecte (veure abaix el model de memòria), per convenció, farem servir punters en comptes de referències.

  	Type * extreu();  // Transfereix al cridador un objecte que estava al receptor
  	Type * creaType() const;  // Crea i transfereix al cridador (no toca el receptor)
  	void adopta(Type *); // Transfereix del cridador cap al receptor 
  	void elimina(Type *) const; // Transfereix del cridador i destrueix
  	

Model de memòria

A C++ no tenim un garbage collector que elimini els objectes. Tot i que gran part dels objectes s'eliminen automaticament per mecanismes de pila.

• Els objectes locals d'un mètode es destrueixen automaticament quan es surt del mètode.
• Els membres no punters (ni referència) d'un objecte es creen automaticament al constructor de l'objecte i es destrueixen automaticament al destructor.
• Els objectes creats amb new necessiten ser eliminats a mà (delete). Per això cal un xic de disciplina i unes convencions clares sobre com manegar la responsabilitat d'eliminar l'objecte.

Convencions de gestió de memòria:

• Tendirem a confinar la responsabilitat de eliminar objectes a la mateixa classe que l'ha creat. Això simplifica molt el sistema.
• Un mètode pot adquirir la responsabilitat d'un objecte fent un new, rebent l'objecte com a paràmetre o com a retorn d'un altre mètode cridat.
• El mètode també pot transferir la responsabilitat al this tot assignant a un attribut de tipus punter. Quan el this adquireix la responsabilitat, l'objecte el pot alliberar qualsevol altre mètode de l'objecte. En darrera instància la responsabilitat recau en el destructor.
• Un atribut punter bé té responsabilitat d'eliminar o bé és una simple referència sense responsabilitat. Mai barregis els dos rols en un mateix atribut.
• Si l'objecte apuntat per un atribut punter és eliminat, cal assignar el atribut punter a zero.
• Quan s'assigna un nou objecte a un membre punter, si el membre punter no és zero, cal alliberar l'objecte anterior abans.
• El mètode pot transferir la responsabilitat passant l'objecte com a paràmetre a un altre mètode o retornant-lo al cridador.
• Quan el pas per paràmetres o el retorn implica una tranferència de la responsabilitat d'alliberar la memòria, adoptem la convenció de fer servir un punter en comptes d'una referència.

  	Type * extreu();  // Transfereix un objecte que ja estava al this
  	Type * creaType() const;  // Crea i transfereix sense tocar el this
  	void adopta(Type *); // Transfereix cap al this