Pensar en C++ (Volumen 1) - Grupo ARCO

✐
✐
✐
“Volumen1” — 2012/1/12 — 13:52 — page 535 — #573
✐
29. Use atributos para variaciones en los valores y métodos virtuales para variaciones
en el comportamiento. Es decir, si encuentra una clase que usa atributos
estáticos con métodos que cambian de comportamiento basandose en esos
atributos, probablemente deberia rediseñarla para expresar las diferencias de
comportamiento con subclases y métodos virtuales anulados.
30. If debe hacer algo no portable, cree una abstracción para el servicio y póngalo
en una clase. Este nivel extra de indirección facilita la portabilidad mejor que
si se distribuyera por todo el programa.
31. Evite la herencia múltiple. Estará a salvo de malas situaciones, especialmente
cuando repare las interfaces de clases que están fuera de su control (vea el Volumen
2). Debería ser un programador experimentado antes de poder diseñar
con herencia múltiple.
32. No use herencia privada. Aunque, está en el lenguaje y parece que tiene una
funcionalidad ocasional, ello implica ambigüedades importantes cuando se
combina con comprobación dinámica de tipo. Cree un objeto miembro privado
en lugar de usar herencia privada.
33. Si dos clases están asociadas entre si de algún modo (como los contenedores
y los iteradores). intente hacer que una de ellas sea una clase amiga anidada
de la otro, tal como la Librería Estándar C++ hace con los interadores dentro
de los contenedores (En la última parte del Capítulo 16 se muestran ejemplos
de esto). No solo pone de manifiesto la asociación entre las clases, también
permite que el nombre de la clase se pueda reutilizar anidándola en otra clase.
La Librería Estándar C++ lo hace definiendo un clase iterador anidada dentro
de cada clase contenedor, de ese modo los contenedores tienen una interface
común. La otra razón por la que querrá anidar una clase es como parte de
la implementación privada. En ese caso, el anidamiento es beneficioso para
ocultar la implementación más por la asociación de clases y la prevención de
la contaminación del espacio de nombres citada arriba.
34. La sobrecarga de operadores en sólo «azucar sintáctico:» una manera diferente
de hacer una llamada a función. Is sobrecarga un operador no está haciendo
que la interfaz de la clase sea más clara o fácil de usar, no lo haga. Cree sólo un
operador de conversión automática de tipo. En general, seguir las directrices y
estilo indicados en el Capítulo 12 cuando sobrecargue operadores.
35. No sea una víctima de la optimización prematura. Ese camino lleva a la locura.
In particular, no se preocupe de escribir (o evitar) funciones inline, hacer algunas
funciones no virtuales, afinar el código para hacerlo más eficiente cuando
esté en las primer fase de contrucción del sistema. El objetivo principal debería
ser probar el diseño, a menos que el propio diseño requiera cierta eficiencia.
36. Normalmente, no deje que el compilador cree los constructores, destructores
o el operator= por usted. Los diseñadores de clases siempre deberían decir
qué debe hacer la clase exactamente y mantenerla enteramente bajo su control.
Si no quiere costructor de copia u operator=, declarelos como privados.
Recuerde que si crea algún constructor, el compilador un sintetizará un constructor
por defecto.
37. Si su clase contiene punteros, debe crear el constructor de copia, el operator=
y el destructor de la clase para que funcione adecuadamente.
38. Cuando escriba un constructor de copia para una clase derivada, recuerde llamar
explícitamente al constructor de copia de la clase base (también cuando se
535
✐
✐
✐
✐