Patrones de Diseño y Orientacion A Objetos en PHP

Patrones de diseño y Orientación a Objetos en PHP5
¡Desarrollo rápido de aplicaciones!
Licencia
Copyright (c) 2006 Anibal Rojas
Copyright (c) 20042006 Ernesto HernándezNovich.
Modificaciones y adaptaciones.
Copyright (c) 2006, 2007 Leonardo Caballero / Jesús Lara.
Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation
License, Version 1.2 or any later version published by the Free
Software Foundation; with no Invariant Sections, no FrontCover
Texts, and no BackCover Texts. A copy of the license is included
in the section entitled "GNU Free Documentation License".
GNU Free Documentation License
Puede obtener una copia de la licencia "GNU Free Documentation
License" en los ficheros llamados "copyright.txt" en ingles,
"copyright.es.txt" en español o en los siguientes sitios en Internet:
• http://www.gnu.org/copyleft/fdl.html
• http://www.fsf.org/licensing/licenses/fdl.html
Definiciones básicas
Estas definiciones son más importante de lo que parece.
• Desarrollo de software.
• Diseño Web.
• Desarrollo Web.
• Aplicación Web.
Tecnologías involucradas en la Web.
Funcionamiento básico de una Aplicación Web.
Desde el punto de vista del Usuario:
1) El usuario abre un URL.
2) Llena un formulario.
3) Oprime alguno de los botones.
4) La aplicación genera un nuevo formulario con resultados.
Funcionamiento básico de una Aplicación Web :: Continuación.
Es un documento .php
La página se
ejecuta y
Solicita un
cambia
Documento
código
HTML
La página HTML se
envía al cliente
Funcionamiento básico de una Aplicación Web :: Continuación.
Módulo de Funciones
Base de
Datos ODBC
Motor
Zend
1 2 3
Compila
6 Interfase del servidor 4
5 Ejecuta
Proyecciones de la Web.
Factibilidad para el desarrollo de Aplicaciones Web.
• ¿Cuánto cuesta encontrar un programador que sepa todo eso?
• ¿Cuánto cuesta mantener toda esta mezcla de multilenguaje?
• ¿En cuanto tiempo puede ofrecer al cliente un prototipo de la aplicación?
• ¿Cuanto tiempo necesita para cambiar toda la interfaz de usuario de la aplicación
a las necesidades del cliente?
• ¿Puede garantizar que la aplicación cumpla con los estándares y normativas de
accesibilidad, reusabilidad y operatividad de la Web?
¡Si no sabes responder a estas preguntas con respuestas a tiempos
cortos, prácticos y razonables, ya entiendes el gran problema!
Hablemos de PHP.
• Originalmente PHP fue siglas de Personal Home Page Tools.
• Creado en 1995 por Rasmu Lerdorf.
• Año 1997, cambios significativos.
• Al redefinirse el motor recibió las siglas del acrónimo Hypertext Pre Processor
• PHP 3, creado por Andi Gutmans y Zeev Zuraski.
• Motor Zend.
• PHP 4 (año 2000).
• PHP 5 (año 2004).
• Está previsto el lanzamiento en breve de la rama 6 de PHP.
• PHP 4 perderá su estado de estable el 31 de diciembre del 2007.
Introducción a PHP5.
• Soporte sólido para Programación Orientada a Objetos (o OOP) con PHP.
• Data Objects.
• Mejoras de rendimiento.
• Mejor soporte para MySQL con extensión de rewrite completa.
• Mejor soporte a XML (XPath, DOM, entre otros).
• Soporte nativo para SQLite.
• Soporte integrado para SOAP.
• Iteradores de datos.
• Excepciones de errores.
PHP5 y Programación Orientación a Objetos.
PHP5 soporta una gran cantidad de funcionalidades para OOP.
• Métodos constructores y destructores.
• Métodos setter y getter.
• Métodos mágicos.
• Clases, objetos y variables estáticas, privadas y protegidas.
• Clases abstractas.
• Interfaces.
• Abstracción de datos.
• Standard PHP Library (SPL).
• Clases extendidas, excepciones, iteradores.
Patrones de diseño.
Los patrones son simples soluciones a problemas recurrentes que ocurren una y otra
vez en nuestro entorno.
Luego de llegar a la solución, encapsulamos todas las variables y factores para llegar
a la solución y disponemos de una “receta” para resolver mil veces el problema sin
tener que “reinventar la rueda”.
Los desarrolladores los usan como una forma de reutilizar la experiencia,
clasificando las soluciones bajo “términos” de común denominación ¿Un
diccionario?, eso lo haces con un singleton+registry pattern.
Causando además, un idioma común entre programadores de distintos lenguajes.
Uno de los principales precursores del movimiento

