[DUDA]Responsabilidad de la clase o del programador.

[SLUGER]

Bueno, por ejemplo, tenemos la clase números  en donde solo queremos que se ingresen los números del 1-9 y no el 0.

Código (cpp) [Seleccionar] Expandir


class numeros
{
private:
int numero;
public:
numeros(int numeros);
};


Ahora, es responsabilidad de la clase(el constructor que es el que inicializara la variable según el parámetro) verificar que no exista 0, o es responsabilidad del programador que utiliza la clase verificar si existe un 0 y luego si no existe pasarle como parámetro la variable.

[.:BlackCoder:.]

Del constructor definitivamente... (es decir de quien hizo la clase)... Debe estar a prueba de fallos  Para que cuando otro programador la use no tenga problemas...
Saludos...

[SLUGER]

 
Gracias. El_nuevo_HH, Littlehorse.

[Littlehorse]

En el constructor por supuesto. Ten en cuenta que chequear los parámetros en un método no difiere de hacerlo en cualquier otra función por lo tanto no tiene sentido no hacerlo. Sobretodo si los datos provienen de funciones externas o del propio usuario.

En cualquiera de los casos tienes que analizar el caso en particular ya que verificar los datos siempre es escribir mas código y (en algunos casos) perder un poco de rendimiento. Mas allá de eso es una buena practica hacerlo y logra que el programador pueda buscar y controlar los errores mucho mas fácilmente . Fallar antes que ocurra un desastre mayor siempre es bienvenido.

Saludos!

[biribau]

Si puedes úsalo. Pero si estas reacio, yo te diría que como regla general si vas a usar ese módulo mucho, ponle la aserción en release. Pero si la vas a usar poco(con poca interdependencia) pónsela sólo en modo debug y estate pendiente. De todos modos siempre es decisión del programador, tú dices qué se le debe pasar a tu función, sólo que normalmente(en los ejercicios sencillos) el sistema de tipos es suficientemente expresivo.
Ejemplos: División por cero, integer overflow, buffer overflow(acceder a un elemento fuera del array no tiene porque resultar ilegal o dar error en C, sí en otros lenguajes)

Por cierto, eso en diseño por contratos se llama invariante de clase

[SLUGER]

Se la dejare en "release", porque la verdad la clase esta muy propensa a que se ingresen otros datos no deseados, además de que evito crashes. Y como dice Littlehorse es una buena practica hacerlo y logra que el programador pueda buscar y controlar los errores mucho mas fácilmente.