Solución Semana 4: "Sistema Modular" (III de V)


El punto III de los requerimientos de la Semana 4 decía:

"Clases Abstractas: hacer una lista de todas las clases que no son necesarias instanciarlas en el sistema y que deban ser "abstractas". Explicar la implementación, justificar la selección y la razón de esta decisión."

Veamos algunos conceptos, tenemos la definición de lo que es una Clase Abstracta según Wikipedia:

Clase Abstracta

La herencia permite que existan clases que nunca sean instanciadas directamente. En el ejemplo anterior, una clase "perro" heredaría los atributos y métodos de la clase "mamífero", así como también "gato", "delfín" o cualquier otra subclase; pero que ocurra que en el sistema no haya ningún objeto "mamífero" que no pertenezca a alguna de las subclases. En ese caso, a una clase así se la conocería como Clase Abstracta. La ausencia de instancias específicas es su única particularidad, para todo lo demás es como cualquier otra clase.

También tenemos la explicación técnica según el manual oficial de PHP:

No es permitido crear una instancia de una clase que ha sido definida como abstracta. Cualquier clase que contenga por lo menos un método abstracto debe también ser abstracta. Los métodos definidos como abstractos simplemente declaran el método, no pueden definir la implementación Cuando se hereda desde una clase abstracta, todos los metodos marcados como abstractos en la declaración de la clase padre, deben de ser definidos por la clase hijo; adicionalmente, estos metodos se deben definir con la misma o menor visibilidad.

Bien, ya tenemos los conceptos técnicos definidos, ahora la pregunta sería... ¿cómo las uso? ¿para qué las uso? ¿cuando las uso?

Las estrategias para usarlas, donde usarlas, son:

Solo sirven para ser heredadas por otras clases o para usarlas sin instanciar.

En el primer caso podemos usar la clase como un esqueleto o un molde que permita solo ser heredada con el argumento de que es tan genérica que es poco probable que se use directamente. Por consiguiente siempre heredaremos de ella, como la clase Persona, para crear objetos más especializados como la clase Usuario. Es poco probable que nuestros sistemas necesiten una clase Persona de forma directa, pero sí la usaremos como molde para crear UsuarioAdmin, UsuarioOperador, etc.

En el segundo caso una clase que no tiene atributos, que sirve como "fachada" para esconder otras clases, por consiguiente no tiene sentido que sea instanciada y se puede usar directamente como una clase, ejecutando sus métodos. También podría ser una clase que sirva de "herramienta genérica" que agrupe un conjunto de funcionalidades que usaremos de manera aislada del resto del objeto. Por ejemplo, podríamos tener una clase Fecha que solo tuviera métodos que reciben valores y luego procesan los resultados, sin necesitar atributos para la clase.

Por eso todas las "fachadas" (Patrón Facade) son generalmente abstractas.

Nota: como no hace falta instanciar la clase para invocar un método, creo una clase "abstracta" y ejecuto directamente la clase e invoco su método, evitando crear una instancia, con la ventaja de tener menos código y no reservar memoria para una variable. La otra ventaja, menos visible pero más importante, es que al obligar por código a hacer que la clase sea abstracta estamos reforzando el diseño de nuestro sistema (nadie podrá usar esa clase de forma directa, evitando un error de desconocimiento por parte de los desarrolladores)

¿Qué se pedía en la letra del problema?

El sentido del requerimiento para esta parte era que buscaran clases que fueran candidatas a convertirse en abstractas basándose en la forma de uso o en que directamente no tenían atributos propios, solo un conjunto de métodos que ofrecen una funcionalidad concreta en cada uno de ellos.

Rápidamente podemos concluir que donde se podría pasar a clases abstractas sería en la Capa de Presentación y las clases claramente candidatas son:
  • ConsultarUsuario.class.php
  • ListadoDeUsuarios.class.php
  • MostrarUsuario.class.php
Las tres clases hacen cosas muy concretas y no necesitan tener atributos, perfectamente podrían trabajar de la siguiente forma:

ConsultarUsuario::ejecutar();

En vez de:

$ConsultarUsuario = new ConsultarUsuario();
$ConsultarUsuario->ejecutar();


¿Y la clase Index?

Sí, tal vez, actualmente no tiene mucho sentido pues aunque existen dos atributos (título y texto), perfectamente podría evitarse y pasarlos por parámetros directamente al método ejecutar.

¿Y las clases BaseDeDatos y Persona (ambas del framework)?

Estos últimos casos son una decisión de diseño ajustada a un contexto, donde deberemos pensar qué es lo que queremos desarrollar dentro de esta clase y cómo trabajará nuestro sistema. Por el momento no es tan evidente como los casos anteriores, así que no necesariamente esta clase deberá ser abstracta.

