 Autor
|
Tema: Representación de Coordenadas (Leído 7,103 veces)
|
amchacon
 Desconectado
Mensajes: 1.211
|
Buenas. Frecuentemente hay que trabajar con coordenadas en la programación. Actualmente conozco tres formas de pasarlas: 1º A "pelo" con dos variables int: int x = 1; int y = 1; pintar(x,y);
2º Creandote una estructura "Cord": struct Cord { int X,Y; Cord(int x,int y) : X(x),Y(y) {} }; //... pintar(Cord(1,1));
3º Un objeto Cord con su encapsulamiento y su todo: class Cord { int X,Y; public: Cord(int x,int y) : X(x),Y(y) {} int getX() const {return X;} int getY() const {return Y;} void setX(int x){X = x;} void setY(int y){Y = y;} bool operator==(const Cord a) const {return X == a.X && Y == a.Y;} bool operator!=(const Cord a) const {return X != a.X || Y != a.Y;} Cord operator+(const Cord a) const{return Cord(A.X+X,A.Y+Y);} }; //... Pintar(Cord(1,1));]
En vuestra opinión. ¿Cual es la forma más adecuada? Con la primera quizás se escribe menos, aunque se te acumulan los argumentos en la función.
|
|
|
|
|
En línea
|
|
|
|
eferion
Desconectado
Mensajes: 1.248
|
A mi me gusta más la tercera opción por varias razones:
* Existe encapsulamiento.
* Permite obtener un código más legible, sobretodo si se sobrecargan varios operadores ( suma, resta, ... )
* Su mantenimiento luego es más sencillo y se limitan la cantidad de "gazapos" por parte del que usa el objeto.
* Es muy sencillo acoplarle una batería te test para asegurar el correcto funcionamiento.
Se que tiene varias desventajas, pero desde mi punto de vista y mi experiencia ( trabajo en un cad orientado al sector naval ) me dicen que la tercera opción es la que más beneficios tiene.
Algunas desventajas:
* Resevas de memoria al crear copias del objeto, lo que reduce sensiblemente el rendimiento.
* Hay que currárselo todo al principio.
|
|
|
|
|
En línea
|
|
|
|
Eternal Idol
Kernel coder
Moderador
Desconectado
Mensajes: 5.969
Israel nunca torturó niños, ni lo volverá a hacer.
|
La segunda manera tambien usa un objeto, en C++ las estructuras son a todos los efectos clases con sus miembros y clases bases publicos por defecto. Los constructores no existen en C.
|
|
|
|
« Última modificación: 9 Abril 2014, 17:35 pm por Eternal Idol »
|
En línea
|
La economía nunca ha sido libre: o la controla el Estado en beneficio del Pueblo o lo hacen los grandes consorcios en perjuicio de éste.
Juan Domingo Perón
|
|
|
eferion
Desconectado
Mensajes: 1.248
|
La segunda manera tambien usa un objeto, en C++ las estructuras son a todos los efectos clases con sus miembros y clases bases publicos por defecto. Los constructores no existen en C.
Ya, lo que sucede es que en las estructuras, por defecto, sus miembros son públicos, lo que viola el concepto de encapsulamiento. Además en C++ la gente espera encontrar clases... es más natural. Las estructuras, en los grupos en los que he estado, se reservan para tareas específicas, por ejemplo, para cuando hay que enviar tramas de datos por red... aunque hay que tener cuidado de no tener estructuras con herencia para no enviar basura.
|
|
|
|
|
En línea
|
|
|
|
Eternal Idol
Kernel coder
Moderador
Desconectado
Mensajes: 5.969
Israel nunca torturó niños, ni lo volverá a hacer.
|
Ya, lo que sucede es que en las estructuras, por defecto, sus miembros son públicos, lo que viola el concepto de encapsulamiento. Lo que decis es correcto - ademas las clases base se heredan por defecto como publicas tambien - pero no invalida mi afirmacion en lo absoluto, en ambos casos al llamar a pintar se usa un objeto y es lo que queria aclarar.
|
|
|
|
« Última modificación: 9 Abril 2014, 18:05 pm por Eternal Idol »
|
En línea
|
La economía nunca ha sido libre: o la controla el Estado en beneficio del Pueblo o lo hacen los grandes consorcios en perjuicio de éste.
Juan Domingo Perón
|
|
|
ivancea96
Desconectado
Mensajes: 3.412
ASMático
|
Yo voto a favor de la estuctura. No es necesario ningún método si solo vas a usar un X y un Y, que no interfieren en nada el uno del otro.
No es necesario controlarlos con una clase. Es más: se hace más engorroso poner coord.getX() que poner coord.x.
Pero bueno. La primera opción, desde luego, si usas muchas coordenadas, es lioso. x1 x2 x3 y1 y2 y3. Y si no lioso, menos legible.
En cualquier caso, también se puede hacer una clase con miembros públicos. Es lo mismo prácticamente. Funciones le vas a poder poner igual a clase como a estructura.
Y como dato final, yo prefiero hacer vectores, no coordenadas. Aunque prácticamente son lo mismo, tienen más usos cuerdos. No es cuerdo sumar coordenadas, en cambio sí lo es sumar vectores. No es cuerdo un producto mixto de coordenadas, pero sí uno de vectores. En fin.
|
|
|
|
|
En línea
|
|
|
|
amchacon
Desconectado
Mensajes: 1.211
|
A mi me gusta más la tercera opción por varias razones:
* Existe encapsulamiento.
* Permite obtener un código más legible, sobretodo si se sobrecargan varios operadores ( suma, resta, ... )
* Su mantenimiento luego es más sencillo y se limitan la cantidad de "gazapos" por parte del que usa el objeto.
* Es muy sencillo acoplarle una batería te test para asegurar el correcto funcionamiento.
Se que tiene varias desventajas, pero desde mi punto de vista y mi experiencia ( trabajo en un cad orientado al sector naval ) me dicen que la tercera opción es la que más beneficios tiene.
Algunas desventajas:
* Resevas de memoria al crear copias del objeto, lo que reduce sensiblemente el rendimiento.
* Hay que currárselo todo al principio.
Vaya no lo había visto así. ¿Pero es necesario el encapsulamiento en un objeto así? La segunda manera tambien usa un objeto, en C++ las estructuras son a todos los efectos clases con sus miembros y clases bases publicos por defecto. Los constructores no existen en C.
Muy cierto, quizás debería haber sido más preciso en la terminología ^^ Y como dato final, yo prefiero hacer vectores, no coordenadas. Aunque prácticamente son lo mismo, tienen más usos cuerdos. No es cuerdo sumar coordenadas, en cambio sí lo es sumar vectores. No es cuerdo un producto mixto de coordenadas, pero sí uno de vectores. En fin.
Las coordenadas se pueden interpretar como un vector desde la posición (0,0) a la posición (x,y). Ergo si tiene un uso cuerdo. Quizás para no liar se puede cambiar el nombre de Cord -> Vector.
|
|
|
|
|
En línea
|
|
|
|
ivancea96
Desconectado
Mensajes: 3.412
ASMático
|
Las coordenadas se pueden interpretar como un vector desde la posición (0,0) a la posición (x,y).
Se puede interpretar. Pero sigue sin ser cuerdo, por ejemplo, ver "coordenada.longitud()".
|
|
|
|
|
En línea
|
|
|
|
amchacon
Desconectado
Mensajes: 1.211
|
Se puede interpretar. Pero sigue sin ser cuerdo, por ejemplo, ver "coordenada.longitud()".
Cierto. Pues le cambio el nombre de Cord a vector y listo ^^
|
|
|
|
|
En línea
|
|
|
|
dato000
Desconectado
Mensajes: 3.034
|
ummmm me voy más con la segunda opción, es algo que herede de conocimientos de amchacon y kaltorak, que trabajan de esta forma el código, y aún no estoy acostumbrado al encapsulamiento (apenas lo estoy comenzando a aplicar para c# con patrón singleton y es todo un dilema aplicarle encapsulamiento del vikingo a esa clase control) y menos en c++, y para un caso particular como este, se me hace un poco enredado utilizar tanto metodo para estas variables, prácticamente cada variable requiere de su clase y sus metodos de control, y a mi se me hace adecuado solo en ciertos casos con variables realmente importantes. Yo voto a favor de la estuctura. No es necesario ningún método si solo vas a usar un X y un Y, que no interfieren en nada el uno del otro.
No es necesario controlarlos con una clase. Es más: se hace más engorroso poner coord.getX() que poner coord.x.
Pero bueno. La primera opción, desde luego, si usas muchas coordenadas, es lioso. x1 x2 x3 y1 y2 y3. Y si no lioso, menos legible.
En cualquier caso, también se puede hacer una clase con miembros públicos. Es lo mismo prácticamente. Funciones le vas a poder poner igual a clase como a estructura.
Y como dato final, yo prefiero hacer vectores, no coordenadas. Aunque prácticamente son lo mismo, tienen más usos cuerdos. No es cuerdo sumar coordenadas, en cambio sí lo es sumar vectores. No es cuerdo un producto mixto de coordenadas, pero sí uno de vectores. En fin.
Creo estoy de acuerdo con ivancea96 en todo, excepto en lo de vectores, bueno, casi, depende del caso. |
|
|
|
|
En línea
|
|
|
|
|
| Mensajes similares |
|
Asunto |
Iniciado por |
Respuestas |
Vistas |
Último mensaje |
|
|
Representación interna de un número real
Dudas Generales
|
DickGumshoe
|
0
|
2,113
|
11 Enero 2012, 19:54 pm
por DickGumshoe
|
|
|
|
Representación de un número
Java
|
maikmilk
|
6
|
3,921
|
6 Junio 2012, 16:48 pm
por lluvplay
|
|
|
|
Representación de los valores de un array en función de su indice
Programación C/C++
|
cabre89
|
3
|
2,153
|
29 Octubre 2012, 22:56 pm
por flony
|
|
|
|
Problema representación dirección de memoria en C.
Programación C/C++
|
lanun
|
6
|
2,858
|
28 Febrero 2014, 19:44 pm
por lanun
|
|
|
|
Representación decimal en la computadora
« 1 2 »
Dudas Generales
|
fafafa01
|
12
|
6,140
|
3 Julio 2016, 13:46 pm
por Orubatosu
|
 |
