elhacker.net cabecera Bienvenido(a), Visitante. Por favor Ingresar o Registrarse
¿Perdiste tu email de activación?.


 


Tema destacado: Personaliza-Escoge el diseño del foro que más te guste.


+  Foro de elhacker.net
|-+  Programación
| |-+  Scripting (Moderador: Eleкtro)
| | |-+  Duda POO
0 Usuarios y 1 Visitante están viendo este tema.
Páginas: [1] Ir Abajo Respuesta Imprimir
Autor Tema: Duda POO  (Leído 672 veces)
Camilo2001

Desconectado Desconectado

Mensajes: 6


Ver Perfil
Duda POO
« en: 8 Mayo 2017, 01:43 »

Hola manola. Recién empecé a programar orientado a objetos en python (estoy aprendiendo por mi cuenta). Estoy tratando de hacer un juego de cartas. El problema es que quiero crear una clase "Efecto", y desde esa clase instanciar los distintos efectos del juego. El problema es que cada efecto tiene que tener un metodo "usar" (que seria el que ejecuta el codigo caracteristico de cada uno) distinto al resto de los efectos. Busque por internet pero no encontre si se puede o como hacer para una vez instanciado el efecto modificarle los metodos. Se puede crear una clase para cada efecto, pero no deja de ser eso: una clase, y no un objeto, por lo que no se si seria correcto. Gracias desde ya :P


En línea

engel lex
CoAdmin
***
Desconectado Desconectado

Mensajes: 12.540



Ver Perfil
Re: Duda POO
« Respuesta #1 en: 8 Mayo 2017, 01:51 »

creas la clase efecto con usar... luego creas una clase "jugador" o "mundo", que contenga cada efecto, la clase efecto, debería representar un solo efecto, luego una clase padre, representaría varios efectos creando un objeto por cada efecto


En línea

El problema con la sociedad actualmente radica en que todos creen que tienen el derecho de tener una opinión, y que esa opinión sea validada por todos, cuando lo correcto es que todos tengan derecho a una opinión, siempre y cuando esa opinión pueda ser ignorada, cuestionada, e incluso ser sujeta a burla, particularmente cuando no tiene sentido alguno.
Camilo2001

Desconectado Desconectado

Mensajes: 6


Ver Perfil
Re: Duda POO
« Respuesta #2 en: 8 Mayo 2017, 02:13 »

  :o :o Entonces te referís a crear una clase "Efecto" padre, después de esa clase heredar a una clase especifica para cada efecto y desde esa clase instanciar?
En línea

engel lex
CoAdmin
***
Desconectado Desconectado

Mensajes: 12.540



Ver Perfil
Re: Duda POO
« Respuesta #3 en: 8 Mayo 2017, 03:08 »

no, no la heredas...

Código:
clase efecto{
  publico:
    texto nombre;
    texto efecto;
    entero fuerza;
   
    efecto(nomb){
      nombre = nomb
      fuerza = 1;
    }
}

clase mundo{
  publico:
    efecto cosa1;
    efecto cosa2; 
    mundo(){
      efecto1 = nuevo efecto("primer efecto");
      efecto2 = nuevo efecto("segundo efecto");
    }


}
En línea

El problema con la sociedad actualmente radica en que todos creen que tienen el derecho de tener una opinión, y que esa opinión sea validada por todos, cuando lo correcto es que todos tengan derecho a una opinión, siempre y cuando esa opinión pueda ser ignorada, cuestionada, e incluso ser sujeta a burla, particularmente cuando no tiene sentido alguno.
NEBIRE


Desconectado Desconectado

Mensajes: 569


Ver Perfil
Re: Duda POO
« Respuesta #4 en: 8 Mayo 2017, 04:10 »

Lo que describes es lo que se llama una interfaz.

Una interfaz, recoge por lo general solo los nombres de los métodos que contiene el objeto... (la firma, sin contener código en su interior).
Luego hay que implementar la interfaz. Cada clase que implementa una interfaz hereda pues todos sus miembros, pero al implmenetarlos, cada uno puede hacerlo de forma distinta (incluso algunos pueden tener el mismo código para determinados métodos).

Si hay un comportamiento por defecto, para uno o varios métodos, entonces ese comportamiento puede estar descrito (escrito el código), en la propia interfaz y desde la clase que la implementa, si no tiene un comportamiento distinto a la de la interfaz (el comportamiento por defecto), entonces para ese método se invoca a la interfaz).
... pero ojo, la interfaz no debe retener métodos privados, ya que si no serían sobrescritos por clases diferentes y no sería algo deseable (cuando es deseable suele ser en casos en los que actúa como un servidor y admite que diferentes 'componentes' (objetos), puedan modificarlo y los demás puedan aceptarlo (pero esto es algo muy distinto a lo que tú buscas)).