Ya está la planilla actualizada, como así también el repositorio con los fuentes y como siempre, en los comentarios de esta entrada se pueden sacar las dudas sobre este tema :-)

Taller: El lunes 23/4 inicio el armado de los equipos de desarrollo

Van dos semanas desde el retorno de la Semana Santa y aún estoy tratando de recuperarme del trabajo que tengo pendiente, el trato con empresas, universidad, proyectos, familia, salud, etc. Suerte que soy histérico, inquieto, con exceso de adrenalina, workaholic, duermo poco, mi esposa e hijas se duermen temprano... pero indefectiblemente me he dado cuenta que es imposible estar en varios lugares a la vez (lamentablemente).

Así que no queda otra que 1) organizarse 2) priorizar 3) delegar 4) asignar prioridades 5) controlar 6) ajustar 7) volver al punto 1)

En el cronograma de mi Taller On-line que empezamos juntos tengo pendiente terminar de publicar las soluciones del último desafío ("semana4") y empezar a trabajar en el armado de los grupos de trabajo, que sucederá el próximo lunes 23 (lindo número ;-)).

A partir de la creación de los grupos se definirán los líderes y su equipo de desarrolladores, con una misión para cada grupo y otra común para todos.

Esto no terminó... recién empieza! ;-)

"Oferta de trabajo para UK desde España"


En el día de ayer recibí un correo de la consultora Cátenon (Spain) donde me preguntaba si en mi círculo de contactos podría tener a alguien que le interesara un trabajo con las siguientes características:
  • "El cliente desarrolla y comercializa productos de entretenimiento para móviles . Ellos son una transnacional de capital español y presencia en 31 países. "
  • Buscan "una posición de marketing webmaster en Uk. Se trata de un profesional que pueda hacer seguimiento al mercado de pantallas y sonidos para móviles y proponer el diseño, contenido y mejores prácticas en las páginas web/comerciales de la empresa."
  • Conocimientos: "mercado de móviles /celulares y conocer WEB 2, PHP, RSS, XML,……para que pueda entenderse con los programadores. Debe dominar el Inglés y poder trabajar en UK ( alguien con nacionalidad europea)"
Por más información, contactarse con Maria Artiles de Cátenon Worldwide Executive Search.

<disclaimer>No tengo relación alguna y menos responsabilidad por lo que suceda posteriormente con la empresa</disclaimer>

Faltan 20 días, cursos de actualización profesional (actualización 22hs)


Actualización (22:00): Me confirmaron a último momento que la fecha de apertura de *todos los cursos* se movió para el 3 de mayo (dentro de 20 días).

Parece que la "Semana Santa" enlenteció las inscripciones y hay interesados para los cursos pero muchos argumentan que no pueden anotarse este mes, razón por la cual se mueve la fecha de inicio para el mes siguiente.


Faltan tan solo 5 días 20 días para dar inicio al curso corto de alta especialización y actualización profesional que se dictará en la Universidad ORT sobre el desarrollo de sistemas web, Orientado a Objetos y con el lenguaje PHP5 (más información en mi blog personal).

Ya está abierta la posibilidad de contratar el curso "in-company" y hacer ajustes del temario según la necesidad de cada empresa o proyecto. Todavía está en estudio alguna invitación que he recibido para armar charlas o seminarios sobre estos temas en otros países, pero cada caso deberé estudiarlo de forma individual.

Por lo pronto a corto plazo en la Universidad ORT la semana el mes que viene y en empresas, a mediano plazo charlas tanto fuera de Montevideo (capital) como del país (Uruguay).

Solución Semana 4: "Sistema Modular" (I y II de V)

Retomando la publicación de soluciones al desafío planteado para la Semana4, lo que se solicitaba en este requerimiento era:

Sistema modular: centralizar las invocaciones que puedan venir únicamente a través del index.php y no del resto del sistema. Solo se ingresa por index.php y luego a los módulos correspondientes. Evitar el acceso por cualquier ruta distinta a index (concepto "web modular").

Aquí casi puedo resumir la respuesta enlazando un muy buen artículo hecho hace unos cuantos años por mi estimadísimo colega Pablo Rigazzi (ZonaPHP, alias Webstudio en Forosdelweb) llamado: Creando Webs Modulares

