Mostrando entradas con la etiqueta software. Mostrar todas las entradas
Mostrando entradas con la etiqueta software. Mostrar todas las entradas

miércoles, 5 de noviembre de 2014

En entradas anteriores vimos Factory Method, y en esta entrada veremos Abstract Factory un patron creacional que amplía el rango de Factory Method. También vimos ObjectPool y una introducción a los patrones de diseño.

Recomiendo leer como minimo el Factory Method para que les sea más sencillo el Abstract Factory.

Si vemos la explicación del Factory Method notaremos que es útil para la creación de objetos de clases subtipos de una en particular, pero si quicieramos tener más de un tipo de clase principal, deberíamos hacer uso de un patrón que lo soporte.

Podemos ver en wikipedia como se explica que si nosotros trabajaramos con botones, dependiendo de la plataforma tendríamos un gran tipo de objeto para botones en linux y uno para botones en windows, si nosotros quicieramos crear objetos de ambos tipos con un factory necesitaríamos utilizar este patrón.

La solución para este problema es simple, si vemos el código de ejemplo de la publicación de Factory Method veremos que la factoría nos permitía crear objetos del tipo de EjemploConcreto, ahora si quicieramos además poder crear de tipode clases OtroEjemploConcreto, bastaría con crear métodos factory para cada clase en particular.

podemos ver el código aquí:

http://pastebin.com/V0HS6fU2

y un diagrama del Abstract Factory extraído de wikipedia:


Un saludo para todos! espero que les haya gustado la entrada y nos veremos la próxima!

miércoles, 29 de octubre de 2014

En esta entrada hablaremos sobre el patrón creacional Object Pool, recordemos que en la entrada anterior de este hilo vimos una introducción a los patrones en general, pueden apreciarla aquí (además de ver un índice de patrones)

En primera instancia hablaremos sobre los patrones creacionales, son aquellos patrones diseñados para solventar problemas enlazados a la creación o instanciación de objetos.

El patrón object pool está diseñado para almacenar instancias de los objetos, un cliente del Object Pool, solicita un objeto, el Object Pool lo devuelve, el cliente lo utiliza, y luego se lo devuelve al Object Pool, de modo que éste lo almacena y espera su próxima solicitud, cuando le solicitan el objeto nuevamente, el Object Pool lo devuelve y así continúa el ciclo, la idea de este patrón es reciclar un objeto. Como apreciará la utilización de este patrón implica que un objeto no se construye y destruye varias veces, sino que se recicla.

Pero hay que ser muy conciente de su funcionamiento, ya que es únicamente útil en situaciones donde el costo de crear una instancia sea relativamente alto, a diferencia del costo de mantenerla almacenada, de modo que solo es útil en ocaciones tales como clases de sockets o de recursos gráficos.

Hay situaciones en donde el costo de utilizar este patrón es mayor al costo de no utilizarlo, y hay situaciones en las que es al reves.

Un ejemplo de object pool en php:


Saludos, espero les haya gustado la entrada y sigan pendientes de las siguientes entradas.

sábado, 25 de octubre de 2014

En esta entrada comenzaremos el hilo de Patrones de Diseño, y comenzaremos hablando sobre una introducción a patrones de diseño, en entradas anteriores hablamos sobre el mal uso que se le da a singleton, y en esta entrada hablaremos sobre los distintos patrones.

El arquitecto Chritopher Alexander dijo en su libro:

"Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno, además incluye una solución para ese problema, de tal manera que usted pueda usar esa solución un millón de veces y más".
Si bien Christopher hablaba de patrones de edificios, no se aleja mucho de la idea de patrones en la industria del software, cuando un problema aparece una cantidad de veces bastante importante, se define un patrón del problema, y se busca una solución que aplique a todos los casos y casos futuros.

Como anuncia wikipedia, un patrón para serlo debe cumplir ciertas características, una de ellas es que debe comprobar su efectividad resolviendo el mismo problema en situaciones anteriores, y otra es la re-usabilidad, que significa que el patrón debe ser aplicado en futuras ocasiones donde el contexto varíe.

Por lo general un patrón está compuesto por cuatro partes:

El nombre: que nos sirve como descripción del problema y la solución que abarca dicho patrón.
El problema: el problema que trata de resolver y para el que fue diseñada la solución (por este motivo mi publicación en queja de la utilización del patrón mvc en la web)
La solución: además de ser la solución al problema, hay que aclarar que no es específica a una situación en concreto, recordemos que los patrones tratan de resolver problemas que ocurran varias veces en situaciones diferentes, funciona prácticamente como una plantilla.
La consecuencia: nos referimos con esto, a los resultados de aplicar el patrón y a los compromisos que conlleva la utilización de dicho patrón.

Los patrones que serán abarcados en las futuras entradas serán los siguientes:

Patrones Creacionales:
Object Pool
Factory Method
Abstract Factory
Builder
Prototype
Singleton
Model-View-Controller

Patrones Estructurales
Adapter
Bridge
Composite
Decorator
Facade
Flyweight
Proxy

Patrones de comportamiento
Chain of Responsibility
Command
Interpreter
Iterator
Memento
Observer
State
Strategy
Template Method
Visitor

