[DUDA]Responsabilidad de la clase o del programador.

Iniciado por SLUGER, 4 Mayo 2010, 02:19 AM

0 Miembros y 1 Visitante están viendo este tema.

SLUGER

Bueno, por ejemplo, tenemos la clase números  :P en donde solo queremos que se ingresen los números del 1-9 y no el 0.
Código (cpp) [Seleccionar]

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...
"No te esfuerzes por saber mas, esfuerzate por ser el mejor en lo que sabes... Y asi sabras mas" .:BlackCoder:. jajaja




SLUGER

#2
 :)
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!
An expert is a man who has made all the mistakes which can be made, in a very narrow field.

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.