Club Delphi  
    FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Principal > OOP
Registrarse FAQ Miembros Calendario Guía de estilo Buscar Temas de Hoy Marcar Foros Como Leídos


Respuesta
 
Herramientas Buscar en Tema Desplegado
  #1  
Antiguo 14-03-2017
Critter Critter is offline
Miembro
 
Registrado: may 2003
Posts: 56
Poder: 15
Critter Va por buen camino
Interfaces y POO

Navegando encontré esta web que veo interesante, muestra un enfoque distinto a lo que conocía para el uso de interfaces y POO (al menos para mi, que soy novato).

me gustaría saber vuestra opinión al respecto.



http://objectpascalprogramming.com/p...-estatico-new/

Última edición por Critter fecha: 14-03-2017 a las 18:09:33.
Responder Con Cita
  #2  
Antiguo 14-03-2017
Avatar de jhonny
jhonny jhonny is offline
Jhonny Suárez
 
Registrado: may 2003
Ubicación: Colombia
Posts: 6.939
Poder: 21
jhonny Va camino a la fama
Gracias por compartirlo, http://objectpascalprogramming.com tiene unos artículos muy interesantes, enfoques que te ponen a pensar y en sí es uno de mis blogs favoritos en general. Muy buena recomendación
__________________
Lecciones de mi Madre. Tema: modificación del comportamiento, "Pará de actuar como tu padre!"

http://www.purodelphi.com/
Responder Con Cita
  #3  
Antiguo 15-03-2017
Avatar de AgustinOrtu
[AgustinOrtu] AgustinOrtu is offline
Miembro Premium
 
Registrado: ago 2013
Ubicación: Argentina
Posts: 1.777
Poder: 8
AgustinOrtu Es un diamante en brutoAgustinOrtu Es un diamante en brutoAgustinOrtu Es un diamante en brutoAgustinOrtu Es un diamante en bruto
Yo utilizo muchas interfaces dentro del dominio de las aplicaciones. Con ellas represento desde objetos que hacen trabajo, colaboradores, incluso a veces entidades si es que requieren de cierto comportamiento, hasta elementos visuales como imágenes, cuadros de diálogo, forms, controles, y más.

Por otra parte intento no usar métodos de clase si es posible. Menos aún para la creación de objetos. El motivo es porque usando métodos estáticos pierdo el polimorfismo. Para crear objetos, sino puedo usar dependency injection, utilizo algún tipo de factory, por lo general en forma de métodos anónimos
Responder Con Cita
  #4  
Antiguo 15-03-2017
Avatar de roman
roman roman is offline
Moderador
 
Registrado: may 2003
Ubicación: Ciudad de México
Posts: 20.075
Poder: 10
roman Tiene un aura espectacularroman Tiene un aura espectacular
Cita:
Empezado por AgustinOrtu Ver Mensaje
El motivo es porque usando métodos estáticos pierdo el polimorfismo.
¿A qué te refieres con esto?

LineComment Saludos
Responder Con Cita
  #5  
Antiguo 15-03-2017
Avatar de AgustinOrtu
[AgustinOrtu] AgustinOrtu is offline
Miembro Premium
 
Registrado: ago 2013
Ubicación: Argentina
Posts: 1.777
Poder: 8
AgustinOrtu Es un diamante en brutoAgustinOrtu Es un diamante en brutoAgustinOrtu Es un diamante en brutoAgustinOrtu Es un diamante en bruto
Como invocas a un metodo estatico? Metodo estatico son los de clase
Responder Con Cita
  #6  
Antiguo 15-03-2017
Avatar de roman
roman roman is offline
Moderador
 
Registrado: may 2003
Ubicación: Ciudad de México
Posts: 20.075
Poder: 10
roman Tiene un aura espectacularroman Tiene un aura espectacular
Cita:
Empezado por AgustinOrtu Ver Mensaje
Como invocas a un metodo estatico? Metodo estatico son los de clase
Pero son hereditarios ¿no? Es decir, no entiendo eso de que se pierde el polimorfismo.

LineComment Saludos
Responder Con Cita
  #7  
Antiguo 15-03-2017
Avatar de AgustinOrtu
[AgustinOrtu] AgustinOrtu is offline
Miembro Premium
 
Registrado: ago 2013
Ubicación: Argentina
Posts: 1.777
Poder: 8
AgustinOrtu Es un diamante en brutoAgustinOrtu Es un diamante en brutoAgustinOrtu Es un diamante en brutoAgustinOrtu Es un diamante en bruto
El resultado, el comportamiento que se observa, no varia, porque para llamar a un metodo estatico tenes que conocer la clase. Osea el codigo que se ejecuta es siempre el mismo y no va a variar a menos que varies la clase

