Hola Comunidad!.

Estoy practicando clases y herencias y se me ocurrió este ejemplo.

He creado como ejemplo un personaje de rol. Este personaje tiene unas propiedades como son:

La clase Héroe



Y luego tengo otras clases que son:
Las razas,la profesión (que pudiera ser múltiple, la dejo en una por ahora) y la alineación.

La clase raza:


La clase profesión o ocupación



Y la ultima. La alineación.


Como la POO la tengo siempre un poco verde. Pregunto.

¿ Quien hereda a quien ?.
¿ El héroe debe heredar todas las demás clases o son las clases Profesión,Raza y Alineación las que heredan al héroe (no creo)?.
Parece mas que el héroe deba ser multi-clase.

La variables las puse como lógicas, por que no todas las razas tienen las mismas profesiones, si es una profesión no puede ser todas las alineaciones,etc.
(Parece una serie de tablas). Quizás las variables luego para que el héroe tenga su raza, alineación o profesión no sea correcto, pero eso es cuestión de estudiarlo.

Es mas complicado de lo que parece ya que por ejemplo un mago es mas inteligente y un monje es mas sabio,son cuestiones propias de los juegos de rol.

Ejemplo de tabla para las ocupaciones:

 

Un poco complicado a lo mejor como ejemplo.Muchas variables.

¿ Que consejos me dais para continuar el ejemplo en gambas ?.

Como en principio las variables son privadas no se van a ver, eso por un lado.Pudiera ponerlas como publicas o hacerlas propiedades.Como aumenta el código.

Pues si que me voy dando cuenta de otras cosas. La raza del héroe puede ser de la clase Raza. Cosas de novato.
Visto eso, compañeros, no habría una herencia directamente, serian clases separadas.  

Saludos.

===================
Gambas Básico
"No es un bug, es una característica no documentada"

Hola Shell, no había leído este mensaje tuyo y me parece muy interesante para aclarar un punto que me parece resulta muy difícil de comprender para la mayoría de las personas.

Este problema básicamente se plantea porque intentas crear clases a partir de datos o de conceptos "crudos" que identificaste en tu programa.

Cuando analizas el "dominio" de tu programa tienes que enfocarte en los objetos, no en las clases. Las clases son un tipo de objeto particular, son fábricas de objetos y son el resultado de una generalización o de una agregación que se realiza durante el análisis y diseño de un programa.

A veces la existencia de una clase es o parece bastante obvia desde el principio y uno tiende a saltarse pasos. Pero lo que realmente se debe hacer es verificar que esa clase realmente debe existir, que tiene razón de ser.

Lo primero que debes considerar es que la clase Héroe es una clase candidata, que es una forma de decir "creo que esto puede llegar a ser una clase en mi programa, pero tal vez no lo sea". Para verificar que existen razones válidas para pensar que esa clase debe existir deberías enfocarte primero en identificar que existen objetos de esa clase, es decir, instancias concretas (¿existen héroes concretos diferentes unos de otros?) y luego en si tienen comportamiento (¿tienen un comportamiento que sólo ellos llevan a cabo?).

Si puedes responder a las preguntas anteriores, entonces tienes que preguntarte ¿tiene sentido que exista un héroe como una entidad independiente? ¿es relevante para el programa que exista?

Lo mismo para las demás clases candidatas: raza, ocupación y alineación. En particular, debes enfocarte en observar si existen comportamientos atribuibles a objetos de esas clases que sean únicos y a si tiene sentido que existan como entidades independientes.

Nota: si no puedes encontrar comportamiento para una clase candidata determinada es altamente probable que ese concepto no deba existir en tu programa o que no deba existir como una clase.

La pregunta ¿quien hereda a quien? la podrás responder adecuadamente cuando hayas identificado los comportamientos de cada clase, en función de que algunos comportamientos son los mismos en una clase y en otras. Luego deberías encontrar un concepto que represente adecuadamente esos comportamientos que esas clases tienen en común y que será su super-clase.

Sé que puede resultar bastante difícil aplicar lo que expliqué antes, así que si te surgen dudas sólo pregunta.

Saludos.