Espero que les haya gustado la entrada, y espero verlos leyendo sobre cada patrón a medida que los publique.

miércoles, 22 de octubre de 2014

Bienvenidos lectores! hoy les traigo un paper en formato pdf relacionado con calidad en desarrollo de software, la idea de este pdf es agrupar algunas de mis entradas (quizá las más importantes) relacionadas con el hilo "El arte de programar".

Éste pdf reúne varias cosas, conceptos muy importantes a tener en cuenta, y por supuesto desde el punto de vista del software como actividad económica, agrupando las razones por las que aplicar cada criterio tanto así como una visión industrial de lo que todos conocemos como programación.

Programación como actividad económica, una visión del software como un trabajo.
Criterios de calidad, los criterios generales para medir cuándo un código es de calidad.
Calidad y balance, cuando corresponde aplicar los criterios y por qué.
Dificultades de aplicar calidad, existiendo la calidad por qué no es tan sencillo aplicarla y hay tan poco código de calidad abierto al público.
Por supuesto incluye una descripción detallada de cada criterio de calidad en particular, además una explicación extra para cada uno, y lecturas complementarias.

Recomendamos leer todo el hilo del Arte de programar (véase indice) si te gustó el pdf.

También comentamos que el próximo pdf estará relacionado con el proceso de normalización y ya se encuentra en el laboratorio de corrección de documentos, esperando los ultimos ajustes para ser publicado.


Para cerrar la entrada nos gustaría que opinara sobre ¿qué tema te gustaría que publicaramos nuevas entradas?, envía tu sugerencia a alexander171294@gmail.com, o a nuestro twitter @std_io, también puedes comentarlo en ésta entrada.

Un saludo para todos los lectores!

sábado, 18 de octubre de 2014

Buenas tardes lectores, hoy les traigo otra entrada relacionada con el tema de los lenguajes de programación, java en android, ¿por qué lo eligieron?, empecé con las razones por las que uso php, luego hablé un poco de visual basic, y ahora hablaré sobre Java.


Hacía varios días que esta entrada estaba a la espera de ser redactada, y recién hoy que estaba husmeando un poco el framework de un amigo que realmente se ve muy muy prometedor, tengo que admitir que si su framework ve la luz mi publicación de los frameworks son una basura tendrá que ser retractada, analizando su código me surgieron algunas preguntas sobre como encararía ciertos aspectos, que para avisarles me dejó realmente satisfecho, al final de la charla surgió el gran dilema del a industria y quizá el soporte en el cual está apoyada esta entrada. ¿Mi código debe ser a prueba de idiotas, o para gente que tenga conciencia de lo que programa?

lunes, 6 de octubre de 2014

Buenas tardes a todos los lectores, hace mucho no publicaba nada, pero hoy decidí desarrollar y llevar adelante un nuevo pdf sobre programación orientada a objetos.


Hablaremos sobre varias cosas, además de una introducción para iniciados en el tema de la programación orientada a objetos hablaremos sobre la falencia de Singleton, y el error que representa, sobre Wrappers, mi property nunca puede faltar, sobre Factory en php, y sobre el gran problema que tienen hoy en día los framewroks (referido al gran error que tienen en el concepto de programación orientada a objetos)

martes, 29 de julio de 2014

Buenas tardes lectores, en la entrada del dia de hoy hablaremos sobre un tema que siempre es interesante para debatir, la diferencia entre un programador y alguien que escribe codigo.

Cualquiera puede escribir un par de lineas de codigo, hasta un programa entero si se quiere, pero no cualquiera en realidad puede programar, hay una gran diferencia y de eso quiero hablar.

Buenos días, voy a continuar mi trilogía de documentos relacionados con la programación, les recuerdo que deben leer primero Introducción a la programación I y también Introducción a la programación II

Requisitos para comprender este documento:

Conocer los conceptos básicos de Introducción a la programación I.
Tener conocimiento de un lenguaje. Y manejarlo con fluidez.
Llevar al menos un año programando.
Haber trabajado de programador en algún proyecto o más de uno.



lunes, 28 de julio de 2014

Buenos días, voy a continuar mi trilogía de documentos relacionados con la programación, les recuerdo que deben leer primero Introducción a la programación I y también Introducción a la programación II

Requisitos para comprender este documento:

Conocer los conceptos básicos de Introducción a la programación I.
Tener conocimiento de un lenguaje. Y manejarlo con fluidez.
Llevar al menos un año programando.
Haber trabajado de programador en algún proyecto o más de uno.


sábado, 29 de marzo de 2014


Buenas tardes lectores, en la entrada de hoy hablaremos sobre el paradigma de la orientación a objetos, y la razón por la que fue ampliamente aceptado, por otra parte luego de esto hablaremos sobre el futuro del blog STD-IO y sus entradas.


El paradigma de la orientación a objetos organiza sistemas de abstracciones alrededor de estructura y comportamiento común y variaciones en estructura y comportamiento.

viernes, 28 de marzo de 2014

