3 0 Disenio Orientado Objetos

Curso: "Programacin Orientada a Objetos PHP5" 2012
Introduccin a Objetos Mdulo 3
Todos los logos y marcas utilizados en este documento, estn registrados y pertenecen a sus respectivos dueos.
AUTOR: Andrs Guzmn Fontecilla. Email: andresguzf@gmail.com WEB: http://www.bolsadeideas.cl/servicios/cursos-de-capacitacion/ LICENCIA: http://creativecommons.org/licenses/by-nc/2.5

Objetivos
Desarrollar Orientado a Objetos va ms all que crear objetos aislados que solo contienen datos, programar usando algunos objetos es distinto a desarrollar 100% Orientado a Objetos, ser programador es distinto a ser un desarrollador, un sitio web no es lo mismo que un sistema web. Existen, adems de los objetos, "Principios de Diseo (OO)", "Patrones de Diseo (OO)", el lenguaje de diseo UML, frameworks, etc.

Nuestros Principios como Desarrolladores Peor que usar un mal estndar o un estndar incorrecto es no seguir ninguno, de la misma forma, lo peor que podemos hacer es no tener ningn criterio para enfrentar los desarrollos. Para aumentar nuestra productividad, tanto individualmente como en equipo, debemos siempre seguir estndares y fijar criterios de desarrollo. Nuestro objetivo debera ser contar con una plataforma de desarrollo que nos evite tener que repensar problemas tpicos y cotidianos, y concentrarnos solo en los problemas nuevos. Empecemos por el principio, por lo ms bsico y elemental nuestros principios base.
"Nadie debe empezar un proyecto grande. Empiezas con uno pequeo y trivial y nunca debes esperar que crezca; si lo haces solamente sobredisears y generalmente pensars que es ms importante de lo que lo es en esta etapa. O peor, puedes asustarte por el tamao de lo que tu esperas que crezca. As que empieza pequeo y piensa en los detalles. No pienses acerca de la foto grande y el diseo elegante. Si no resuelve una necesidad inmediata, seguramente est sobre-diseado. Y no esperes que la gente salte a ayudarte, no es as como estas cosas funcionan. Primero debes tener algo medianamente usable y otros dirn "hey, esto casi funciona para m" y se involucrarn en el proyecto." - Linus Torvalds

Principio 1: RTFM - "Lee el Maldito Manual"
RTFM es una sigla que significa lee el maldito manual, algo muy usado en los foros como respuesta hacia los novatos que lo ltimo que hacen es leerlos (lamentablemente *todo* se encuentra ah) http://es.wikipedia.org/wiki/RTFM
Principio 2: DRY - "No Te Repitas"

No te repitas significa algo muy simple: si cuando desarrollas ves que al programar copias un cdigo para pegarlo en otro lado, es muy probable que ests haciendo algo mal, ya que ese cdigo debera estar aislado y ser usado a travs de parmetros. Generalmente no existe razn para tener que duplicar el cdigo, si estamos muy apurados, seguro, lo pagaremos muy caro dentro de poco. http://es.wikipedia.org/wiki/DRY
Principio 3: KISS - "Mantenlo Simple, Estpido!"

Hay una frase que dice la mejor arquitectura es la sencillez. La sencillez es escalable, si resolvemos pequeos problemas y luego los unimos, ser ms fcil que hacer un sistema complejo de entrada (as funciona Unix / Linux) http://es.wikipedia.org/wiki/Principio_KISS
Principio 4: Estndar de Codificacin PHP / Zend

El lenguaje PHP y su comunidad, por aos, no ha tenido ningn referente nico para seguir un estndar, por consiguiente los desarrolladores usan o inventan el que ms le quede cmodo. La empresa Zend Technologies, principal desarrolladora de PHP (junto al autor original) y creadora de Zend Framework, ha tomado cada vez ms protagonismo (principalmente por su framework), por lo que debera ser de ahora en ms nuestra referencia a seguir. Evita crear un estndar propio, usa el definido por Zend.
http://framework.zend.com/manual/en/coding-standard.html

Los Desarrolladores PHP debemos Profesionalizarnos
Esta reflexin se la escribo a todos los "Programadores PHP"
Al da de hoy la mayora de los institutos o universidades de muchos pases siguen enseando PHP4, o mejor dicho, programacin "scripting" bsica. Se mueven en el viejo concepto de la "programacin estructurada", trabajando constantemente sobre cdigo que mezcla html y sintaxis PHP, todo como si de una ensalada o cdigo espagueti estuviramos hablando. Casi paralelamente, los jvenes autodidactas siguen por el mismo camino, tal vez ayudados por la gran cantidad de material repetido y obsoleto que se encuentra tanto en la web como en las editoriales de turno, donde a pesar que un libro haya sido impreso recientemente, los autores siguen siendo los mismos y escribiendo -una y otra vez- sobre los mismos temas elementales.
Enfrentar la realidad con madurez

Solo nos damos cuenta que estamos en un grave problema cuando nos enfrentamos a la realidad: salimos al mercado laboral y con inocente sorpresa vemos que se habla mayoritariamente de Java o .Net, de UML, desarrollos en 3 capas, lgica de negocios, persistencia, polimorfismo, frameworks, patrones de diseo, refactoring... y t solo tienes una vaga idea de algunos conceptos, pero nulo conocimiento de si es realmente posible hacerlo con PHP...
No crees que algo est pasando y que t ests quedando fuera de la "conversacin"?
Este es el gran problema de la mayora de los "Programadores PHP": se quedan en el "lenguaje", en la programacin lisa y llana, rechazando todo lo que sea objetos hasta que no les queda otra salida que aprender a usarlos mnimamente... pues todas las nuevas herramientas solo hablan "ese" idioma. Hasta donde piensas que podemos llegar con tan poca preparacin?

Mi experiencia personal
De lo que trato de hablar es de "profesionalizarnos", de copiar y mejorar, de aprender y evolucionar. La mayora de los temas que expongo no son nuevos, trato de basarme en autores reconocidos y darle ms prioridad a los conceptos que al lenguaje, y por sobre todas las cosas: ser simple y directo (pragmtico antes que dogmtico, pero sin olvidarme de lo ltimo). Hay muchas cosas que desconozco de PHP y otras que directamente no uso, y nunca me baso en la memoria, siempre voy a buscar hasta lo ms elemental al manual (doy prioridad al razonamiento por sobre la retencin mecnica de conocimientos). Siguiendo esta metodologa, maana deberas poder cambiar de lenguaje y seguir trabajando sin problemas, pues los conceptos base los tendras claros y estos se aplican sin importar la plataforma que ests usando. Muchas veces comento que los temas sobre los que escribo son elementales para muchos desarrolladores Java de nivel medio y alto, pero en el ambiente PHP esto cambia (todava no hemos madurado hacia el concepto de "arquitectura") donde "en el mundo de los ciegos puedo ser rey". Debemos cambiar la mentalidad ahora que existe PHP5 y que su nueva sintaxis nos permite hacer muchas cosas que son habituales en el mundo Java. Por lo tanto, tenemos todas las herramientas para "evolucionar" y no quedarnos en las excusas. T, qu vas a hacer? Te vas a quedar donde ests o te vas a subir al tren? Eres parte del problema o parte de la solucin? Tenemos que especializarnos y profesionalizarnos, el mundo pide POO, arquitecturas, capas, etc, y habla en "UML"... t, en qu idioma hablas?

