Foros Club Delphi - Dominas realmente la oop?

Foros Club Delphi (https://www.clubdelphi.com/foros/index.php)

- Debates (https://www.clubdelphi.com/foros/forumdisplay.php?f=29)

- - Dominas realmente la oop? (https://www.clubdelphi.com/foros/showthread.php?t=9764)

Dominas realmente la oop?

Hola.

Hay muchas personas que vienen de lenguajes estructurados (como pascal), que han aprendido a desarrollar aplicaciones en delphi sin aprender toda la teoria de objetos. A mi me parece que esta es una gran característica de delphi, pues permite que esto suceda.

Ahora, yo creo que si estas personas se estan perdiendo del 80% del potencial de la herramienta; ademas de verse limitados o no poder en realidad desarrollar algunas ideas (o incluso concebirlas) debido a la falta de dominio en herencia, polimorfismo y demas bichos de la POO, o la forma de implementarlos en delphi.... derivar sus propias clases, hacer componentes propios o trastear alguno de un tercero... en fin.

Simplemente me pareció curioso medir cual es el nivel en que cada uno considera encontrarse... quizas mas adelante podamos medir el nivel de interes en seguir aprendiendo para llegar a ser "expertos en POO", que es algo sano y recomendable para todos.

Las opciones de la encuesta me las he pensado apenas unos segundos... asi que seguramente faltará alguna... responde con la que mas se acerque a tu situación actual, y sentite libre de explicar como te definirias en una respuesta a este post.

Quienes se sientan tentados de usar la segunda opción... por favor, abstenerse y mejor votar por la primera. :D

Saludos y hasta luego.

;)

jejeje, me ha gustado esta encuesta Juan Antonio :p

Para los que han contestado que son "expertos" en OOP o piensan que tienen un buen nivel... aquí les dejo una preguntas, a ver que tan buen nivel tienen ;)
(aviso: ésto está sacado de un ejercicio real de la universidad en la asignatura de OOP que se realiza en Java)

1. Supongamos que partimos de un lenguaje idéntico a Java pero con la particularidad que no existen las palabras clave abstract ni extends, es decir, sólo se podrá hacer herencia entre clases vía interfaces. (para aquellos que no lo sepan, abstract = que en Delphi y extends = hereda de).
Preguntas:
a) Se ha perdido la posibilidad de propagar código automáticamente entre clases dentro la jerarquía de herencia. Siempre se tendrá que implementar desde 0 todos los métodos que se definen en los interfaces de los que heredamos. ¿Esta afirmación es totalmente cierta? ¿Qué manera hay para reaprovechar el máximo posible del código de las clases sin tener que partir de 0?
b) ¿si se tuviera que partir absolutamente de 0al momento de implementar cada subclase, crees que el mecanismo de herencia pierde totalmente su sentido? ¿Qué propiedades pueden conservarse aun que puedan ser útiles?

2. Suponemos que partimos de un lenguaje idéntico a Java pero con herencia múltiple y que el compilador:
a) obliga a que todos los atributos sean privados
b) cuando una clase hereda de varias, busca si todos los métodos que no son privados definidos a la superclase tienen cabeceras diferentes i, si encuentra alguna repetida, da error.
Pregunta:
¿Es esto suficiente para que todo funcione? ¿Se tendría que buscar también entre los métodos y atributos privados?

3. Una clase con un método abstracto ha de ser a la vez abstracta para que no se pueda instanciar. Dado que siempre se puede redefinirán método a una subclase, ¿qué crees que aporta el hecho de declararlo abstracto respecto a simplemente declararlo y implementarlo sin código y de esta manera no perder la posibilidad de instanciar la clase? ¿Por qué si la clase tiene un método abstracto no se puede dejar instanciar?

Alguna pregunta es básica, otras no tanto, pero todas tienen "su cosa". Ahora... que tanto sabes de POO???? ;) Podeis contestar las preguntas y las debatimos entre todos si quereis ;)

Por cierto, no es lo mismo saber OOP (la teoría) que saber implementarla en Delphi (conocimiento de clases, de donde derivan,..... de Delphi)

PD: Prometo publicar las respuestas dentro de un tiempo

Wenassss...

Cita:

Empezado por jachguate

Quienes se sientan tentados de usar la segunda opción... por favor, abstenerse y mejor votar por la primera

Yo diría más bien que la segunda opción se equipara a la tercera :p

Aún no comprendo qué le ven de malo algunos a Vb. Aunque tampoco comprendía qué le veían de bueno a Linux y he terminado comprendiéndolo :rolleyes:

