viernes, mayo 13, 2011
Lógico o físico, esa es la cuestión.
Antes que nada holaaa, la verdad es que hacia mucho que no posteaba.
Bueno pero aquí estoy de nuevo.
Estaba leyendo mi último post que trataba sobre el tema de las DLL's y de ahí el título de este post.
¿Cuál es la difrencia entre lógico y físico?.
Lógico tiene que ver con lo conceptual, forma parte de la solución a nivel de concepto, de idea. Se llama así porque tiene que ver con la lógica que se sigue en la resolución del problema.
Físico tiene que ver con lo tangible, je siempre y cuando seamos suficientemente imaginativos como para pensar a un archivo en el rígido, como algo que se puede tocar.
Una DLL forma parte del mundo físico, porque en el rígido habrá algo como MiDLL.dll, un archivo.
Ajá, ¿pero cómo se relaciona con lo lógico?.
Con el contenido. Lo que hay adentro de la DLL es algo lógico escrito en algún lenguaje con el cuál pueda escribirse una DLL, también llamada librería.
Ok, ok, ¿pero específicamente que podría contener?.
Bueno una DLL podría contener; todas las clases de una capa de la aplicación, en ese caso la capa (lógica) coincide con la DLL (física), también podría tener todas las clases necesarias para realizar un caso de uso, todas las clases necesarias para dar soporte a un conjunto de casos de uso, por ejemplo la gestión de clientes, o las clases necesarias para algún servicio, etc..
Uhhhh, muy técnico y hacia mucho que no posteaba, me agoté.
Bueno voy a seguir comiendo mis churros y disfrutar de la lluvia, la seguimos en la próxima que prometo que va a ser dentro de este año, jajajajaja. Chauuu.
Bueno pero aquí estoy de nuevo.
Estaba leyendo mi último post que trataba sobre el tema de las DLL's y de ahí el título de este post.
¿Cuál es la difrencia entre lógico y físico?.
Lógico tiene que ver con lo conceptual, forma parte de la solución a nivel de concepto, de idea. Se llama así porque tiene que ver con la lógica que se sigue en la resolución del problema.
Físico tiene que ver con lo tangible, je siempre y cuando seamos suficientemente imaginativos como para pensar a un archivo en el rígido, como algo que se puede tocar.
Una DLL forma parte del mundo físico, porque en el rígido habrá algo como MiDLL.dll, un archivo.
Ajá, ¿pero cómo se relaciona con lo lógico?.
Con el contenido. Lo que hay adentro de la DLL es algo lógico escrito en algún lenguaje con el cuál pueda escribirse una DLL, también llamada librería.
Ok, ok, ¿pero específicamente que podría contener?.
Bueno una DLL podría contener; todas las clases de una capa de la aplicación, en ese caso la capa (lógica) coincide con la DLL (física), también podría tener todas las clases necesarias para realizar un caso de uso, todas las clases necesarias para dar soporte a un conjunto de casos de uso, por ejemplo la gestión de clientes, o las clases necesarias para algún servicio, etc..
Uhhhh, muy técnico y hacia mucho que no posteaba, me agoté.
Bueno voy a seguir comiendo mis churros y disfrutar de la lluvia, la seguimos en la próxima que prometo que va a ser dentro de este año, jajajajaja. Chauuu.
domingo, enero 13, 2008
Ser solidario, compartir
Holaaaaa, aca estoy de nuevo.
Porqué, ser solidario y compartir?. Es un poco la idea promotora de la tecnología de componentes.
A ver. Supongamos que nos esforzamos y escribimos un trozo de buen código, hicimos pruebas unitarias, pruebas de integración, etc. (mmmm en algún momento tocaremos estos temas).
Como nos salió tan lindo estaría bueno tratar de reescribirlo para la próxima o sea, cuando necesitemos algo parecido, usar directamente este código. Esto ya vimos que se llamaba reutilización.
Por eso es buena idea cuando nos encontramos con alguna funcionalidad que sabemos o intuímos que puede ser útil en otro momento, tratar de escribir el código de manera tal que pueda funcionar en otro contexto o sea, bajo otras circustancias, bajo otra demanda.
Así nos vamos haciendo nuestra propia biblioteca de código, guardada en un carpetita todo ordenado y bonito como corresponde.
Je, bárbaro. Cuando sea necesario nuevamente, qué hacemos, cortamos y pegamos ese código?.
Mmmmmmm la verdad que sería una forma de reutilización pero, media precaria, digna de un estudiante de salita de 5 años. :).
Mas profesional sería hacer un componente.
Ehhhhh?.
Si si, ese código lo ponemos en una clase juntos con otros códigos que se nos ocurran y armamos un componente.
Ojo debemos tener algunas cosas en cuenta, una clase tiene que ser coherente (esto es el patrón de diseño de alta coherencia), esto significa que debe hacer pocas cosas y estas pocas cosas deben estar de alguna manera relacionada.
Por ejemplo, hacemos una clase y le ponemos la operación ImprimirListado(...), y también le ponemos la operación GrabarRegistro(...) no resultan muy relacionadas ambas operaciones dado que una plantea la salida de información a granel, formateada hacia la impresora y la otra operación plantea el almacenamiento permanente de información podríamos decir atómica sobre alguna forma de almacenamiento.
Nuestra clase sería mas coherente si contuviera las operaciones; ImprimirListado(...), ImprimirEncabezado(...), etc. y otra clase que contuviera las operaciones; GrabarRegistro(...), RecuperarRegistro(...), etc.
Ok las clases son lo que antes hemos llamado componentes?.
Si pero, el empaquetamiento físico o sea, el archivo donde están contenidas es un Exe Estandar?.
No.
La manera mas fácil de hacer un componente es, al abrir el proyecto seleccionar DLL ActiveX y ahí poner nuestras clases.
O sea, que en una DLL podemos tener una o más clases.
Estas clases, como ya vimos, tendrán operaciones públicas y operaciones privadas. Cualquier otra aplicación que use la DLL (aplicación cliente), sólo podrá usar las operaciones públicas de cada una de las clases, siempre que la misma se vea desde afuera de la DLL.
De ahí la separación de operación y método.
Mientras no cambiemos la signatura de la operación, su definición, el cliente ni se entera. Esto permite mejorar el día de mañana el algoritmo, cambiar el método, y otras cuantas cosas más que iremos viendo.
También hay que tener cuidado con algunas cosas, por ejemplo, nunca compilar una DLL hasta que las clases y sus interfaces sean estables porque haremos un chiquero en el registro de Windows y ademas tendremos problemas de incompatibilidad con los clientes viejos.
De ahí el título de este posteo, un componente comparte con el resto del mundo.
Ahhhh antes de terminar me olvidaba, otra cosa buena de la tecnología de componentes es que no importa cómo se implementó el componente, en nuestro caso la DLL. Esto significa que, por ejemplo, la escribimos en VisualBASIC y la usamos con cualquier lenguaje que pueda cargar una DLL.
Es interesante.
Bueno la sigo la próxima porque hace mucho calor, chauuuu.
Porqué, ser solidario y compartir?. Es un poco la idea promotora de la tecnología de componentes.
A ver. Supongamos que nos esforzamos y escribimos un trozo de buen código, hicimos pruebas unitarias, pruebas de integración, etc. (mmmm en algún momento tocaremos estos temas).
Como nos salió tan lindo estaría bueno tratar de reescribirlo para la próxima o sea, cuando necesitemos algo parecido, usar directamente este código. Esto ya vimos que se llamaba reutilización.
Por eso es buena idea cuando nos encontramos con alguna funcionalidad que sabemos o intuímos que puede ser útil en otro momento, tratar de escribir el código de manera tal que pueda funcionar en otro contexto o sea, bajo otras circustancias, bajo otra demanda.
Así nos vamos haciendo nuestra propia biblioteca de código, guardada en un carpetita todo ordenado y bonito como corresponde.
Je, bárbaro. Cuando sea necesario nuevamente, qué hacemos, cortamos y pegamos ese código?.
Mmmmmmm la verdad que sería una forma de reutilización pero, media precaria, digna de un estudiante de salita de 5 años. :).
Mas profesional sería hacer un componente.
Ehhhhh?.
Si si, ese código lo ponemos en una clase juntos con otros códigos que se nos ocurran y armamos un componente.
Ojo debemos tener algunas cosas en cuenta, una clase tiene que ser coherente (esto es el patrón de diseño de alta coherencia), esto significa que debe hacer pocas cosas y estas pocas cosas deben estar de alguna manera relacionada.
Por ejemplo, hacemos una clase y le ponemos la operación ImprimirListado(...), y también le ponemos la operación GrabarRegistro(...) no resultan muy relacionadas ambas operaciones dado que una plantea la salida de información a granel, formateada hacia la impresora y la otra operación plantea el almacenamiento permanente de información podríamos decir atómica sobre alguna forma de almacenamiento.
Nuestra clase sería mas coherente si contuviera las operaciones; ImprimirListado(...), ImprimirEncabezado(...), etc. y otra clase que contuviera las operaciones; GrabarRegistro(...), RecuperarRegistro(...), etc.
Ok las clases son lo que antes hemos llamado componentes?.
Si pero, el empaquetamiento físico o sea, el archivo donde están contenidas es un Exe Estandar?.
No.
La manera mas fácil de hacer un componente es, al abrir el proyecto seleccionar DLL ActiveX y ahí poner nuestras clases.
O sea, que en una DLL podemos tener una o más clases.
Estas clases, como ya vimos, tendrán operaciones públicas y operaciones privadas. Cualquier otra aplicación que use la DLL (aplicación cliente), sólo podrá usar las operaciones públicas de cada una de las clases, siempre que la misma se vea desde afuera de la DLL.
De ahí la separación de operación y método.
Mientras no cambiemos la signatura de la operación, su definición, el cliente ni se entera. Esto permite mejorar el día de mañana el algoritmo, cambiar el método, y otras cuantas cosas más que iremos viendo.
También hay que tener cuidado con algunas cosas, por ejemplo, nunca compilar una DLL hasta que las clases y sus interfaces sean estables porque haremos un chiquero en el registro de Windows y ademas tendremos problemas de incompatibilidad con los clientes viejos.
De ahí el título de este posteo, un componente comparte con el resto del mundo.
Ahhhh antes de terminar me olvidaba, otra cosa buena de la tecnología de componentes es que no importa cómo se implementó el componente, en nuestro caso la DLL. Esto significa que, por ejemplo, la escribimos en VisualBASIC y la usamos con cualquier lenguaje que pueda cargar una DLL.
Es interesante.
Bueno la sigo la próxima porque hace mucho calor, chauuuu.
jueves, noviembre 08, 2007
Hola Amigos
No los abandoné. Ocurre que no sé porqué, no podía entrar a editar mi blog.
Bueno de ahora en más volveré con estos temas, creo que interesantes, sobre programación.
Bueno saludos a todos y en estos días subo material nuevo.
No los abandoné. Ocurre que no sé porqué, no podía entrar a editar mi blog.
Bueno de ahora en más volveré con estos temas, creo que interesantes, sobre programación.
Bueno saludos a todos y en estos días subo material nuevo.
miércoles, mayo 16, 2007
Pongámonos más técnicos
Hasta acá ya hemos visto unas cuantas cosas de objetos.
Qué cosas?.
Bueno que es una clase, una instancia, un atributo, un método, cómo implementar todo esto en VisualBASIC y ya veremos cómo hacerlo en otros lenguajes.
La idea en este Post es dar algunas definiciones más técnicas ahora que ya estamos mas conocedores del tema, así que ahí van:
Clase: define un conjunto de objetos que comparten los mismos atributos, las mismas operaciones, las mismas relaciones y la misma semántica. (¿misma semántica?, tomalo como el mismo significado).
Instancia: un elemento específico de los definidos en una clase. Por ejemplo, podemos tener la clase Persona (habla de un conjunto) y la instancia Juancito (habla de un elemento del conjunto).
Atributo: propiedad de una clase que define un conjunto de valores que puede tener una instancia del atributo. Ehhhh?. Fácil un atributo es una propiedad que tiene cualquier instancia que pertenezca a la clase y cada una de esas instancias tendrá su propio valor para ese atributo. Por ejemplo nuestra clase Persona tiene un atributo llamado nombre, una instancia podrá tener el calor "Juan" para ese atributo y otra instancia el valor "Ana".
Operación: define un servicio de la clase, que puede ser requerido a cualquier instancia de la clase. Esto sería....? Algo que cualquier instancia de la clase puede hacer. Acá cabe hacer una aclaración hay una diferencia entre operación y método. Operación se refiere a la signatura o sea a la definición por ejemplo ExtraerPromedio(Nota1: real, Nota2: real):real, oops. Non calentarum largum vivirum esto significa que la operación se llama ExtraerPromedio y que devuelve un resultado que será del tipo real y que recibirá dos parámetros, los que están dentro del paréntesis, que se llaman Nota1 y Nota2 y ambos serán también del tipo real. Recordemos que el significado matemático de los dos puntos es "es" así que poner Nota1:real sería los mismo que poner Nota1 es real.
¿Ok y el método que será?. Será la implementación, el código que habrá detrás de ExtraerPromedio y que en definitiva hará algo.
¿A qué se debe que la compliquen así?. Se separa el concepto de operación y método para, entre otras cosas, poder usar polimorfismo. Esperá no te cuelgues con el cable del mouse, ta vamos a ver de que se trata.
Además las operaciones forman parte de la interfaz y los métodos no.
Interfaz: define un conjunto de operaciones que especifica un servicio que puede proporcionar una clase o componente. O sea, son todas las operaciones públicas que muestra una clase o componente. Bah, en realidad no es tan así porque estos clasificadores (clases y componentes) pueden mostrar más de una interfaz pero, por hoy ya fué bastante.
Listo nos vemos en la próxima chau, chau.
Qué cosas?.
Bueno que es una clase, una instancia, un atributo, un método, cómo implementar todo esto en VisualBASIC y ya veremos cómo hacerlo en otros lenguajes.
La idea en este Post es dar algunas definiciones más técnicas ahora que ya estamos mas conocedores del tema, así que ahí van:
Clase: define un conjunto de objetos que comparten los mismos atributos, las mismas operaciones, las mismas relaciones y la misma semántica. (¿misma semántica?, tomalo como el mismo significado).
Instancia: un elemento específico de los definidos en una clase. Por ejemplo, podemos tener la clase Persona (habla de un conjunto) y la instancia Juancito (habla de un elemento del conjunto).
Atributo: propiedad de una clase que define un conjunto de valores que puede tener una instancia del atributo. Ehhhh?. Fácil un atributo es una propiedad que tiene cualquier instancia que pertenezca a la clase y cada una de esas instancias tendrá su propio valor para ese atributo. Por ejemplo nuestra clase Persona tiene un atributo llamado nombre, una instancia podrá tener el calor "Juan" para ese atributo y otra instancia el valor "Ana".
Operación: define un servicio de la clase, que puede ser requerido a cualquier instancia de la clase. Esto sería....? Algo que cualquier instancia de la clase puede hacer. Acá cabe hacer una aclaración hay una diferencia entre operación y método. Operación se refiere a la signatura o sea a la definición por ejemplo ExtraerPromedio(Nota1: real, Nota2: real):real, oops. Non calentarum largum vivirum esto significa que la operación se llama ExtraerPromedio y que devuelve un resultado que será del tipo real y que recibirá dos parámetros, los que están dentro del paréntesis, que se llaman Nota1 y Nota2 y ambos serán también del tipo real. Recordemos que el significado matemático de los dos puntos es "es" así que poner Nota1:real sería los mismo que poner Nota1 es real.
¿Ok y el método que será?. Será la implementación, el código que habrá detrás de ExtraerPromedio y que en definitiva hará algo.
¿A qué se debe que la compliquen así?. Se separa el concepto de operación y método para, entre otras cosas, poder usar polimorfismo. Esperá no te cuelgues con el cable del mouse, ta vamos a ver de que se trata.
Además las operaciones forman parte de la interfaz y los métodos no.
Interfaz: define un conjunto de operaciones que especifica un servicio que puede proporcionar una clase o componente. O sea, son todas las operaciones públicas que muestra una clase o componente. Bah, en realidad no es tan así porque estos clasificadores (clases y componentes) pueden mostrar más de una interfaz pero, por hoy ya fué bastante.
Listo nos vemos en la próxima chau, chau.
viernes, febrero 16, 2007
Implementaciones IV
Holaaaaaa. Si ya sé pensaban que había abandonado el blog. Naa.
Anduve un poco ocupado y además, los chicos de Arnet me tuvieron más de un mes sin servicio, y eso que contrate el servicio más grande que ofrecen. Estos chicos... Deberían poner una verdulería en lugar de dedicarse a la tecnología. Mmmmmm, ¿podrán manejar una verdulería?.
Bueno pero vamos al tema de este post. Repasemos un poco, estabamos con las propiedades.
Habíamos visto que básicamente teníamos dos formas de codificar una propiedad para una clase.
La primera, y la más fácil y precaria, era a través de una variable pública cuyo nombre se transformaba directamente en la propiedad del objeto.
La segunda, un poco menos fácil pero más seria, era mediante la definición previa de una variable privada y las definiciones posteriores de dos métodos Property; uno para leer el valor de la propiedad (GET) y otro para poner un valor en la propiedad (LET).
Bien, los que ya han tenido algunas horas de desvelo programando, habrán observado que hay algunos objetos que tienen propiedades que solamente pueden leerse y otros propiedades que solamente pueden escribirse.
Oops y esto ¿cómo se hace?.
Es muy sencillo, si queremos hacer una propiedad de sólo lectura debemos definir solamente el procedimiento Property GET así el cliente que use nuestra clase, verá la propiedad en la lista automática de miembros pero solamente podrá leerla.
Mmmmmmmm veamos un ejemplo. Supongamos que a la clase Persona que ya habíamos mencionado en otro post le queremos agregar la propiedad FechaDeNacimiento obviamente se tratará de una propiedad que el cliente debe poder usarla tanto para leer (consultar la fecha de nacimiento de la persona) como para escribir (asignar la fecha de nacimiento de la persona). Bárbaro eso ya sabemos como hacerlo.
Que linda nos está quedando nuestra clase Persona. Nos queda tan linda que podríamos mejorla un poco más, por ejemplo podríamos darle un servicio extra al cliente indicando la edad de la persona.
Bien, pensemos un poco. La fecha de nacimiento es algo que no cambia, para cada persona, permanece fija. La edad es un valor dinámico, cambia a cada momento.
Ahora bien, sabiendo la fecha de nacimiento de una persona y teniendo algunas funciones de manejo de fechas, no resultaría difícil hacer alguna rutinita, algún algoritmo, que permita calcular la edad.
Uhhhhhhhhhh que bien venimos.
Sigamos pensando, la edad la calculamos a partir de la fecha de nacimiento entonces, ¿debe implementarse como una propiedad de escritura/lectura?.
No, porque el valor no debe ser ingresado sino que como dijimos se calcula. Esto se conoce como valor derivado.
Ya que no hace falta ingresarlo solamente necesitamos escribir el código de una propiedad de sólo lectura. Algo así:
Public Property Get Edad() As Integer
Edad = m_intEdad
End Property
Obviamente a m_intEdad se le habrá calculado el valor apropiado, previamente.
Cómo no existe el procedimiento Property Let el cliente no podrá acceder a Edad para ponerle un valor, nuestro amigo VisualBASIC le hará notar el error.
Menos frecuente pero también posible es hacer propiedades de sólo escritura. Sería bastante parecido a lo que hicimos pero en lugar de implementar el procedimiento Property Get solamente implementaríamos el procedimiento Property Let.
Bueno ya vimos algo más de las propiedades pero la seguimos en la próxima.
Prometo no colgarme y postear mas seguido. Chauuuuu.
Nota: En la implementación de la propiedad Edad que puse anteriormente, se supone que el valor de la edad ya fue calculado. ¿Donde se debe calcular?. Uno de los patrones de diseño que se aplica es el Patrón Experto, el mismo dice que cada quién se debe encargar de lo que le corresponde (dicho de entrecasa). Mmmmmm si aplicamos esto, la edad debería calcularse entonces cuando se necesita o sea, cuando es requerida o sea, en el mismo código de la propiedad y en todo caso buscar la manera que una vez calculada no vuelva a hacerse el cálculo.
Si ya sé que también la puedo calcular al ingresar la fecha de nacimiento y vaya uno a saber en que otras partes del código pero bue, son detalles que van mejorando el diseño. La verdad no escribí el código para calcular el valor de m_intEdad dentro del Property Get por fiaca. Jajajaja, nos vemos la próxima
Anduve un poco ocupado y además, los chicos de Arnet me tuvieron más de un mes sin servicio, y eso que contrate el servicio más grande que ofrecen. Estos chicos... Deberían poner una verdulería en lugar de dedicarse a la tecnología. Mmmmmm, ¿podrán manejar una verdulería?.
Bueno pero vamos al tema de este post. Repasemos un poco, estabamos con las propiedades.
Habíamos visto que básicamente teníamos dos formas de codificar una propiedad para una clase.
La primera, y la más fácil y precaria, era a través de una variable pública cuyo nombre se transformaba directamente en la propiedad del objeto.
La segunda, un poco menos fácil pero más seria, era mediante la definición previa de una variable privada y las definiciones posteriores de dos métodos Property; uno para leer el valor de la propiedad (GET) y otro para poner un valor en la propiedad (LET).
Bien, los que ya han tenido algunas horas de desvelo programando, habrán observado que hay algunos objetos que tienen propiedades que solamente pueden leerse y otros propiedades que solamente pueden escribirse.
Oops y esto ¿cómo se hace?.
Es muy sencillo, si queremos hacer una propiedad de sólo lectura debemos definir solamente el procedimiento Property GET así el cliente que use nuestra clase, verá la propiedad en la lista automática de miembros pero solamente podrá leerla.
Mmmmmmmm veamos un ejemplo. Supongamos que a la clase Persona que ya habíamos mencionado en otro post le queremos agregar la propiedad FechaDeNacimiento obviamente se tratará de una propiedad que el cliente debe poder usarla tanto para leer (consultar la fecha de nacimiento de la persona) como para escribir (asignar la fecha de nacimiento de la persona). Bárbaro eso ya sabemos como hacerlo.
Que linda nos está quedando nuestra clase Persona. Nos queda tan linda que podríamos mejorla un poco más, por ejemplo podríamos darle un servicio extra al cliente indicando la edad de la persona.
Bien, pensemos un poco. La fecha de nacimiento es algo que no cambia, para cada persona, permanece fija. La edad es un valor dinámico, cambia a cada momento.
Ahora bien, sabiendo la fecha de nacimiento de una persona y teniendo algunas funciones de manejo de fechas, no resultaría difícil hacer alguna rutinita, algún algoritmo, que permita calcular la edad.
Uhhhhhhhhhh que bien venimos.
Sigamos pensando, la edad la calculamos a partir de la fecha de nacimiento entonces, ¿debe implementarse como una propiedad de escritura/lectura?.
No, porque el valor no debe ser ingresado sino que como dijimos se calcula. Esto se conoce como valor derivado.
Ya que no hace falta ingresarlo solamente necesitamos escribir el código de una propiedad de sólo lectura. Algo así:
Public Property Get Edad() As Integer
Edad = m_intEdad
End Property
Obviamente a m_intEdad se le habrá calculado el valor apropiado, previamente.
Cómo no existe el procedimiento Property Let el cliente no podrá acceder a Edad para ponerle un valor, nuestro amigo VisualBASIC le hará notar el error.
Menos frecuente pero también posible es hacer propiedades de sólo escritura. Sería bastante parecido a lo que hicimos pero en lugar de implementar el procedimiento Property Get solamente implementaríamos el procedimiento Property Let.
Bueno ya vimos algo más de las propiedades pero la seguimos en la próxima.
Prometo no colgarme y postear mas seguido. Chauuuuu.
Nota: En la implementación de la propiedad Edad que puse anteriormente, se supone que el valor de la edad ya fue calculado. ¿Donde se debe calcular?. Uno de los patrones de diseño que se aplica es el Patrón Experto, el mismo dice que cada quién se debe encargar de lo que le corresponde (dicho de entrecasa). Mmmmmm si aplicamos esto, la edad debería calcularse entonces cuando se necesita o sea, cuando es requerida o sea, en el mismo código de la propiedad y en todo caso buscar la manera que una vez calculada no vuelva a hacerse el cálculo.
Si ya sé que también la puedo calcular al ingresar la fecha de nacimiento y vaya uno a saber en que otras partes del código pero bue, son detalles que van mejorando el diseño. La verdad no escribí el código para calcular el valor de m_intEdad dentro del Property Get por fiaca. Jajajaja, nos vemos la próxima
miércoles, julio 26, 2006
Implementaciones III
Con esta humedad lo único que dan ganas es de escribir sobre programación.
Jajajajajaja.
La verdad es que anduve un poco ocupado y estaba atrasado con darle al teclado.
Pero buen, veamos si puedo ir poniendome al día.
Ya habiamos visto como hacer para que una clase tenga una propiedad, creando una variable y declarandola del tipo Public dentro del código de la clase.
Esa es la forma más sencilla de hacer esta tarea pero, en este caso, lo más sencillo no es lo mejor.
¿Por qué?. Porque cuando un objeto cliente le asigna un valor a la variable no tenemos forma de controlar, validar ni manipular dicho valor.
Pensemos como ejemplo la clase Persona con una variable pública llamada Apellido. Ni bien se le asigna un valor a esa variable no hay manera de operar sobre él. Supongamos por ejemplo que, independientemente de lo que el usuario escriba, deseamos que el apellido esté siempre en mayúscula. En este caso no hay forma de hacerlo.
Veamos entonces una manera más versátil y profesional de escribir el código correspondiente a una propiedad de una clase.
Propiedades de las clases, la forma correcta.
Lo primero que debemos recordar es que lo definido como privado dentro del código de la clase, pertenece exclusivamene a ella y no hay manera que de acceder a ello desde afuera de la misma.
Entonces, para cada propiedad definimos en la sección de declaraciones, para que tenga una visibilidad de módulo, una variable privada.
En el ejemplo planteado anteriormente nos quedaría algo así:
Private m_strApellido As String
Al ser privada no está disponible para el exterior de la clase.
¿Cómo usamos esa variable entonces?.
Tenemos que tener en cuenta que pueden existir dos posibilidades, que necesitemos asignarle un valor a ella o sea, guardar algo en ella o bien, que necesitemos recuperar, leer, el valor que ella contiene.
Entonces debemos definir dos procedimientos especiales para estas dos posibilidades. Estos procedimientos son los Property. Je!! el nombre los vende de que se trata de procedimientos de propiedad no?.
La sintaxis sería algo como lo siguiente:
Public Property Get Apellido() As String
Apellido = m_strApellido
End Property
Public Property Let Apellido(ByVal vNewValue As String)
m_strApellido = vNewValue
End Property
Cosa rara che. Naa.
Primero hay dos porque uno sirve para recuperar el valor y otro para asignarle un valor.
El Get, recupera un valor y usa el mismo nombre de la propiedad como contenedor, si nos fijamos en el código pone en Apellido el contenido de m_strApellido.
El Let, asigna el valor. ¿Cuál?. El que recibe en vNewValue.
Un cliente que use la clase persona, para asignarle un valor al apellido, escribir un código como el siguiente:
Dim objPers As Persona
Set objPers = New Persona
objPers.Apellido = "Perez"
Muy sencillo.
Para usar tal valor, en un cuadro de mensajes por ejemplo deberá escribir un código mas sencillo todavía.
MsgBox objPers.Apellido
Una ganga.
¿Si quisieramos que el apellido esté siempre en mayúscula?.
Solamente debemos modificar el procedimiento Property Let de la siguiente manera:
Public Property Let Apellido(ByVal vNewValue As String)
m_strApellido = UCase(vNewValue)
End Property
m_strApellido = UCase(vNewValue)
End Property
Nada y además el cliente ni se entera.
Como pueden ver el tema de las propiedades se pone bueno así que la seguimos en la próxima.
Nos vemos.
sábado, julio 01, 2006
Implementaciones II
Bueno es sábado a la tarde, hay solcito y no hace tanto frío.
La verdad me dieron ganas de escribir, entonces que mejor que avanzar un poco más en la manera de hacer objetos con Visual BASIC.
Ya habíamos visto una manera precaria de implementar atributos o propiedades, obviamente el decir que es precaria implica que hay otras mejores. Si si y ya las vamos a ver.
Lo que hoy vamos a ver son los métodos.
¿Qué son los métodos?.
Los métodos son las implementaciones de las operaciones. Mmmmm dificil che.
No tanto, conceptualmente, se separa las operaciones o sea, la definición de su signatura (su nombre, el nombre y tipo de los argumentos de entrada y el nombre y tipo de valores devueltos) de sus métodos o sea, el código que permite que la operación haga algo.
Así por ejemplo si defino un procedimiento de la siguiente manera:
Public Sub BuscarCliente(IDCliente As Long)
Esa es una operación de la clase, el código dentro del procedimiento, que es el que en realidad hace algo, será el método.
No era tan difícil. Pero, ¿para qué la complican tanto?.
Ya lo vamos a ir viendo.
Una vez que defino ese procedimiento, cuando instancio un objeto de la manera que ya expliqué mediante una variable, al poner el operador punto aparece BuscarCliente entre la lista de miembros desplegable o sea puede ser usado por cualquier código cliente que use el objeto.
Esto explica el motivo de separar las operaciones de los métodos, un cliente solamente ve la signatura de la función o sea la operación y podemos cambiar, mejorar o corregir el método sin que el cliente se entere. La verdad que está polenta.
Este es otro ejemplo de encapsulamiento todo lo que sea interno de la clase, los clientes no lo ven.
Hablando de interno.
¿Qué ocurre si necesitamos hacer alguna función o algún método y no queremos que los clientes lo usen?.
Muy sencillo lo declaramos como Private en lugar de Public. Debemos recordar que todo lo que sea Private podrá ser usado solamente dentro de la clase.
Es muy normal definir funciones o procedimientos privados que hacen algún trabajo de soporte al trabajo principal que se espera de la clase.
Como norma solamente se debe dejar público aquellas funcionalidades que el sentido común dice que nuestra clase debe tener, técnicamente esto se expresa que las clases deben ser cohesivas o sea que sus operaciones y atributos deben estar fuertemente relacionados.