===================
Cómo programar con Gambas

Speed Books: informática libre.

Hola fabian.

fabianfv escribió: 

Este problema básicamente se plantea porque intentas crear clases a partir de datos o de conceptos "crudos" que identificaste en tu programa.

Cuando analizas el "dominio" de tu programa tienes que enfocarte en los objetos, no en las clases. Las clases son un tipo de objeto particular, son fábricas de objetos y son el resultado de una generalización o de una agregación que se realiza durante el análisis y diseño de un programa.

Es un problema común cuando comenzamos la creación de cualquier programa.Tenemos una serie de variables o datos que intentamos relacionar
de alguna manera y todo esta en el aire.Luego van encajando, dando forma.

Me parecieron unos datos muy generales.Como el héroe tiene una serie de propiedades comunes a todos los héroes,asocie todas estas
propiedades al patrón o clase que los crea.

El objeto sale de una clase concreta.Se crea con esta.Entonces, ¿ por que los llamas objetos si no forman parte de una clase ?.
¿ Como puede crearse un objeto, si no forma parte de una clase ?.

He buscado el significado de "dominio", encontré una serie de términos algo confusos.

"Llamamos dominio de un programa al producto cartesiano entre los tipos de datos de las variables de entrada."

Referencias:

Verificación formal frente a "Unit testing" en desarrollo software
Producto cartesiano

fabianfv escribió: 

A veces la existencia de una clase es o parece bastante obvia desde el principio y uno tiende a saltarse pasos. Pero lo que realmente se debe hacer es verificar que esa clase realmente debe existir, que tiene razón de ser.

Lo primero que debes considerar es que la clase Héroe es una clase candidata, que es una forma de decir "creo que esto puede llegar a ser una clase en mi programa, pero tal vez no lo sea". Para verificar que existen razones válidas para pensar que esa clase debe existir deberías enfocarte primero en identificar que existen objetos de esa clase, es decir, instancias concretas (¿existen héroes concretos diferentes unos de otros?) y luego en si tienen comportamiento (¿tienen un comportamiento que sólo ellos llevan a cabo?).

Si puedes responder a las preguntas anteriores, entonces tienes que preguntarte ¿tiene sentido que exista un héroe como una entidad independiente? ¿es relevante para el programa que exista?

Lo mismo para las demás clases candidatas: raza, ocupación y alineación. En particular, debes enfocarte en observar si existen comportamientos atribuibles a objetos de esas clases que sean únicos y a si tiene sentido que existan como entidades independientes.

Nota: si no puedes encontrar comportamiento para una clase candidata determinada es altamente probable que ese concepto no deba existir en tu programa o que no deba existir como una clase.

Creo que la clase héroe es correcta.La demás son prescindibles.Mas parecen una lista de valores que pueden tomar
las propiedades.

He hecho otro ejemplo:

 

Se podría suponer que tenemos una clase infantería y luego esta es heredada por cada tipo de soldado con características
diferentes. Tales como su tipo,sus misiones, habilidades,sus armas, sus mejoras, que son diferentes por cada tipo de infantería.

Aunque me vuelve a recordar el ejemplo del héroe.Pero ya es diferente.

Es un ejemplo, naturalmente.Es curioso, lo fácil que es crear ejemplos de POO.

Saludos.

Shell escribió: [Ver mensaje]

Hola fabian.
Es un problema común cuando comenzamos la creación de cualquier programa.Tenemos una serie de variables o datos que intentamos relacionar
de alguna manera y todo esta en el aire.Luego van encajando, dando forma.

No Shell, eso no es programación orientada a objetos, sino programación estructurada. En POO eso sólo se aplica a un nivel atómico (por decirlo de algún modo), es decir, cuando se escribe un método, pero no es el modo es que se analiza y diseña la "arquitectura" del programa.

Shell escribió: [Ver mensaje]

Me parecieron unos datos muy generales.Como el héroe tiene una serie de propiedades comunes a todos los héroes,asocie todas estas
propiedades al patrón o clase que los crea.

Te repito, que debes enfocarte siempre en encontrar "comportamiento" común, no "propiedades".

