Class // Module // Function??

[Fernando_net]

Hola a todos.

Veréis, para una mayor optimización del código, se me presenta la siguiente duda.

Tengo un lio tremendo entre para que sirve una clase, un modulo, donde se ponen las funciones, etc...

Es decir, tengo claro que las clases sirven para definir objetos si estoy orientado a la Programación Orientada a Objetos.

Pero que pasa? Que dentro de la clase puedes poner funciones que te hagan calculos (por ejemplo, que te calcule la edad)

Después tienes los módulos, que son trozos de código que puedes llamar desde dentro del formulario y que puedes poner funciones también.

Entonces, si las funciones se pueden poner dentro de la clase... dentro del modulo.... que utilidad tienen los módulos?

No quiero que penséis que soy un inutil programando, lo que pasa es que tengo una forma de programar poco eficiente (ya he hecho algún que otro programa). Para mi, poco eficiente, es que no explota las posibilidades que ofrece la Programación Orientada a Objetos, con sus getters i setters y todo bien estructurado.

Para que os hagáis una idea, yo lo mezclo todo... Clases con modulos, con funciones en ambas, etc etc...

Y claro, veo codigo por Internet que está tan bien estructurado que lo siento, no me aclaro para que sirve cada cosa. Más que nada los modulos...

Alguien podría iluminarme ni que sea un poco?

Gracias por la ayuda.

Un saludo

[Wuakap]

Los modulos en POO no se utilizan. Microsoft los mantuvo para aquellos programadores provenientes de VB 6, aun pudieran programar al estilo "antiguo".

La utilidad que en VB 6 proveian los modulos, era establecer funciones publicas de utilidad general, como validaciones de nulos, modulos de calculos numericos, entre otros.

Ahora eso se puede hacer con clases y funciones shared, de modo que pueden ser utilizadas sin la necesidad de ser instanciadas, lo que (y aqui es opinion mia, no tengo certeza si sera cierto o no) a mi juicio ahorra consumo de recursos en la maquina y lineas de codigo.

Sobre las funciones que estan dentro de las clases, a estas se le llaman metodos, y las variables definidas en el ambito de la clase, se le llaman propiedades. Pueden ser publicas o privadas, y pueden ser accesadas directamente o desde property declarados manualmente.

En fin, espero haber sido de ayuda.

[Fernando_net]

Caray, pues a partir de ahora intentaré prescindir de utilizar modulos y acostumbrarme a utilizar metodos dentro de la clase.

Nada, costará el cambio, tendré que acostumbrarme a utilizar cosas como "nombredelaclase".getnombre o "nombredelaclase".setnombre = "Prueba", por poner ejemplos.

Ahora lo que hacía era cargar directamente el valor a la base de datos, sin utilizar clases ni nada por el estilo. Por ejemplo:

Insert into X values (txtnombre.text)

Ahora que me paro a pensar, esto es fatal a nivel de aplicación, ya que si hago algún cambio y desaparece ese textbox, la consulta quedará inutilizada.

En realidad debería ser:

Insert into X values (nombredelaclase.getnombre())

No?

Gracias por la ayuda :)

[Wuakap]

Iniciado por Fernando_net

Caray, pues a partir de ahora intentaré prescindir de utilizar modulos y acostumbrarme a utilizar metodos dentro de la clase.

Nada, costará el cambio, tendré que acostumbrarme a utilizar cosas como "nombredelaclase".getnombre o "nombredelaclase".setnombre = "Prueba", por poner ejemplos.

Ahora lo que hacía era cargar directamente el valor a la base de datos, sin utilizar clases ni nada por el estilo. Por ejemplo:

Insert into X values (txtnombre.text)

Ahora que me paro a pensar, esto es fatal a nivel de aplicación, ya que si hago algún cambio y desaparece ese textbox, la consulta quedará inutilizada.

En realidad debería ser:

Insert into X values (nombredelaclase.getnombre())

No?

Gracias por la ayuda :)

Hasta aqui maestro llega mi sabiduria... Estoy en la disyuntiva sobre como se deben diseñar las aplicaciones... el estandar establece que se debe programar por capas UI (presentacion), BLL(capa de negocio) y DAL(capa de acceso a datos).