Código Delphi [-]
type
  TClase = class
  public
    class function Ejecutar: string; { podria ser virtual, pero no cambia nada }
  end;

Si yo llamo a TClase.Ejecutar el codigo que se ejecuta es siempre el mismo y el resultado el mismo (o al menos, predecible). Esta decidido en tiempo de compilacion. Por eso digo que se pierde el polimorfismo. Como haces variar al comportamiento de TClase?

1. Cambiar el codigo del cuerpo de TClase.Ejecutar
2. Tener una subclase de TClase, por ej. TClaseHija e invocar a TClaseHija.Ejecutar.

Código Delphi [-]
type
  TClaseHija = class
  public
    class function Ejecutar: string; override;
  end;

Pero sigue siendo el mismo problema, no hay realmente polimorfismo

Para tener polimorfismo se pueden usar metaclases:

Código Delphi [-]
type
  TClaseClass = class of TClase;


procedure InvocarEjecutar(const Metaclass: TClaseClass);
begin
  Metaclass.Ejecutar;
end;

En este caso si tengo polimorfismo porque el codigo que se ejecuta depende de la metaclase que pase como parametro a InvocarEjecutar
Responder Con Cita
  #8  
Antiguo 15-03-2017
Avatar de roman
roman roman is offline
Moderador
 
Registrado: may 2003
Ubicación: Ciudad de México
Posts: 20.075
Poder: 10
roman Tiene un aura espectacularroman Tiene un aura espectacular
Cita:
Empezado por AgustinOrtu Ver Mensaje
En este caso si tengo polimorfismo porque el codigo que se ejecuta depende de la metaclase que pase como parametro a InvocarEjecutar
Pues entonces nunca perdiste el polimorfismo; no el polimorfismo de clases.

En objetos, si tomamos el típico ejemplo:

Código Delphi [-]
type
  TFigura = class
    procedure Dibuja(); virtual; abstract;
  end;

  TTriangulo = class(TFigura)
    procedure Dibuja; override;
  end;

  TCirculo = class(TFigura)
    procedure Dibuja; override;
  end;

  TEtcetera = class(TFigura)
    procedure Dibuja; override;
  end;

el polimorfismo se da cuando llamamos al método Dibujar desde una variable del tipo TFigura:

Código Delphi [-]
var
  F: TFigura;

....

F.Dibuja();

ya que, dependiendo de si F fue instanciado como TTriangulo, TCirculo o TEtcetera, el método variará. Si, en cambio, usas una variable del tipo explícito TTriangulo:

Código Delphi [-]
var
  T: TTriangulo;

....

T.Dibuja();

es, como dices, predecible qué método se llamará. Pero no por eso digo que se pierde el polimorfismo.

En el caso de clases es lo mismo: si usas una referencia particular, como TClaseHija, se "pierde" el polimorfismo, tanto como se pierde en TTriangulo. Pero, como tú mismo ejemplificas, si usas una referencia de clase general, como TClaseClass, "recuperas" el polimorfismo.

Lo interesante aquí sería que nos dieras un ejemplo más cercano a lo que quieres decir. Esto es, ¿en qué sentido usar un método de clases no te funciona y una interfaz sí? ¿En qué forma un método de clase que cree objetos no te funciona?

En otras palabras, creo que tienes en mente algo más específico y es eso por lo que yo preguntaba.

LineComment Saludos
Responder Con Cita
  #9  
Antiguo 15-03-2017
Avatar de AgustinOrtu
[AgustinOrtu] AgustinOrtu is offline
Miembro Premium
 
Registrado: ago 2013
Ubicación: Argentina
Posts: 1.777
Poder: 8
AgustinOrtu Es un diamante en brutoAgustinOrtu Es un diamante en brutoAgustinOrtu Es un diamante en brutoAgustinOrtu Es un diamante en bruto
En estos links esta mejor explicado, y lo analiza desde el punto de vista de como los metodos estaticos dificultan los test de unidad. De hecho se aventura a decir que los metodos estaticos = programacion procedimental. No por "nada" se llaman "estaticos"; y su contraparte, los metodos de instancia son "dinamicos"

Punto 6 de esta lista: http://misko.hevery.com/2008/07/30/t...-hard-to-test/

http://misko.hevery.com/2008/12/15/s...o-testability/
Responder Con Cita
  #10  