Shell escribió: [Ver mensaje]

El objeto sale de una clase concreta.Se crea con esta.Entonces, ¿ por que los llamas objetos si no forman parte de una clase ?.

En un programa orientado a objetos puro, todo es un objeto: los números son objetos, las cadenas son objetos, los booleans son objetos, las clases son objetos, las estructuras de control son objetos, los mensajes (las llamadas a los métodos) son objetos... Aunque el único lenguaje que cumple con esto (al menos que yo conozca) es Smalltalk.

Shell escribió: [Ver mensaje]

¿ Como puede crearse un objeto, si no forma parte de una clase ?.

En gambas no se puede, pero existen otros lenguajes que no se basan en clases para crear los objetos, por ejemplo, Self (basado en Smalltalk) y Javascript.

Shell escribió: [Ver mensaje]

He buscado el significado de "dominio", encontré una serie de términos algo confusos.

"Llamamos dominio de un programa al producto cartesiano entre los tipos de datos de las variables de entrada."

No, no, olvídate de la verificación formal. El dominio del problema es el conjunto de conceptos que es capaz de describir el problema (como un todo) completamente. El dominio de la solución serían todos los conceptos (objetos) capaces de describir la solución.

Shell escribió: [Ver mensaje]

Creo que la clase héroe es correcta.La demás son prescindibles. Mas parecen una lista de valores que pueden tomar las propiedades.

Exacto. Pero la esencia de toda clase es su comportamiento (sus métodos). La existencia en tu diseño de clases sin métodos tiene que disparar un alerta en tu mente, para que las revises muy concienzudamente porque es probable que sean incorrectas (aunque no siempre).

Shell escribió: [Ver mensaje]

He hecho otro ejemplo:

 

Se podría suponer que tenemos una clase infantería y luego esta es heredada por cada tipo de soldado con características
diferentes. Tales como su tipo,sus misiones, habilidades,sus armas, sus mejoras, que son diferentes por cada tipo de infantería.

No Shell, estarías repitiendo el mismo error. No tienes que hacer esa suposición basada en "características", sino en "comportamiento". Yo no puedo, con base en esa imagen, decirte si eso está bien analizado y diseñado según la POO. La única manera de saberlo sería analizar el dominio del problema y yo no lo conozco. Por eso sólo te puedo dar esta pauta general, pero fundamental, que es centrarse en el comportamiento.

Saludos.

===================
Cómo programar con Gambas

Speed Books: informática libre.

Shell escribió: 

Es un problema común cuando comenzamos la creación de cualquier programa.Tenemos una serie de variables o datos que intentamos relacionar
de alguna manera y todo esta en el aire.Luego van encajando, dando forma.

fabianfv escribió: 

No Shell, eso no es programación orientada a objetos, sino programación estructurada. En POO eso sólo se aplica a un nivel atómico (por decirlo de algún modo), es decir, cuando se escribe un método, pero no es el modo es que se analiza y diseña la "arquitectura" del programa.

Perdona, son las costumbres "muy" arraigadas de la programación estructurada.Pues si que cuesta cambiar la manera de pensar con la POO.
Cuando a lo mejor en realidad, debería ser mas sencillo que con la estructurada.

fabianfv escribió: 

Te repito, que debes enfocarte siempre en encontrar "comportamiento" común, no "propiedades".

Ahora ya se que el comportamiento son los métodos.Nunca los hubiera llamado así, pero es la manera de responder
una acción, por lo tanto un comportamiento. A veces estoy espeso.

De alguna manera estas creando,las respuestas de la aplicación sin pensar en nada mas.
No te entretienes si vas a necesitar una variable, una propiedad.Solo una respuesta.

fabianfv escribió: 

En un programa orientado a objetos puro, todo es un objeto: los números son objetos, las cadenas son objetos, los booleans son objetos, las clases son objetos, las estructuras de control son objetos, los mensajes (las llamadas a los métodos) son objetos... Aunque el único lenguaje que cumple con esto (al menos que yo conozca) es Smalltalk.

Complicado, llamar a todo un objeto.Tengo en mente siempre que el objeto se crea a partir de una clase.

