On Friday, December 4, 2009, Carles Pina i Estany wrote: > > A primera vista yo haría un método. Una regla fácil para colocar cosas > > en la > > Yo no, ni mucho menos. Argumentos para el no: > > -string es un basic_string (creo) y no tiene el destructor virtual. Si > por despiste ponemos, ahora en un futuro (mantenimiento) datos en la > clase derivada que se tuvieran que destruir en el destructor no sería > llamado (si se usa polimorfismo). Es fácil que en algun punto de la vida > del programa esto pase y haya un "sutil" memory leak
Es posible que en el futuro te des cuenta de que lo que necesitabas en realidad era hacer bacalao al pil pil. Así que, por previsión, podrías usar desde ya mismo una cazuela de barro. > > Claro que además de la herencia, también puede tener sentido la > > composición. Es decir, varias clases incluyen miembros de tipo > > std::string, y necesitan partir esas cadenas miembro de una misma > > forma. Si la operación es común, entonces podría ser un método > > heredado de un ascendiente común. > > Si es posible prefiero evitar herencia multiple. Lleva fácilmente a > dependencias en rombo con más bugs sutiles. En ningún momento he sugerido herencia múltiple. Pero precisamente la herencia múltiple de la implementación en C++ me parece una de las mayores fortalezas/ventaja de este lenguaje sobre Java, C#, Delphi y similares, que solamente permiten herencia múltiple de interfaces. > Generar una clase que haga composición de string lo veo trabajo por el > hecho de tener que redefinir el interfaz público de string, no? No. http://en.wikipedia.org/wiki/Object_composition Saludos, Pedro -- _______________________________________________ Comandob mailing list [email protected] http://lists.badopi.org/mailman/listinfo/comandob