Antiguo 15-03-2017
Avatar de AgustinOrtu
[AgustinOrtu] AgustinOrtu is offline
Miembro Premium
 
Registrado: ago 2013
Ubicación: Argentina
Posts: 1.777
Poder: 8
AgustinOrtu Es un diamante en brutoAgustinOrtu Es un diamante en brutoAgustinOrtu Es un diamante en brutoAgustinOrtu Es un diamante en bruto
Respondimos al mismo tiempo .

En este hilo en el foro hermano surgio un debate similar en donde di una respuesta un poco mas larga y analitica que esta relacionada con lo que se esta tratando aqui
Responder Con Cita
  #11  
Antiguo 15-03-2017
Avatar de AgustinOrtu
[AgustinOrtu] AgustinOrtu is offline
Miembro Premium
 
Registrado: ago 2013
Ubicación: Argentina
Posts: 1.777
Poder: 8
AgustinOrtu Es un diamante en brutoAgustinOrtu Es un diamante en brutoAgustinOrtu Es un diamante en brutoAgustinOrtu Es un diamante en bruto
Cita:
Empezado por roman Ver Mensaje
Pues entonces nunca perdiste el polimorfismo; no el polimorfismo de clases.

En objetos, si tomamos el típico ejemplo:

Código Delphi [-]
type
  TFigura = class
    procedure Dibuja(); virtual; abstract;
  end;

  TTriangulo = class(TFigura)
    procedure Dibuja; override;
  end;

  TCirculo = class(TFigura)
    procedure Dibuja; override;
  end;

  TEtcetera = class(TFigura)
    procedure Dibuja; override;
  end;

el polimorfismo se da cuando llamamos al método Dibujar desde una variable del tipo TFigura:

Código Delphi [-]
var
  F: TFigura;

....

F.Dibuja();

ya que, dependiendo de si F fue instanciado como TTriangulo, TCirculo o TEtcetera, el método variará. Si, en cambio, usas una variable del tipo explícito TTriangulo:

Código Delphi [-]
var
  T: TTriangulo;

....

T.Dibuja();

es, como dices, predecible qué método se llamará. Pero no por eso digo que se pierde el polimorfismo.

En el caso de clases es lo mismo: si usas una referencia particular, como TClaseHija, se "pierde" el polimorfismo, tanto como se pierde en TTriangulo. Pero, como tú mismo ejemplificas, si usas una referencia de clase general, como TClaseClass, "recuperas" el polimorfismo.

Lo interesante aquí sería que nos dieras un ejemplo más cercano a lo que quieres decir. Esto es, ¿en qué sentido usar un método de clases no te funciona y una interfaz sí? ¿En qué forma un método de clase que cree objetos no te funciona?

En otras palabras, creo que tienes en mente algo más específico y es eso por lo que yo preguntaba.

LineComment Saludos
No es del todo cierto:

Código Delphi [-]
procedure DibujarTriangulo(const t: TTriangulo);
begin
  t.Dibuja;
end;

Que metodo se ejecuta?
Responder Con Cita
  #12  
Antiguo 15-03-2017
Avatar de roman
roman roman is offline
Moderador
 
Registrado: may 2003
Ubicación: Ciudad de México
Posts: 20.075
Poder: 10
roman Tiene un aura espectacularroman Tiene un aura espectacular
Cita:
Empezado por AgustinOrtu Ver Mensaje
No es del todo cierto:

Código Delphi [-]
procedure DibujarTriangulo(const t: TTriangulo);
begin
  t.Dibuja;
end;

Que metodo se ejecuta?
El de TTriangulo A menos que tengas TTrianguloEquilatero, TTrianguloIsosceles, TTrianguloEscaleno, pero eso no cambia la situación: no es lo mismo el polimorfismo de objetos que el de clases.

LineComment Saludos
Responder Con Cita
  #13  
Antiguo 15-03-2017
Avatar de roman
roman roman is offline
Moderador
 
Registrado: may 2003
Ubicación: Ciudad de México
Posts: 20.075
Poder: 10
roman Tiene un aura espectacularroman Tiene un aura espectacular
Cita:
Empezado por AgustinOrtu Ver Mensaje
en el foro hermano
¡JA!

Pero, en realidad, sigo sin enteder tu punto o tu crítica a usar métodos estáticos. Necesitarías ejemplificar con algo más puntual y sigo sin ver dónde entran las interfaces.

LineComment Saludos
Responder Con Cita
  #14  
