No entiendo las interfaces

Citar

Escrito el 26 Feb 2009 04:14 pm

Lo voy a intentar, pero sé que me voy a quedar muy corto, porque tiene que ver con patrones, clases abstractas y "yerbas" de ese porte. Así que vamos con algo más sencillo que es más frecuente que nos encontremos con ello. Así que sea sólo una breve introducción con un ejemplo muy sencillo

Imaginemos que tenemos dos Clases con un método que se llame igual, aunque hagan cosas distintas. Un ejemplo puede ser una clase "Sonido" que tenga el método "play" -que haga sonar el sonido- y una clase "Video" que también tenga el método "play" -que muestra un vídeo-

Ahora queremos tener una función que reciba como argumento un objeto de cualquiera de las clases y que quiera ejecutar el método play() del objeto. Vamos

Código ActionScript :

//tenemos
var sonido:Sonido=new Sonido();
var video:Video=new Video();

//...y en algún momento queremos...
ejecutar(sonido);

Código ActionScript :

//nuestra función ejecutar sería
public function ejecutar(objeto){ 
    objeto.play()
}

No he puesto el tipo de objeto que es porque ¡¡NO LO SÉ!! Evidentemente eso generará un error.

Una solución pasa por escribir

Código ActionScript :

public function ejecutar(objeto:*){ 
    objeto.play() 
}

y Flash tratará de ejecutar el método play. En este caso funcionará y no nos tenemos que preocupar de nada.

La otra solución pasa por implementar un interface y que "objeto" sea del tipo del interface. Un interface no es más que escribir en un fichero .as (por ejemplo que se llame iitems.as). Se suele hacer que la primera letra de un interface sea siempre la "I" (i mayúscula)

Código ActionScript :

package  
{
   public interface IItems
        {
      function play():void;
   }
}

Así, si nuestras Clases implementan el "Interface IItems", serán algo parecido a

Código ActionScript :

public class Sonido extends Sprite implements IItems{
    .....habrá que implementar el método "play"....
}
//y
public class Video extends MovieClip implements IItems{
    .....habrá que implementar el método "play"....
}

Podremos escribir

Código ActionScript :

public function ejecutar(objeto:IItems){ 
    objeto.play() 
}

Otro ejemplo sería tener un bucle for each que recorra un array

Código ActionScript :

for each (var objeto:IItems in misItems){ //<--le decimos que el objeto será Sonido o Video, pero seguro 
                        //que implementa el método play()
      objeto.play();
}

Aunque bien es cierto que podemos escribir

Código ActionScript :

for (var i:int=0;i<misItems.length){
       misItems[i].play();
}

Pero bueno.

Ya sé que parece que no hemos ganado nada pero no es del todo cierto. Creando un interface:
1.-Nos aseguramos de que a la función ejecutar sólo le lleguen clases que implementen la interface IItems (si no el compilador nos dará un error)
2.-No forzamos tanto al player a averiguar qué objeto le pasamos.
3.-No tendremos problemas con las conversiones de cast
4.-Si tenemos un IDE (un editor de código) con "inteligence" (o como se diga), mientras estamos escribiendo código nos dirá los métodos y propiedades que tiene el "objeto".

No te preocupes que hay más y más sobre interfaces, pero de momento dejo el post aquí esperando que no los veas tan inútiles como te parecían.

Por Eliseo2

710 de clabLevel

Citar

Escrito el 26 Feb 2009 08:15 pm

Osea que las clases implementan interfaces. Pero a partir de las interfaces creas objetos (como las clases) que comparten las funciones especificadas dentro de la interfaz, pero estan desarrolladas (en codigo) dentro de las clases.

Estoy en lo cierto, o no se pueden crear objetos basados en interfaces?

Aun así, en tu ejemplo. Como sabe 'objeto' que es un video o un sonido para ejecutar una funcion u otra?

Si todo esto es correcto: No habría alguna manera mejor de hacerlo esto con herencias?
---------------------------
O es mas bien que las interfaces solo son una forma de restriccion/ampliacion de funciones no basadas en herencia?

Por ejemplo una funcion DevolverTexto. La podriamos tener en la clase una Cadena que solo tiene una variable String y la misma funcion la podriamos tener en en una clase CampoDeTexto que en este caso nos podria devolver lo que hay dentro escrito.

Es alguna de las 2 cosas que he dicho, las dos, o estoy diciendo locuras solamente? De todos modos, si es algo de lo que yo he dicho, me da la impresion de que con una buena organizacion de clases mediante herencia, polimorfismo, etc... podria conseguirse. No??