Programador versus Desarrollador
Desarrollar Orientado a Objetos va ms all que crear objetos aislados que solo contienen datos, programar usando algunos objetos es distinto a desarrollar 100% Orientado a Objetos, ser programador es distinto a ser un desarrollador, un sitio web no es lo mismo que un sistema web. Existen, adems de los objetos, "Principios de Diseo (OO)", "Patrones de Diseo (OO)", el lenguaje de diseo UML, frameworks, etc, y todo es perfectamente aplicable usando PHP. Es ms, muchos de estos conceptos e ideas son independientes al lenguaje si este cumple mnimamente con las caractersticas de la OO, cosa que sucede a partir de PHP5 en adelante y que PHP4 casi carece por completo. Finalmente, es mi visin que un programador resuelve problemas aislados usando un lenguaje, pero un desarrollador disea e implementa una solucin global, une los componentes en un nico sistema integrado y es lo suficientemente inteligente y estratega para poder reutilizar la experiencia y conocimientos adquiridos en favor de los prximos desarrollos. Los sistemas que van quedando atrs nunca sern un lastre porque podrn ser mantenidos con el mnimo costo posible, permitiendo que el desarrollador pueda afrontar nuevos y enriquecedores desafos. Todos estos detalles los percibimos claramente cuando nuestros desarrollos dejan de ser un "programa menor" y necesitamos crecer, pero vemos que con los conocimientos que contamos hasta el momento todo se nos hace cuesta arriba.
La culpa es enteramente nuestra

No podemos quejarnos que a los programadores Java se les paga el doble que a nosotros y que a la mayora de los proyectos PHP se los desvalorice, se los trate como "algo menor", "poco serio", todo porque es un "simple lenguaje web" limitado en sus posibilidades. El "Simple Lenguaje" lo hacemos todos, al ser "Simples Programadores PHP" y nuestras son las limitaciones fundamentales. Perfectamente podemos tratar de trabajar "ms seriamente" como lo hacen los "desarrolladores Java".

Introduccin a los Objetos
Una buena forma de ver los prximos pasos que daremos es trazar una analoga entre aprender Diseo Orientado a Objetos y aprender a jugar ajedrez. Lo primero que es necesario para poder jugar ajedrez es conocer las piezas y que comportamiento o caractersticas tienen. Una vez que se domina esto, se puede comenzar a estudiar estrategias o prcticas a aplicar durante las partidas. Llegado el punto en que se tiene una compresin cabal del juego y se conocen las estrategias ms importantes, una buena herramienta para continuar aprendiendo es analizar las partidas de los grandes maestros, para ver cmo se comportan frente a determinadas circunstancias y qu resultados obtienen. Nosotros intentaremos seguir un proceso similar dentro del paradigma, por lo que en este primer paso analizaremos cules son nuestras piezas (aquellos elementos bsicos a partir de los cuales construiremos nuestras soluciones) y cules son sus caractersticas y comportamientos. Dominar estos conceptos es fundamental para poder pasar a nuestra siguiente etapa, que ser el analizar las tcticas (principios de diseo) que se pueden aplicar para lograr resultados esperados al disear software dentro del paradigma de orientacin a objetos. Aqu es donde inicia todo, el primer viaje con destino aprender las profundidades de la POO. En el mundo real, estamos rodeados de objetos, basta que echemos una mirada a nuestro alrededor y nos daremos cuenta de ello: el teclado con el que escribo, la silla en la que estoy sentado, el apunte que estoy leyendo, el celular que tengo en mi bolsillo, el computador que uso para conectarme al internet, el libro de UML que est en la biblioteca, el sistema operativo de mi computador, el microbs del Transantiago que me trae al trabajo, el semforo que me hizo llegar tarde, etc. Todos estos ejemplos representan distintas cosas que vemos, tocamos, usamos, omos y entendemos como objetos de nuestra realidad.

Pues, la definicin de lo que es un objeto en OO no est alejada de esa realidad, porque un objeto no es ms que cualquier cosa con la cual se interacta. As, podemos decir que: Un objeto es cualquier cosa real o abstracta que posea atributos, se pueda almacenar informacin y tenga un conjunto de operaciones con las cuales se puede interactuar. En la POO lo que interesa es el comportamiento del objeto. De esta forma, al disear la estructura de la informacin incorporaremos objetos para representar cada entidad o elemento que interacta dentro del sistema. Por ejemplo, una Factura es un objeto ya que posee un cdigo de factura, informacin de a quien se le est entregando esa factura, la informacin del emisor de dicha factura, el detalle de los servicios o productos, los montos por esos productos, un total, etc. A pesar de que todas las facturas que conocemos poseen esta informacin, el objeto se refiere a una de ellas en particular como individuo nico dentro de su especie.

"Un sistema complejo que funciona resulta invariablemente de la evolucin de un sistema simple que funcionaba. Un sistema complejo diseado desde cero nunca funciona y no puede ser arreglado para que funcione. Tienes que comenzar de nuevo con un sistema simple que funcione." John Gall
Vacuidad: vaciar todos los conocimientos

Como dira el legendario Bruce Lee, si tienes un vaso medio lleno no vas a poder recibir por completo toda la enseanza que te quiero transmitir, por consiguiente, vaciarse de todo lo que crees que sabes es lo ms importante, ms que acumular conocimientos y luego simplemente rechazar lo nuevo creyendo que eso ya lo sabes. As que de aqu en adelante, olvida todo lo que crees que sabes sobre objetos y empecemos de cero. La sencillez es la mejor arquitectura Los objetos como concepto -fuera de la informtica- existen desde antes de la programacin (obviamente). Qu es lo que intenta hacer entonces la Programacin Orientada a los Objetos (POO)? Lisa y llanamente intentar simplificar la complejidad (simplificar las abstracciones) y tratar de representar de forma simple lo que vemos y manejamos todos los das los objetos que nos rodean. Un nio, cuando empieza a hablar, nos demuestra que ya entiende el concepto de objetos, empieza a nombrar esas cosas:
VASO, AGUA, PAP, MAM, CASA, GUAU GUAU (PERRO), ETC.
10

Todos estamos sumidos en un mundo que tiene reglas (sepamos o no que existen, nos afectan), como cuando tiramos un objeto y este cae (gravedad), cuando pisamos la cola de un gato y este grue (y probablemente nos arae), aunque parezca absurdo, tiene mucho sentido observar los objetos de la vida real y cotidiana, es aqu donde comenzamos, observando la realidad para llevarla y plasmarla en el mundo informtico de un sistema orientado a objetos.
Nos vamos dando cuenta que generalmente no manipulamos los objetos directamente ni tenemos un completo control sobre ellos, muchas veces solo interactuamos con ellos, por ms que no queramos que el gato se defienda, este lo har. Nos damos cuenta que cada uno tiene dentro una programacin que le dice cmo reaccionar ante determinados estmulos o situaciones, y descubrimos luego que un gato reacciona distinto de otro gato (a pesar que ambos son gatos) y que no es lo mismo la reaccin de un perro con respecto a la de un gato (a pesar que entre ellos existe una relacin que los une como mamferos).
Por lo tanto, as son los objetos: pueden ser de un tipo determinado (perro, gato), tambin pertenecer a una misma familia (mamferos) y a su vez ser nicos (el gato llamado Risn)
Lo ms importante es detectar los objetos