Lo primero que se me vino a la cabeza, fue eso, variables.Entendiendo un conjunto de cosas que forman el héroe, pero no que hace este, como se desenvuelve.
Por ejemplo, las armas no pueden usarlas todos los héroes, son propias de cada uno, de su rango, de su profesión.Y si queremos complicarlo, de su nivel
adquirido,su experiencia, destreza,fuerza.El arma en si, no puede ser usada por un héroe inexperto.

La aplicación exclusivamente se basa en generar un carácter.Solo comprueba una serie de normas que están en unas tablas para crear un personaje
y que no incumpla esas normas.

Shell escribió: 

Del ejemplo del ejercito:

"fabianfv escribió: 

No Shell, estarías repitiendo el mismo error. No tienes que hacer esa suposición basada en "características", sino en "comportamiento". Yo no puedo, con base en esa imagen, decirte si eso está bien analizado y diseñado según la POO. La única manera de saberlo sería analizar el dominio del problema y yo no lo conozco. Por eso sólo te puedo dar esta pauta general, pero fundamental, que es centrarse en el comportamiento.

Ok. Vamos a poner un trozo de código.Aunque no quería, por que esta basado en un juego comercial. Como es para estudiar
y no tiene ningún otro motivo.

Esta es la clase infantería.



Y ahora me centro en el ingeniero:



Este ejemplo, lo asimile del tuyo. El perro y el gato que "hablaban". Con su clase principal animal.
¿ Te acuerdas ?.

Como ves, son una serie de descripciones que seria valido una base de datos, que fue lo que hice al final.
Pero quise llevarlo un poco a la POO.

Gracias maestro, por hacer entrar en esta cabeza tan dura, conceptos de POO.  

===================
Gambas Básico
"No es un bug, es una característica no documentada"

Shell escribió: 

Ahora ya se que el comportamiento son los métodos.Nunca los hubiera llamado así, pero es la manera de responder
una acción, por lo tanto un comportamiento. A veces estoy espeso.

El problema es que hay mucha literatura que se jacta de enseñar programación orientada a objetos cuando lo que hace, en realidad, es mostrar solamente cómo se usan los recursos de un cierto lenguaje que dan soporte a la POO. La terminología que se usa en POO es muy importante conocerla porque esos vocablos conforman una metáfora consistente mediante la cual es posible comprender de qué se trata en realidad esto (Objeto, Mensaje, Interfaz o Protocolo de mensajes, Colaboración, etc).

Shell escribió: 

De alguna manera estas creando,las respuestas de la aplicación sin pensar en nada mas.
No te entretienes si vas a necesitar una variable, una propiedad.Solo una respuesta.

Exacto. Esto es fundamental en varios aspectos.

En primer lugar, porque te permite tomar la perspectiva externa, la del usuario del objeto; eso te conduce a plantearte cuál debería ser la interfaz (el protocolo de comunicación) del objeto con el exterior, es decir, en los mensajes que el objeto debería entender y a los que debería responder, sin tener que pensar en cómo implementarlo; es decir, permite pensar en qué debe hacer un objeto sin tener que pensar en cómo lo hará.

En segundo lugar, uno puede centrarse en cosas fundamentales como por ejemplo la consistencia en la denominación de las clases y de los métodos. Los nombres son fundamentales porque van conformando la metáfora mediante la que uno "visualiza" el diseño general del programa.

En tercer lugar, favorece que uno pueda plantear alternativas de diseño, evaluarlas y optar por una, porque uno sabe que debe hacer cada clase y no es necesario meterse con los detalles de implementación.

En cuarto lugar, el diseño resultante será más claro y flexible (es decir, con mayor facilidad para introducir cambios y añadir funcionalidades al programa) que si uno se centrara en los "datos". Por ejemplo, al definir que tal método de tal clase debe cumplir con tal responsabilidad (lo que debe hacer), como no nos metemos con el "cómo", es decir, la implementación, cuando finalmente lo hagamos podemos usar cualquier tipo de estructura de datos que necesitemos. En cambio, si hubiéramos definido al objeto a partir de los datos (variables) hubiéramos definido de entrada las estructuras de datos, ello nos conduciría a una forma muy particular (muy sesgada) de entender lo que el objeto "debe hacer". No es fácil de ver a la primera, pero realmente centrarse en los datos hace que el código resultante sea inflexible y que las clases tengan alto acoplamiento.