Los cambios que deberíamos hacer:
  • index.php - agregarle la posibilidad que procese invocaciones de parámetros a través de la url (método "get") así ir llamando por el nombre del módulo a cada parte del sistema, siempre entrando por el index.php, por ejemplo index.php?m=listado_usuarios.
  • listado_usuarios.php - este fuente funcionaría sin problemas si es requerido desde el index.php, pero vamos a hacer algunos cambios ya que ahora buscaremos que todas las invocaciones entren por el index.php. Cambiamos el nombre del archivo por la nomenclatura de clases ListadoUsuarios.class.php, sacamos toda ejecución automática dentro de la clase, y ahora esta va a funcionar dentro de index.php. Aunque se intente acceder a ella, no ejecutará nada de forma independiente. Y para terminar de ordenar la estructura vamos a mover esta clase al paquete "presentación", pues esa es su función.
  • consultar_usuarios.php - el procedimiento es exactamente igual que el caso anterior.
  • mostrar_usuario.php - aquí es un poco más complejo, pero nada qué asustarse. Justamente este fuente es el primero que recibe verdaderamente un parámetro además del nombre del módulo (id del usuario). Lo que hay que hacer es pasar el array entero $_GET ó $_POST al método de la nueva clase MostrarUsuario.class.php que estará alojada en el subdirectorio o paquete "presentación".
  • menúes - no hay que olvidar actualizar los templates (sitio_menu.tpl.html) para que dejen de apuntar a listado_usuarios.php y consultar_usuario.php desde la raíz y pasen a usar invocaciones a los nombres de los módulos directamente: index.php?m=listado_usuarios
Si queremos ser muy prolijos y ayudar a que puedan seguir mejor los cambios implementados -¿para eso sirve la documentación, o no?- les presento cómo quedaría ahora nuestro diagrama de paquetes:

No necesariamente esta solución propuesta es la única existente ni la mejor, pero de forma simple ejemplifica la esencia del desafío y el concepto que se quiere transmitir.

En breves momentos estará actualizado el fuente del proyecto "surforce-proyectobase" para que puedan bajarlo y estudiar el funcionamiento del mismo.

PD: ya está la planilla con los puntos ganados.

Trabajos recibidos con el desafío de la "Semana 4"

Está disponible la planilla pública con todos los trabajos recibidos con las soluciones del desafío de la "Semana 4" titulado "Modularizar el Sistema". Ya puedo ver que quedaron por el camino 6 participantes, pasamos de contar con 19 en la Semana 3 y ahora son solo 13 trabajos entregados (chicos, chicas, ¿que les está pasando?).

Tengo que publicar primero mi versión ampliada que servirá como referencia para evaluar vuestros trabajos, espero terminarla en el correr de las próximas horas y mañana culminar con la evaluación individual.

Luego de cerrada esta semana haré los anuncios correspondientes sobre el inicio de la segunda parte del taller: armar pequeños equipos de desarrollo con un líder a cargo y encomendarles sistemas para desarrollar en equipo. Espero que sea la parte más entretenida y desafiante del taller. ¿Más? sí, siempre hay más... no se quejen, con todo el entrenamiento sufrido los veo ahora mucho más preparados para trabajar en equipo que al principio... aunque ustedes no se den cuenta .

Espero que esta segunda etapa les transmita otro poco de conocimientos sobre desarrollo de sistemas orientados a objetos con PHP5. Hay un montón de temas para profundizar en esta área, pero por lo menos dimos los primeros pasos.

Más novedades en las próximas horas. ;-)

Cerrada la "Semana 3" del taller

Recién concluí con la corrección de todos los trabajos recibidos. Veo que tuvieron mejor desempeño cuando hubo trabajo de codificación, aunque también es claro que los trabajos llegaron más incompletos que en los desafíos anteriores.

De todas formas creo que lo más valioso no es si sacamos más o menos puntos, es de aplaudir el compromiso y el esfuerzo por intentar superar cada uno de los desafíos y entender lo que se aprende al comparar lo que uno hizo con los trabajos de los demás participantes, además de un resumen final con mi versión extendida de la solución esperada.


Todos los puntos que fui dando de acuerdo a mis correcciones pueden ser discutidos. Aunque no es algo que le de extremada importancia a la acumulación de puntos, están en todo su derecho de sacarse las dudas y verificar si he cometido errores de apreciación.

Verdaderamente los felicito por haber llegado hasta donde llegaron, que los "puntos bajos" o los "sutiles errores" en algunos casos no los debilite, todo lo contrario, son una guía para reforzar los lugares donde debemos hacer más hincapié.

En las próximas horas seguiré con los trabajos de la Semana 4

Errores de la Semana 3: no interpretaron los diagramas UML

Pensé que los diagramas iban a ser reveladores, pero creo que "no vieron más allá de lo evidente". Si analizan tranquilamente el diagrama que muestra la corrección de las 3 capas se visualiza la representación de cada módulo como si fuera una clase, documentando además que existen para cada nueva clase un método llamado "ejecutar" que no retorna "nada" (void).