Código:
Interfaz Planta

enumeracion TipoDehojas  
   Perenne=0
   Caducifolio=1
fin enumeración

propiedad Nombre
Propiedad Raiz  ' valor fijo para propiedad...
   Raiz = True
fin propiedad
propiedad Hojas(modelo como TipoDehojas))
propiedad Fruto
propiedad Tallo
propiedad FechaDeRecoleccion
método Madurar(CantidadFrutos)
método Floracion(Cantidad, Color)
método Recolectar( P como Planta, fechaActual) como buleano
   Si p.FechaDeRecoleccion >= fechaActual luego
       Mostrar mensaje "Ha llegado la hora de recolectar."
       Devolver cierto
   fin si ' devuelve falso   
fin metodo
 
' si hubiera métodos privados, las clases que implementen la interfaz, no requieren implementarlos... o si los necesita puedne llamarse de forma diferente y contener parámetros distintos.


---------------------------------
Código:
Clase Amapola implementa Planta

miembro privado _TipoDehojas como TipoDeHojas
miembro privado _FechaDeRecoleccion numero

propiedad Nombre
   Devolver "Amapola"
fin propiedad
propiedad Raiz   'ejemplo que delega en algo por defecto.
   Devolver Planta.Raiz
fin propiedad

' Nota que por simplicidad se ha puesto propiedad x... como representación de lo que corresponda: lectura y escritura/solo lectura/ solo escritura)
' Aquí se representaría Write y Read de la propiedad Hojas
propiedad HojasW(modelo como TipoDehojas)
    _tipoDehoja=modelo
fin propiedad
propiedad HojasR como TipoDehojas
    devolver _TipoDeHojas
fin propiedad

propiedad Fruto....
...
...
...
propiedad FechaDeRecoleccion
     devolver _FechaDeRecoleccion
fin propiedad

método Madurar(CantidadFrutos)
....
fin metodo
método Floracion(Cantidad, Color)
    llamar AumentarFlores(Cantidad)
    llamar CambiarColores(Color)
Fin método
método Recolectar( P como Planta, fechaActual) como buleano ' método por defecto...
    llamar Planta.Recolectar(Esta Amapola, FechaActual)
fin metodo


metodo privado AumentarFlores(cantidad)
...
fin metodo
metodo privado CambiarColor(Color)
...
fin metodo



Otra planta, podría tener una floración diferente, pero en cambio la propiedad Hojas  no tenga diferente contenido de la anterior pero cada cual debe guardar ese dato sobre sí mismo... La propiedad Raiz, sobre todas tendrán raíz, pero es un modo dever como se delega en la interfaz cuando algo es común. Algunos lenguajes no permiten a un interfaz nada más que definir su composición, no admitiendo código alguno.
Quizás en vez de implementar directamente una planta u otra, si uno va a implementar 8pongamos) cientos de plantas, es seguro que mucha funcionalidad va ser equivalente en un muchas plantas, entonces es cuendo se puedne implementar sólo determinadas ramas de plantas (por ejemplo acuáticas, cereales, legumbres, tuberculo, arbol, etc...) y luego las diferencias entre las diferentes plantas heredarlas de la clase padre.... (por ejemplo: trigo, centeno, maíz, heredarla de la clase cereal, que podría mantener una característica 'espigas' que en la interfaz podría ser algo más abstracto, partiendo de la propiedad Fruto, que podría ser una enumeración desde "no tiene" hasta el resto "grano de espiga", "grano de vaina", "fruta fresca", "fruto seco", etc...
« Última modificación: 8 Mayo 2017, 04:19 por NEBIRE » En línea

NEBIRE


Desconectado Desconectado

Mensajes: 569


Ver Perfil
Re: Duda POO
« Respuesta #5 en: 8 Mayo 2017, 16:58 »

Ten en cuenta que la herencia está más enfocada a la reutilización de código. Una interfaz se vale del mecanismo del paradigma de la POO, llamado Polimorfismo, cuyo objetivo principal es tener un comportamiento diferente, para los mismos métodos. El polimorfismo, no deja de ser una herencia, pero si no es bien entendido se desaprovecha su potencial, y bien entendido se hace herencias más sencillas y útiles.
En línea

Páginas: [1] Ir Arriba Respuesta Imprimir 

Ir a:  

Aviso Legal - Powered by SMF 1.1.21 | SMF © 2006-2008, Simple Machines