Shell escribió: 

fabianfv escribió: 

En un programa orientado a objetos puro, todo es un objeto: los números son objetos, las cadenas son objetos, los booleans son objetos, las clases son objetos, las estructuras de control son objetos, los mensajes (las llamadas a los métodos) son objetos... Aunque el único lenguaje que cumple con esto (al menos que yo conozca) es Smalltalk.

Complicado, llamar a todo un objeto.Tengo en mente siempre que el objeto se crea a partir de una clase.

Y eso es verdad en la mayoría de los lenguajes orientados a objetos, pero no es un requisito. Es más importante comprender que en programación orientada a objetos "todo (debería ser) es un objeto".

Te pongo un ejemplo simplista: en un programa se necesita saber la edad de una persona y hay varias "reglas de negocio" (restricciones) asociadas con la edad.

Un "pensador estructurado" que usa un lenguaje de objetos que no es puro, crearía una clase Persona y una variable "FechaNacimiento" a partir de la cual calcularía la edad de la persona y en algún método de esta clase escribiría el código de validación que asegura que esas restricciones se cumplan. Para esta persona FechaNacimiento es una variable de un tipo nativo (Integer) y Edad es un dato calculado.

En cambio, un "pensador de objetos" podría concebir al concepto Edad como un objeto colaborador de Persona (Persona tendría una variable de referencia a un objeto de clase Edad y sería responsable de su instanciación). Ese objeto edad tendría la responsabilidad de calcular la edad de la persona a partir de su fecha de nacimiento. Además, podría concebir las restricciones que se deben aplicar también como objetos, de modo que los métodos en los que el "pensador estructurado" añadía todo el código de validación, el "pensador de objetos" sólo tendrá que añadir llamadas a los métodos que realizan esas validaciones y que pertenecen a la clase (o clases) que tiene como responsabilidad conocer y saber cómo aplicar esas restricciones.

El ejemplo de Edad puede parecer trivial, pero imagina que luego el programador se da cuenta de que existe la necesidad en el programa de conocer la "antigûedad" de ciertos conceptos (objetos). Resulta fácil observar que Edad y Antigüedad son básicamente el mismo concepto y, por lo tanto, la misma clase de objeto. Ahora el "pensador de objetos" puede reutilizar la clase Edad y donde lo necesite añadir una variable de referencia, que por conveniencia puede llamar Antigüedad, de tipo (clase) Edad, en cualquier clase que lo necesite. En cambio, el "pensador estructurado" muy probablemente hubiera duplicado código añadiendo variables de tipo Integer con un nombre como "FechaFabricación" y una función que calcula su antigüedad (su edad).

También podría pasar que una persona tuviera diferentes "edades", por ejemplo, su antigüedad en diferentes trabajos. Por supuesto, se podría cambiar el nombre de la clase Edad por Antigüedad porque parece ser un concepto más general (aplicable a más casos) que el de Edad, de modo que en la clase Persona, Edad sería el nombre de una variable de clase "Antigûedad".

El caso es que es muy fácil duplicar código y crear un diseño confuso cuando se "piensa en forma estructurada". En cambio, es mucho más fácil realizar un diseño limpio, más sencillo y más adaptable, y evitar la duplicación de código cuando se "piensa en términos de objetos". Además, este ejemplo muestra que es mucho más fácil darse cuenta de que Edad y Antigüedad son el mismo concepto, también es más sencillo comprender cómo generalizar (utilizar la herencia) y agregar (conformar objetos a partir de otros) objetos.

Shell escribió: 

Lo primero que se me vino a la cabeza, fue eso, variables.Entendiendo un conjunto de cosas que forman el héroe, pero no que hace este, como se desenvuelve.
Por ejemplo, las armas no pueden usarlas todos los héroes, son propias de cada uno, de su rango, de su profesión.Y si queremos complicarlo, de su nivel
adquirido,su experiencia, destreza,fuerza.El arma en si, no puede ser usada por un héroe inexperto.

