Investigación e ingenio

Lógico o físico, esa es la cuestión.

noreply@blogger.com (Fernando) — Fri, 13 May 2011 20:40:00 +0000

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.

Ser solidario, compartir

noreply@blogger.com (Fernando) — Sun, 13 Jan 2008 15:48:00 +0000

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.

noreply@blogger.com (Fernando) — Thu, 08 Nov 2007 16:26:00 +0000

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.

Pongámonos más técnicos

noreply@blogger.com (Fernando) — Wed, 16 May 2007 20:27:00 +0000

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.

Implementaciones IV

noreply@blogger.com (Fernando) — Fri, 16 Feb 2007 23:06:00 +0000

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

Implementaciones III

noreply@blogger.com (Fernando) — Thu, 27 Jul 2006 00:38:00 +0000

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

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.

Implementaciones II

noreply@blogger.com (Fernando) — Sat, 01 Jul 2006 20:30:00 +0000

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.

Oops I

noreply@blogger.com (Fernando) — Thu, 22 Jun 2006 23:43:00 +0000

Me olvidaba.

En este caso Oop no son iniciales de nada "Orientado a Objetos" solamente significa que me estaba olvidando.

En VisualBASIC, cada clase se guarda en su propio archivo de disco. Para ello usa como nombre de archivo el que le hemos dado a la clase y como extensión Cls (de Class obvio).

Idea.

Cuando empezamos a escribir nuestras propias clases y le vamos tomando la mano a la filosofía de la programación orientada a objetos empezamos a hacerlas más genéricas o sea, que se pueden usar en un mayor número de oportunidades. Esto es lo que decía al principio de reutilización.

En este caso no es mala idea guardarlas en una carpeta aparte que podemos llamar con algún nombre brillante, por ejemplo; "Biblioteca de clases", y las cargamos desde allí en futuros proyectos.

¿No traen problemas las versiones?.

¿Puedo meter las clases en una DLL?.

Bueno che, esto es una idea nada más. Ya vamos a ir viendo esos temitas.

Hasta la próxima.

Implementaciones I

noreply@blogger.com (Fernando) — Wed, 21 Jun 2006 00:19:00 +0000

Implementación en Visual BASIC.

Bueno después de tanta teoría creo que vendría bien algo de práctica.

Como ya mencioné en varias oportunidades, la tecnología de objetos abarca una gran variedad de aspectos. La estrategia que aborde en estos artículos es ir atendiendo a tales aspectos en forma paulatina a medida que se vayan haciendo necesarios. Los que saben dicen que esta técnica se llama aprendizaje significativo.

Entonces, debido a que es nuestra primera aproximación a alguna forma de implementación de clases y objetos, comenzaremos modestamente viendo clases y objetos en VisualBASIC.

La gente que "sabe" siempre dijo que VisualBASIC no esta hecho para trabajar con objetos pero, desgraciadamente me enteré de ello después de muchos años de trabajar con objetos en VisualBASIC, deberían haberme avisado antes.

No es un lenguaje orientado a objetos, eso es verdad, pero hasta el momento nunca tuve problemas para implementar, incluso, hasta algunos patrones de diseño bastantes complejos.

Una Clase.

Dada la interfaz amigable del lenguaje que nos ocupa, resulta sencillo crear una clase. Para ello debemos ir a la opción de menú Proyecto y en ella seleccionar Agregar módulo de clase.

Nos presentará en nuestra pantalla entonces un cuadro de diálogo con algunas opciones y de ellas nosotros eligiremos la primera, Módulo de clase.

Entonces se agregará una nueva carpeta en el explorar del proyecto identificada con la etiqueta Módulos de clase. En esta carpeta se iran incorporando las otras clases que contenga nuestro proyecto.

Primera cosa rara, solamente se muestra la ventana de código para una clase. Esto ocurre porque una clase no tiene interfaz gráfica como los formularios.

En la ventana de propiedades veremos tres propiedades, por ahora nos interesaremos solamente por la primera, el nombre. Siempre a las clases debemos ponerle un nombre que sea representativo del conjunto de objetos del cuál será la plantilla. Así, si la clase será la plantilla de un grupo de personas es lógico que la misma se llame Persona.

Ya está, tenemos una clase.

¿Qué hace?. Nada. Bueno paciencia vamos de a poco.

Los atributos de nuestra clase.

Hay dos formas de que una clase tenga atributos. Una fácil y una un poco más complicada.

Como siempre la solución fácil es la más limitada. Empezaremos con la fácil.

Supongamos que toda persona tendrá un apellido y un nombre, entonces en la ventana de código de la clase en la sección de declaraciones definiremos dos variables de la siguiente manera:

Public Apellido As String

Public Nombre As String

Listo, nuestra clase ya tiene dos atributos a los cuales podemos acceder desde afuera. ¿Porqué?. Todo lo que en una clase declaremos como público, ya sean variables, funciones o procedimientos, formarán parte de la interfaz de la misma.