UI: Controlas la interfaz, y el como se ven los datos. En esta capa no se programa nada complicado, ya que toda la logica esta en la BLL, la cual es consumida por la UI.
BLL: Van todas las validaciones y procesos como obtención de folio entre otros. Aqui no se usan select ni insert. Esta capa consume los servicios de la DAL.
DAL. Esta clase contiene todos los select, insert, update, etc que necesites, junto con la conexion a la BD.

Adicionalmente, puedes implementar una interfaz en la capa de negocio para optimizar el paso de informacion entre la BLL y la UI.

De todas formas no soy experto en la materia. Esa es la teoria... el llevarla a la practica en sistemas complejos se me ha hecho un poco mas dificil de lo que puedo escribir sobre ella. Siempre, en lo personal, me encuentro con casos donde mi BLL se fuciona en cierto punto con mi DAL o al reves, ni UI con mi BLL.

En fin, la experiencia y los años forjarán al maestro.

Saludos!

[Fernando_net]

Jejeje; si, la teoría dice que se tiene que programar intentando enfocar la aplicación a las 3 capas que has comentado (Presentación, negocio y datos)

Pero claro, el problema está como implementarlo todo para que funcione sin que haya ningún cruce entre capas ni ningún dato que quede colgado.

Por poner un ejemplo: Tu tienes un form con un botón. Y en este botón llamas a una clase. Ya pasas de la capa de presentación a la capa de negocio, a mi entender.

Entonces, en la clase, para seguir con la estructura de 3 capas, debería pasar a la capa de datos y llamar a alguna función que te devuelva el dato que quieras mediante una consulta Select que ataque a la Base de Datos.

Entonces, para pasar a la capa de datos... ¿se puede hacer desde la misma clase?

A mi entender creo que no porqué estaría jugando todo el rato en la capa de negocio, sin pasar a la de datos, no es cierto?

Entonces... como sería entonces para pasar a la capa de datos?

Resumen:

Formulario --> Capa de presentación, hasta aquí bien, es lo que ve el usuario y con lo que debe de jugar.
Capa de negocio --> ¿Clases?
Capa de datos --> ¿Como ejecutarla?

[Wuakap]

Por lo que entiendo deberia ser asi.

DAL: public function leerDocumentos() as data.datatable

BLL: dim MisDatos as new data.datatable = DAL.leerDocumentos

UI: MyGrilla.datasource = BLL.MisDatos



Se entiende que en la BLL sobre ese datatable haras un par de validaciones, setearas ciertas variables y algo que "justifique" la existencia de esa capa, puesto que asi como esta, perfectamente podrias hacer algo asi:

UI: MyGrilla.datasource = DAL.leerDocumentos()

De este modo te saltas la BLL.


De todas formas, al menos a gusto personal, en la BLL siempre declaro variables booleanas, de forma que en la UI pueda hacer algo como esto:

UI: MyBoton.enabled = BLL.estaBotonHabilitado
MyTextbox.readonly = BLL.esTextoSoloLectura
...

De esta forma, el code behind de mi aplicacion (presentacio o UI), solo mantiene llamadas a la capa de negocio y que sea en esta, donde reside la lógica para habilitar o deshabilitar los controles de la interfaz.



NOTA: Ojo, en .NET la presentacion es una clase. En esta tu instancias a otra clase, que sería la BLL. Finalmente, la BLL instancia a la clase DAL. De esta forma el desarrollo por capas contempla a lo menos tres clases.

[Fernando_net]

Iniciado por Wuakap

Por lo que entiendo deberia ser asi.

DAL: public function leerDocumentos() as data.datatable

BLL: dim MisDatos as new data.datatable = DAL.leerDocumentos

UI: MyGrilla.datasource = BLL.MisDatos



Se entiende que en la BLL sobre ese datatable haras un par de validaciones, setearas ciertas variables y algo que "justifique" la existencia de esa capa, puesto que asi como esta, perfectamente podrias hacer algo asi:

UI: MyGrilla.datasource = DAL.leerDocumentos()

De este modo te saltas la BLL.