Entonces, la Programacin Orientada a Objetos no es ms que eso, detectar los objetos existentes en nuestro contexto real y construirlos como si furamos Dios, dndoles un comportamiento para que estos sepan solos cmo reaccionar ante la interaccin con otros objetos. A esta actividad la llamaremos diseo y ser cuando debamos decidir cmo sern y cmo se comportarn nuestros objetos ante la interaccin con otros objetos. Nada ms y nada menos... y hemos logrado empezar a hablar del tema sin mostrar -hasta el momento - una sola lnea de cdigo ;-)
11

"La complejidad es destructiva. Absorbe la sangre de los desarrolladores, hace que los productos sean difciles de planificar, construir y probar, introduce problemas de seguridad y provoca la frustracin de usuarios finales y administradores" -Ray Ozzie
Cmo Pensar en Objetos

Veremos en este captulo cmo detectar los objetos sin preocuparnos an del cdigo. "Mucho software hoy da es en cierta medida como una pirmide egipcia con millones de piedras apiladas una encima de otra, sin integridad estructural, construido por fuerza bruta y miles de esclavos." Por Alan Kay (cientfico de la computacin) Lo menos importante es el cdigo Lo ms importante por lo menos al principio- no es jugar con el cdigo (ya que este podr funcionar, no dar error, pero conceptualmente nuestro sistema no funcionar como un sistema Orientado a Objetos ni aprovecharemos todas sus virtudes), es detectar los objetos dentro de un contexto determinado. Todo problema est sujeto a un determinado contexto, no existe un diseo que se adapte a todos los posibles contextos El cdigo con el que se construyen los objetos es meramente circunstancial , una vez que tengamos claro el diseo conceptual, luego ser seguir la receta a travs del manual del lenguaje de turno.
12

Veamos un ejemplo simple de la vida real - Un nio pequeo
Empecemos por el dilogo de un nio que recin empieza a hablar: Borja, de 5 aos, dice: mira el perro negro y blanco, se llama Prospero, le toco la cabeza y mueve la cola, y si le doy de comer, al rato, duerme la siesta. Claramente tenemos un objeto de tipo Perro con caractersticas bastante definidas (y probablemente con algn problema en su digestin). Tenemos entonces: Un perro, el objeto propiamente dicho. Es de color negro y blanco, el color es un atributo del objeto perro reacciona si le tocan la cabeza, el comportamiento ante un estmulo externo. mueve la cola, tiene acciones. come, otras acciones relacionadas con su exterior/interior duerme siesta e hace digestin, tiene otras acciones que estn relacionadas con su interior, y que posteriormente se exteriorizan de alguna forma. Tambin es importante destacar, un poco ms sutil, que existe otro objeto en este escenario y se llama Borja, y adems existe (aunque no lo veamos) un contexto (todo sistema tiene un contexto, un sistema no puede aplicarse en absolutamente todos los contextos) donde viven los objetos y que permite que se genere una interaccin entre ambos. Ms importante que codificar es detectar los objetos sin preocuparnos -an- del cdigo que los representar
13

El medio de comunicacin
De alguna forma u otra, ambos objetos tienen cosas en comn: existe un medio que les permite comunicarse, pero a su vez ellos tienen los elementos para generar ese dilogo, como as tambin existen acciones que son internas e implcitas de cada uno: Aunque Borja y an el perro- no lo entienda, ambos tienen internamente distintos mecanismos de digestin y ninguno controla el mecanismo del otro. El perro, que sabe que cuando est nervioso mueve la cola, no logra entender del todo por qu si Borja lo acaricia, esta tambin se mueve. Borja sabe que si lo acaricia su cola se mover. Borja tiene una mano y el perro una cabeza, Borja tiene acceso a su cabeza, y la cabeza es accesible para que la mano pueda acariciarla.
Parece tonto y simple, pero as son los objetos, y en esos temas tenemos que pensar cuando diseamos: El contexto, los objetos, sus atributos, sus acciones, cules pueden ser conocidos por otros objetos y cuales son (o deben ser) naturalmente internos del propio objeto, para finalmente hacerlos interactuar como en una obra de teatro o en un cuento, con varios posibles principios y finales segn la historia que necesitemos contar. Cuando veamos los primeros ejemplos codificados entendern un poco ms de lo que hablo
POO segn los manuales

En la era web es muy probable que antes de consultar un libro impreso usemos nuestro navegador y busquemos material de lectura. Esto no est mal, el problema es que existe mucha informacin antigua o incorrecta, tambin existen demasiados charlatanes, por lo que deberemos ser desconfiados y selectivos con lo que leemos. Dos fuentes que son confiables y que tenemos ms a mano son Wikipedia, principalmente para consultar los conceptos fundamentales que se aplican a cualquier lenguaje Orientado a Objetos, y el manual oficial del lenguaje POO, que aunque es un manual de programacin y no de desarrollo (se concentra ms en la sintaxis que en los conceptos), tiene mucho para ensearnos (el resto lo haremos a travs de este curso).
14

La POO segn Wikipedia
Amn que la introduccin conceptual de Wikipedia est bien, en algunas partes puede generar confusin o no estar suficientemente explicado. Intentaremos resaltar algunos puntos fundamentales sin reescribir el captulo original. De todas formas, se sugiere primero la lectura del captulo en Wikipedia http://es.wikipedia.org/wiki/POO Luego de haber ledo el captulo original en Wikipedia, quiero resaltar los siguientes puntos fundamentales: La POO es un paradigma que tiene sus orgenes desde antes de 1990 (a partir de este ao se empieza a popularizar). Por lo tanto no es ninguna excusa (menos como Desarrollador) seguir a la fecha desconociendo cmo trabajar con POO o discutiendo si realmente es til su adopcin. Los objetos son entidades que combinan estado, comportamiento e identidad Fundamental, los beneficios que obtenemos usando este paradigma: La programacin orientada a objetos expresa un programa como un conjunto de estos objetos, que colaboran entre ellos para realizar tareas. Esto permite hacer los programas y mdulos ms fciles de escribir, mantener y reutilizar. La razn de por qu no es necesario que todos los objetos que creemos tengan un id como si fuera una clave primaria de una tabla (con el fin de ubicar un objeto en particular): De esta forma, un objeto contiene toda la informacin que permite definirlo e identificarlo frente a otros objetos pertenecientes a otras clases e incluso frente a objetos de una misma clase, al poder tener valores bien diferenciados en sus atributos. Diferencias con respecto a la Programacin Estructurada versus Programacin Orientada a Objetos: la primera se pens como funcionalidad por un lado y datos por otro, es decir, llamar a una funcin y pasarle constantemente datos para que los procese, mientras que la POO est pensada para tener todo integrado en el mismo objeto: En la programacin estructurada slo se escriben funciones que procesan datos. Los programadores que emplean ste nuevo paradigma, en cambio, primero definen objetos para luego enviarles mensajes solicitndoles que realicen sus mtodos por s mismos. Muy importante es tener SIEMPRE en claro los conceptos FUNDAMENTALES , si no los tienes claros cuando programas OO, algo est mal, seguro errars el camino que define el paradigma: Clase, Herencia, Objeto, Mtodo, Evento, Mensaje, Atributo, 15