He votado por la penúltima :D

Un saludo.

Código:

// declaracion de una interface y su correspondiente clase

// mediante la interface heredo y mediante la clase implemento



interface IA{

  public void metodo1();

  public void metodo2();

  ..

}



public class A implements IA{

  ..

}



interface IB{

  ..

}



public class B implements IA, IB{

  A a;

  public B(){

    a=new A();

  }

  // implemento el metodo de la interface IA

  public void metodo1(){

    a.metodo1();

  }

  public int metodo2(){

    return a.metodo2();

  }

  ..

}



interface IC{

  ..

}



public class C implementes IA, IB, IC{

  A a;

  B b;

  public C(){

    a=new A();

    b=new B();

  }

  ..

}

etc, etc...

puede exista alguna forma mas sencilla de hacerlo. a mi se me ha ocurrido esta. para ser la hora de la siesta mas no se podia pedir.

b)

creo que si se declaran dentro del mismo archivo dos clases, aunque sus metodos o atributos sean privados, por el hecho de estar en el mismo fichero son visibles para todas las clases, por lo que el compilador en este caso, deberia comprobar los atributos y funciones privadas.

c)

creo que para evitar invocar un metodo que no esta implementado.

tambien creo que en Delphi si se pueden instanciar clases abstractas, pero te avisa y ademas si llamas a un metodo que no esta implementado te da un mensaje de error tan filosofico como este: "Abstract error"
que aporta tanta informacion como el mensaje de error de güindous:

"Se ha producido un error y por eso el programa finalizara" (mas o menos) y que se puede traducir a
"Como el programa me a tocao los güevos, voy y lo cierro"

he aprovado el examen?
si no, quiero que me devuelvan el dinero de la matricula.

Cita:

Empezado por cadetill

b) ¿si se tuviera que partir absolutamente de 0al momento de implementar cada subclase, crees que el mecanismo de herencia pierde totalmente su sentido? ¿Qué propiedades pueden conservarse aun que puedan ser útiles?

se me olvidaba. no pierde su sentido. la clase que extiende otra se trata como si fuera un caso particular de esta, por ejemplo:

public void metodo(A a){
..
}

si declaro una clase B que extiende la clase A, puedo pasarla como parametro al metodo, no necesito crear otro metodo especifico para cada clase.

creo.

Cita:

Empezado por haron

creo que si se declaran dentro del mismo archivo dos clases, aunque sus metodos o atributos sean privados, por el hecho de estar en el mismo fichero son visibles para todas las clases, por lo que el compilador en este caso, deberia comprobar los atributos y funciones privadas.

Eso no es enteramente cierto. En java solamente puedes usar una clase publica por fichero, no como en Delphi. Por tanto, no tienes acceso a sus metodos/atributos privados. En conclusión, a no ser que metieses las tres clases en un fichero y solo fuese publica la subclase de las otras dos (cosa bastante estrambótica y que, si no está prohibida, debería) no habría ningun problema. Además, si son metodos privados, tu no tienes porque conocer su existencia.

Cita:

Empezado por haron

Po si, esa es la grandeza del polimorfismo ;)

De todas maneras, vale aclarar que de responder a eso a ser que paz de diseñar un sistema OO va un rato:)

Algunas experiencias (una del tercer tipo)

¡Buen día a todos!

Interesante encuesta. Voté por la penúltima opción.

Me llamaron la atención dos de los planteamientos:

1. Si la herencia tendría sentido si se tuviera que implementar a partir de cero el código de cada método en clases descendientes.

La respuesta es si, como ya se ha mencionado, por la capacidad que aún (en ese pobre estado) tendrían las instancias de clases descendientes para tratarse polimórficamente (una manzana puede tratarse genéricamente como una fruta).

2. Si una clase es abstracta y no instanciable por declarar (o heredar) un método abstracto.

Se entiende que una clase abstracta no puede ser instanciada porque se trata de una definición parcial de la implementación de un objeto, por lo tanto un objeto instanciado bajo una clase abstracta sería un objeto incompleto (como una manzana mordida, jeje :), aunque he escuchado hablar de una manzana mordida que está más que excelente ;)). Obligar a implementar el método abstracto en clases descendientes, es una manera de garantizar que no se creen instancias de objeto con implementaciones incompletas. No obstante, Delphi permite la creación de objetos bajo clases que tienen métodos abstractos, reportando el compilador una advertencia al respecto cuando la expresión de instanciación lleva explícitamente el nombre de la clase. Y es que en ocaciones, la falta de implementación de un método no significa que la clase esté incompleta, sino que se trata de una característica que el objeto instanciado simplemente no tendría (la manzana no tiene etiquetita de distribución). Sin embargo, lo correcto en esos casos es definir el método sin código (sólo Begin y End), en lugar de Abstract.

