Este foro usa cookies
Este foro utiliza cookies para almacenar su información de inicio de sesión si está registrado y su última visita si no lo está. Las cookies son pequeños documentos de texto almacenados en su computadora; las cookies establecidas por este foro solo se pueden usar en este sitio web y no representan ningún riesgo de seguridad. Las cookies en este foro también rastrean los temas específicos que ha leído y la última vez que los leyó. Si Ud. continúa navegando, entenderemos que acepta todas las cookies.

Se almacenará una cookie en su navegador, independientemente de la elección, para evitar que se le vuelva a hacer esta pregunta. Podrá cambiar la configuración de sus cookies en cualquier momento utilizando el enlace en el pie de página.

El foro antiguo se encuentra accesible desde https://foro.gambas-es.org en modo de solo lectura.

Calificación:
  • 0 voto(s) - 0 Media
  • 1
  • 2
  • 3
  • 4
  • 5

POO: Hacer con más, lo que se puede hacer con menos...
#1

Hola  todos:

Acostumbrado desde hace muchos años a la programación lineal, me veo "obligado" [aunque con cierta curiosidad], a desentrañar el por qué la POO es mas "conveniente".

He buscado en la web, las ventajas y desventajas de la POO, pero las explicaciones son tan ambiguas como la propia POO. No obstante saltan a la vista las desventajas, y la mas importante: Es mas lenta la ejecución de un proyecto o programa elaborado con POO.

Será cierto? De todos modos, me gustaría mirar un diagrama de Clases, Constructores, métodos y propiedades en donde se observe que "hay ganancia" en la Programación Orientada a Objetos....

Saludos..

Es mejor saber un poco de todo, que todo de muy poco. Lo primero, garantiza la supervivencia humana.
[-] Los siguientes 1 usuarios dice gracias a AlfredoSC por este post:
  • Shordi
    ¡Gracias!
#2

En gambas estás usando POO en el momento en que utilizas cualquier control y casi cualquier componente. La inmensa ventaja es la reutilización y modificación del código que ya está hecho... sin siquiera llegar a verlo. Respecto a las velocidades alegadas y demás, pues no tengo claro si eso es así "en condiciones de laboratorio" pero en "la vida real" y hablando de aplicaciones gráficas no creo que puedas apreciar diferencias de ningún tipo. Cuesta hacer el cambio de chip, al menos a mí me costó, pero una vez lo asimilas estás encantado con ella.
Como muestra un botón:

Ayer necesité un control que se comportase como un FileChooser pero que permitiese mostrar o dejar de mostrar el árbol de directorios a voluntad del usuario y sin perder las "cositas" que lleva FileChooser (menús contextuales, breadcrumbs, etc.).
Una pequeña investigación en la clase y su estructura y en diez minutos lo tenía desarrollado y mi Gambas exendido en un control nuevo que heredando de FileChooser y con una propiedad añadida para ese comportamiento, en un derroche de imaginación y creatividad llamé ChooserFiles.

[Imagen: 0egzAnB.png]


Eso con funciones me habría costado semanas. Adjunto el ejemplo de la imagen.

Saludos


Archivos adjuntos
.gz ChooserFiles-0.0.1.tar.gz Tamaño: 15.4 KB  Descargas: 2

No podemos regresar
[-] Los siguientes 2 usuarios dicen gracias a Shordi por este post:
  • AlfredoSC, Grandamakulo
    ¡Gracias!
#3

Se me olvidó añadir el código para el que no desee descargar el ejemplo:

GAMBAS
  1. ' Gambas class file
  2.  
  3.  
  4. Inherits FileChooser  ''Just add a property to filechooser that allow hide/show the directories treeview
  5.  
  6. Public Const _Properties As String = "*,ShowTree=True"
  7. Public Const _Group As String = "Chooser"
  8. Public Const _Similar As String = "FileChooser"
  9. Public Const _Draw As String = "FileView"
  10.  
  11.  
  12. Public Sub _new()
  13.  
  14.     Dim o As Object
  15.  
  16.     o = Me
  17.     $tree = o.DirView.parent
  18.  
  19.  
  20. Private Function ShowTree_Read() As Boolean
  21.  
  22.     Return $tree.visible
  23.  
  24.  
  25. Private Sub ShowTree_Write(Value As Boolean)
  26.  
  27.     $tree.visible = value
  28.  



Saludos

No podemos regresar
[-] Los siguientes 3 usuarios dicen gracias a Shordi por este post:
  • AlfredoSC, Grandamakulo, jsbsan
    ¡Gracias!
#4

AlfredoSC:
Cita:me gustaría mirar un diagrama de Clases, Constructores, métodos y propiedades en donde se observe que "hay ganancia" en la Programación Orientada a Objetos....

El otro dia, hice un ejemplo de un programa que hace lo mismo usando el paradigma  procedimental y el POO:


Para ver "ganancia", puedes ver por ejemplo lo simple que es realizar "hacer y deshacer"  .

Tambien en mi curso online gratuito de gambas3, puedes ver un montón de ejemplos de programación orientada a objetos y patrones de diseño:

POO: PATRONES DE DISEÑO
 


Saludos

Julio
[-] Los siguientes 5 usuarios dicen gracias a jsbsan por este post:
  • AlfredoSC, Grandamakulo, guizans, jguardon, Shell
    ¡Gracias!
#5

Hola.

Ya que hablamos de POO me surge una duda. Pongamos que creo la clase B que hereda de la clase A. En la clase B hago un constructor, pero en la clase A tiene también un constructor, que pongamos recibe parámetros. ¿Como hago para llamar al constructor de la clase A desde la clase B?

Gracias.
    ¡Gracias!
#6

Eso no tiene sentido. Un objeto hereda al otro, es decir "es" el otro con modificaciones. El constructor de B debe establecer sus propios parámetros.

No podemos regresar
    ¡Gracias!
#7

Se puede acceder a las propiedades y métodos específicos del ancestro usando la palabra Super. Pero es verdad que acceder al constructor del padre, no tiene mucho sentido, puesto que al crear el objeto heredado estás llamando al constructor del objeto hijo que ya es parte del padre, no se si me explico bien.

Saludos

Por favor, usa el corrector ortográfico antes de pulsar el botón 'Enviar'
    ¡Gracias!
#8

Hola.

 Si, se que lo he escrito no tiene sentido. Estaba pensando en lo que hace Python con, por ejemplo, con Gtk3.

Python
  1. import gi
  2.  
  3. gi.require_version("Gtk", "3.0")
  4. from gi.repository import Gtk
  5.  
  6.  
  7. class LabelWindow(Gtk.Window):
  8. def __init__(self):
  9. super().__init__(title="Label Example")



Como se puede ver, la clase LabelWindow hereda de Gtk.Window y en el constructor se ve como llama al constructor de la clase padre. Se que Python no es Gambas y hace las cosas de otra manera, y por eso mi comentario, me he confundido de lenguaje Blush

Un saludo.
    ¡Gracias!
#9

El tema es que al "construir" la clase hijo ya se ha "construido" la clase padre previamente. Por eso no tiene sentido "reconstruir" la clase padre. Aquí lo correcto es establecer la propiedad que se desea en la propia clase hijo y dar los valores y comportamientos que se deseen en él.

Saludos.

No podemos regresar
    ¡Gracias!
#10

Hola.

Tienes razón Shordi, lo veo claro, y parece coherente añadir propiedades para por ejemplo en el caso de querer añadir un texto a la etiqueta. Pero también es verdad es si en Python se hace así algún motivo habrá, se me escapa el por qué.

Saludos.
    ¡Gracias!


Posibles temas similares…
Tema / Autor Respuestas Vistas Último mensaje

Salto de foro:


Usuarios navegando en este tema: 1 invitado(s)