Muchas gracias Eliseo2 por la respuesta. Si me ha ayudado o no, creo q lo puedes leer en mi respuesta mejor que yo, lol.

Un saludo

Por X-TUS

94 de clabLevel

Citar

Escrito el 27 Feb 2009 08:52 am

Se suele decir que el sentido de los interfaces es "programar un interface, no un objeto". Evidentemente la frase está referida a funciones o componentes que reciben como argumento un objeto que no sabemos de qué clase es, pero sí que implementa un interface. ejemplos más complejos pueden ser, por ejemplo un "grid" que se rellene de datos. El "grid" se programa para que su "datasource" sea cualquier objeto capaz de devolver, p.e. un XML, -y al que programó el "grid" no le importa que ese objeto sea una clase que lea un fichero de texto, o una clase que lea una base de datos local, o una clase que devuelva datos leídos de un webservice.
Así que sí: "NO se pueden crear objetos basados en interfaces", un objeto se crea con una Clase

La función NO sabe que "objeto" es un Video o un Sonido. Pero es que las funciones no saben nada, las funciones sólo ejecutan instrucciones en tiempo de ejecución, y en tiempo de ejecución cuando le pasamos un Video, ya sabe que es un video. (quizá me excedí en la frase poco afortunada de que si hubieramos puesto objeto:* hacemos trabajar a flash para averiguar qué objeto es -olvidalá-)

Así que el motivo de implementar interfaces es porque vamos a tener una función (o un componente) que reciba como argumento (o que tenga como propiedad) un objeto del que desconocemos de qué clase va a ser.

Es lo que se conoce como poliformismo: La implementación de dos métodos es completamente diferente, pero a una función o a un componente o a un objeto le da igual.

Si quieres tener "una funcion DevolverTexto tanto en una clase Cadena como en una clase CampoDeTexto", no tienes porqué hacer un interface. Es cuando creas un componente o una función que le sea indiferente el objeto que reciba, cuando podemos pensar en crear un interface para tener mejor definido nuestra función (o nuestro componente)