Por otro lado, me permito agregar algunas experiencias algo especiales que he tenido con Programación Orientada a Objetos (POO) en Turbo Pascal y Delphi.

Por varios años utilicé Turbo Pascal 5.5, y me enteré de que éste manejaba objetos cuando ya llevaba tiempo usando la versión 6.

En alguna época abstracta ;), me di a la tarea de reimplementar varias de las clases de la biblioteca Turbo Vision (aquella que venía con Turbo Pascal 6 y 7) para que todos los componentes derivados de TView (el nostálgico TView :() desplegaran su contenido en modo gráfico (en lugar de modo texto ASCII). Abandoné el proyecto cuando supe que existía un Turbo Pascal para Windows :).

Ya en Delphi, lo primero que aprendí de objetos, fue que las variables de este tipo eran punteros implícitos a los bloques de memoria donde se guardan las instancias (no me imagino escribiendo en pascal de Delphi Rejilla^.DataSource^.DataSet^.Refresh;).

Después de un par de meses con Delphi, descubrí la manera de cambiar en tiempo de diseño la clase de un componente agregado a una forma. Por ejemplo, si después de agregar un TEdit en una forma y haberle establecido valores en varias de sus propiedades, decido cambiar el componente por un TComboBox, en lugar de quitar el componente TEdit, agregar un TComboBox y volver a establecer las propiedades, lo que hago es mostrar la forma como texto (Alt+F12), cambiar ahí la declaración del objeto "TEdit" por "TComboBox", vuelvo a mostrar la forma (Alt+F12) y guardo.

Pero cambiar la clase de un objeto en tiempo de ejecución, requirió de conocer qué es exactamente una instancia de objeto y que guarda en su interior. Los primeros cuatro bytes del bloque de memoria de un objeto, osea de la instancia, es el identificador de la clase (la dirección de memoria donde está la definición estructural de la clase). Por lo tanto, es sumamente sencillo cambiar la clase de un objeto en tiempo de ejecución, tratando a la referencia objeto como un valor de tipo PClass (puntero a clase). Por ejemplo:

Código:

Type

  PClass    = ^TClass;

Begin

  Edit1 := TEdit.Create (Self);

  PClass (Edit1)^ := TMiEdit;

Otro truco que también emplea molde de tipo (type cast), es el de acceder a un método protegido (Protected) de una clase, desde una unidad distinta a la que define esa clase:

Código:

Type

  TMiEdit = Class (TEdit);

Begin

  TMiEdit (Edit1).KeyDown (vk_Return, [ssCtrl]);

Pero quizás el truco de molde de tipo más chapucero sea el de acceder a los campos privados de un objeto:

Código:

Type

  { Tipo Molde de Acceso a TIBTable }

  TMoldAcceTIBTable = Class (TIBCustomDataSet)

    Private

      FSystemTable :Boolean;

      FMultiTableView :Boolean;

      FMasterLink :TMasterDataLink;

  End;

Begin

  TMoldAcceTIBTable (IBTable1).FMasterLink.Free;

(NOTA: Manéjese con cuidado. La clase que hace de molde de tipo debe ajustarse a las modificaciones que el fabricante haga de la clase que parcialmente emula.)

Un truco que he encontrado muy útil es el de llamar a un método que por la herencia ha sido tapado (escondido) por uno homónimo en clase descendiente. Consiste en asignar a una estructura TMethod, la dirección de memoria del método escondido y el objeto con el cual queremos que se ejecute (el que será Self dentro del método). Entonces ejecutar el paquete TMethod bajo un molde de tipo que tenga la misma cabecera declarativa del método en cuestión.

Recientemente, he venido observando (y externando en algunos temas) la necesidad de que Delphi cuente con herencia insertada. Así denomino a la capacidad (aún teórica) de que se pueda definir una nueva clase de objeto e insertarla en la jerarquía de otras dos, sin tener que modificar el código fuente de éstas últimas. De tal forma que la nueva clase se convierta en el nuevo padre de la hija y en el nuevo hijo de la padre.

Código:

Type

  TMiDataSet = Class (TDataSet) Inserted;

    Public

      Function Permitida :Boolean;

  End;



  — ó —



  TMiDataSet = Class (TDataSet) Inserted For

    TCustomADODataSet, TIBCustomDataSet;

    Public

      Function Permitida :Boolean;

  End;