Antiguo 15-03-2017
Avatar de AgustinOrtu
[AgustinOrtu] AgustinOrtu is offline
Miembro Premium
 
Registrado: ago 2013
Ubicación: Argentina
Posts: 1.777
Poder: 8
AgustinOrtu Es un diamante en brutoAgustinOrtu Es un diamante en brutoAgustinOrtu Es un diamante en brutoAgustinOrtu Es un diamante en bruto
Ok en realidad tenicamente tenes razon, no es que "per se" se pierde el polimorfismo, todo depende de como se utilice el codigo. En otras palabras, lo que intente decir es que el lugar o momento en que se invocan a los metodos (y no solo estaticos, los de instancia tambien) puede introducir un flujo de codigo que esta definido y no se puede, o es muy dificil de cambiar

Lo importante es diferir estas decisiones lo mas cercano al inicio de la aplicacion, y que no sea la aplicacion o el modelo de objetos el que decide el flujo del codigo

Por ejemplo, utilizar constructores dentro de las entrañas de una aplicacion (cuanto mas adentro peor) introducen esto que yo llamo "perdida" del polimorfismo. Ahora bien, si se una metaclase que se definio en el inicio de la aplicacion (en el composition root) pues esta todo bien, solo que es una alternativa que puede imponer ciertas restricciones, por ej:

Por que me "obligas" a usar como clase ancestro una clase en particular?

Si estamos usando interfaces estamos obligados a implementar IInterface. Hay muchas formas de implementar IInterface.

1. Podria escribir yo mismo el codigo para los 3 metodos
2. Podria ser una subclase de TInterfacedObject
3. Podria ser una sublclase de TComponent
4. Podria usar TAggregatedObject
5. Podria usar TSingletonImplementation
6. Podria usar TContainedObject

Por lo general, el modo en que yo lo hago, es solicitar siempre las implementaciones en los constructores y diferir esta decision a quien decida instanciar la aplicacion. Es decir, no necesito los metodos estaticos

Siguiendo tu ejemplo de las figuras, si tu aplicacion es un editor grafico, supongamos que tenemos

1. Un paquete Delphi que implementa la aplicacion editor grafico. El editor solamente manipula objetos de la clase abstracta TFigura. Dentro de este paquete no existen referencias a clases concretas

2. Otro paquete Delphi, o mejor dicho, una aplicacion Vcl, utiliza el paquete del editor grafico y decide que existen implementaciones: TTriangulo, TTrianguloIsoceles, TRectangulo, TCuadrado, TCirulo

3. El editor grafico deberia, en algun lugar, proveer algun mecanismo para crear las instancias concretas:

a. Podria decirte: dame un descendiente de la metaclase TFiguraClass y yo la instancio. Esto te obliga a descender de TFigura y de tener el constructor de TFigura

b. Podria tener un evento: OnCreateFigura(Sender: TObject; const TipoFigura: string; var Figura: TFigura); esto es un poco mas flexible

c. Podrias decirte, ok, dame una fabrica asi:

Código Delphi [-]
type
  IFigureFactory = interface
    function CrearRectangulo(parametros): TFigura;
    function CrearTriangulo(parametros): TFigura;
  end;

En los dos ultimos casos tenes mas flexibilidad porque podrias retornar objetos asi:

Código Delphi [-]
type
  TTrianguloOpenGL = class(TFigura)
  public
    constructor Create(EngineOpenGL: TEngineOpenGL);
  end;

  TTrianguloUnrealEngine = class(TFigura)
  public
    class function New: TFigura; 
  end;

class function TTrianguloUnrealEngine.New: TFigura; 
begin
  Result := TTrianguloUnrealEngine.Create;
  Result.UnrealEngine := TUnrealEngine.Create; // como hago para reemplazar esto? pues no se puede. Como testeo con un "unreal engine de mentira". No se puede 
end;
Responder Con Cita
Respuesta


Herramientas Buscar en Tema
Buscar en Tema:

Búsqueda Avanzada
Desplegado

Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro

Temas Similares
Tema Autor Foro Respuestas Último mensaje
interfaces luislat40 Varios 2 23-10-2007 03:47:23
Interfaces en C# YaninaGenia .NET 1 18-06-2006 05:14:48
Interfaces... OscarG OOP 9 14-10-2005 13:26:57
Interfaces de XML vhr Providers 2 26-08-2005 17:22:06
Interfaces Legolas Varios 14 17-11-2003 14:39:07


La franja horaria es GMT +2. Ahora son las 03:09:50.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi
Copyright 1996-2007 Club Delphi