¿Qué es una interfaz?.

Una interfaz exporta la funcionalidad de, en este caso, la clase o sea, define para qué puede usarse la clase desde afuera.

Todo lo que en la clase sea declarado como privado no habrá manera que sea accedido desde afuera de ella.

Instanciación de nuestra clase.

Recordemos que la clase es la plantilla de un conjunto de posibles objetos, un programa usará un objeto específico de determinada clase, Uff, se está complicando.

En el programa que usa objetos de la clase Persona debemos crear instancias de objetos Persona, para ello primero declaramos variables del tipo de clase que vamos a utilizar y después instanciamos el objeto.

En código quedaría algo así:

Dim objPers As Persona 'Crea al objeto

Set objPers = New Persona 'Instancia al objeto

Ahora sí ya podemos usar el objeto objPers, por ejemplo:

objPers.Apellido = "PEREZ"

Después de poner el nombre de la instancia del objeto y el operador punto, se despliegan automáticamente todos los miembros de la interfaz.

Bueno no hemos creado algo que figure en la historia de la informática pero es nuestro primer acercamiento práctico y creo que seguir avanzando, por ahora, solamente incrementará las horas en el Analista.

Obviamente queda mucho por ver pero eso es solamente un pretexto para seguirla.

Un abrazo.

Objetos III

noreply@blogger.com (Fernando) — Sun, 11 Jun 2006 21:35:00 +0000

Veamos algunas iniciales.

Bueno.

Acá estamos otra vez.

Obviamente vamos a seguir con los objetos y ya que vimos algunas cosas veamos un poco mas.

En toda esta terminología que se usa en el universo de los objetos hay una que suena mucho y es UML.

¿Qué es UML?.

Un lenguaje, de hecho UML significa Lenguaje Unificado de Modelado, claro que en inglés.

Expliquemos un poquito más. En toda actividad es importante lograr un entendimiento entre las personas que la desarrollan, ese es uno de los objetivos de UML. Que todas las personas que usamos esta tecnología nos expresemos de la misma manera.

Así UML determina una serie de definiciones y símbolos que cualquier desarrollador debe conocer para poder comunicarse con otros desarrolladores.

Además también determina reglas para combinar esos símbolos en determinados diagramas que permiten entonces alcanzar una gran expresividad en el momento de diseñar aplicaciones.

Estos diagramas abarcan desde la estructura de un sistema (clases y subsitemas que lo componen), al comportamiento (o sea, como se hace internamente lo que se debe hacer) sin dejar de lado otras cuestiones como la configuración y distribución (o sea, las computadoras que harán de servidores y de clientes en la aplicación, los nodos).

Ya que estamos esa es otra cualidad de los objetos, en una misma entidad conjugan estructura de datos y comportamiento. Como ven nos vamos poniendo técnicos

¿Es importante conocer UML?.

Si. Aca cabe hacer una aclaración es importante para poder lograr expresarnos, organizarnos y entendernos con otros pero no es suficiente saber UML para poder diseñar orientado a objetos.

Hacen falta algunos conocimientos más como ser alguna metodología de diseño como puede ser OMT (un poco antigua), RUP (mas nueva) y algunas cositas mas como ser patrones, etc..

Bueno como ven son muchas cosas y las vamos a ir viendo de a poco.

Saludos para todos y el que lo desea que escriba sobre cualquier tema de los que promueven a este blog.

Hasta la próxima.

Objetos II

noreply@blogger.com (Fernando) — Thu, 25 May 2006 22:35:00 +0000

Sigamos con los objetos.

Bueno ya estuvimos viendo algunas cositas del tema objetos.

Metamonos un poco más en cuestiones técnicas.

Cuando entramos al mundo de los objetos, entre los primeros conceptos que aparecen están los de clase de objeto e instancia de objeto. Estos términos, explicados por muchos profesores se convierten en extrañas cosas muy esotéricas, abstractas que han generado los dioses del Olimpo para torturar la mente de los mortales haciendolos sentir poca cosa por no entender a los mismos.

La verdad es que nada tiene de complicado y los que lo complican sólo puede ser porque ellos no lo comprenden en realidad o bien porque les dá status de investigadores serios, mmmmm.

¿Qué es una clase?.

La definición correcta es que define un conjunto de objetos con una comunidad de semántica, atributos, comportamiento y relaciones con otros objetos. ¿Y qué significa esto?. Fácil una clase es la plantilla que define a un conjunto de objetos concretos.

Por ejemplo, la clase Persona define a un conjunto de objetos concretos (Juancito, Pedrito, Ana, etc.) pués ocurre que todos ellos tienen características comunes (atributos) como ser; Apellido, Nombre, Fecha de nacimiento, DNI, etc.

¿Qué es una instancia?.

