En este espacio vamos a poder Observar algunos de los Patrones de Programacion Orientada a Objetos.
Los Patrones de diseño ayudan a que nuestro software tengan algunas caracteristicas como la Reusabilidad, Flexibilidad y Portabilidad.
Representa una operacion sobre los elementos de una estructura de objetos. Permite definir una nueva operacion sin cambiar las clases de los elementos sobre los que opera.
Nombre del Patron: Visitor (visitante).
Clasificacion del Patron: Patron de Comportamiento.
Intencion:
Proporcionar una forma facil y sostenible de ejecutar acciones en una familia de clases. Este patron centraliza los comportamientos y permite que sean modificados o ampliados sin cambiar las clases sobre las que actuan.
Motivacion:
Un compilador representa los programas como árboles de sintaxis abstracta, sobre los que ejecuta operaciones. Muchas operaciones necesitan diferenciar distintos tipos de nodo en el árbol (expresiones, variables, etc.).
Estructura:
Participantes:
Visitor: Define una operación de visita para cada clase de elemento concreto en la estructura de objetos.
ConcreteVisitor: Implementa la interfaz Visitor, Cada operación implementa un fragmento de la labor global del visitor concreto, pudiendo almacenar información local.
Element: Define una operación accept con un visitor como argumento.
ConcreteElement: Implementa la operación accept.
ObjectStructure: Gestiona la estructura de objetos, y puede enumerar sus elementos, Puede ser un compuesto (patrón composite) o una colección de objetos, Puede ofrecer una interfaz que permita al visitor visitar a sus elementos.
Consecuencias:
Facilita la definición de nuevas operaciones.
Agrupa operaciones relacionadas.
Añadir nuevas clases ConcreteElement es costoso.
Permite atravesar jerarquías de objetos que no están relacionados por un padre común.
El visitor puede acumular el estado de una operación al visitar la estructura de objetos, en vez de pasarlo como argumento o usar variables globales.
Define una operacion, el esqueleto de un algoritmo, delegando en las subclases algunos de sus pasos. Permite que las subclases redefinan ciertos pasos del algoritmo sin cambiar su estructura.
Nombre del Patron: Template Method (Metodo Plantilla).
Clasificacion del Patron: Patron de Comportamiento.
Intencion:
Proporcionar un metodo que permite que las subclases redefinan parte del metodo sin rescribirlo.
Motivacion:
Cuando se construyen jerarquias de clases complejas para una aplicacion, a menudo se duplican distintas partes de codigo. esa situacion no es deseable, porque la intencion es reutilizar tanto codigo como sea posible. La refactorizacion de codigo para que los metodos comunes esten en una superclase es un paso en la direccion correcta. El problema es que algunas veces una operacion que ha sido refactorizada confia en la informacion especifica que solamente esta disponible en una subclase. Debido a esto, los desarrolladores a menudo deciden no refactorizar y aceptar la presencia de codigo duplicado en distintas clases.
Estructura:
Prticipantes:
AbstractTemplate: Implementa un metodo plantilla que define el esqueleto de un algoritmo y define metodos abstractos que implementan las subclases concretas.
ConcreteTemplate: Implementa los métodos abstractos para realizar los pasos del algoritmo que son específicos de la subclase.
Colaboraciones:
Las clases concretas confían en que la clase abstracta implemente la parte fija del algoritmo.
Consecuencias:
Favorece la reutilización del código. Muy útiles para construir bibliotecas, pues ayuda a factorizar el comportamiento común de las clases.
Lleva a una estructura de control invertido (Principio de Hollywood): la superclase base invoca los métodos de las subclases.
Define una familia de algoritmos, encapsula uno de ellos y los hace intercambiables. Permite que un algoritmo varie independientemente de los clientes que lo usan.
Nombre del Patron: Strategy (Estrategia, Policy).
Clasificacion del Patron: Patron de Comportamiento.
Intencion:
Definir un grupo de clases que representan un conjunto de posibles comportamientos. Estos comportamientos pueden ser facilmente intercambiados en una aplicacion, modificando la funcionalidad en cualquier instante.
Motivacion:
Estructurar una familia de algoritmos de modo que sus clientes puedan intercambiarlos en tiempo de ejecución.
Estructura:
Participantes:
IStrategy: declara una interfaz común para todos las variantes de un algoritmo.
StrategyX: implementa una variante del algoritmo.
StrategyClient: es el responsable de crear y mantener una referencia a una estrategia concreta.
Colaboraciones:
El cliente de la estrategia decide la estrategia a crear.
Consecuencias:
Factoriza aspectos comunes de una familia de algoritmos y utilizarlos en las clases base de la jerarquía.
Aumenta cohesión del cliente
Sistematiza el uso de implementaciones alternativas
El cliente es el responsable de crear estrategias, por tanto debe comprender las posibilidades que ofrecen, esto es, debe ser relevante para el contexto del cliente.
Menor eficiencia. Aumenta el número de objetos creados.
Permite que un objeto modifique su comportamiento cada vez que cambia su estado interno. Parecera que cambia la clase del objeto.
Nombre del Patron: State (Estado, Objects for States).
Clasificacion del patron: Patron de Comportamiento.
Intencion:
Cambiar facilmente el comportamiento de un objeto en tiempo de ejecucion.
Motivacion:
Cambiar el comportamiento dependiendo del estado. Cuando queremos que un objeto cambie su comportamiento, según cambia su estado, se presenta el problema de la complejidad de código.
Estructura:
Participantes:
Context: Define la Interfaz y mantiene una instancia con el estado actual.
State: Define una interfaz para el comportamiento asociado a un determinado estado del Contexto.
ConcreteState: Cada subclase implementa el comportamiento asociado con un estado del contexto.
Consecuencias:
Localiza el comportamiento dependiente del estado y divide dicho comportamiento en diferentes estados.
Define una dependencia de uno a muchos entre objetos, de forma que cuando un objeto cambia de estado se notifica y actualizan automaticamente todos los objetos.
Nombre del Patron: Observer (Observador, Publishe-Suscriptor).
Clasificacion del Patron: Patron de Comportamiento.
Intencion:
Proporcionar a los componentes una forma flexible de enviar mensajes de difusion a los receptores interesados.
Motivacion:
Muchas veces un efecto lateral de partir un sistema en una colección de objetos relacionados es que necesitamos mantener la consistencia entre objetos relacionados.
Estructura:
Participantes:
Subject: Conoce a sus observadores, Proporciona una Interfaz para que se suscriban los objetos Observer.
Observer: Define una interfaz para actualizar los objetos que deben ser notificados de cambios en el objeto Subject.
ConcreteSubject: Guarda el estado de interes para los objetos ConcreteObserver, Envia una notificacion a sus observadores cuando cambia su estado.
ConcreteObserver: Mantiene una referencia a un objeto ConcreteSubject, Guarda el estado que deberia permanecer sincronizado con el objeto observado, Implementa la interfaz Observer para mantener su estado consistente con el objeto observado.
Colaboraciones:
El objeto observado notifica a sus observadores cada vez que ocurre un cambio. Después de ser informado de un cambio en el objeto observado, cada observador concreto puede pedirle la información que necesita para reconciliar su estado con el de aquél
Representa y externaliza el estado interno de un objeto sin violar la encapsulacion de forma que este puede a dicho estado mas tarde.
Nombre del Patron: Memento (Recuerdo, Token).
Clasificacion del Patron: Patron de Comportamiento
Intencion:
guardar una "Instantanea" del estado de un objeto, de forma que pueda ser devuelto a su estado original sin revelar su contenido al resto del mundo.
Motivacion:
Se usa este patrón cuando se quiere poder restaurar el sistema desde estados pasados y por otra parte, es usado cuando se desea facilitar el hacer y deshacer de determinadas operaciones, para lo que habrá que guardar los estados anteriores de los objetos sobre los que se opere (o bien recordar los cambios de forma incremental).
Estructura:
Participantes:
Memento: Permite almacenar (parte de) el estado de Creador. Ofrece dos interfaces distintas: una estrecha para el conserje (Caretaker) y una extendida para Creador.
Caretaker: Se encarga de mantener los objetos Memento y en ningun caso accede a su informacion interna.
El creador es capaz de crear objetos Memento con informacion sobre su estado y restaurar este a partir de un Memento.
Define un objeto que encapsula como interactuan un conjunto de objetos. Promueve un bajo acoplamiento al evitar que los objetos se refieran unos a otros explicitamente, y permite variar la interaccion entre ellos de forma independiente.
Nombre del Patron: Mediator (Mediador).
Clasificacion del Patron: Patron de Comportamiento.
Intencion:
Simplificar la comunicacion entre los objetos de un sistema introduciondo un unico objeto que gestiona la distribucion de mensajes entre los otros.
Motivacion:
Cuando muchos objetos interactúan con otros objetos, se puede formar una estructura muy compleja, con objetos con muchas conexiones con otros objetos. En un caso extremo cada objeto puede conocer a todos los demás objetos. Para evitar esto el patrón Mediator encapsula el comportamiento de todo un conjunto de objetos en un solo objeto.
Estructura:
Participantes:
Mediator: Define una interface para comunicarse con los objetos colegas.
ConcreteMediator: Implementa el comportamiento cooperativo entre los colegas (como se comunican entre ellos). Además los conoce y mantiene.
Colleagues: Cada colega conoce su mediador, y usa a este para comunicarse con otros colegas.
Colaboraciones:
Los colegas envían y reciben requerimientos (requests) de un objeto mediador. El mediador implementa como se comunican los colegas.
Proporciona un modo de acceder secuencialmente a los elementos de un objeto agregado sin exponer su representacion interna.
Nombre del Patron: Iterator (Iterador, Cursor).
Clasificacion del Patron: Patron de Comportamiento.
Intencion:
proporcionar una forma coherente de acceder secuencialmente a los elementos de una coleccion, independientemente del tipo de coleccion subyacente.
Motivacion:
Un objeto agregado, tal como una lista, debería proveer un modo de brindar acceso a sus elementos sin exponer su estructura interna. Más aún, quizás se desea recorrer la lista en diferentes formas, dependiendo de lo que Ud. quiera realizar. Pero, probablemente, la idea no es aumentar la interfaz de la lista con operaciones para recorridos diferentes, aún anticipando los que se necesitarán. Tal vez, también se necesite tener más de un recorrido en la misma lista.
El patrón Iterator permite llenar todas estas espectativas. La idea principal en este patrón es tomar la responsabilidad del acceso y recorrido de la lista y colocarla dentro del objeto iterator. La clase Iterator define una interfaz para el acceso de los elementos de la lista. Un objeto iterador es responsable de mantener la pista del elemento actual; esto es, sabe cuáles elementos ya han sido recorridos.
Estructura:
Participantes:
Iterador: Define una interfaz para recorrer los agregados.
IteradorConcreto: implementa la interfaz iterador.
Agregado: Define la interfaz para crear un objeto iterador.
AgregadoConcreto: Implementa la interfaz de creacion de un iterador para devolver un iterador concreto.
Colaboraciones:
Un iteradorConcreto almacena la posicion del objetoactual en el agregado de modo que sabe cual es el objeto siguiente en el recorrido.
Dado un lenguaje, define una representacion de su gramatica junto con un interprete que usa dicha representacion para interpretar las sentencias del lenguaje.
Nombre del Patron: Interpreter (Interprete).
Clasificacion del Patron: Patron de Comportamiento.
Intencion: Definir un Interprete para un lenguaje.
Motivacion:
Existen problemas particulares que pueden expresarse en función de algún Lenguaje. A veces es conveniente representar un lenguaje como palabras de algun lenguaje sencillo, como por ejemplo, evaluar expresiones booleanas. El patron Interpreter describe como definir una gramatica, representar palabras del lenguaje y como interpretarlas.
Estructura:
Participantes:
Cliente: Construye el arbol Sintactico Abstracto de expresiones no terminales, e instancias de la clase Expresion Terminal. Luego inicializa el contexto e invoca al Interpretador.
AbstractExpresion: Es la clase Abstracta a travez de la cual el cliente interactua con las expresiones.
TerminalExpresion: La implementacion de la clase Abstracta AbstractExpresion para nodos terminales en la gramatica y el arbol de sintaxis.
NonTerminalExpression: Es otra implementacion de la clase abstracta para nodos no terminales de la gramatica y el arbol de sintaxis. Mantiene una referencia a la siguiente expresion e invoca el metodo interpret en cada uno de sus hijos.
Context: El contenedor de la informacion que se necesita en distintos lugares del interprete. Puede servir como un canal de comunicacion entre distintas instancias de Expression.
Encapsula una peticion en un objeto, permitiendo asi parametrizar a los clientes con distintas peticiones, encolar o llevar un registro de las peticiones y poder deshacer las operaciones.
Nombre del Patron: Command (Comando).
Clasificacion del Patron: Patron de Comportamiento.
Intencion:
Encapsular un comando en un objeto de tal forma que pueda ser almacenado, pasado a metodos y devuelto igual que cualquier otro objeto.
Motivacion:
A veces se quiere poder enviar solicitudes a objetos sin conocer exactamente la operación solicitanda ni del receptor de la solicitud. En general un objeto botón o menú ejecuta solicitudes pero la solicitud no está implementada dentro del mismo. Una biblioteca de clases para interfaces de usuario tendrá objetos como botones y elementos de menú responsables de realizar alguna operación en respuesta a una entrada del usuario.
Estructura:
Participantes:
Command: Declara la interface para la ejecucion de la operacion.
ConcreteCommand: Define la relación entre el objeto Receiver y una acción, Implemeta Execute() al invocar las operaciones correspondientes en Receiver.
Client: Crea un objeto ConcreteCommand y lo relaciona con su Receiver.
Invoker: Le hace solicitudes al objeto Command.
Receiver: Sabe como ejecutar las operaciones asociadas a la solicitud. Cualquier clase puede ser receptora.
Consecuencias:
Command desliga el objeto invocador del objeto receptor
Los comandos son objetos de primera clase.
Se pueden ensamblar comandos en comandos compuestos.
Para un nuevo comando no se necesita extender las clases.
Evita acoplar el emisor de una peticion a su receptor, al dar a mas de un objeto la posibilidad de responder a la peticion. Crea una cadena con los objetos receptores y pasa la peticion a travez de la cadena hasta que esta sea tratada por algun objeto.
Nombre del Patron: Chain of Responsability (Cadena de Responsabilidad).
Clasificacion del Patron: Patron de Comportamiento.
Intencion:
Establecer una cadena en un sistema, para que un mensaje pueda ser manejado en el nivel en el que se recibe en primer lugar, o ser redirigido a un objeto que pueda manejarlo.
Motivacion:
La petición debe ser procesada por los receptores, lo cual quiere decir que, ésta petición queda al margen del uso exclusivo. Pretendemos dar una mayor detalle y especificación a las peticiones generadas. Las peticiones serán filtradas por todos los receptores a medida que se van generando los resultados esperados.
Estructura:
Participantes:
Cliente: será el encargado de generar las peticiones que hayan de pasar por el manejador genérico.
Manejador: Deberá estar compuesto por un interfaz donde se vayan a desarrollar las peticiones que genera el cliente.
ManejadorConcreto: Tratará la petición que le corresponda del cliente.
Colaboraciones:
Cuando un cliente envía una petición, ésta se propaga a través de la cadena hasta que un objeto manejador específico se hace responsible de procesarla.
Proporciona un sustituto o representante de otro objeto para controlar el acceso a este.
Nombre del patron: Proxy (Representante).
Clasificacion del Patron: Estrctural.
Intencion:
proporcionar un representante de otro objeto, por distintas razones como pueden ser el acceso, la velocidad o la seguridad, entre otras.
Motivacion:
Retrasar el coste de crear e inicializar un objeto hasta que es realmente necesario. Por ejemplo, no abrir las imágenes de un documento hasta que no son visibles.
Puede haber ocasiones en que se desee posponer el coste de la creación de un objeto hasta que sea necesario usarlo.
El objeto proxy actúa en lugar del verdadero objeto, y ofrece las misma interfaz, y las solicita en el objeto cuando es necesario.
Estructura:
Participantes:
Subject:Define la interfaz común para el RealSubject y el proxy, de modo que pueda usarse un Proxy en cualquier sitio en el que se espere un RealSubject.
RealSubject: Define el objeto real representado.
Proxy: Mantiene una referencia que permite al Proxy acceder al objeto real, Proporciona una interfaz identica a la del sujeto, de manera que un Proxy pueda ser sustituido por el sujeto real.
Controla el acceso al sujeto real, y puede ser responsable de su creacion y borrado.
usa el compartimiento para permitir un gran numero de objetos de grano fino de forma eficiente.
Nombre del Patron: Flyweight (Peso Ligero).
Clasificacion del Patron: Estructural.
Intencion:
Reducir el numero de objetos detallados de muy bajo nivel en un sistema mediante la comparticion de objetos.
Motivacion:
Los caracteres de un procesador de palabras podrian ser objetos.
La cantidad de caracteres en un documento puede ser muy grande.
Cada caracter es compartido por los objetos que lo contienen.
Estructura:
Participantes:
Flyweight: Declara una interfaz a traves de la cual los flyweights pueden recibir y actuar sobre estados no compartidos.
ConcreteFlyweight: Implementa la interfaz Flyweight y almacena los estados compartidos, si los hay. Un objeto ConcreteFlyweight debe ser compartible. Cualquier estado que almacene debe ser intrinseco; es decir, debe ser independiente de su contexto.
UnsharedConcreteFlyweight: No todas las subclases de Flyweight tienen por que ser compartidas. La interfaz Flyweight permite que se comparta; no lo fuerza. Es comun que los objetos de esta clase tengan hijos de la clase ConcreteFlyweight en algun nivel de su estructura.
FlyweightFactory: Crea y gestiona a los objetos flyweight. Garantiza que los objetos flyweight se compartan de forma apropiada. Cuando un cliente solicita un flyweight, el objeto de la clase FlyweightFactory proporciona una instancia existente, o crea una.
Client: Contiene referencias a los flyweights. Calcula o almacena los estados no compartidos de los flyweights.
Proporciona una interfaz unificada para un conjunto de interfaces de un sistema. Define una interfaz de alto nivel que hace que el subsistema sea mas facil de usar.
Nombre del patron: Facade (Fachada)
Clasificacion del Patron: Estructural.
Intencion:
Proporcionar una interfaz simplificada para un grupo de subsistemas o un sistema complejo.
Motivacion:
Simplificar el acceso a un conjunto de clases proporcionando una única clase que todos utilizan para comunicarse con dicho conjunto de clases.
Reducir la complejidad y minimizar dependencias
Estructura:
Participantes:
Facade: Conoce cuales clases del subsistema son responsables de una peticion y delega las peticiones de los clientes en los objetos del subsistema.
Clases del subsistema: Implementan la funcionalidad del subsistema, manejan el trabajo asignado por el objeto Facade y ademas de esto no tienen ningun conocimiento del Facade.
Añade dinamicamente nuevas responsabilidades a un objeto, proporcionando una alternativa flexible a la herencia para extender funcionalidad.
Nombre del patron: Decorator (wrapper)
Clasificacion del patron: Estructural
Intencion:
Proporcionar una forma flexible de introducir o eliminar funcionalidad de un componente sin modificar su apariencia externa o su funcion.
Motivacion:
A veces se desea adicionar responsabilidades a un objeto pero no a toda la clase. Las responsabilidades se pueden adicionar por medio de los mecanismos de Herencia, pero este mecanismo no es flexible porque la responsabilidad es adicionada estáticamente. La solución flexible es la de rodear el objeto con otro objeto que es el que adiciona la nueva responsabilidad. Este nuevo objeto es el Decorator.
Estructura:
Participantes:
Component: Define la interface de los objetos a los que se le puede adicionar responsabilidades dinamicamente.
ConcreteComponent: Define el objeto al que se le puede adicionar una responsabilidad.
Decorator: Mantiene una refeencia al objeto Component y define una interface de acuerdo con la interface de Component.
ConcreteDecorator: Adiciona la responsabilidad al componente.
Combina objetos en estructuras de arbol para representar jerarquias de parte-todo. Permite que los clientes traten de manera uniforme a los objetos individuales y a los compuestos.
Nombre del patron: Composite (Compuesto)
Clasificacion del patron: Estructural
Intencion:
Componer objetos en jerarquías parte-todo y permitir a los clientes tratar objetos simples y compuestos de modo uniforme.
Motivacion:
Necesitamos representar un conjunto de elementos de una interfaz gráfica de usuario (GUI). Algunos de estos elementos son simples, mientras que otros están formados por varios elementos más simples. El comportamiento y/o la información que proporciona un elemento complejo estádeterminada por los elementos que lo componen.
Estructura:
Participantes:
Component: Declara la interfaz para los objetos de la composicion, es la interfaz de acceso y manipulacion de los componentes hijo e implementa algunos comportamientos por defecto.
Client: Manipula objetos atravez de la interfaz proporcionada por Component.
Composite: Define el comportamiento de los componentes compuestos, almacena a los hijos e implementa las operaciones de manejo de los componentes.
Leaf: Definen comportamientos para objetos primitivos del compuesto.
El patron bridge desvincula una abstraccion de su implementacion, de manera que ambas puedan variar de forma independiente.
Nombre del patron: Bridge (Puente)
Clasificacion del patron: Estructural
Intencion:
Disociar una abstracción de su aplicación, de manera que los dos pueden variar independientemente.
Publicar una interfaz en la jerarquía de herencia, y insertar en su propia aplicación herencia jerarquía.
Motivacion: Desacoplar una abstracción de su implementación. La Herencia liga una implementación a una abstracción dificultando la modificación, extensión y reutilización.
Estructura:
Participantes:
Abstraction: define una interfaz abstracta. Mantiene una referencia a unobjeto tipo Implementor.
RefinedAbstraction: Extiende la interfaz definida por Abstraction.
Implementor: Define la interface para la implementacion de clases. Esta interface no se tiene que corresponder exactamente con la interface de Abstraccion; de hecho, las dos interfaces pueden ser bastante diferentes.
ConcreteImplementor: Implementa la interface de Implementor y define su implementacion concreta.
UML es una creacion de Grady Booch, James Rumbaugh e Ivar Jacobson. Estos caballeros son apodados recientemente "Los tres caballeros", ellos trabajaron en distintas empresas durante la decada de los ochenta y principios de los noventa y cada uno diseño su propia metodologia para el analisis y diseño orientado a objetos. Sus metodologias predominaron sobre las de sus competidores. A mediados de los noventa empezaron a intercambiar ideas entre si y decidieron dasarrollar su trabajo en conjunto.
UML (Lenguaje de Modelado Unificado) es el lenguaje de modelado de sistemas de software mas conocido y utilizado en la actualidad. Es un lenguaje grafico para visualizar, especificar, construir y documentar un sistema.
UML es un lenguaje de modelado para especificar o describir metodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que esta descrito el modelo.
REPRESENTACION DE ATRIBUTOS Y METODOS:
Publica: Todos los objetos la pueden usar (+).
Protegido: Solo las subclases lo pueden ver (#).
Privado: Solo el objeto al que pertenece lo puede ver (-).
Friendly: Solamente los que pertenecen al mismo paquete lo pueden ver (*).
Nota: En los atributos en lo posible no se debe utilizar la visibilidad publica.
REPRESENTACION DE CLASES:
Publica: Declaracion general de una clase que puede ser modificada por un objeto.
Abstracta: Cuando por lo menos uno de sus metodos debe ser anstracto.
Final: Es una clase que no puede ser modificada por ningun objeto.
CLASE:
Es la unidad basica que encapsula toda la informacion de un objeto (instancia de una clase). A traves de ella podemos modelar el entorno en estudio. En UML, una clase es representada por un rectangulo que posee tres divisiones:
en donde:
Superior: Contiene el nombre de la clase.
Intermedio: Contiene los atributos que caracterizan la clase.
Inferior: Contiene los metodos u operaciones, loc cuales son la forma como interactua el objeto con su entorno.
RELACIONES ENTRE CLASES:
Herencia (Especializacion/Generalizacion):Indica una subclase que hereda los metodos y atributos especificados por una super clase, por ende la subclase ademas de poseer sus propios metodos y atributos, poseera los metodos y atributos visibles de la super clase.
Agregacion: para modelar objetos complejos, no bastan los tipos de datos basicosque proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollo de la aplicacion.
Asociacion: Permite asociar objetos que colaboran entre si. Cabe destacar que no es una relacion fuerte, es decir, el tiempo de vida de un objeto no depende de otro.
Dependencia o Instanciacion (uso): Representa un tipo de relacion muy particular, en la que una clase es instanciada y se denota por una flecha punteada.
Composicion: Son asociaciones que representan acumulaciones muy fuertes. Esto significa que las composiciones tambien forman relaciones completas, pero dichas relaciones son tan fuertes que las partes no pueden existir por si mismas. Unicamente existen como parte del conjunto, y si este es destruido las partes tambien lo son.
Realizacion: Es una relacion semantica entre clasificadores, en donde un clasificador especifica un contrato que otro clasificador garantiza que cumplira. Se pueden encontrar relaciones de realizacion: entre interfaces y las clases o componentes que las realizan, y entre los casos de uso y las colaboraciones que los realizan
En esta aplicacion podremos observar un codigo con el cual nos conectaremos a una base de datos desde java y validaremos un usuario que se encuentra en una base de datos en MySql dandole tambien algunos permisos al usuario para ingresar a una aplicacion y aun lo mas importante es que esta aplicacion es extensible para otros usuarios.
ConexionBaseDatos conexionBaseDatos= new SingletonConexionBaseDatos();
cadenaSql = "SELECT * FROM usuarios WHERE(usuario='"+usuario+"')";
tabla=null;
usuarios= new String[4][4];
try{
conexion= conexionBaseDatos.getConexion();
stmt= (Statement) conexion.createStatement();
tabla = stmt.executeQuery(cadenaSql);
if (tipo.equals("1")){
CreadorTipo1 tipo1 = new CreadorTipo1();
tipo1.CrearCliente();
}
if (tipo.equals("2")){
CreadorTipo2 tipo2 = new CreadorTipo2();
tipo2.CrearCliente();
}
if (tipo.equals("3")){
CreadorTipo3 tipo3 = new CreadorTipo3();
tipo3.CrearCliente();
}
}
}
package co.com.udistrital.tiposClientes;
public class CreadorTipo1 extends CreadorCliente{
public void CrearCliente(){
ClienteTipo1 clienteTipo1= new ClienteTipo1();
clienteTipo1.MostrarDialogo();
}
}
package co.com.udistrital.tiposClientes;
public class CreadorTipo2 extends CreadorCliente {
public void CrearCliente(){
ClienteTipo2 clienteTipo2= new ClienteTipo2();
clienteTipo2.MostrarDialogo();
}
}
package co.com.udistrital.tiposClientes;
public class CreadorTipo3 extends CreadorCliente {
public void CrearCliente(){
ClienteTipo3 clienteTipo3= new ClienteTipo3();
clienteTipo3.MostrarDialogo();
Aca podremos encontrar todas las clases necesarias para la compilacion en eclipse pero sin embargo necesitaremos de la base de datos en mysql llamada usuarios de la siguiente manera:
usuario
contrasena
permisos
jimmy
1234
1
darepecu
123
1
jack
sparrow
2
aura
aura89
2
caro
carito
3
perro
uno
3
pero tambien necesitaremos de un .jar para la conexion a base de datos con MySql.
En la clase conexion tambien podremos encontrar alli los parametros para la conexion a base de datos por lo cual tendremos que hacer en esa clase las modificaciones pertinentes segun nuestra configuracion de MySql.