Buenas tardes, en esta entrada hablaremos sobre la Abstracción, Ocultamiento de información y encapsulación, además hablaremos también sobre el rol de la abstracción...

Abstracción, Ocultamiento de Información y Encapsulación son conceptos diferentes pero fuertemente relacionados. Podríamos argumentar que la abstracción es la técnica que nos ayuda a identificar que es significativo y que no lo es de un objeto. La encapsulación es la técnica que nos permite construir con estos aspectos, los de significación y aquellos que no lo son, una entidad cohesiva, una cápsula. El ocultamiento de información es la técnica que nos permite enfatizar, hacer visibles, que aspectos son esenciales a la entidad y cuales no.

jueves, 27 de marzo de 2014

esto va septimo.
Buenas tardes, para continuar las publicaciones diarias que volvimos a realizar, hoy hablaremos sobre Encapsulamiento, uno de los temas que nos quedaron pendientes sobre el hilo del Arte de Programar.
En entradas anteriores vimos de todo un poco, incluyendo criterios de calidad, abstracción y otras teorías importantes que deben ser tenidas en cuenta.


Al igual que ocurre con la idea de abstracción y ocultamiento de información, la palabra encapsulación puede ser utilizada para describir diferentes cosas. A continuación se presentan algunas de las definiciones o ideas vinculadas al termino encapsulación en el contexto del desarrollo del software:

miércoles, 26 de marzo de 2014


Para concluir con el tema de abstracción dejaré una última publicación para cerrar el tema, con mejores definiciones dadas por distintos autores, una publicación bastante completa y lo más explícita posible para tratar el tema de Abstracción que comencé en un par de entradas anteriores y que desarrollé estos días.


La abstracción es el concepto clave de la teoría de la programación. El refinamiento del concepto y la evolución de los mecanismos que le dan soporte han permitido, a lo largo de la historia de la programación, no solo abordar niveles crecientes de complejidad, sino además, permitir que esta, como actividad industrial, logre crecientes niveles de calidad, volumen y economía en el desarrollo de software.

lunes, 24 de marzo de 2014

Continuando con el tema de abstracción que como habrán notado en entradas anteriores es sumamente importante en la programación, ahora hablaremos sobre la abstracción y la programación


En los primeros días de la programación los programadores introducían instrucciones en el computador como secuencias de unos y ceros. Los códigos mnemónicos del lenguaje ensamblador fueron abstracciones diseñadas para liberar a los programadores de recordar los patrones de bits que componían cada instrucción.

domingo, 23 de marzo de 2014

Buenas tardes, hoy voy a continuar con una entrada que se relaciona íntegramente con una entrada previa de abstracción...
Hablaremos sobre Complejidad y Abstracción.


El desarrollo de software está lejos de ser una tarea trivial, por el contrario desarrollar software implica tratar con la complejidad, no solo como Brooks sugiere con la complejidad esencial de la porción de la realidad que se pretende modelar, sino además, con la complejidad arbitraria, propia del proceso de desarrollo.

sábado, 22 de marzo de 2014

Para continuar con la series de entradas que iniciamos hace un tiempo del hilo de El Arte de Programar, donde hablamos de criterios de calidad, y de programación en general, hoy vamos a hablar de Ocultamiento de Información


El principio de ocultamiento de información puede ser establecido de manera informal de la siguiente manera: Toda la información acerca de un modulo debería ser privada al él, a menos que específicamente sea declarada pública.

viernes, 21 de marzo de 2014

Hoy hablaremos sobre dos terminos importantes a la hora de hablar de modularidad, Continuidad Modular y Protección Modular



martes, 18 de marzo de 2014

Buenas tardes a todos los lectores, ayer estaba yo en un curso en la UNICEN (Universidad del centro sede Tandil), y para mi sorpresa empezaron a discutirme que una multiplicación consumía menor tiempo de ejecución que una división.
Claro esta, e imagino que el lector comprende que no haría nunca una entrada para hablar precisamente de eso, por lo que voy a basar mi entrada en la persecutoria que tienen algunos en relación al "consumo" o mejor conocido como Eficiencia, dando algunos motivos para dejar de lado esta postura.


Vamos a hablar en la entrada de hoy precisamente del Criterio de calidad numero 6, Eficicencia.

lunes, 17 de marzo de 2014

Buenas tardes queridos lectores!!! imagino que extrañaban mis entradas sobre todo aquellas del hilo El Arte De Programar, se que hace rato no escribo y como ya me han dicho mis publicaciones se extrañan.
Se que a mas de uno le cuesta comprender muchas veces lo que escribo pero bueno, nadie dijo que sea fácil.



Hoy hablaremos sobre la abstracción, una palabra que junto con su significado desempeñan un papel muy importante a la hora de captar conceptos importantes en la programación.

viernes, 6 de diciembre de 2013

 Para continuar con la serie de publicaciones referentes a modularidad, abarcaremos en esta entrada el segundo criterio de modularidad, que corresponde a lo denominado como Composición Modular.


Trataremos de explicar en esta entrada el concepto de composición modular de la forma más sencilla y recordaremos también el concepto de descomposición modular.
Subscribete al RSS Follow me on Twitter!