Más fácil todavía es uno de los elementos del conjunto definido por la clase o sea, un objeto concreto. Esto es, Juancito es una instancia de la clase Persona.

Como vemos, no estamos tratando conceptos tan elevados, un poco locos pueden ser eso sí.

En las clases se incluyen todas las características comunes que van a tener todas las posibles instancias de la misma. Por ejemplo si la clase Persona la usaremos para representar al ciudadano común no tiene sentido que tenga el atributo (característica) Título. ¿Por qué?. Fácil porque no todas las personas tienen algún título universitario, terciario, etc.

Che y cuando se dice objeto a secas, ¿de qué se está hablando?.

Depende puede ser de una clase o de una instancia pero, el contexto de la conversación o texto seguramente nos permitirá darnos cuenta de cuál de las dos opciones se trata.

¿Y cuando programamos hacemos clases o instancias?.

Ambas, primero definimos la clase para poder usarla después. Más tarde en alguna parte de la aplicación que necesitemos crear un objeto concreto, específico de esa clase entonces las instanciamos, palabrita top que significa que hemos creado una instancia de una clase.

Bueno algo más hemos visto, espero que no haya sido una discusión filosófica sino algo maso entendible.

La seguimos.

Objetos I

noreply@blogger.com (Fernando) — Sat, 13 May 2006 02:07:00 +0000

¿Objetos, una moda pasajera?
Hoy en día están muy de moda pero, ¿son una moda en realidad?.
No, en mi opinión no lo son.
He visto muchas modas informáticas pseudo-revolucionarias que, por ser solamente modas, duraron nada.
Los objetos vinieron para instalarse y no por decisión de una empresa o un grupo de investigadores trasnochados. Se instalaron por peso propio.
Ocurre que la programación orientada a objetos (POO), es lo más similar a lo que ocurre en el mundo real donde no existen funciones aisladas y con entidad propia. Lo que existe son objetos que tienen funciones parra llevar a cabo determinadas tareas y que al interactuar con otros objetos consiguen algún comportamiento combinado mucho más complejo que la suma de las posibilidades de cada objeto por separado.
Esto es sólo una perspectiva de la tecnología de objetos desde el punto de vista de un contexto global, cómo estamos tratando de diseñar e implementar aplicaciones de una manera más parecida a la realidad.
Pero existen otras perspectivas, otras miradas, de esta tecnología.
Para los informáticos la POO ofrece muchos beneficios, entre ellos podemos citar los siguientes:

Encapsulamiento: esto significa que todo lo concerniente a un objeto está "encerrado" dentro de él y el entorno, lo de afuera, no tiene manera de acceder al mismo. Si el entorno no puede acceder a él, cualquier cambio que hagamos en el código interno de un objeto no será visible desde afuera o sea, cualquier cambio que hagamos no impactará en el resto del código.
Reutilización: cuando tenemos objetos genéricos, los de las capas de servicio (esto lo discutiremos en otra oportunidad), debido a que todo lo que hacen y necesitan, está encapsulado en el propio objeto, puede volver a usarse en otra oportunidad donde lo necesitemos. Por ejemplo si tenemos un objeto que encapsula todos los datos de un cliente y su almacenamiento persistente, cada vez que tengamos la necesidad de incorporar en un sistema el concepto de cliente, podemos implementarlo volviendo a usar (reutilizando) nuestro objeto cliente, sin programar una sola línea.

Estas son algunas de las ventajas que nos ofrecen y las cité en este momento porque para cualquiera que haya programado alguna vez una aplicación sabrá valorarlas.
Antes de terminar creo conveniente dejar claro que es un objeto.

Objeto: cualquier concepto, cosa o abstracción con límites bien definidos y con sentido para el problema que estamos tratando. O sea, un objeto puede ser; una persona, un automóvil, una carpeta de archivos, una política de venta, un usuario, una venta, un sensor, un puesto de trabajo, etc.

¿Cuáles son los objetos que debemos usar en una aplicación?
Bueno eso dependerá de la aplicación que tenemos que diseñar y para poder determinarlos hay diversas técnicas de análisis y diseño orientado a objetos (ADOO).
Bueno poco a poco iremos viendo algo más sobre el mundo de los objetos.
Los saludo y que la pasen bárbaro.

Bienvenidos

noreply@blogger.com (Fernando) — Thu, 30 Mar 2006 02:41:00 +0000

Hola Bienvenidos.
Este Blog es para la gente de cualquier edad, sexo, creencia, etc, etc..
Lo único que nos junta es que somos apasionados por temas de programación de computadoras sea en el lenguaje que sea.
Bueno, esa es la idea, juntarnos a discutir e intercambiar ideas sobre programación, diseño gráfico, diseño de sistemas, diseño web, etc.
Como un bar pero desde nuestras compus.
Espero que se encuentren a gusto.
Un abrazo.