Ejemplo 2 Persona Empresa POO-PHP

Hoy vamos a ver un ejemplo que tiene 2 clases en realidad dos clases separadas ya que no vamos a hablar de eso ya que es Analisis y Diseño orientado a objetos sera en otra ocasion , seguiremos viendo como trabajar POO con PHP.

La idea de cada tarea es aplicar y extender los conocimientos que se debieron haber adquirido con la lectura de los capítulos anteriores.

• A partir de las clases UML se deben generar siempre archivos aparte, por clase, con la nomenclatura Persona.php y no persona.class.php o persona.php (debemos usar el Estándar de Codificación de Zend)

• Las llaves “{}” van abajo solo en las clases y métodos, para ningún caso más, ni if, ni while, etc (estándar Zend)

• Los atributos y métodos privados deben llevar delante “_” (estándar Zend), por ejemplo: $_nombre, _hacerDigestion()

• Siempre realizar “exactamente” lo que se solicita (a menos que solicite explícitamente lo contrario), no más, debemos ajustarnos siempre a los requerimientos que nos solicitan (Principio KISS). Debemos evitar la “sobre-ingeniería” y extender la funcionalidad de una clase, aumentando innecesariamente su complejidad. En un proyecto, donde hay más de un desarrollador es importante que la arquitectura se mantenga “simple”, de lo contrario, cuando crezca, será más costoso mantener el sistema.

• Mi sugerencia es no hacer mucho uso de los _set y _get que incorpora PHP5, ya que en la mayoría de los casos –según lo que he leído en internet- debilitan los diseños al generar efectos de “atributos públicos”. No siempre lo genérico es bueno, como en este caso.

• Los atributos deben iniciar siempre en minúsculas, igual que los métodos

• No es necesario especificar el constructor del diagrama si este no aporta nada relevante.

Aplicación del “Principio KISS” “mantenlo simple estúpido”

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 límite.

Recuerda: un diseño está atado siempre a un contexto, si cambia el contexto, muy probablemente deberá cambiar el diseño. No existen diseños que sirvan para absolutamente todos los contextos posibles, por lo tanto, es recomendable hacer un diseño concreto para un contexto concreto.

Sugerencias para enfrentar los diseños

En general, tratar de:

• Empezar a pensar el diseño a partir de los objetos de más bajo nivel (los más 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 diseñen una clase, “pararse literalmente sobre ella” razonando qué es lo que debería ver o conocer esta, sin entrar a pensar qué es lo que deberían hacer las demás clases. Tan importante como diseñar qué hacen es entender qué no deberían hacer.

• Seguir el principio de diseño OO: “Una clase, una única responsabilidad”, si tiene más de una responsabilidad, debe estar haciendo más de lo que le corresponde, y deberá descomponerse en otra clase.

• Finalmente, con él o los objetos de más alto nivel, empezar a interactuar con los objetos de más bajo nivel, sin interesar cómo están construidos por dentro y qué hace su código interno; solo hay que tomar los objetos y pedirles la información o el comportamiento que necesitamos de ellos (“interfaz pública”).

• Y el más importante de todos, Mantener un “Diseño Simple” en todos los sentidos, evitar complejidad innecesaria. Por ejemplo, puedes tomar la siguiente métrica: si un método no se puede visualizar en una sola pantalla, hay algo que evidentemente está mal y hay que descomponerlo en varios métodos (refactoring), etc.

Bien ahora vamos a ver en si el ejercicio de que se trata de dos clases una que representa a una persona y otra a la empresa lo que buscamos en este ejemplo no es una relacion entre clase y nada de diseño de clase sino que veamos la sintaxis basica de la POO en php y veamos un ejemplo sencillo pero claro.

Bien las clases son estas:

Persona.php
Esta clase solamente asigna los valores predefinos a las variables privadas de clase para luego invocar ese metodo.

Empresa.php
Esta clase es un poco diferente ya que en ella hacemos uso de mas metodos a los cuales invocaremos desde el index php

Hacemos un require para las dos clases y las instanciamos con new y mandamos a llamar la clase con su metodo y tenemos un resultado como el siguiente.

Bien hasta aca hemos visto lo basico de la programacion orientada a objetos como crear una clase declarar atributos en sus visibilidades como private public protected que son las que soporta php tambien la declaracion de un metodo publico y las instancias que hay que crear para llamar a la clase junto con la llamada al metodo.

Descargar

comenten no sean bayuncos