La aplicación exclusivamente se basa en generar un carácter.Solo comprueba una serie de normas que están en unas tablas para crear un personaje
y que no incumpla esas normas.

Este es el típico caso de modelar las reglas de negocio como objetos. Hay patrones de diseño que se pueden aplicar. Es largo y no puedo explicar todo eso en un comentario.

Shell escribió: 

Del ejemplo del ejercito:

"fabianfv escribió: 

No Shell, estarías repitiendo el mismo error. No tienes que hacer esa suposición basada en "características", sino en "comportamiento". Yo no puedo, con base en esa imagen, decirte si eso está bien analizado y diseñado según la POO. La única manera de saberlo sería analizar el dominio del problema y yo no lo conozco. Por eso sólo te puedo dar esta pauta general, pero fundamental, que es centrarse en el comportamiento.

Ok. Vamos a poner un trozo de código.Aunque no quería, por que esta basado en un juego comercial. Como es para estudiar
y no tiene ningún otro motivo.

Esta es la clase infantería.

Código: [Descargar] [Ocultar] [Seleccionar]

Código: [Descargar] [Mostrar]

PRIVATE $nombre AS String

PUBLIC SUB _new(nombre AS String)  
  $nombre = nombre  
END

PUBLIC SUB getNombre() AS String  
  RETURN $nombre  
END

PUBLIC SUB Nombre()  
    
END

PUBLIC SUB Tipo()    
  
END

PUBLIC SUB Mision()  
 
  
END

PUBLIC SUB Armas()
  
  
END

PUBLIC SUB Mejoras()
  
  
END

PUBLIC SUB Habilidades(cajatexto AS TextArea)
  
  
END

 

Y ahora me centro en el ingeniero:

Código: [Descargar] [Ocultar] [Seleccionar]

Código: [Descargar] [Mostrar]

INHERITS Infanteria

PUBLIC SUB Nombre()  
  PRINT ME.getNombre()  
END

PUBLIC SUB Tipo() AS String
  RETURN "Ingeniero"  
END

PUBLIC SUB Mision() AS String  
   RETURN "Construcción y apoyo"    
END

PUBLIC SUB Armas() AS String
  RETURN "Ametralladora M3"  
END

PUBLIC SUB Mejoras() AS String
  RETURN "Lanzallamas,buscaminas"  
END

PUBLIC SUB Habilidades() AS String
   RETURN "Despejar alambre,plantar cargas de demolición." &
  "Los ingenieros son unidades de apoyo a otras tropas.Pueden construir y " &
  "mantener fortificaciones,colocar minas para dificultad el progreso del enemigo " &
  "y reparar vehículos en el campo de batalla.En combate también pueden enfrentarse " &
  "al enemigo de cerca.Aunque los ataques calibrados los deja desprotegidos."  
END
 

Este ejemplo, lo asimile del tuyo. El perro y el gato que "hablaban". Con su clase principal animal.
¿ Te acuerdas ?.

Sí, me acuerdo. Pero ese ejemplo sólo presenta el concepto de polimorfismo (ni siquiera es una explicación completa). Y no es una receta que puedas aplicar a cualquier caso. Fíjate que en ese ejemplo las clases Perro y Gato no repiten todos los métodos de la clase Animal, sino que redefinen un método, un comportamiento que es distinto tanto en la clase Perro como en la clase Gato, que está representado como la impresión de una cadena en la consola sólo por simplicidad. Piensa en vez de Habla, en Dormir, el Gato para dormir hará algo previamente... no se qué hacen los gatos, pero supongamos que busca un lugar alto para dormir como una rama de un árbol; a diferencia del gato, el perro dará muchas vueltas pequeñas intentando armar un colchón de hojas sobre el que acostarse.

En este código tuyo no parece haber ninguna razón para que exista una clase Ingeniero.



Otra historia sería si encuentras otros comportamientos. Habría que revisar todo con amplitud, no sólo un par de clases.

Saludos.

===================
Cómo programar con Gambas

Speed Books: informática libre.