De todas formas, al menos a gusto personal, en la BLL siempre declaro variables booleanas, de forma que en la UI pueda hacer algo como esto:

UI: MyBoton.enabled = BLL.estaBotonHabilitado
MyTextbox.readonly = BLL.esTextoSoloLectura
...

De esta forma, el code behind de mi aplicacion (presentacio o UI), solo mantiene llamadas a la capa de negocio y que sea en esta, donde reside la lógica para habilitar o deshabilitar los controles de la interfaz.



NOTA: Ojo, en .NET la presentacion es una clase. En esta tu instancias a otra clase, que sería la BLL. Finalmente, la BLL instancia a la clase DAL. De esta forma el desarrollo por capas contempla a lo menos tres clases.

Claro, tiene su lógica.

Lo que es curioso el tener que ir saltando capas para al final hacer lo que queremos hacer (en tu ejemplo, leer datos de un documento)

Si lo que haces en la capa de datos la hicieses directamente en la de presentación, jerarquicamente está mal, aunque quien sabe si a nivel de rendimiento sería optimo que no ir creando tantos objetos y ir saltando de capa a capa.

Aunque bueno, a nivel de reutilización sería lo correcto. Estoy haciendo pruebas, a ver si cojo la rutina de hacerlo, como se suele decir, como Dios manda

Oye, gracias por la ayuda Crack :)

[Wuakap]

De nada maestro... de todas formas esto de trabajar en capas, almenos para mi, es mas facil decirlo que hacerlo...

En fin, suerte!

[Fernando_net]

Buffff, me estoy acojonando con las clases.

He estado investigando más y más con el tema de clases: de Herencia, de Polimorfismo y de Encapsulación.

Y creo que puedo hacer clases de todo, y creo que se me está yendo un poco la olla. Estoy haciendo una clase hasta de los botones, en que dependiendo el botón llamo a un método u otro, me estoy volviendo loco! :O

Es decir, si es un boton que es de Aceptar, hago un:

Código vb:

Dim Boton1 as new Boton
 

"Boton" es el nombre de la clase de los botones.

Entonces a partir de ahí hago:

Código vb:

Boton1.text = boton.nombre() (y devuelve el nombre)
Boton1.location = new point(boton.horizontal(), boton.vertical())
 

etc etc.....

