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.
