Cita:
Iniciado por lcervantes 
Las herencias me queda claro como implementarlas. "EXTENDS", pero las de dependencia, asociación y variantes... como se implementarían.
Como se haría en cualquier otro lenguaje que permita implementar POO, la forma es conceptual y no técnica.
Cualquier manual de POO o de UML lo explica, la asociación es simplemente construir un objeto a partir de otros, y eso se hace definiendo objetos en los atributos.
Por ejemplo, si decimos que una camioneta escolar está compuesta por un conductor y un asistente, podríamos hacer un diseño de esta forma:
Código PHP:
class CamionetaEscolar extends Auto
{
private $_conductor;
private $_asistente;
public function __construct($conductor, $asistente)
{
$this->_conductor = $conductor;
$this->_asistente = $asistente;
}
}
Y la forma de usarlo podría ser:
Código PHP:
$conductor = new Conductor('Enrique');
$asistente = new Asistente('Carlos');
$camionetaEscolar = new CamionetaEscolar($conductor, $asistente);
Borrador de un diseño UML para la Camioneta Escolar
La "relación de dependencia" (es una relación de "uso"), es decir, las únicas dos formas que existen es:
- Dentro de un método, recibir un objeto por parámetro
- Dentro de un método, crear un objeto
En ambos casos, "usas" un objeto, ya que lo necesitas, lo usas dentro de un método de tu clase, y luego de terminada la ejecución del método, se termina la vida del objeto "usado" (es una relación más débil que la asociación, por eso en UML se representa con una línea punteada).
En este caso, la conexión a la base de datos podría ser una relación de uso, instancias la clase Database, la usas, y luego muere. Digo "podría", pues dependerá el diseño que quieras hacer en el contexto que te encuentres.
Ejemplo del diagrama anterior pero con acceso a la clase Database Cita: En el caso del ejemplo que pone Nemutagk, la soclución a IOMConnect solo esta en cambiar ele nombre de la clases IOMConnect por otra que diga Database.?
No necesariamente está mal, pero me parece que la situación es redundante, crear una clase de abstracción de base de datos, entonces, para qué llamarle otra cosa que no sea "BaseDeDatos" o "Database".
Cita: Realmente aunque una no contenga la otra, eso siempre nos lo vamos a encontrar. Es decir, el poder realizar consultas SQL dentro de una clase. Como propones el poder hacerlo?
Separando las responsabilidades. No puede ser que todas las clases de tus sistemas conozcan todos los detalles de la persistencia, cómo se arman las consultas sql, etc.
Aquí se hace más claro cuando separamos nuestro sistema en 3 capas, donde cada clase de cada capa deberá resolver problemas de la capa correspondiente.
Si tenemos las capas presentación -> dominio -> persistencia, se puede decir que podría existir un representante en cada capa del tema que estás tratando de resolver.
Por ejemplo, si estamos hablando de Planetas, tal vez puedas tener para cada capa:
PlanetaPresentacion, PlanetaDominio, PlanetaPersistencia
Ejemplo de diagrama UML Nota: si quieren pueden cambiar PlanetaDominio por Planeta solo, aquí lo hago para diferenciar los nombres y como no hay manejo de paquetes / namespaces (bueno, sí hay pero en la versión PHP 5.3), tengo que poner cada clase con nombres distintos para que no colisionen.
La primer clase resolverá toda la interfaz relacionada con los Planetas, cuando necesite información de los mismos, se lo pedirá a la clase de Dominio, y si la clase de Dominio necesita información que se encuentra almacenada en la base de datos (u otro medio), de lo pedirá a la clase de Persistencia (donde esta última tendrá las consultas SQL y no en Dominio ni en Presentación).
Ejemplo rápido de lo que podría ser un sistema en 3 capas
Se ve más claro en una división de capas que teniendo todo en una capa, por eso parece que es imposible no tener sentencias SQL, ya que no dividen las responsabilidades correspondientes.
Nota: aunque no parezca, los ejemplos que hice fueron "rápidos" (usando
ArgoUML) y pude haber cometido algún error, si detectan uno o tienen alguna duda sobre algún punto me avisan que lo revisamos.
Creo que queda claro que "la única relación posible" no es la herencia y esta no se usa para usar código de forma mecánica