acerca de los Design Patterns fue Martin Fowler.
Patrones de diseño :: Continuación.
En el área de patrones de diseño hablamos de solventar problemas de:
●
Interfaz gráfica.
●
Optimización de Código.
●
Reutilización de componentes.
●
Simplicidad de las soluciones.
Uso de los patrones de diseño.
Los patrones de diseño nos permiten:
• Extensibilidad.
• Flexibilidad.
• Concurrencia.
• Organización.
• Soluciones ya probadas y efectivas.
• Mayor facilidad para hacer cambios.
• Reutilización.
• Refactorización.
• Idioma común de intercambio de soluciones.
• Buenas prácticas en el desarrollo de Software.
Ideas básicas en el desarrollo de aplicaciones.
Lo que se logra en toda aplicación, al implementar patrones es que, en conjunto con
la programación Orientada a Objetos (OOP):
●
Encapsulemos la lógica de la aplicación de tal manera que sea
innecesario pensar a bajo nivel.
(¿Tendré que escribir una función que haga eso?)
●
Desviarse de la lógica de mi aplicación.
(¿Para implementar AJAX debo usar otra cosa?)
●
Preocuparse únicamente por la “operatividad de la aplicación”
(¿Funcionará esa implementación de roles y seguridad que me “inventé”?).
●
Lograr una flexibilidad sin límites
(¿Funcionará ese objeto en otro proyecto futuro?).
Clasificación de los patrones de diseño.
De creación:
Como se crean instancias de los objetos y/o como se implementan.
• Singleton, Multiton, Facade.
Estructurales:
Como se relacionan y combinan las clases para crear nuevas estructuras.
• Abtract Factory, Visitor, Facade, Flyweight, Adapter.
De comportamiento:
Como interactúan y cooperan las clases.
• Decorator, Memento, Chain of Responsability, Flyweight, Adapter.
Clasificación de los patrones de diseño :: Continuación.
De ámbito:
De Como se utilizan dinámicamente los Objetos.
• Delegator, Observer, Interpreter, Visitor.
De operación
De como se comportará la aplicación.
• Business Logic, Proxy Adapter, Front Controller, ModelView Controller.
MVC (Model view controller).
1) Patrón de diseño orientado a objetos.
2) Describe cualquier aplicación con interacción humana y es particularmente
adecuado para aplicaciones Web.
3) Separa clara y consistentemente las "preocupaciones":
1) Modelo (Model) Interacción con la base de datos.
2) Vista (View) Presentación de la información al usuario.
3) Controlador (Controller) Flujo de información y procesos.
Si su aplicación no está diseñada siguiendo MVC, inevitablemente tendrá problemas
de escalabilidad, de mantenimiento y de extensión.
MVC (Model view controller) :: Continuación.
• Permite múltiples representaciones (vistas) de la misma información (modelo).
• De forma muy fácil permite agregar, remover o cambiar interfaces de usuarios
(vistas).
• Permite responder a lo ingresado por el usuario (controladora) para ser
fácilmente cambiando.
• Permite que múltiples desarrollos simultáneamente actualiza la interfaz, la lógica
de negocios o introducir un aplicación nueva sin afectar a otros código fuentes.
• Los cambios pueden suceder dinámicamente en la ejecución de la aplicación.
• Promete reducir código (ej. “una vista puede ser usada con diferentes modelos”).
• Ayuda a enfocar a los desarrolladores en un solo simple aspecto de la aplicación
al mismo tiempo.
MVC con PHP5.
MVC con PHP5 :: Continuación.
1) Solicitud: El usuario ejecuta un Navegador, pide un URL solicitando a la Aplicación.
2) Despacha: La Aplicación delega a la capa Controladora la petición del usuario desde
el Navegador.
3) Almacena: Consulta en la capa Modelo por medio a la capa de Datos del manejador
de base de datos existente.
4) Devuelve: La capa de Datos devuelve los resultados en “data pura” a la capa
Controladora.
5) Genera: La capa Controladora genera la capa de Vista en base a los tipos de datos
generados por la capa de Datos.
6) Responde: La Vista generada se envía como respuesta a la solicitud al Navegador.
MVC con PHP5 :: Continuación.
Clasificación de los patrones de acuerdo a la capa MVC.
Capa de Datos (Data Layer)
• ORM – ActiveRecord.
• Data Layer.
• Delegator.
Modelo (Lógica)
• Abstract Factory y Registry.
• Value Object.
• Business Delegate.
• Aggregate Entity.
• Service Locator.
• Strategy.
Clasificación de los patrones de acuerdo a la capa MVC.
Controladora
• Inherit Application Controller.
• Front Controller.
• Delegate Controller.
• Service Controller.
Vista
• Decoration Filter.
• Helper View.
• Composite View.
• Template View.
• Dispatcher View.
Patterns Design: the Real Life!
Memento + Singleton > Gestión de deshacer,rehacer,historia, transacciones.
Facade > Gestión de documentos de varios tipos en una misma interfaz.
Facade + Adapter > Una única interfaz de acceso para múltiples bases de datos.
Singleton + Registry > Sistemas de Diccionario, i18n (Internacionalización),