Debajo de la imagen decía la leyenda
"Diseño corregido, lo que se solicita implementar".


Cada "rectángulo" en UML es un clase, y cada representación de nuestro diagrama es el mapa de lo que deben implementar los desarrolladores, siempre. Pensé que la pista de definirles los métodos iba a ayudarlos.

No se olviden, la "comprensión lectora" es muy importante, y saber interpretar la documentación es fundamental. Siempre estuvieron los comentarios en cada entrada del blog para hacer consultas, pero veo que a todos se les pasó por alto este "detalle no menor".

Espero que en los próximos desafíos le dediquen más atención y tiempo a analizar los problemas, o vamos a tener muchas "bajas" cuando empecemos a desarrollar en equipo (este tipo de problemas son graves para la subsistencia de un proyecto).

Sigo corrigiendo y sacando conclusiones.

Empecé la corrección de la Semana 3


Estoy en este momento empezando a corregir los trabajos recibidos de los 19 valientes que fueron quedando vivos desde el inicio del taller piloto de PHP5. Podrán ver los avances a través de los cambios que se visualizan en la planilla electrónica pública, donde voy agregando los puntos de cada trabajo y comentarios si corresponden en cada uno de ellos.

Desde ya les voy comentando que veo un error muy común en todos, y acentuado en esta etapa del taller (asumo que debe ser la falta de tiempo): sus trabajos son difíciles de entender, no se han tomado el tiempo suficiente para simplificarlos, aclararlos, quitarles complejidad innecesaria.

Consejo

Para cualquier trabajo en la vida, hasta cuando hacemos un currículum vitae: si quieren ser tenidos en cuenta, leídos, evaluados, no descartados de entrada, dediquen un buen tiempo para facilitarle el trabajo a su evaluador, a su contraparte. Si estamos hablando de un gerente, sin tiempo y con mucho material para leer, corren el riesgo de ser mal entendidos o directamente desechados.

No corran ese riesgo, la suerte ayuda a quién está preparado, no esperen que sus escritos, informes, trabajos, serán considerados buenos por su extensión. Ayuden a sus lectores.

Novedades entre hoy y mañana

Estimados todos:

Gracias por los emails, no he renunciado al taller ni mucho menos. Estas últimas dos semanas fueron bastante complicadas para mi, se juntaron la gripe, fiebre alta, dolor de garganta, antibióticos, inicio de las clases en la universidad y luego una recaída de la gripe, tos, lo cual me genera mucho cansancio.

También al retornar de mi licencia he tenido mucho trabajo por concluir, además de compromisos y reuniones que tenía pendientes con empresas.

Actualmente estoy bastante mejor, pero los últimos días me han impedido ponerme a trabajar de noche, en las horas que soy más productivo, así que estoy atrasado con:
  • El resumen de los puntos obtenidos por el desafío de la Semana 3
  • El resumen de trabajos recibidos para el desafío de la Semana 4
  • El resumen de los punto obtenidos por el desafío de la Semana 4
  • Y definir los pasos a seguir con el taller de ahora en más.
Por suerte aquí en Uruguay tenemos una casi semana de descanso con la Semana Santa lo que me permitirá ponerme al día con el atraso.

Desde ya les voy confirmando que tengo decidido:
  • Dar por terminado los desafíos y pasar inmediatamente al armado de los grupos de desarrollo con un sistema concreto para cada uno. Tengo algunos puntos a resolver pues las pruebas que he hecho con los líderes no han salido muy bien.
  • Habilitar el registro de nuevos usuarios para ver de incorporar nuevos grupos, tarea que se hará con una evaluación previa (que buscará suplir de alguna forma todas las evaluaciones que se han hecho a los restantes participantes). Corregir este sistema fue una tarea asignada a un grupo de líderes para hacer una prueba anticipada de trabajo en equipo, pero esta tarea nunca culminó.
  • Poner una fecha fin del taller, todo tiene que tener un fin para poder sacar conclusiones al respecto y ver cómo proseguimos luego de concluido. Si se harán grupos de desarrollo permanentes sobre un sistema en particular para que quienes quieran seguir aprendiendo puedan incorporarse, o armar con esta experiencia nuevos talleres temáticos, no solo de PHP (puede ser sobre Ajax, RoR, etc), que podrán ser algunos gratuitos y otros cobrando para garantizar dedicación y calidad de los dictados y los materiales, etc.
Bueno, sigo tomando los antibióticos y sonándome la nariz, y volveré a trasnochar para terminar mis tareas pendientes.

Saludos a todos ;-)

Entradas populares