Foros Club Delphi

Foros Club Delphi (http://www.clubdelphi.com/foros/index.php)
-   OOP (http://www.clubdelphi.com/foros/forumdisplay.php?f=5)
-   -   Interfaces y POO (http://www.clubdelphi.com/foros/showthread.php?t=91606)

Critter 14-03-2017 18:04:40

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/

jhonny 14-03-2017 18:55:39

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 :)

AgustinOrtu 15-03-2017 08:28:58

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

roman 15-03-2017 16:03:39

Cita:

Empezado por AgustinOrtu (Mensaje 514338)
El motivo es porque usando métodos estáticos pierdo el polimorfismo.

¿A qué te refieres con esto?

LineComment Saludos

AgustinOrtu 15-03-2017 16:07:28

Como invocas a un metodo estatico? Metodo estatico son los de clase

roman 15-03-2017 16:17:08

Cita:

Empezado por AgustinOrtu (Mensaje 514361)
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

AgustinOrtu 15-03-2017 16:27:06

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

roman 15-03-2017 17:07:00

Cita:

Empezado por AgustinOrtu (Mensaje 514364)
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

AgustinOrtu 15-03-2017 17:07:31

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" :p

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/

AgustinOrtu 15-03-2017 17:38:12

Respondimos al mismo tiempo :p.

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

AgustinOrtu 15-03-2017 17:40:42

Cita:

Empezado por roman (Mensaje 514367)
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?

roman 15-03-2017 17:51:12

Cita:

Empezado por AgustinOrtu (Mensaje 514371)
No es del todo cierto:

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

Que metodo se ejecuta?

El de TTriangulo :confused: 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

roman 15-03-2017 17:55:07

Cita:

Empezado por AgustinOrtu (Mensaje 514370)
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

AgustinOrtu 15-03-2017 18:36:48

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;


La franja horaria es GMT +2. Ahora son las 01:07:42.

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