Interfaces y POO

[Critter]

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]

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]]

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]

Empezado por AgustinOrtu

El motivo es porque usando métodos estáticos pierdo el polimorfismo.

¿A qué te refieres con esto?

LineComment Saludos

[[AgustinOrtu]]

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

[roman]

Empezado por AgustinOrtu

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]]

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]

Empezado por AgustinOrtu

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]]

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/

[[AgustinOrtu]]

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

[[AgustinOrtu]]

Empezado por roman

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]

Empezado por AgustinOrtu

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

[roman]

Empezado por AgustinOrtu

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]]

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;