Y sí, aunque los interfaces también pueden heredar uno de otro, no tiene nada que ver con la herencia.
Herencia se refiere a que, teniendo definida una Clase con diversos métodos y propiedades, una Clase que extienda de ella tendrá los mismos métodos y propiedades. Ya en Flash los tenemos. un objeto de la clase DisplayObject tiene la capacidad de mostrarse en la película, y tiene las propiedades "x" e "y". Un objeto de la clase MovieClip que extiende de DisplayObject también tiene esa capacidad de mostrarse en la película y tiene las propiedades "x" e "y". Además tiene una línea de tiempo. Un objeto de la Clase Button (que también extiende de DisplayObject") tiene la capacidad de mostrarse en la película, la propiedad "x" y la propiedad "y". Además tiene las características de un botón -pero no tiene linea de tiempo como un MovieClip.
Podemos, p.e. tener dos Clases Movil y MovilExtendido

Código ActionScript :

//Nuestra clase Movil
public class Movil extends MovieClip{
      public function Movil(){
           graphics.beginFill(0xFF00FF);
           graphics.drawCircle(50, 50, 50);
           graphics.endFill();
           this.addEventListener(Event.ENTER_FRAME, mover);
      }
      public function mover(e:Event){
           this.x++
      }
}

Podríamos tener una clase MovielExtendido de la forma

Código ActionScript :

//Nuestra clase MovilExtendido
public class MovilExtendido extends MovieClip{
      public function MovilExtendido(){
           graphics.beginFill(0xFF00FF);
           graphics.drawCircle(50, 50, 50);
           graphics.endFill();
           this.addEventListener(Event.ENTER_FRAME, mover);
      }
      public function mover(e:Event){
            this.x++
     }
     public function parar(){
          this.removeEventListener(Event.ENTER_FRAME,mover)
     }
}

Así, un objeto de la clase Movil se movería y no habría forma de parralo y un objeto de la clase MovieExtendido podríamos pararlo.
Pero también podríamos haber definido nuestra clase MovilExtendido como

Código ActionScript :

public class MovilExtendido extends Movil{
      public function MovilExtendido(){
      }
     public function parar(){
          this.removeEventListener(Event.ENTER_FRAME,mover)
     }
}

¡Sólo hemos tenido que definir el método "parar"! Eso es porque MovilExtendido "hereda" todas las propiedades y métodos de
Pero observa que esto ha sido posible debido a que el modo de moverse hacia la derecha es idéntico en uno u otro caso.
No es como cuando teníamos un interface, que sólo nos interesa que un método devuelve un valor, pero el modo de implementar cómo devuelve ese valor no nos interesa y es distinto según el objeto de que se trate.

Si quisiéramos que MovilExtendido se moviera hacia la izquierda tendríamos que "override" la función mover

Código ActionScript :

public class MovilExtendido extends Movil{
      public function MovilExtendido(){
      }
      public override function mover(e:Event):void{
            x--;
     }

     public function parar():void{
          this.removeEventListener(Event.ENTER_FRAME,mover)
     }
}

Sí, aunque una Clase herede ("extienda") de otra, todavía podemos hacer que los métodos se comporten de modo distinto. ¿es eso poliformismo? ¿es herencia? ¿tiene que ver con los interfaces?

En Adebe Center hay, en inglés :glups:, una introdución de OOP en AS.3 -no es un inglés demasiado difícil de seguir, pues hay mucho código-
NOTA (crítica):¿Por qué cojones todo el mundo cuando explica la OOP tiene que hablar de perros y gatos?

Por Eliseo2

710 de clabLevel

Citar

Escrito el 28 Feb 2009 12:04 am

Pero si la herencia la conozco perfectamente, lo que no pillaba son las interfaces

He seguido investigando por mi cuenta y creo q ahora mas o menos las entiendo.

De todos modos muchas gracias por tus explicaciones, me han ayudado bastante.

Por X-TUS

94 de clabLevel

Citar

Escrito el 02 Mar 2009 01:25 pm

Hola X-TUS

Mira el concepto de las interfaces en OOP no es simpe de enteder rapidamente, pero voy a tratar de ser lo mas ejemplifico posible para q lo entiendas (vos y todos los q lo lean)...

Veamos...

¿Q es una interface?
Una interface intenta crear un "contrato", o sea, especifica un grupo de funcionalidades o servicios (en definitiva, un API) que debe tener la clase que la implementa.

¿Porque solo se declaran las firmas de los metodos y no su implementacion?
Las interfaces solo definen que es lo "q debe hacer" la clase q la implementa y no el "como". Esto coincide en q los metodos declarados en la interfaz son siempre publicos. Esto es asi porq la idea de que la interfaz define un "contrato de cominicacion" con las demas clases.

Diferencia con clases abstractas
Una clase abstracta tiene la funcionalidad de proveer implementantaciones comunes a un grupo de clases hijas, o sea, una clase abstracta nos proporciona tanto el "que" y el "como". La interfaz intenta definir que funcionalidad (en OOP se dice "responsabilidad") van a tener las clases, o sea solo el "que".
Una clase abstracta puede implentar una interfaz para saber "que" responsabilidades tiene y adjuntarles el "como" hacerlas.

Responsabilidades en las clases
Cuando estas diseñando en OOP lo q uno arma son objetos q se comunican entre si (uno no diseña clases, diseña objetos q luego se les define un estereotipo, o sea, la clase. Una clase es como la firma de un objeto, por decirlo de alguna manera). Los objetos tienen responsabilidades, muchas veces compartidas con otros objetos, por ese motivo aparecen las interfaces y las clases abstractas (Luego veremos cuando usar una u otra).

Veamos unos ejemplos basicos

Código ActionScript :

packague 
{
      public interfaz ICamina
      {
         function caminar():void;
      }
}

Aca definimos la interfaz ICamina, por lo cual, estamos definiendo una responsabildad que tiene la interfaz y en su defecto, una de las responsabilidad es que van tener las clases q la implementen.

Código ActionScript :

package
{
     public class Persona implements ICamina
     {
          public function caminar():void
          {
               //implementacion
          }
     }
}

Esta es una implementacion válida para la interfaz ICamina. La implementacion de una interfaz a una clase determina el agregado de resposabilidades a la misma.

Ahora tb podemos crear esta clase

Código ActionScript :

package
{
     public class Perro implements ICamina
     {
          public function caminar():void
          {
               //implementacion
          }
     }
}

Es otra implmentacion valida para ICamina. Pero con una salvedad, la funcion caminar en la clase Persona y en la clase Perro sera my diferente ya q una persona camina sobre sus dos piernas y un perro utiliza sus cuatro patas.

Cual fue mi intencion al implentar la interfaz
Veamos, ponele q vos tengas un juego de plataformas, en donde el personaje principal pueda variar en una persona o un perro (ridiculo yase, pero bueno... je). El juego tendra un control para hacer caminar al personaje... pero pensemos un momento... ¿al juego le interesa q sea un perro o una persona? mmm no... solo le interesa que el objeto q hace referencia al personaje sepa q debe caminar y ademas sepa como hacerlo. Esto se conoce como "polimorfismo" en OOP (o por lo menos en una de sus tantas variantes). Como podes ver aca ya le estamos sacando jugo a las interfaces, ya no nos importa q objeto (clase) estamos usando, sino q ese objeto sepa que debe hacer "algo".

Polimorfismo con interfaces
Es un concepto complicado... pero veamoslo sencillamente. La idea es "utilizar" objetos sin saber cuales son, sino que el objeto q va a hacer uso de el, sepa (y este seguro) q este objeto puede realizar algo...
Veamos, si tenemos el objeto "A" y este le tiene q indicar q "camine" a un objeto "B", el objeto "B" puede pertenecer a cualquier clase q implemente el metodo "camine" y A no debe interesarle q tipo de objeto B es... sino q tiene un objeto al que le puede ejecutar camine.
Veamos un ejemplo

Código ActionScript :

package
{
    public class Juego
    {
          public var personaje:ICamina;
          
          public function caminar():void
          {
                  this.personaje.caminar();
          }
     }
}

Veamos como usarlo

Código ActionScript :

var juego:Juego = new Juego();
juego.personaje = new Persona();
juego.caminar();
.
. //aca el personaje le aplicarion una magia y se convirtio en perro
.
juego.personaje = new Perro();
juego.caminar()

Este es un ejemplo de polimorfismo y de uso de interfacez para definir contratos de responsabilidades.
Como ves, la clase Juego no conoce si el personaje es un Perro o una Persona, sino que sabe q el objeto q hace referencia la variable "personaje" saber q puede caminar...
Este es un ejemplo claro del uso de interfaces, de polimorfismo, de reutilizacion y modularizacion.

Cuando utilizar interfaces y clases abstractas
No hay nada fijo de cuando utilizar una u otra opcion. Es mas, una no reemplaza a la otra. La idea es saber para que sirve cada una y utilizarlas correctamente.

Debo declarar todos los metodos en la interfaz
No, solo los metodos q seran compartidos, o sea... uno al crear una clase define un API de comunicacion con otras clases. La idea es q cuando un objeto debe utilizar otro, este sepa q le puede "solicitar" y esto es por medio de la interfaz.
Hay q tener en cuenta q una clase puede tener cualqueir cantidad de interfaces.

Bueno... este es un comienzo para q puedas entender el concepto de interfaz... hay un poco mas para seguir, pero la base es esta, el resto lo entenderas tranquilamente cuando ya estes un poco canchero con esto..

Saludos y cualquier cosa chifla. bye!

Por alfathenus

833 de clabLevel

5 tutoriales

buenos aires || Argentina

Citar

Escrito el 02 Mar 2009 01:40 pm

Sigamos...

Toda clase debe implementar interfaces
No, no todas las clases deben implementar interfaces. Solo las clases necesarias.

Cuando utilizar intefeces
Hay muchos motivos por los que se quiere implmentar interfaces, veamos algnos
Para polimormismo de objetos: Como vimos en los ejemplos.
Para comunicacion: Supongamos q tenemos un sistema y 2 subsistemas. El sistema carga los dos subsitemas y a cada uno, supongamos q esos dos subsistemas deben tener si o si ciertas responsabilidades (por ejemplo "calcular", "dame estadisticas", etc) ademas de sus tareas en particular cada uno... En ese caso se definiria una intefaz con las "responsabilidades" comunes a los 2 subsitemas, de esa manera el sistema sabe q el objeto q carga implementa esas funcionalidades.
Para trabajar en equipo[/b]: Supongamos ahora q estos 2 subsistemas pasan a ser cientos... bueno ahi el resto del equipo se encargaria de hacer los diferentes subsistemas y con la interfaz te aseguras q los diferentes subsitemas puedan interactuar correctametne con tu sistemas... es mas... si alguno de estos subsitemas es un componente de tercero o si se tereceriza su construccion, te aseguras q va a andar correctamente en tu sistema.
[i]Compartir codigo/librerias: Podes crear librerias de componentes y solo publicar sus API, o sea su interfaz, dejando la implementacion oculta. Los sistemas q implementaran tus componentes saben q cumplen un cierto contrato "interfaz".

BUeno.. eso fue algo q me olvidaba en el post anterior

Saludos!

Por alfathenus

833 de clabLevel

5 tutoriales

buenos aires || Argentina

Citar

Escrito el 02 Mar 2009 05:39 pm

Mmmm sinceramente nunca le encontré una funcionalidad a las interfaces..
voy a crear un ejemplo con el mismo consepto que explicaste, (el de tu Humano perro jaja) para que me expliques (para aprender) la diferencia entre hacerlo con interfaces o sin ellas.

Veamos en tu ejemplo tenias la interface caminar, aca no vamos a usar interface..
asi que:

Creamos a nuestro humano.. (con su método publico caminar)

Código ActionScript :

package { 
     public class Humano extend Sprite{ 
          public function caminar():void { 
               //implementacion 
          } 
     } 
}

Creamos a nuestro Perro: (también con su método caminar)

Código ActionScript :

package { 
     public class Perro extend Sprite { 
          public function caminar():void{ 
               //implementacion 
          } 
     } 
}

y Por ultimo a nuestro Juego:

Código ActionScript :

package { 
    public class Juego { 
          public var personaje:Sprite; 
           
          public function caminar():void { 
                  this.personaje.caminar(); 
          } 
     } 
}

Lo implementamos!!

Código ActionScript :

var juego:Juego = new Juego(); 
juego.personaje = new Persona(); 
juego.caminar(); 
. 
. //aca el personaje le aplicarion una magia y se convirtio en perro 
. 
juego.personaje = new Perro(); 
juego.caminar()

asi que, cual fue la diferencia y la ventaja entre usar interface y no??..
Sinceramente no le encuentro diferencia en la funcionalidad.

Por phoxer

Claber

827 de clabLevel

4 tutoriales

Genero:Masculino

Ing en Sistemas

@phoxer

Citar

Escrito el 02 Mar 2009 05:55 pm

Creo que entiendo el punto de alfathenus. El objetivo de las interfaces no es que tan funcional sea sino que tan "ordenado" y "claro" sea tu codigo, es como un asunto de buenas costumbres

Muchas veces no le damos mucha inportacia a esta parte, yo en lo personal siempre he programado a lo que "sirva", aunque todo al final quede un deshorden

Ultimamente he visto la importancia de aplicar lo que es una buena programacion OOP, especialmente cuando alguien superior a ti va a revisar tu codigo, y en especial de que te acepten en un trabajo por ello

Aunque el ejemplo de phoxer sirva de igual manera, al final es mas profesional, mas lindo, entendible y rehutilizable usar interfaces.

Por Lunaty

Claber

118 de clabLevel

Genero:Femenino

Flash Developer & RM Email Support for Google

@lunatybu

Citar

Escrito el 02 Mar 2009 07:28 pm

Phoxer ¿has intentado compilar la clase Juego? ¿en modo extricto?
Si lo haces supongo que saldrá un error de "llamada a un método caminar posiblemente no definido" (porque la clase Sprite no tiene ningún método "caminar")
Vale, si me dices que has definido la variable personaje como MovieClip sí que compila la clase Juego pero ¿no te da error al decir que juego.personaje=new Persona();?
Vale, le realizamos una conversión de cast de tal modo que juego.personaje=MovieClip(new Persona()) pero no sé si te va a dejar puesto que Persona no extiende de MovieClip......
Puff. no hay modo de salir del lío. Un interface no es necesario hasta que queremos usar un método (o tener una clase) que maneje un "algo" que no sabemos si a priori es Perro, Humano, Persona o Extraterrestre. No es que "sea más lindo", es que hay veces que no tenemos otra

Por Eliseo2

710 de clabLevel

Citar

Escrito el 02 Mar 2009 08:24 pm

Eliseo2 escribió:

Phoxer ¿has intentado compilar la clase Juego? ¿en modo extricto?
Si lo haces supongo que saldrá un error de "llamada a un método caminar posiblemente no definido" (porque la clase Sprite no tiene ningún método "caminar")
Vale, si me dices que has definido la variable personaje como MovieClip sí que compila la clase Juego pero ¿no te da error al decir que juego.personaje=new Persona();?
Vale, le realizamos una conversión de cast de tal modo que juego.personaje=MovieClip(new Persona()) pero no sé si te va a dejar puesto que Persona no extiende de MovieClip......
Puff. no hay modo de salir del lío. Un interface no es necesario hasta que queremos usar un método (o tener una clase) que maneje un "algo" que no sabemos si a priori es Perro, Humano, Persona o Extraterrestre. No es que "sea más lindo", es que hay veces que no tenemos otra

Eliseo2, no he intentado compilar la clase , pero si tienes razon que tiraria ese error.. y que oviamenete si crearon las interfaces no creo que sea por nada. solamente que no las veo tan utilez y creo que se pueden usar alternativas mas simples, nada mas..

y con respecto a mi error, cambiaría mi clase juego por:

Código ActionScript :

package {  
    public class Juego {  
          public var personaje:Object;  
            
          public function caminar():void {  
                  this.personaje.caminar();  
          }  
     }  
}

Teniendo en cuenta que Object es la base de todas las clases.
Sprite > DisplayObjectContainer> InteractiveObject>DisplayObject>EventDispatcher>Object

Asi no tiraría error, ya que personaje puede ser representado por Humano o perro con el método caminar();..

Igualmente aclaro no digo que no hay que usar interfaces, es mas, ojala las implementara mas seguido si es un "estandar" pero no lo veo tan "necesario", a eso voy..

Por phoxer

Claber

827 de clabLevel

4 tutoriales

Genero:Masculino

Ing en Sistemas

@phoxer

Citar

Escrito el 02 Mar 2009 08:26 pm

Buenas gente

Lunaty escribió:

Creo que entiendo el punto de alfathenus. El objetivo de las interfaces no es que tan funcional sea sino que tan "ordenado" y "claro" sea tu codigo, es como un asunto de buenas costumbres

El objetivo de las interfaces es totalmente funcional. Las interfaces deberias especificar cuales son las funcionalidades de un sistemas, define el API del sistema, por lo q cual sistemas q se interrelacionan con el, saben q funcionalidad es ofrece.

Phoxer,
Mmm es un punto de vista valido...
Pero veamos ... los personajes de un juego (siguiendo el ejemplo) conforman un subsistema dentro del un sistema mayor (el juego), un subsistema es un sistema en si mismo y todo sistema se relaciona con otros.
La forma en q los diferentes sistemas saben como "hablar" entre ellos es por medio de "contratos". Estos contratos son las interfaces (o en menor medida clases abstractas), o sea, un sistema conoce la API de los sistema con los q interactua. Esta api esta definida en la interfaz.
Siguiendo el ejemplo, el personaje es la puerta de entrada al subsistema de personajes, lo q puede hacer un personaje lo define un contrato (interfaz) y todos los objetos q interactuan con el conocen su API (no le importa si es un Sprite o no), veamos

Código ActionScript :

packague
{
     public interfaz IPersonaje
     {
         function caminar():void;
         function saltar():void;
         function saltar():void;
     }
}

Ahora hagamos 2 implementaciones diferentes

Código ActionScript :

public class Personaje extends Sprite implements IPersonaje
{
     //implementamos los metodos
}

y tambien esta

Código ActionScript :

public class Personaje implements IPersonaje
{
    // implementamos los metodos
}

Mmmm son similares pero difernetes, fijate q la 2 no extiende de Sprite... veamos 2 puntos
1. Hace falta q personaje extienda de Sprite?
Mmm no secesariamente, eso depende de lo q necesecites. Yo no creo q extendiera de Sprite, principalmente porq utilizaria a Personaje como puerta de entrada a utilizar el personaje (piensen q este ejemplo es un poco trivial... hay ejemplos muuuucho mas complicados). La clase personaje puede utilizar un Sprite en forma de composicion o como referencia interna.
2. Hace falta q el juego sepa q Personaje es o no un Sprite?
MM totalmente no. El juego debe saber q tiene como referenecia un objeto, no importa cual ni de q tipo, pero q si cumple con el contrato IPersonaje, o sea, sabe q el objeto q tiene puede ejecutar todas las funciones q necesita pedirlo (pero no como lo hace).

Hora veamos la clase juego

Código ActionScript :

public class Juego
{
     public var personaje:IPersonaje;

     public function caminar():void
     {
         personaje.caminar();
     }
}

Como podes ver, de esta manera el codigo es mucho mas extensible para diferentes tipos de juegos, ya q personaje no tiene porque ser un Sprite. La idea es q no pienses mucho en este ejemplo en particular. Sino en el beneficio q trae q personaje cumpla un contrato, ya q para un jego puede q el personaje sea un sprite (un tipo corriendo) y en otro, por ejemplo, en un juego de ajedrez, el personaje es algo abstracto (la persona del otro lado del pc) y por lo tanto no tiene representacion grafica. Si usas la interfaz no vas a necesitar cambiar nada... este es un concepto bastante importante en cuanto a reutilizacion de codigo y comunicacion entre objetos.

Repito.... piensen un poco mas alla a una implementacion de juegos, por ejemplo un sistema de control de permisos

Código ActionScript :

public interfaz IPermission
{
     function get user():IUserData;
     function set user(value:IUserData):void
     
     function hasPermission(moduleKey:int):Boolean;
}

Esta interfaz es el contrato de permisos para cualqueir tipo de aplicacion, sea cual sea la implementacion de la misma.

Por ejemplo podemos crear 2 implementaciones, una q va a buscar el permiso a la BBDD y en otra ya tiene cargados los permisos

Código ActionScript :

public class Permiso1 implements IPermission
{
    public function hasPermission(moduleKey:int):Boolean
    {
       //va a buscar a la base de datos
    }
}

y esta

Código ActionScript :

public class Permiso2 implements IPermission
{
    public function hasPermission(moduleKey:int):Boolean
    {
       //ya tiene los permisos cargados en un objeto
    }
}

Como pueden ver son 2 implementaciones muy diferentes y si en nuestra aplicacion utilizamos el contrato querdaria

Código ActionScript :

class UserSystem
{
     public var user:IUserData;
     private var perm:IPermission;
     public function setPermissionSystem( value:IPermission):void
     {
        this.perm = value;
        this.perm.user = this.user;
     }
     public function hasPerm(moduleKey:int):Boolean
     {
        return this.perm.hasPermission(moduleKey);
     }
}
// y lo usamos asi
public var permSystem:UserSystem= new UserSystem();
permSystem.user = user;
permSystem.setPermissionSystem(new Permiso1());

Fijate q de esta forma el sistema de usuarios es independiente al sistema de permisos q utilices y este puede cambiar en cualquier momento, incluso podes especificar el sistema de persmisos un un archivo de configuracion xml, y con solo cambiar el xml cambias el sistema de permisos.
De esta forma obtenes un codigo mucho mas reutilizable y ademas es mucho mas sencillo trabajar en equipo. Podes usar la clase UserSytem en cualqueir lado y para cambiar el sistema de permisos de un sistema a otro, solo instancias una clase diferente q respete el contrato IPermission..... no es mucho mas reutilizable de esta manera?
Este ya es un ejemplo un poco mas avanzado pero talvez un poco mas demostrativo de para q se utilizan las interfaces...

Igualmente antes de ver esto hay un par de puntos q se deberian saber: Comunicacion y envio de mensajes entre objetos, intercomunicacion entre objetos, herencia, chain of responsabilities, polimorfismo, abstraccion de datos, encapsulamiento.... todos esos son temas q hay q ver antes de entrar en las interfaces.... Igualmente, en la teoria pura de OOP hay muchas ramas para donde encarar y depende del libro q leas o de quien sea tu profesor te orientaras mas para un lado u otro (talvez para un lado casi ni se usen las intefaces.... es mas creo q C++ no existen...)

Cualquier cosa chiflen... bye!!

Por alfathenus

833 de clabLevel

5 tutoriales

buenos aires || Argentina

Citar

Escrito el 02 Mar 2009 08:26 pm

Eliseo2: muy buen punto ese. En modo estricto no lo compila, y lo mejor es compilar siempre en ese modo asi te ahorras muchos errore en tiepo de ejecucion... ponele q si haces esto

Código ActionScript :

juego.personaje = new Sprite();

Compilaria lo mas bien, pero luego en tiempo de ejecucion no funcionara
(bah... si compilas desde flex creo q aunq no este en modo estricto no compila... pero desde flash si)

Por alfathenus

833 de clabLevel

5 tutoriales

buenos aires || Argentina

Citar

Escrito el 02 Mar 2009 08:55 pm

alfathenus escribió:

Ahora hagamos 2 implementaciones diferentes

Código ActionScript :

public class Personaje extends Sprite implements IPersonaje 
{ 
     //implementamos los metodos 
}

y tambien esta

Código ActionScript :

public class Personaje implements IPersonaje 
{ 
    // implementamos los metodos 
}

Mmmm son similares pero difernetes, fijate q la 2 no extiende de Sprite... veamos 2 puntos
1. Hace falta q personaje extienda de Sprite?
Mmm no secesariamente, eso depende de lo q necesecites. Yo no creo q extendiera de Sprite, principalmente porq utilizaria a Personaje como puerta de entrada a utilizar el personaje (piensen q este ejemplo es un poco trivial... hay ejemplos muuuucho mas complicados). La clase personaje puede utilizar un Sprite en forma de composicion o como referencia interna.
2. Hace falta q el juego sepa q Personaje es o no un Sprite?
MM totalmente no. El juego debe saber q tiene como referenecia un objeto, no importa cual ni de q tipo, pero q si cumple con el contrato IPersonaje, o sea, sabe q el objeto q tiene puede ejecutar todas las funciones q necesita pedirlo (pero no como lo hace).

Tenez razon no hay motivo para que extienda de Sprite, la segunda es un Object.

alfathenus escribió:

Igualmente antes de ver esto hay un par de puntos q se deberian saber: Comunicacion y envio de mensajes entre objetos

No sirve con el numero de celular? jaja

(un poco de humor malo)

alfathenus escribió:

De esta forma obtenes un codigo mucho mas reutilizable y ademas es mucho mas sencillo trabajar en equipo. Podes usar la clase UserSytem en cualqueir lado y para cambiar el sistema de permisos de un sistema a otro, solo instancias una clase diferente q respete el contrato IPermission..... no es mucho mas reutilizable de esta manera?

La respuesta es Si.. Compro jaja.. para ciertos sistemas si es mejor utilizar una interfas, lo que yo decía es que no siempre es necesario usarlos, pero lo mejor es si siempre seguir la misma metodología por mas simple sea el proyecto.
Nadie quiere ser un pez que va contra la corriente jajaj (y me conoses que me gusta debatir jaja) asi que tratare de usar interfaces cuando sea necesario :wink:

.

Saludos.

Por phoxer

Claber

827 de clabLevel

4 tutoriales

Genero:Masculino

Ing en Sistemas

@phoxer

Citar

Escrito el 02 Mar 2009 09:57 pm

Como andas

phoxer escribió:

Nadie quiere ser un pez que va contra la corriente jajaj (y me conoses que me gusta debatir jaja) asi que tratare de usar interfaces cuando sea necesario

hahaha si ya se jajaja, y a mi tb!! bah... no discutir sino intercambiar opiniones sobre de desarrollo me encanta jajaja

Igual tampoco es ir a favor o en contra de la corriente, sino q simplemente tener diferentes herramientas para trabajar y elejir la q mejor se adapta (bajo las circunstancias de cada proyecto en particular) bajo fundamentos solidos...

phoxer escribió:

Tenez razon no hay motivo para que extienda de Sprite, la segunda es un Object.

Prefiero usar Sprite... un variable q acepta Object.... nonono solo en casos muuuy especificos

phoxer escribió:

La respuesta es Si.. Compro jaja.. para ciertos sistemas si es mejor utilizar una interfas, lo que yo decía es que no siempre es necesario usarlos, pero lo mejor es si siempre seguir la misma metodología por mas simple sea el proyecto.

Si cierto no siempre es mejor utilizarlos, a veces no hace falta, todo depende de muchos factores..... como por ejemplo el tiempo en hacer el trabajo, la futura reutilizacion del codigo q estes haciendo, etc, etc...

Mi intencion fue compartir un poco de conocimiento con respecto a las interfaces y q tanto X-TUS como cualqueir otra persona q lea el post y le interese aprenda un poco mas sobre q son las interfaces (ya q a mi me costo tambien bastante en comprender completamente), como utilizarlas y para que utilizarlas....
Espero q por lo menos algo de todo se haya entendido jajaja.... =D

Saludos!

Por alfathenus

833 de clabLevel

5 tutoriales

buenos aires || Argentina

Citar

Escrito el 02 Mar 2009 10:22 pm

alfathenus escribió:

Mi intencion fue compartir un poco de conocimiento con respecto a las interfaces y q tanto X-TUS como cualqueir otra persona q lea el post y le interese aprenda un poco mas sobre q son las interfaces (ya q a mi me costo tambien bastante en comprender completamente), como utilizarlas y para que utilizarlas....
Espero q por lo menos algo de todo se haya entendido jajaja.... =D

Si a mi me sirvió para entender en realidad bien las interfaces

(e imaginarme a un humano/perro :lol:

)
pero este tipo de hilos suelen aclarar muchas dudas, por lo menos a mi.

Por phoxer

Claber

827 de clabLevel

4 tutoriales

Genero:Masculino

Ing en Sistemas

@phoxer

Citar

Escrito el 03 Mar 2009 01:00 pm

Acabo de leerme solo la primera respuesta del hombre / perro y me ha quedado bastante claro, de hecho, esto me viene genial para un juego que estaba pensando...

Me he imprimido el resto para leermelo en el metro (ahora estoy en el curro) pq tiene buena pinta.

Un saludo

PD.

e todos modos lo del hombre que se transforma en perro no es tan ridiculo. Yo he visto juegos beat'em up que tu personaje principal se transforma en lobo...

Por X-TUS

94 de clabLevel

Citar

Escrito el 03 Mar 2009 08:02 pm

alfathenus escribió:

(talvez para un lado casi ni se usen las intefaces.... es mas creo q C++ no existen...)

Vamos que todo lo que se hace con interfaces se puede hacer sin ellas.

Yo creo que ya he pillado las interfaces (de hecho creo que voy a empezar a buscarles usos futuros) pero a que te refieres con lo de uso de interfaces para la comunicacion y envio de mensajes entre objetos?? Como pueden comunicarse 2 objetos mediante una interfaz? Podrias poner un ejemplo?

Muchas gracias, tus explicaciones han sido de gran ayuda.

Por X-TUS

94 de clabLevel