...

Begin

  If IBTable1.Permitida And ADOQuery1.Permitida Then

    ...  { Si tiene acceso }

La herencia insertada resolvería muchos casos donde, a falta de ella, se tiene que implementar dos o más veces la misma característica en clases que tienen un ancestro común que podría albergar dicha característica de forma centralizada, además de las ventajas polimórficas que esto otorgaría.

Añado que en una ocasión desarrollé una rutina que servía para clonar objetos, es decir, copiar por completo la instancia de un objeto (el bloque de memoria que ocupa). Pero considerando los contadores de referencia que hubiese de sus campos String, Variant, interfaces y arreglos dinámicos. Para ello utilicé la función interna _CopyRecord de la unidad System.pas. Deduzco que _CopyRecord es la función que se llama cuando se realiza una asignación del tipo Registro1 := Registro2, donde los operandos son estructuras declaradas como Record. Observé que _CopyRecord utiliza información RTTI para determinar los desplazamientos y tipos de campos que utilizan contadores de referencia, incrementando en uno dichos contadores cuando se realiza la asignación de un Record a otro.

Finalmente, en la unidad System.pas, justo después de la función _CopyRecord, se encuentra una función llamada _CopyObject. Por su cabecera declarativa, pareciera que ésta realiza una tarea similar a _CopyRecord (de hecho la llama), pero con objetos. Sin embargo, tengo dos dudas al respecto: ¿basta una llamada a _CopyObject para copiar todo el objeto por completo?, y la más enigmática, ¿en qué situaciones emplea Delphi la función _CopyObject?. Objeto1 := Objeto2 es sólo una copia de puntero, Objeto1^ := Objeto2^ es sintácticamente inválida.

¿Dónde se usa _CopyObject? :confused:

Como siempre, les envío un fuerte abrazo.

¡Hasta pronto!

Al González :).

Cita:

Empezado por marto

pos es verdad! :confused:

y lo peor de todo es que lo habia comprobado con el compilador de Java.
no se que clase de comprobacion habre hecho :p

seguro que el potaje de garbanzos antes de la comprobacion me hizo ver ilusiones.

Cita:

Empezado por santana

Yo diría más bien que la segunda opción se equipara a la tercera :p

Claro que no!!

La tercera opción implica que aunque no sepas nada de POO, tenes idea de que es la POO... (no se si eso será posible, pero esa era mi idea). Quien crea que sabe POO porque sabe VB... evidentemente no solo no sabe nada de POO, sino no sabe que es la POO. Si lo supuera, comprendería que VB no es un lenguaje orientado a objetos.

Es mi argumento...

Hasta luego.

;)

Cita:

Empezado por jachguate

Bueno, me parece que a partir de .NET tendremos que especificar de qué VB hablamos para decir si es o no OO ;)

Cita:

Empezado por marto

Bueno, me parece que a partir de .NET tendremos que especificar de qué VB hablamos para decir si es o no OO ;)

:o :o cierto... es que yo soy un poco mas anticuado todavia... :D

Cita:

Empezado por jachguate

:o :o cierto... es que yo soy un poco mas anticuado todavia... :D

No te preocupes.
Ya sabes que los clásicos nunca dejan de estar de actualidad :D :D

Saludos

Cita:

Empezado por cadetill

jejeje, me ha gustado esta encuesta Juan Antonio :p

Pos a mi también... :p

Cita:

Empezado por cadetill

Para los que han contestado que son "expertos" en OOP o piensan que tienen un buen nivel... aquí les dejo una preguntas, a ver que tan buen nivel tienen ;)
(aviso: ésto está sacado de un ejercicio real de la universidad en la asignatura de OOP que se realiza en Java)

El ejercicio está bonito... lástima que no soy purista de la OOP, ni me gusta mucho el Java ese...