Estado Interno, Componentes de un objeto y Representacin de un objeto . No dudes en volver a repasarlos todas las veces que lo necesites, por ms experto que te consideres, siempre viene bien una relectura de nuestras bases. Caractersticas de la POO: igual que el punto anterior, es fundamental tener claros estos conceptos cada vez que desarrollamos, con principal nfasis en el Principio de Ocultacin (que es muy comn confundir con Encapsulamiento), lo que explica por qu no deberan existir los atributos pblicos ni abusar de los setter/getter.
16

POO segn el manual Oficial de PHP
De la misma forma que en el punto anterior, es muy importante hacer una lectura de Referencias del Lenguaje (la base para empezar comprender PHP) y posteriormente del captulo sobre POO en el manual oficial, aunque algunos captulos no aborden en profundidad cada tema (lo cual es entendible si comprendemos que hablamos de un manual de sintaxis y no un tutorial para aprender a programar). Todos estos temas los veremos ms adelante y har todas las referencias oportunas al manual oficial, pero aqu la lista de temas bsicos que trata.
Clases y Objetos (PHP 5) Tabla de contenidos

Introduccin Lo bsico Propiedades Constantes de Clases Auto-carga de Clases Constructores y destructores Visibilidad Herencia de Objetos Operador de Resolucin de mbito (::) Palabra Clave Static Abstraccin de clases Interfaces de objetos Traits Sobrecarga Iteracin de objetos Patrones Mtodos mgicos Palabra clave Final Clonacin de Objetos Comparacin de Objetos Type Hinting Enlace esttico en tiempo de ejecucin Objetos y referencias Serializacin de objetos Registro de cambios de POO
17
"Medir el progreso de programacin en lneas de cdigo es como medir el progreso de construccin de un avin en peso" Bill Gates
Empezar a plasmar los objetos en un diseo En este captulo empezaremos a ver cmo transformar los objetos que detectamos en nuestra observacin de la realidad en algo informticamente palpable. "Hay dos maneras de disear software: una es hacerlo tan simple que sea obvia su falta de deficiencias, y la otra es hacerlo tan complejo que no haya deficiencias obvias" -- C.A.R. Hoare
18

Aplicacin del Principio KISS
Si en una empresa/proyecto para hacer un sistema cada desarrollador (con toda la mejor voluntad del mundo) agrega un extra y trata de hacer la super clase (agregar funcionalidad no solicitada), la complejidad aumentar exponencialmente. Es recomendable ajustarse a los requerimientos, a menos que estos digan que deben cubrir todos los posibles errores, situaciones, etc, pero de todas formas habr que definir un criterio o un lmite. Recuerda: un diseo est atado siempre a un contexto, si cambia el contexto, muy probablemente deber cambiar el diseo. No existen diseos que sirvan para absolutamente todos los contextos posibles, por lo tanto, es recomendable hacer un diseo concreto para un contexto concreto.
Sugerencias para enfrentar los diseos

En general, tratar de: Empezar a pensar el diseo a partir de los objetos de ms bajo nivel (los ms simples) y en ese momento olvidarse del bosque (as no se pierde el foco de lo que se est tratando de abstraer, el objeto concreto como entidad independiente). Siempre cuando diseen una clase, pararse literalmente sobre ella razonando qu es lo que debera ver o conocer esta, sin entrar a pensar qu es lo que deberan hacer las dems clases. Tan importante como disear qu hacen es entender qu no deberan hacer. Seguir el principio de diseo OO: Una clase, una nica responsabilidad, si tiene ms de una responsabilidad, debe estar haciendo ms de lo que le corresponde, y deber descomponerse en otra clase. Ejemplo la clase Automovil y el Motor. Finalmente, con l o los objetos de ms alto nivel, empezar a interactuar con los objetos de ms bajo nivel, sin interesar cmo estn construidos por dentro y qu hace su cdigo interno; solo hay que tomar los objetos y pedirles la informacin o el comportamiento que necesitamos de ellos (interfaz pblica). Y el ms importante de todos, Mantener un Diseo Simple en todos los sentidos, evitar complejidad innecesaria. Por ejemplo, puedes tomar la siguiente mtrica: si un mtodo no se puede visualizar en una sola pantalla, hay algo que evidentemente est mal y hay que descomponerlo en varios mtodos (refactoring), etc. Sugerencia: Prefiere Simple sobre Complejo
19

Cmo representar la estructura de los objetos
En un captulo anterior habamos hablado de una situacin de la realidad donde un nio llamado Borja que interactuaba con un perro, as que vamos a ir por partes y tratar de representar lo que podemos interpretar del texto que est en un lenguaje natural y nos describe claramente los objetos y sus relaciones: Borja, de 5 aos, dice: mira el perro negro y blanco, se llama Prospero, le toco la cabeza y mueve la cola, y si le doy de comer, al rato, duerme la siesta. Si nos concentramos en el perro, tenemos que: Atributos Color Nombre Comportamiento Se le puede tocar la cabeza Mueve la cola Puede comer Duerme siesta
Los Objetos tienen Atributos, Comportamientos y Estados.

Todos los objetos tienen atributos, comportamientos (mtodos) y un estado. Este ltimo no es ms que la informacin que tienen los atributos en un momento dado. Un perro se llamar Prospero y otro Feliza, pero el atributo es el mismo (nombre). Si maana el perro cambia de nombre, lo que cambia es su estado y el mecanismo para cambiar el estado sern sus mtodos (cambiar el nombre).
20

La clase, un molde para construir objetos
Este ejemplo es muy usado para tratar de transmitir el concepto que hay detrs. Podramos decir que si jugramos a ser Dios, primero definiramos un diseo de cmo va a ser la criatura que queremos crear, haramos un molde a partir de ese diseo, y posteriormente podramos crear vida con similares caractersticas, pero que siempre sern objetos nicos. Crear Personas Por ejemplo, si quiero crear Personas dira que todas tendrn un sexo (masculino / femenino), dos piernas, dos brazos, una cabeza y pelo sobre ella (es un diseo simple para un contexto simple, si fuera otro el contexto, muy probablemente debera cambiar mi diseo). Crear Perros Por ejemplo, podra decir que los Perros tambin tendran un sexo, pero ahora tendran cuatro patas, una cabeza y pelo sobre todo su cuerpo. Para ambos ejemplos ya cuento con dos moldes, el de Personas y el de Perros, por lo tanto ahora puedo crear a Borja y a Prospero, pero tambin podra crear a Josefina y a Feliza, por lo que tendramos dos personas y dos perros, con caractersticas similares, pero que seran a su vez criaturas nicas, identificables y distinguibles entre las dems criaturas, an entre las criaturas del mismo tipo (aunque se llamaran igual y tuvieran los mismos rasgos, seran solo parecidos).
21

Los atributos y comportamientos pueden ser pblicos o privados
Existir informacin y comportamientos que sern conocidos por otros objetos ( acceso pblico) y esto permitir que se pueda generar una interaccin entre ellos. Tambin existir informacin y comportamientos que sern internos de cada objeto (acceso privado) y no sern conocidos por los dems objetos. Un diseo posible para nuestro Perro podra ser: Perro Atributos nombre color Comportamiento comer recibir caricia mover la cola hacer digestin dormir siesta
Cmo se debera leer este diagrama:

Todo lo que se encuentre seguido de una imagen de candado es interno y privado (invisible e inaccesible para el exterior) y lo restante ser nuestra interfaz con el exterior, los comportamientos pblicos del objeto que sern invocados por los mensajes enviados por otro objeto que quiere interactuar con nosotros. Un objeto de tipo Perro tiene como atributos su color y su nombre Dentro de los posibles comportamientos pblicos de nuestro perro podran ser comer, recibir una caricia, etc. Dentro de los posibles comportamientos privados de nuestro perro podra ser hacer la digestin, que muy probablemente ser activada a travs de otros mtodos (como comer).
22

Qu es lo que vera Borja desde el exterior:
Perro Comportamiento comer recibir caricia mover la cola dormir siesta
Solo podramos interactuar con lo que es pblico del diseo, como as lo decidimos. Ahora la pregunta sera Qu debera ser pblico y qu debera ser privado?, bueno, intentemos usar el sentido comn: el perro necesita poder interactuar con su exterior de alguna forma, pero existirn detalles que no conciernen al exterior ni nos interesa que otro objeto pueda modificar a su antojo. Por ejemplo, Borja no tiene por qu saber cmo es el mecanismo de digestin de un perro, qu rganos entran en juego durante todo el proceso, es ms, por la vida del perro creo que tampoco Borja debera poder tener la potestad para cambiarlo a su antojo (ya que seguro estara en peligro la vida del perro).
Esto es un ejemplo terico para tratar de transmitir varios conceptos, como todo diseo, tendr debilidades y fortalezas, y si cambiamos de contexto, muy probablemente este diseo no servir (no dudo que en este momento estarn pensando que pasara si y muy probablemente se encuentren con que algo no se puede hacer... bueno, vayamos paso a paso y veremos de a poco el horizonte, pero ya les voy adelantando: no existen diseos que pueda funcionar en absolutamente todos los contextos posibles, por esta razn es importante definir el contexto de nuestro sistema. Nota: a menos que estemos hablando concretamente de patrones de diseo, pero aun as se define en qu contextos se podran aplicar y en cules no. Por ejemplo: el diseo de una clase Persona no ser exactamente el mismo si estamos hablando de un sistema de reserva de pelculas, una universidad con alumnos o un sistema de salud. Tendrn cosas comunes, pero su diseo no ser necesariamente el mismo. En mi opinin no existe el 100% de reuso puro, existirn componentes que dada su naturaleza s podrn usarse en distintos contextos y otros directamente no, a menos tal vez que hayamos pensado de entrada que as debamos disear nuestros componetes: reusables en varios contextos, aunque esto podra aumentar exponencialmente la complejidad del componente o de los sistemas. Para ms informacin sobre el apasionante tema sobre diseo se recomienda leer el siguiente artculo de Martn Fowler: Ha muerto el diseo?
23

En Resumen
Las clases se construyen en la etapa de diseo donde definimos qu es lo que queremos crear. Lo que creamos a partir de ellas es un objeto que tendr vida (ser lo que verdaderamente se ejecutar en nuestro sistema) y a la vez nico (podrn existir muchos objetos del mismo tipo, pero podremos interactuar con ellos e identificarlos de forma nica). Dentro de las definiciones de la clase tenemos los atributos y los comportamientos que tendr nuestra creacin, algunos de ellos sern pblicos y otros sern privados. Todo lo que definamos como pblico ser nuestra conexin con el exterior y permitir la interaccin entre los objetos. Esta interaccin se dar a travs de envos de mensajes entre objetos, como por ejemplo Borja le da de comer al perro, por lo que existirn dos objetos, uno que puede comer y otro que puede decirle al otro que coma (si no existen estos mtodos, el perro directamente no har nada y estar desconectado con el exterior). Esto se clarificar cuando empecemos a usar los diagramas UML (similares al diagrama presentado anteriormente) y a traducirlos en cdigo concreto y ejecutable. "Codifica siempre como si la persona que finalmente mantendr tu cdigo fuera un psicpata violento que sabe dnde vives" -- Martin Golding
24

Cmo representar una clase en UML
Empezamos con los primeros pasos en el Lenguaje Unificado de Modelado (UML) y usa las herramientas que te sean ms cmodas, puede ser StarUml, ArgoUML, Gliffy, Umbrello, Dia, etc (existen muchos programas ms), o directamente dibujando en un papel o una pizarra (lo que puedes luego fotografiar y subir a una wiki). Lo que importa son los conceptos. Primero resuelve el problema. Entonces, escribe el cdigo -- John Johnson Los lenguajes de programacin, en general hablando de PHP, Java y C# tienen Estndares: aunque no lo crean por ejemplo en el caso de PHP5, Zend es la empresa que desarrolla el lenguaje y el framework, tiene definido un documento que especifica los estndares de codificacin.
Conceptos Generales
Primer Regla: de nomenclatura, los nombres de las clases son siempre en singular y la primera letra de cada palabra en maysculas (CamelCase), al revs de los nombres de las tablas de una base de datos, generalmente en plural y en minsculas: Tablas en base de datos: personas, animales,usuarios, usuarios_administradores Clases en POO: Persona, Animal, Usuario, UsuarioAdministrador
Mi primer diagrama UML

Definamos un contexto para luego disearlo con UML: Una persona tiene nombre, apellido y fecha de nacimiento, cuando se le pregunta qu edad tiene, responde con su edad que calcula en base a la fecha de nacimiento Y el diagrama UML debera verse de la siguiente manera:
25

Este diagrama se debe leer de la siguiente forma:
La Seccin #1 es para definir el nombre de la clase (como explicamos al principio, usando CamelCase). La Seccin #2 es para definir los atributos de nuestra clase (CamelCase, pero a diferencia de las clases, inician con minscula), la visibilidad de cada uno (el signo - para privado, el signo + para pblico) y qu tipo de dato debera ser (no importa si el lenguaje lo soporta exactamente, recuerda que UML es independiente del lenguaje) La Seccin #3 es para definir los mtodos de nuestra clase (CamelCase, igual que con los atributos), la visibilidad de cada uno, los parmetros que pueden recibir y si retornan o no alguna informacin (para ambos casos, especificando el tipo de dato). Regla: todos los atributos de una clase son por defecto no-pblicos. Existe una convencin (que casi no se discute) desde los principios de la POO que si cualquiera desde el exterior puede conocer y modificar los atributos de un objeto, y por ende, su estado, todo diseo ser dbil.
26

Cmo se traduce en cdigo
Vayamos por partes (dijo Jack, El Destripador), empieza por arriba y sigue secuencialmente hacia abajo, y la traduccin se har muy simple y natural.
Seccin #1 nombre de la clase

Siguiendo la nomenclatura del estndar, deberamos primero crear un archivo / fichero con el mismo nombre que la clase: Persona.php Posteriormente, en cdigo todo se traduce en:
Seccin #2 los atributos de la clase

Segn el diagrama, tenemos 3 atributos, todos privados (signo -) y dos sern de tipo String (cadena de caracteres) y uno de tipo Date (fecha).
27
Aqu es donde tenemos que interpretar el diagrama y ajustarlo a nuestro lenguaje. Si quisiramos traducir esta clase a Java no tendramos problema porque existen clases base (ya que en Java todo es un objeto) como String, Integer, Date, etc. Pero, como no tenemos esta posibilidad en PHP (an, espero que en un futuro cercano s), podemos enfrentarlo de dos maneras, la manera simple y pragmtica (PHP), o la estricta y dogmtica (Java, C#, C++).
Estndar de Codificacin Como podrn apreciar en el primer cdigo de ejemplo sucede algo atpico: nuestra clase tiene las llaves a la izquierda y no existe el tag de cierre ?> Todo corresponde al estndar de codificacin de Zend, particularmente para el ltimo caso se omite cuando el archivo usar solo cdigo PHP y no con HTML embebido.
Versin pragmtica en PHP
Comentario aparte: perfectamente podramos haber usado una traduccin directa de los atributos y decir que son $nombre, $apellido y $fechaNacimiento, pero como estamos siguiendo el estndar definido por Zend, usaremos el agregado $_ para todos los atributos que son privados. No olvidar, esto no es un problema que debe contemplar UML, ya es un problema del lenguaje de turno, en nuestro caso, PHP.
28

Versin dogmtica Por ejemplo, como Java es un lenguaje de fuertemente tipado, cada uno de los atributos se traduciran de la siguiente forma: Cdigo JAVA:
Pero como PHP es un lenguaje de tipado dinmico no requiere definir inicialm ente un tipo para sus variables, el tipo es definido dinmicamente cuando se hace una asignacin de valor (y su uso tambin depender del contexto en donde se encuentre)
29

Lo mximo que podramos hacer en PHP es:
Al asignarle un valor por defecto de tipo String, su atributo sera de tipo String y cumpliramos exactamente con el diagrama, a no ser por la fecha, porque no tenemos nada parecido a Date. Si tuviramos la necesidad de definir un Integer, simplemente asignaramos un 0 a nuestro atributo, por ejemplo: private $_edad = 0; SUGERENCIA, sean PRAGMTICOS: no conviene perder mucho ms tiempo con esto ya que como PHP es de asignacin dinmica de tipos, el hecho que definamos en el comienzo un valor por defecto no asegura que se vaya a mantener, y UML es un medio y no un fin en s mismo. El mensaje que nos debe quedar es que ese atributo debe manejar este tipo de dato, y nosotros como desarrolladores estamos siendo notificados de ello y somos responsables de ver luego qu controles deberemos agregar para que se cumpla en el resto de la clase. Por ejemplo, imaginemos lo siguiente: la documentacin que nos entreg nuestro director de sistemas dice que manejarn valores de tipo Date en el atributo fechaNacimiento por consiguiente no deberamos permitir el uso de algo que no sea de tipo Date, as tendr coherencia el diseo con la implementacin. Si el cdigo no respeta el diseo, el cdigo est mal y hay que corregirlo.
30

Seccin #3 los mtodos de la clase
Finalmente, la traduccin de los mtodos. Aqu tenemos un mtodo pblico (signo +), que no recibe parmetros (los parntesis estn vacos) y luego de los : representan qu tipo de valor retornar (en este caso ser un nmero entero que representar la edad). El resultado en cdigo sera:
En este ejemplo se puede ver un detalle importante: Cmo y cundo se define el valor de la fecha de nacimiento de la persona? Respuesta: en ningn momento, el diagrama UML no dice nada, aqu est supeditado al pblico objetivo de la documentacin y a su interpretacin. Cabe aclarar que cuando se entrega un diagrama UML no solo van los dibujos, tambin se acompaan con ms informacin escrita explicando los posibles detalles o problemas de la implementacin, o simplemente se har una reunin para tratar el tema y sacar dudas.
31

El Constructor
Si tuviramos la necesidad de documentar alguna particularidad del constructor, lo que generalmente se hace es agregar un mtodo con el mismo nombre de la clase, lo que representara el constructor de la clase (sintcticamente sera similar a como lo hace Java, ya que cambia en PHP5 por la palabra reservada __construct() ). Nota: al no existir el tipo Date lo que se hace es recibir un parmetro y pasarle el valor al atributo que se encuentra protegido internamente en la clase (atributo privado). El elemento void: significa vaco, nada, es decir, debemos leerlo como este mtodo no retorna nada. En los diagramas UML podemos encontrar que todo lo que no devuelva nada o no tenga tipo, es de tipo void. Tambin podemos encontrar que directamente se omita y no se muestre nada al final del mtodo (eliminado :void del final).
32
33

Cmo se prueba? Si lo estamos probando desde otro archivo, como corresponde (cada clase debe tener su propio archivo aparte), deberamos invocar siempre una sentencia que cargue el archivo de la clase. En nuestro caso usaremos siempre require_once (ms adelante iremos explicando con ms profundidad la razn de usar esta sentencia y no otras). Nuestro index.php se debera ver de la siguiente forma: Luego creamos el objeto a partir de la clase: Cdigo PHP:
Esto debera funcionar sin problemas siempre y cuando index.php y Persona.php estn ubicados en el mismo directorio, de lo contrario deberamos especificar su ruta para llegar hasta l (tanto relativa como absoluta).
34

Los mtodos "getter / setter" o "accesores / modificadores"
He visto mucha documentacin que habla sobre el tema de los mtodos "getter / setter", o traducido al castellano los mtodos "accesores / modificadores", y la mayora se va a los extremos, perdiendo de explicar de forma simple la razn de su existencia, y algo ms importante, por qu no deberamos abusar de esta prctica.
El origen de la necesidad de los "set y get" para los atributos

En PHP4 todos los atributos de un objeto son siempre atributos pblicos, es decir, cuando creamos una instancia del objeto a partir de la definicin de la clase, tanto para leerlos como para modificarlos. Definicin de la clase "Usuario" en PHP4
Creo el objeto "unUsuario":
En este momento el usuario est vaco, pues sus atributos no tienen ningn valor asignado. Por lo tanto, le daremos sentido a este objeto:
35

Definamos un contexto de ejemplo
Supongamos ahora que nuestro sistema es mantenido por varios desarrolladores y que una parte del sistema es mantenida por un "estudiante de programacin" que decidi unilateralmente que cuando le llegue el objeto "unUsuario" le pondr siempre el nombre en maysculas y le colocar una clave por defecto si esta est vaca. Nosotros, como "desarrolladores experimentados", nos sentimos molestos por la tontera que acaba de hacer el "estudiante"... ahora la pregunta es, como evitamos que esto suceda?
Uno de los problemas aqu es que PHP4 no soporta la definicin del "alcance" (o tambin llamada "visibilidad") de los atributos y mtodos, algo habitual en cualquier lenguaje serio de tipo "Orientado a Objetos". Esto hace que -aunque no nos guste- el desarrollador de turno pueda hacer lo que quiera con los atributos de cualquier objeto a su alcance.
Migremos la sintaxis a PHP5

PHP5, consciente de este problema, implementa la definicin de "visibilidad" de los atributos y mtodos, como lo hara Java o .Net. Si hiciramos una migracin "mecnica" de nuestro cdigo, este cambiara la sintaxis a esta forma (ya que la sintaxis "var" pasa a desuso y esta defina a los atributos siempre "pblicos"):
Ahora disponemos de las siguientes opciones gracias a la nueva sintaxis: public, private y protected.
36

Ahora bien, si queremos que el "estudiante" no pueda modificar nuestros datos, podemos pasar a colocar todos los atributos como "private":
Listo, ahora cuando el "estudiante" quiera ver o modificar un atributo, el sistema le enviar un error. El problema ahora es que nosotros queremos que: 1. La edad se pueda saber y cambiar en todo momento. 2. Se pueda saber el nombre del usuario, pero no modificarlo 3. No nos interesa que se sepa el nombre real del mismo 4. Pero queremos que pueda colocar una nueva clave si el usuario se la olvida, pero no saber la que existe actualmente Esto no lo podemos hacer ni teniendo todos los atributos pblicos como suceda con PHP4 ni restringiendo toda la visibilidad como nos permite ahora PHP5. Cmo se hace entonces? Por un tema de principios de la POO los atributos de los objetos deben ser siempre "privados" (concepto "encapsulacin": no son accesibles desde fuera del objeto, solo el objeto tiene la potestad de usarlos directamente) y se debern crear mtodos pblicos que sustituya una u otra operacin, o ambas, cada vez que la situacin lo amerite: un mtodo "setter" para "cargar un valor" (asignar un valor a una variable) un mtodo "getter" para "retornar el valor" (solo devolver la informacin del atributo para quin la solicite).
Veamos cmo se resuelve, paso a paso.
37

Requerimiento 1
La edad se puede acceder y modificar en todo momento, por consiguiente se deben agregar los dos mtodos, un "get" y un "set" para ese atributo:
Pronto, ahora el atributo se puede consultar o modificar no directamente, solo a travs de los mtodos "get / set". En este caso no se nota la utilidad, pero pasemos al siguiente requerimiento.
Recordatorio Estamos usando el estndar de codificacin definido por la empresa Zend. Por ejemplo, los mtodos y atributos privados deben iniciar con _ y todas las llaves de mtodos y clases inician a la izquierda (ninguna otra ms, como un if, for, etc).
38

Requerimiento 2
Poder saber el nombre del usuario pero no modificarlo, para eso hay que agregar solo un mtodo get para ese atributo:
Ahora se puede consultar el nombre pero no modificar, pues el atributo no es visible desde fuera del objeto, solo a travs de los mtodos pblicos que vamos definiendo.
Requerimiento 3
No nos interesa que se sepa el nombre real del usuario Lo dejamos como est y queda inaccesible desde fuera del objeto.
39

Requerimiento 4
Queremos que pueda colocar una nueva clave si el usuario se la olvida, pero no saber la que existe actualmente Para eso, hacemos lo contrario que con el atributo nombre, agregamos un mtodo "set" pero no el "get":
Pronto, usando simples mtodos podemos reforzar el diseo de nuestro objeto, restringiendo segn nuestra necesidad el acceso a sus atributos.
40

Formalicemos: "Getter/Setter es solo un tema de conceptos"
Cuando empezamos a aprender a usar Objetos el primer error que cometemos es dejar todos los atributos pblicos, lo que permite que cualquier usuario de nuestra clase pueda hacer y deshacer sin control nuestro objeto (modificando y consultando sus valores). Generalmente nuestros objetos deberan contener determinada informacin que no necesariamente el usuario de nuestro objeto debera saber, porque no conviene, o porque directamente no corresponde y permitirle acceder a la misma es aumentar innecesariamente la complejidad del uso del objeto. Regla: "Evitar que el objeto muestre detalles de su implementacin" Por ejemplo: si tu sabes que tu objeto "Persona" tiene una fecha de nacimiento y calculas su edad, no deberas poder permitir que alguien "de afuera del objeto" cambie la edad, pues est relacionada con otra informacin (fecha de nacimiento) y a partir de ella es que se genera (calcularEdad()). Lo correcto sera modificar la fecha de nacimiento para que el propio objeto la vuelva a calcular. Los detalles del funcionamiento del objeto son internos, y el usuario del objeto (otro desarrollador u otro sistema) no debe ni necesita conocerlos. Por consiguiente ya tenemos otro caso claro, el atributo "edad" no debera poder ser modificado externamente, pero s consultado cada vez que se necesite. Si este fuera un atributo pblico sera imposible restringir una operacin y habilitar la otra. De ah que nace el concepto de "getter / setter", o de "mtodos accesores / modificadores", o como muchos autores se refieren a estos mtodos especiales como "propiedades" (pero creo que puede generar confusiones con el concepto "atributo", pues muchos otros autores usan las mismas palabras indistintamente). Si t colocas atributos privados, estos sern solo "vistos / accedidos / usados / modificados" dentro de la propia clase. Si tu quieres que puedan ser accedidos desde fuera de la clase, debes crear mtodos pblicos que internamente "accedan" a los atributos, pero que los dejarn "resguardados" dentro del objeto (no hay que olvidar que en un caso pueden hacer una operacin u otra, no necesariamente ambas).
41

Recalco, digo "nomenclatura", puesto que los nombres de los mtodos pueden llamarse como quieras, pero si cumplen con ambas definiciones (get/set), cumplir con la esencia de la funcionalidad. El tema es que, por convencin, se tiende a reconocer as a los mtodos que solo sirven para "hacer operaciones bsicas como si trabajramos con atributos pblicos", y que adems, no deben tener ms complejidad que la que describo.
42

Repasando conceptos de Clases y Objetos un poco ms profundo
Repasando un poco ms los conceptos y en vista a que estamos dentro del paradigma de orientacin a objetos, tiene sentido hacernos la siguiente pregunta: Qu es un Objeto? (Aunque ya hemos visto algo anteriormente) Desde el punto de vista del anlisis y diseo cualquier entidad tangible o visible del problema cualquier entidad que se pueda conceptualizar una entidad receptora de acciones
Desde el punto de vista de la programacin un objeto es una instancia de una clase. Preguntmonos entonces: Qu es una clase? Una clase representa un concepto discreto dentro de la aplicacin que se est modelando: una cosa fsica (avin), una cosa de negocios (pedido), una cosa lgica (horario), una cosa de una aplicacin (botn, ventana), una cosa del computador (tabla de hash), o una cosa del comportamiento (una tarea). La clase es una especificacin genrica para objetos similares. Para explicarlo en forma sencilla una clase se puede ver como un molde, que define la forma que tendrn los elementos que se creen a partir del mismo. Los objetos son los elementos creados a partir de un molde. A partir del mismo molde (clase) es posible crear muchos objetos, todos con la misma forma (las mismas caractersticas) pero cada uno con sus propios valores para estas caractersticas. La implementacin de una clase comprende dos componentes: la declaracin y el cuerpo de la clase. De esta forma, un objeto contiene toda la informacin que permite definirlo e identificarlo frente a otros objetos pertenecientes a otras clases e incluso frente a objetos de una misma clase Primero deberemos crear una clase antes de poder crear objetos o ejemplares de esa clase. Para especificar una clase es necesario especificar dos aspectos fundamentales:
43

Datos: Se debe determinar qu datos podrn almacenar los objetos de la clase. A cada uno de estos datos se lo conoce con el nombre de atributo o campo (field). Operaciones: Se describen los mensajes (operaciones) a las que sern capaces de responder todos los objetos creados de la clase. Cada operacin se implementa mediante uno o ms mtodos. Tpicamente, primero se declaran las variables miembro (Datos) de la clase y luego se proporcionan las declaraciones e implementaciones de los mtodos (Operaciones), aunque este orden no es necesario. Como estndar en general los nombres de clase siempre comienzan con mayscula, mientras que los nombre de variables y mtodos comienzan en minscula. Cuando son nombres compuesto se debe separar con una letra Mayscula en la primera letra de la palabra compuesta, el estilo de escritura de palabra compuesta se le conoce con el nombre CamelCase. De esta forma el nombre de una clase podra ser MiClaseDeUpperCamelCase y de un mtodo o variable miMetodoDeLowerCamelCase()
44

Tipos de Datos Primitivos
Normalmente los LPOO tienen una serie de tipos de datos primitivos que son parte del lenguaje, por ejemplo: int, double, char, etc. En la declaracin de una nueva clase se utilizan atributos de tipos primitivos o de otras clases del lenguaje definidas por el desarrollador.
Atributos o Variables de la clase

Como mnimo, una declaracin de variable miembro tiene tres componentes: el modificador de acceso el tipo de dato y el nombre de la variable, por convencin empieza con una letra minscula. Junto con el nombre, se pueden especificar la visibilidad de la variable, tipos de acceso son public, private o protected. Adems especificar si la variable es una variable de clase o una variable de ejemplar, y si la variable es una constante. Una declaracin de variable miembro define los siguientes aspectos de la variable especificadordeAcceso define si otras clases tienen acceso a la variable static indica que la variable es una variable miembro de la clase en oposicin a una variable miembro del ejemplar. const o final indica que la variable es una constante
Los mtodos
La implementacin de un mtodo consiste en dos partes, la declaracin y el cuerpo del mtodo. Los nicos elementos necesarios para una declaracin de mtodo son el nombre, el tipo de modificador de acceso o visibilidad y el tipo de dato del retorno. Respecto a la visibilidad del mtodo, los tipos de acceso son public, private o protected. Junto con el nombre del mtodo, tipo retorno y el modificador, la declaracin lleva informacin como el nmero y el tipo de los argumentos. Los mtodos utilizan el operador return para devolver un valor. Todo mtodo que no sea declarado como void debe contener una sentencia return.
45

Clasificacin de tipos de mtodos
Por convencin empieza con una letra minscula. Los mtodos se dividen en: Mtodos de instancia (aplicables a objetos) Mtodos de clase (aplicables a toda la clase) Mtodos de Construccin y Destruccin
Los mtodos de instancia son aquellos que se implementan para representar una operacin a la que cada objeto de la clase ser capaz de responder. Un ejemplo clsico de mtodos de instancia son los accesores y modificadores que ofrecen un mecanismo para obtener o modificar los datos almacenados por una instancia. Los mtodos de clase o estticos representan operaciones que se le pueden pedir a la clase (el molde) que ejecute, y no objetos en particular de la clase (por lo general todos los lenguajes orientados a objetos lo soportan), en UML van subrayados.
Modificador de Acceso
Uno de los benficos de las clases es que pueden proteger sus variables y mtodos miembros frente al acceso de otros objetos. En los LPOO (Lenguajes Programacin Orientado a Objetos) se pueden utilizar los especificadores de acceso para proteger tanto las variables como los mtodos de la clase cuando se declaran, soportan cuatro niveles de acceso para las variables y mtodos miembros: private, protected, public. public: Todo el mundo puede acceder al elemento. Si es un un dato miembro todos pueden ver el elemento, usarlo y modificarlo. private: Solo se puede acceder desde mtodos de la clase, o solo puede invocarse el mtodo desde otro mtodo de la clase. protected: Slo se puede acceder a las clases que se encuentran en el mismo paquete y desde las clase que la heredan.
46

En Resumen
Vimos cmo se representa el paradigma Orientado a Objetos ms all de crear objetos aislados que solo contienen datos, dando un profunda mirada a los distintos conceptos de la POO en PHP5.
Enva tus consultas a los foros!

Aqu es cuando debes sacarte todas las dudas haciendo consultas en los foros correspondientes
47

3 0 Disenio Orientado Objetos

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

3 0 Disenio Orientado Objetos

Caricato da

Copyright:

Formati disponibili

Curso: "Programacin Orientada a Objetos PHP5" 2012

Introduccin a Objetos Mdulo 3

Curso: "Programacin Orientada a Objetos PHP5" 2012

Curso: "Programacin Orientada a Objetos PHP5" 2012

Curso: "Programacin Orientada a Objetos PHP5" 2012

Principio 2: DRY - "No Te Repitas"

Principio 3: KISS - "Mantenlo Simple, Estpido!"

Principio 4: Estndar de Codificacin PHP / Zend

Curso: "Programacin Orientada a Objetos PHP5" 2012

Enfrentar la realidad con madurez

Curso: "Programacin Orientada a Objetos PHP5" 2012

Curso: "Programacin Orientada a Objetos PHP5" 2012

La culpa es enteramente nuestra

Curso: "Programacin Orientada a Objetos PHP5" 2012

Curso: "Programacin Orientada a Objetos PHP5" 2012

Curso: "Programacin Orientada a Objetos PHP5" 2012

Vacuidad: vaciar todos los conocimientos

Curso: "Programacin Orientada a Objetos PHP5" 2012

Lo ms importante es detectar los objetos

Curso: "Programacin Orientada a Objetos PHP5" 2012

Cmo Pensar en Objetos

Curso: "Programacin Orientada a Objetos PHP5" 2012

Curso: "Programacin Orientada a Objetos PHP5" 2012

POO segn los manuales

Curso: "Programacin Orientada a Objetos PHP5" 2012

Curso: "Programacin Orientada a Objetos PHP5" 2012

Curso: "Programacin Orientada a Objetos PHP5" 2012

Clases y Objetos (PHP 5) Tabla de contenidos

Curso: "Programacin Orientada a Objetos PHP5" 2012

Curso: "Programacin Orientada a Objetos PHP5" 2012

Sugerencias para enfrentar los diseos

Curso: "Programacin Orientada a Objetos PHP5" 2012

Los Objetos tienen Atributos, Comportamientos y Estados.

Curso: "Programacin Orientada a Objetos PHP5" 2012

Curso: "Programacin Orientada a Objetos PHP5" 2012

Cmo se debera leer este diagrama:

Curso: "Programacin Orientada a Objetos PHP5" 2012

Curso: "Programacin Orientada a Objetos PHP5" 2012

Curso: "Programacin Orientada a Objetos PHP5" 2012

Mi primer diagrama UML

Curso: "Programacin Orientada a Objetos PHP5" 2012

Curso: "Programacin Orientada a Objetos PHP5" 2012

Seccin #1 nombre de la clase

Seccin #2 los atributos de la clase

Curso: "Programacin Orientada a Objetos PHP5" 2012

Versin pragmtica en PHP

Curso: "Programacin Orientada a Objetos PHP5" 2012

Curso: "Programacin Orientada a Objetos PHP5" 2012

Curso: "Programacin Orientada a Objetos PHP5" 2012

Curso: "Programacin Orientada a Objetos PHP5" 2012

Curso: "Programacin Orientada a Objetos PHP5" 2012

Curso: "Programacin Orientada a Objetos PHP5" 2012

Curso: "Programacin Orientada a Objetos PHP5" 2012

El origen de la necesidad de los "set y get" para los atributos

Creo el objeto "unUsuario":

Curso: "Programacin Orientada a Objetos PHP5" 2012

Migremos la sintaxis a PHP5

Curso: "Programacin Orientada a Objetos PHP5" 2012

Veamos cmo se resuelve, paso a paso.

Curso: "Programacin Orientada a Objetos PHP5" 2012

Curso: "Programacin Orientada a Objetos PHP5" 2012

Curso: "Programacin Orientada a Objetos PHP5" 2012

Curso: "Programacin Orientada a Objetos PHP5" 2012