No sé, estoy haciendo clases de todo, y creo que no es bueno :(

[Wuakap]

No puedo decir que esta malo lo que haces... por que no soy un experto en la materia. Pero si te puedo decir es que pocas veces he visto eso. Las pocas veces son cuando es necesario ir creando controles en runtime, dado que lo que se carga depende de variables y parametros que cambian constantemente.

Ahora, yo creo que debes analizar costo / beneficio... y en base a eso determinar que clases se deben crear y cuales no.

Saludos!

[Fernando_net]

Bueno, sigo con mi periplo con las clases y ahora estoy con la clase "Botones"

Ya hago el llamamiento a la clase que he creado, con sus métodos bien organizados y bien puestos y los añado al formulario mediante me.controls.add() en runtime.

Pero ahora me pregunto si esto que pienso se podría hacer.

Imaginad que tengo los típicos botones "Aceptar" y "Cancelar". El botón "Aceptar" siempre debe de estar a la izquierda del botón "Cancelar". Hasta aquí perfecto, debido que puedo jugar con las posiciones relativas de los botones.

Ahora, ¿habría algún modo de que llamando a algún método de la clase que he creado se pongan los botones a la parte baja-derecha del formulario desde donde hago el llamamiento?

Es decir. Como tengo más de un formulario donde tengo botones "Aceptar"-"Cancelar", para no tenerlos que poner siempre a mano y ir creando métodos dependiendo del formulario que es (lo que me haría un listado de métodos con posiciones bestial, dos método por cada formulario) dependiendo del tamaño del formulario, había pensado en crear un método en la clase "Botones" en que me calculara el solo la posición donde debe ir el botón cogiendo la propiedad size del formulario y a partir del size que calcule la posición donde debe ir el botón.

Creo que si que se puede hacer, a ver si lo consigo.

Un saludo!

[Fernando_net]

Hola a todos.

Estos días he estado probando y quisiera ver si voy bien con los pasos que estoy haciendo.

Imaginad que tengo una pantalla de login con dos textbox, uno para el usuario y otro para la contraseña. Además de tener un botón aceptar.

Bien, si quiero que la programación sea Orientada a Objetos, necesito tener una clase Login con sus respectivos Getters i Setters al respecto, uno para el campo "usuario" y otro para el campo "contraseña"

Actualmente estoy en la capa de presentación.

Cuando aprieto el botón aceptar hago lo siguiente:

Código vb:

Private Sub btn_login_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btn_login.Click
        Dim logueo As New Clase_Login
 
        'Llamo a la clase Clase_Login y le paso los datos
        logueo.usuario = txt_usuario.Text
        logueo.contrasena = txt_contrasena.Text
End Sub
 

Ahora me voy a la Clase_Login. Yo entiendo que todavía estoy en la capa de presentación, ya que aun no he entrado en la capa negocio.

Entonces en la clase_Login tengo un metodo que se llama "Logueo", que sirve para que compruebe si os datos están bien introduidos.

Código vb:

Public Sub logueo(ByVal usuario As String, ByVal contrasena As String)
        'enviamos los datos a la capa de negocio
        Dim loguin As New Negocio_logueo
 
        If loguin.comprueba_logueo(usuario, contrasena) = False Then
            System.Windows.Forms.MessageBox.Show("Compruebe los datos, ha habido un error en la autenticación")
        Else
            'Si los datos son correctos, crearemos una nueva clase Menu_Principal, que es el formulario
            Dim mPrincipal As New Menu_Principal
 
            'accedemos al formulario y escondemos el actual
            mPrincipal.Show()
        End If
End Sub
 

Ahora si, accedemos a la capa de negocio para ver si tiene datos, si están vacios, etc...

Código vb:

Public Class Negocio_logueo
    'Esta capa mirará a ver si los datos que li pasamos de la clase Clase_Login son correctos i devolverá un valor
    Public Function comprueba_logueo(ByVal usuario As String, ByVal contrasena As String) As Boolean
        Dim erroneo As Boolean
 
        'si el usuario està vacio
        If usuario = "" Then
            erroneo = True
        Else
            If contrasena = "" Then
                erroneo = True
            Else
                'si el usuario tiene texto y la contrasena tiene texto, procedimos a conectarnos a la BBDD para el logueo del usuario
                 Dim conexion as new BBDD
 
                 'llamo al metodo loguin y le paso los parametros
                 BBDD.loguin(usuario , contrasena)
 
                 'si todo ha ido bien, no ha habido nada erroneo
                 erroneo = False
            End If
        End If
 
        return erronio
    End Function
End Class
 

Me falta diseñar la Capa de datos pero bueno, creo que la estructura la estoy haciendo bien. Como lo veis?

Saludos

[Fernando_net]

Upeo, que me interesa :$

[Fernando_net]

Nada pues.

Gracias, muy amables :)

[Highlander]

A mi tb me interesa.

[Fernando_net]

Si, pero fijate, este tema no le ha gustado a 4 personas...

Es decir, no les gusta que preguntes la estructura interna de un programa y como hacer llamamientos.

Una lastima, porqué podía haber sido un tema interesante...

[Fernando_net]

Iniciado por Highlander

A mi tb me interesa.

Añado cosas a lo que he añadido en el anterior.

Fijate que puede ser un post interesante, en cuanto como puede estar estructurada una aplicación, como funcionan las clases, el llamamiento a ellas, como debe de hacerse de forma correcta, etc.

Creo que es una cosa a tener en cuenta para desarrollar software de calidad y bien optimizado.

He añadido codigo más arriba para ver si estaba bien estructurado como sería una aplicación en 3 capas, pero ya ves que por motivos que desconozco no se han dignado a explicarlo.

En cambio, tienes post como el de la factura electronica SAT Mexico que ya ves, ya tienen páginas y despierta gran interés.

En cambio, como estructurar internamente una aplicación, con sus respectivas capas y como hacer un buen llamamiento de clases, con sus respectivos métodos, etc.... veo que no interesa a nadie, solamente a los que queremos realizar software de calidad, que veo que somos pocos.

Un saludo