Comunidad Gambas-es

Hola Comunidad!.

Continuo poco a poco con el ejemplo de una baraja de cartas y el juego de las siete y media.
Es prácticamente mi primer juego de cartas y no es solo por el juego (que debe haber muchos),
si no mas bien como trabajar con clases, sus métodos, etc.

Cuando comencé la aplicación no usaba gráficos y todo era texto.Al usar gráficos, la clase
carta se ha quedado "casi" sin uso. Lo primero que se me ocurrió fueron dos clases.

- La clase carta
- La clase baraja.

La clase carta tiene propiedades como:
- El palo del a carta (bastos,copas..),el nombre de la carta (as,rey..) y su valor (1,2,3).

La clase baraja contiene los métodos para:
- Creación del mazo
- Barajar
- Cortar
- Extraer una carta del mazo.
- Decir el valor de la carta
- Mostrar la carta gráficamente en un contenedor del formulario.

Al comenzar. En la clase "baraja", cree un objeto de la clase "carta"
Cree un constructor en la clase "baraja", dando todos los valores posibles a los palos,nombres y valores de las cartas en la clase "baraja".
Tal que así:



En este aspecto los tantos o valores de las cartas están "limitados" a un juego en concreto,"Las siete y media" y no
a cualquier juego de cartas, que es lo que creo que se pretende con la POO.

Visto así.Se podría o se debería tener una clase mas que fuera la que usa las reglas de cada juego.
Ya sea Tute,Brisca,La escoba,Las siete y media, el cinquillo,etc y que en la clase "baraja" tan solo quede
los métodos comunes de una baraja de cartas.

- Creación del mazo
- Barajar
- Cortar
- Extraer una carta del mazo.
- Mostrar la carta ya sea texto o gráfico

Entonces tendríamos la clase Reglas por cada juego.
ClaseSieteyMedia.

Cuando di unos valores a las propiedades de cartas en la clase "baraja", también creo que esos valores,los mas
comunes, palo y nombre los podía haber creado con un constructor en la propia clase "carta"

Estas propiedades son arrays.

A la clase carta se le puede añadir una imagen que represente gráficamente que carta es.
En parte viéndola, ya dice que es, no se necesita decir que es un rey o un as, tan solo
importa su valor como carta, 1, 2,3..y no digo según el tipo de juego.

Es solo un ejemplo de juego con POO.Lo importante es ir comprendiendo la POO para mejorar.
Tardo en hacer las aplicaciones por que le doy muchas vueltas.

Saludos

Shell:

He encontrado este documento
Enlace,
donde viene un diagrama de las clases (página 3) que intervienen en un programa de juego de cartas del siete y medio.

Es una práctica para hacerlo con Smalltalk, pero el diagrama sirve para ver como se organizan las clases.

Nota:
Las clases "abstractas", no se como se implementarián en gambas... en principio con herencia y la clase "padre", con el método/s sin definir...

Enlace Pdf explicando clases abstractas e interfases en java

Y el tema de herencia multiple (interfases y abstractas)... ni idea como se podia llevar a cabo... ¿quizás con módulos? ¿quizas añadiendo una propiedad que sea una clase, osea que nuestra clase, estuviera compuesta por otras clases?

Tambien es interesante este comentario de la practica:

Citar:

El orden de implementación más adecuado es: Carta, Baraja, BarajaEspañola, Jugador, JugadorDeSieteYMedio, Juego, JuegoSieteYMedio.

Hola Julio.

jsbsan escribió: [Ver mensaje]

He encontrado este documento
Enlace,
donde viene un diagrama de las clases (página 3) que intervienen en un programa de juego de cartas del siete y medio.

Es una práctica para hacerlo con Smalltalk, pero el diagrama sirve para ver como se organizan las clases.

Gracias. Estos juegos son muy parecidos.Es mejor pensarlo un poco. En principio no creo que sea realmente muy difícil de hacer.
Es sencillo, lo complicado es hacerlo con clases (afinando claro), siempre que entendamos por que ese método , se encuentra en esa clase concreta.

Ejemplo, he quitado el método crear mazo de clase baraja y lo añadí directamente a la clase carta, con su constructor.
Si tomas al pie de la letra "un mazo de cartas", una baraja, grupo de cartas que están definidas.
El objeto en si, la carta, tiene un valor, un palo,una imagen, un nombre.La carta como tal, es el objeto, con toda
sus características.

No tiene mucho sentido que se defina este método en baraja, se da por confirmado que la baraja siempre
es la clásica, no es un mazo de cartas distinto.Sus propiedades y valores siempre serán los mismos.

Lo he dejado así en la clase carta:



Estos conceptos cuestan aprenderlos.Por ahora es con solo texto, claro.
Se tiene que añadir una propiedad para la imagen.

Lo cierto es que no busque por Internet.Directamente tome la idea de un juego de ordenador antiguo.
Voy leyendo revistas y se enciende la bombilla.

jsbsan escribió: [Ver mensaje]

Nota:
Las clases "abstractas", no se como se implementarián en gambas... en principio con herencia y la clase "padre", con el método/s sin definir...

Enlace Pdf explicando clases abstractas e interfases en java

Y el tema de herencia multiple (interfases y abstractas)... ni idea como se podia llevar a cabo... ¿quizás con módulos? ¿quizas añadiendo una propiedad que sea una clase, osea que nuestra clase, estuviera compuesta por otras clases?

Tu sabes que la herencia no es que sea algo indispensable.Que se puede programar estilo POO, sin ser fundamental la herencia, para hacerlo.
Es como quieras plantearlo.

Tenia en mente la clase jugador, que mínimo sera el jugador y el ordenador.No se acaba nunca..

Podía haber optado por la programación estructurada de siempre pero con la POO queda mejor.
No veas como se acumula código con la de siempre.Se puede dividir en módulos.

Saludos.