Registros de Sistema y configuración.
Abstract + Composite + Helper View > Construcción de vistas complejas a

partir de archivos sencillos.
Observer + State > Sistema de gestión online de usuarios.
Decorator + Composite > Sistemas de reportes.
Patterns Design: the Real Life!
Abstract Factory + Singleton > Fabrica abstracta de controles complejos.
Flyweight > Gestión de vistas y uso de class (CSS) y IDREF (XML).
Iterator + Data Layer > Explorar datos dentro de los objetos sin iterar sobre el
objeto en si (ej. Explorar sobre los datos de una DB usando FOREACH).
Singleton + Decorator + Hierarchical Visitor > Gestión de usuarios y Roles.
Composite + Facade + Interpreter > Gestores de idiomas especializados,

parsers de funciones.
Session Facade + Delegator > Loggers y gestores de sesiones de usuario.
Un ejemplo Desglosado (Memento):
Necesidad:
●
Retornar un estado previo
de una operación
(operaciones “undo” o
“Rollback”).
●
Retonar a estados
“específicos” del objeto
(History).
●
Crear estados de “guardado
temporal” o “Check points”.
Sumario: (Qué debemos identificar):
●
Identificar la clase que posee la “habilidad” de tomar un “snapshot” de si
misma. (clase con el rol “Originator”).
●
Diseñar una clase que no hace nada más que que aceptar y entregar los
distintos “snapshots” de objetos (clase con el rol “memento”).
●
Diseñar una clase “gestora” a la cual el “originator” puede preguntar para
que retorne un “estado”; puede causar que el “originator” vuelva a estados
previos (clase con el rol “caretaker”).
●
La clase cliente (Originator) sabe “cuando” debe salvarse su snapshot.
●
La clase cuidadora (CareTaker) sabe “como” debe guardarse el snapshot.
●
La clase contenedora (memento) sabe “donde” debe guardarse el snapshot.
Estructura:
Estructura: (Continuación):
Diagrama de Secuencia:
●
El objeto (originator) pide un “checkpoint” o revisión inicial a su
custodio (caretaker).
●
El custodio (caretaker) toma el objeto actual y guarda una copia en
una clase estática memento (Set).
●
Si el cliente desea un “rollback” o deshacer una acción, simplemente
le solicita al custodio retornar a un estado previo y este “extrae” del
memento el estado solicitado; borra de memoria (haciendo el
checkpoint respecto para posibles “redo”) el Originator actual y lo
reemplaza con el extraído desde el memento.
Implementación:
●
Cada objeto puede llamar “estáticamente” a un “memento object” (Checkpoint State)
usando una clase “pasarela” llamada Caretaker, que toma las funciones de
monitorización del objeto base (Originator); inicialmente el objeto crea una copia de
si mismo dentro del memento (primer estado).
●
Memento Object puede simplemente recibir (en un arreglo estático) nuevas copias
(snapshots) del objeto base (Originator) e indizarlas para su obtención rápida
(unlimited undo y lista de historia).
●
Memento debe ser “opaco”; es decir, solamente debe saber que guardó un estado de
un objeto, sin averiguar que tipo de objeto guardó (Claro que guardando el índice de
“a quien” guardó); adicionalmente, el cliente (Originator) desconoce la naturaleza del
memento (se entiende con él a través del “caretaker”).
Para más implementaciones les recomiendo que visiten
www.phppatterns.com
De lo horrible a practico :: El Camino MVC en 10 pasos
1. Desarrollas proceduralmente según tu manual de 10 días de PHP3, mezclas HTML,
código de conexión a la base de datos, loops sobre resultsets, lógica condicional, estilo
(CSS) en una misma página.
2. Te das cuenta que si abstraes proceduralmente la lógica de conexión a datos (conectar,
consultar, insertar, borrar) podrás cambiar de DB sin traumas (eso dices tú).
3. ¿Si abstraes la lógica también, no será mejor?, ¡nacen los includes infinitos!.
4. ¿Y si centralizo esta clase en un objeto?, ¡puedo tener varias instancias!.
5. Creo que la clase hace mucho, ¿por que no la separamos y reducimos el acoplamiento
de los objetos?.
6. Dos objetos diferentes tienen propiedades similares, ¿Por qué no una clase abstracta?.
7. ¿Puedo gestionar todo desde una clase única de registro?, configuraciones únicas y
Controladora Frontal.
De lo horrible a practico :: El Camino MVC en 10 pasos
8. Te das cuenta que si separas el código HTML de las clases de la aplicación, puedes
tener otros tipos de vistas (PDF, XML, WSDL, GTK, entre otros).
9. Tu gran aplicación consiste en miles de clases, unidas entre sí (alta cohesión) en
distintas capas (ntier), con pocas relaciones entre ellas (bajo acoplamiento), que
interactúan unas con otras sin conocerse (alta composición), muy genéricas (baja
implementación) y con estándares seguros sobre ordenamiento, nombres de
funciones (interfaces) y seguimiento de patrones.
10. ¡Felicidades!, haz llegado a MVC! ... ¿y ahora ... que?
De lo horrible a practico :: Frameworks
Un Framework, “Marco de Trabajo” o WAF (Web Application Framework), es una
serie de librerías (toolkits) que se han unido bajo un único esquema de colaboración
para que de manera rápida (RAD: Rapid Application Development) logremos
desarrollar nuestras aplicaciones.
Entre las ventajas se cuenta:
• No hay que definir “marco de desarrollo”, solo “rellenar” los huecos que los
frameworks nos indican.
• Trabajamos sobre un Estándar que miles de personas ya conocen.
• Facilidad para encontrar herramientas, librerías o documentación.
• Relación Coste de aprendizaje vs. Aplicabilidad mínima.
De lo horrible a practico :: Frameworks
Algunos Framework MVC:
• Solar.
• CakePHP.
• CodeIgniter.
• Symfony.
• PHP on Trax.
• Zend Framework.
• Agavi, entre otros...
Comparativa de 10 Framework en PHP
Conclusiones
El desarrollo de web aplicaciones mezcla es un conjunto de tecnologías, estándares
y normativas de accesibilidad, reusabilidad y operatividad de la Web que se deben
cumplir para evitar posteriores “dolores de cabeza” por desconocimiento del entorno
de despliegue de la aplicación, es decir la Web.
Los patrones de diseño, es una forma simple de resolver problemas cotidianos y que
que son muy repetitivos en nuestro entorno. No requiere una implantación con
lenguaje de programación por lo que ofrece, un idioma común entre programadores
de distintos lenguajes.
Conclusiones :: Continuación.
La programación MVC aplicada a la web no es una opción, ¡es una necesidad!
¿Por que?
• Desarrollas para una interfaz, no para una implementación.
• Todo tu equipo se dedica a su especialidad preferida.
• Desarrollo sostenible y mantenible.
• Es posible migrar en diferentes direcciones.
• Evolución rápida de la aplicación.
• ¡Terminas más rápido!.
Conclusiones :: Continuación.
Los llamados “Framework” o , “WAF”, es una serie de librerías (toolkits) que se han
unido bajo un único esquema de colaboración para que de manera rápida (RAD:
Rapid Application Development) logremos desarrollar nuestras aplicaciones.
Sitios en Internet :: Continuación
Definiciones básicas
• Desarrollo de software Wikipedia (http://es.wikipedia.org/wiki/Desarrollo_de_software)
• * Diseño web Wikipedia (http://es.wikipedia.org/wiki/Diseno_web)
• Desarrollo web Wikipedia (http://es.wikipedia.org/wiki/Desarrollo_web)
• Aplicación web Wikipedia (http://es.wikipedia.org/wiki/Aplicacion_web)
• Patrones de diseño con PHP5 (http://www.phppatterns.com/)
• Charla “Desarrollo de Aplicaciones Web con Perl Simplicidad, Productividad y
Elegancia”, Copyright (c) 20042006, Ernesto HernándezNovich, VELUG, Caracas Perl
Mongers. <emhn@usb.ve>
• Charla “Desarrollo web en Python usando el framework Django” Blog de MilMazz
(http://www.milmazz.com/)
Sitios en Internet :: Continuación
Patrones de Diseño
• * Patrón de diseño Wikipedia (http://es.wikipedia.org/wiki/Patron_de_diseno)
• Design pattern (computer science) Wikipedia
(http://en.wikipedia.org/wiki/Design_pattern_(computer_science))
• MVC Wikipedia (http://es.wikipedia.org/wiki/MVC)
• Model View Controller Wikipedia (http://en.wikipedia.org/wiki/Modelviewcontroller)
• Patrones de Diseño (http://home.earthlink.net/~huston2/dp/patterns.html)
¡Gracias por su atención!
¡Visita nuestros Blog!
http://lcaballero.8k.com/
http://www.jesuslara.com.ve/blog/
¡Visita y descarga este trabajo!
https://finde.gob.ve/projects/lcaballerodoc/
¡Escribenos!
leonardocaballero@gmail.com
jesuslara@gmail.com

Patrones de Diseño y Orientacion A Objetos en PHP

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Patrones de Diseño y Orientacion A Objetos en PHP

Uploaded by

Copyright:

Available Formats

Patrones de diseño y Orientación a Objetos en PHP5

Uno de los principales precursores del movimiento

Singleton + Registry > Sistemas de Diccionario, i18n (Internacionalización),

Abstract + Composite + Helper View > Construcción de vistas complejas a

Composite + Facade + Interpreter > Gestores de idiomas especializados,

You might also like

Patrones de Diseño y Orientacion A Objetos en PHP

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Patrones de Diseño y Orientacion A Objetos en PHP

Uploaded by

Copyright:

Available Formats

Patrones de diseño y Orientación a Objetos en PHP5

Uno de los principales precursores del movimiento

Singleton + Registry ­> Sistemas de Diccionario, i18n (Internacionalización),

Abstract + Composite + Helper View ­> Construcción de vistas complejas a

Composite + Facade + Interpreter ­> Gestores de idiomas especializados,

You might also like

Singleton + Registry > Sistemas de Diccionario, i18n (Internacionalización),

Abstract + Composite + Helper View > Construcción de vistas complejas a

Composite + Facade + Interpreter > Gestores de idiomas especializados,