java
1. ¿Esta afirmación es totalmente cierta? No quedamos que no habia herencia?? ¿Qué manera hay para reaprovechar el máximo posible del código de las clases sin tener que partir de 0? Lo único que se me ocurre es declarar miembros de las clases que nos interesen, y en los nuevos métodos, invocar métodos de estos miembros. Obviamente la especialización desde esta perspectiva seria un asco.
2. ¿si se tuviera que partir absolutamente de 0 al momento de implementar cada subclase, crees que el mecanismo de herencia pierde totalmente su sentido? claro que no! como bien lo apunto ya Al, sigue existiendo el polimorfismo
Herencia múltiple
1. ¿Es esto suficiente para que todo funcione? asi de rapidito puedo decirte que si...
2. ¿Se tendría que buscar también entre los métodos y atributos privados? No. No conozco java lo suficiente, pero supongo que las subclases no tienen acceso a los atributos y métodos privados, con lo que se evita toda ambiguedad
Métodos y clases abstractos
1. Hay una gran diferencia entre declarar un método abstracto y declararlo vacio.
  - El método abstracto indica que la clase es "parcial" (o abstracta). Es decir, que las subclases deben tener una funcionalidad tal, que es desconocida al momento de implementar la clase ancestro.
  - Por el contrario, cuando se prevee que la subclase simplemente se especialice, pero que no es un comportamiento "requerido", el método puede declararse como vacio.
  Quizas sea mejor aclarar esto con un ejemplo.
  
  Supongamos el caso típico de TFiguraGeometrica en una aplicación de dibujo. Habrá un método Dibujar que es abstracto. TCuadrado, TTriangulo y TCirculo declaran cada uno su implementación del método, pero evidentemente deben declararlo. No tiene ningun sentido crear una instancia de la clase abstracta, y de hecho el compilador no debiera permitirlo (aunque me conformo con que delphi lo advierta en un warning).
  
  Por el contrario, supongamos el caso hipotético de TCD, que tiene un método vacio reproducir. Se derivan de esta las clases TAudioCD, TVideoCD y TDatosCD. Cada una reimplementan el método virtual reproducir. Sin embargo, sigue siendo posible tener un TCD en blanco... de manera que al invocar su método reproducir, simplemente no hace nada. (El ejemplo es bastante irreal... pero ilustra)
2. Creo que la decisión de declarar un método como abstracto, o simplemente dejarlo vacio, depende del diseñador de la jerarquia, y es un punto importante que merece atención especial en cada caso.

Espero ansioso las respuestas correctas... y mi calificación.. :D

¡Hola a todos!

Retomando este interesante debate de hace 10 meses...

Cita:

Empezado por Al González

...¿Dónde se usa _CopyObject? :confused:

¿Acaso será un misterio sin resolver? :eek:

Al González :).

La encuesta está cerrada pero, de todos modos, lo que hubiese votado no estába:

Se bastante, lo aplico sólo cuando es necesario y lo evito cuando puedo ;)

Hola,

Digo yo, ¿hay alguna razón para evitar la POO? Me gustaría saberla, puesto que, personalmente, y, aún sin ser un experto, le encuentro no pocas cosas buenas. Ahora bien, entonces, ¿quién querría evitar estas cosas buenas, si están a su disposición? Je je je... ;)

Cita:

Empezado por dec (Mensaje 336301)

Y bueno... un buen motivo para evitarla es que si te le unes, y le tomas gusto al tiempo terminas con un cerebro polifórmico, y sobrecargado:D. Un ejemplo concreto... ¿alguien se ofrece?
...
...
cri... cri...
...
...
cri... cri...

¡Yo!:D:p:o

Saludos,

creo que lo siguiente resume:
"No hay bien que por mal no venga" (y vicecersa)
"En todo lo bueno hay algo malo y en todo lo malo hay algo bueno"

lee algo de lo siguiente sino:
http://es.wikipedia.org/wiki/Yin_y_yang

Creo que cada uno, cuando acepta una supuesta parte, la otra viene implícita.
Es decir, si uno acepta lo bueno de algo, inevitablemente e implícitamente, acepta lo malo.

Creo que eso es aplicable a todo.

Lo importante es conocerse a uno mismo. Si conocemos nuestros propios límites podremos actuar en consecuencia.

Los abusos nos pueden llevan muy lejos... pero por un camino a equivocado.

Los lenguajes orientados a objetos no son la panacea ni nada por el estilo. Sólo hay que reconocer cuándo es el momento oportuno de usarlos, de lo contrario, simplemente estaremos haciendo algo distinto a lo correcto, aunque inclusive ésto de (aparentemente) el mismo resultado...
Lo mismo corre para los lenguajes tradicionales no orientado a objetos o los lenguajes interpretados o cosas como Java, .NET)
(bueno, estos últimos... puaj!) :D

Ahora que lo pienso creo que Dec estaba siendo un poco sarcástico/irónico.:D

Saludos,

Ciertamente tiene cosas buenas y otras no tan buenas, personalmente prefiero usar una mezcla de ambos :)

p.d.: No domino la POO, me domina ella a mí :D
Si tuviera que ponerme una puntuación de 0 a 10, uuuummmmmm...... me pondría un......... 6 :)