Dominas realmente la oop?

[marto]

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.

Empezado por haron

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.

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

[[Al González]]

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

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:

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:

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.

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?

Como siempre, les envío un fuerte abrazo.

¡Hasta pronto!

Al González .

[[Al González]]

¡Hola a todos!

Retomando este interesante debate de hace 10 meses...

Empezado por Al González

...¿Dónde se usa _CopyObject?

¿Acaso será un misterio sin resolver?

Al González .

[poyo]

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

[dec]

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

[[Delphius]]

Empezado por dec

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

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. Un ejemplo concreto... ¿alguien se ofrece?
...
...
cri... cri...
...
...
cri... cri...

¡Yo!

Saludos,

[poyo]

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

[[Delphius]]

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

Saludos,

[haron]

Empezado por marto

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.

pos es verdad!

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

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