Patrón Singleton

Cuando escribí el artículo Desarrollo en capas, un amigo me comento que de alguna manera debería de explicar que es el patrón Singleton.

Bien su suplica se ha hecho realidad y para ejemplificar utilizaré Java

En realidad este patrón es muy simple. La idea básica de este patrón es que solo pueda existir una instancia de una clase en la aplicación.

El primer paso para conseguir este patrón es bloquear la forma de generar instancias de la clase, esto se hace simplemente privatizando el constructor de la clase

Capa de Negocio (Parte 1): Transaction Script

Edición: Por sugerencia de varios amigos, he decidido separar este articulo por tema, al final se encuentran las ligas hacia los otros patrones

Recuerdo perfectamente que entre las capas que más trabajo me costo entender como funcionaban y como utilizar fue la capa de negocio y es que termina siendo la ultima que descubres y la última que entiendes como usar y programar, por ello decidí dar un pequeño salto en el orden de las capas para adentrarnos en este pequeño mundito. No quiero decir que no habrá articulo sobre la capa de vista, ¡por su puesto que lo habrá!, solo quise explicar de una vez por todas, lo que mas trabajo me costo entender.

La capa de negocio puede ser manejada de varias formas y en este contexto encontramos principalmente 3 contrincantes, el patrón Transaction Script, el patrón Domain Model y el patrón Table Module.

La conclusión a la cual quiero llegar al final, no es decir cual es mejor o peor, ya que los 3 tienen sus pros y contras; la idea es dar un panorama y porque no, un par de consejos del ¿como? y el ¿cuando? utilizar uno u otro y que al final te sea mas simple tomar una decisión de que patrón(es) te conviene(n) usar mas.

Ahora, vamos a echarle un ojo a los participantes para tener un lugar en la capa de negocio.

Patrón Transaction Script 

La idea básica de este patrón se basa en las rutinas.

Desarrollando en Capas

Hace algún tiempo llegue a trabajar a una empresa donde tenían ya algunos sistemas implementados, la empresa tenía la necesidad de añadir funcionalidad a dichos sistemas, comencé a revisarlos y me di cuenta de algo, no existía la capa de negocio (Domain o Business como la quieran llamar), me pregunte muchas veces el porque sin llegar a una respuesta, tenían 2 capas híbridas(porque no eran ni uno ni lo otro), una para la vista y  una para acceso a datos, pero, las reglas del negocio estaban mezcladas entre la vista y el acceso a datos, lo cual significa que una nueva regla de negocio o una modificación involucraba mover por todos lados sin tener la certeza que funcionara, así que pensé en escribir algo sobre el como, el porque, el cuando y el donde, yo usaría las 3 capas convencionales (Presentación, Negocio y Acceso a datos).