Saber qué métodos pertenecen a qué clases

[xberni]

Muy buenas. Mi consulta es más bien de concepto de OO, que de php puramente, pero no he encontrado otro foro más adecuado, y ya que la aplicación que estoy montando es en php lo posteo aquí.

Tengo problemas en decidir qué métodos son propios de qué clase. Por ejemplo imaginemos una aplicación de comercio electrónico, en la que los productos se organizan de manera típica: productos, que se agrupan en categorías o tipos de productos, que estos a su vez se agrupan en tiendas. Es decir, y resumiendo mucho, tres clases: tienda - categoría - producto.

Entonces, para obtener las categorías de una tienda, a mi se me ocurre tener un método tal que así:

Código PHP:

  $tienda->getCategorias(); 
   

Y para obtener los productos de una categoría, algo así:

Código PHP:

  $categoria->getProductos(); 
   

En otros sitios he visto otras soluciones, como tener clases llamadas ConjuntoCategorías, y ConjuntoProductos, y tener métodos tales como:

Código PHP:

  $conjuntoCategorías->getCategoriasPortienda($tienda) 
   

Código PHP:

  $conjuntoProductos->getProductosPorCategoria($categoria) 
   

Quisiera saber si las dos soluciones son igual de buenas o no, igual de correctas desde un punto de vista OO, y sobretodo si hay alguna regla para poder efectuar estas decisiones de la manera más correcta posible.

Muchas gracias

[rodrigo_00]

Las clases $conjunto... no las veo necesarias, yo haria

Código PHP:

  $categoria->getProductos();  
$categoria->getProductos($categoria); 
   

Si envias la categoria entonces devuelves los productos de esa categoria, sino devueltes todos

lo mismo con las tiendas

[GatorV]

Son iguales los dos, la única diferencía es que una es llamada usando el conjunto, e internamente en tus clases tienda y producto puede ser algo así:

Código PHP:

public function getCategorias()
{
          $conjuntoCategorias = new Conjunto_Categorias();
          return $conjuntoCategorias->getCategoriasPorProducto($this);
}
 

Saludos.

[enriqueplace]

Que tal xberni

La verdad que te sugiero siempre discutir diseños usando UML más que código (si no sabes UML, es un buen momento para empezar ).

Sobre diseños con clases de tipo ConjuntoCategorías, si bien lo he visto (en aplicaciones complejas de mundos Java), considero que son distorsiones de una representación de la realidad que no existe... es decir, lo más natural (pensando en POO puro) es tu primer propuesta, lo otro, no existe en tu "realidad", el "conjunto" se arma "conceptualmente", pero no a través de una clase de tipo "Conjunto".

De todas formas, hay momentos que no queda otra forma que aplicar este tipo de clases "ficticias", pero si no llegaste a esa situación comprometida (aún los diseños son simples, o intentas siempre que sean simples), evita ese tipo de clases (en lo personal las evito siempre).

Prefectamente tu "conjunto de categorías" se representa con una colección (array) de objetos de tipo Categoría.

No se si quedó clara mi explicación, cualquier cosa me vuelves a preguntar.

Saludos!

[xberni]

Antes que nada, gracias a todos por las respuestas, especialmente a enrique por su excelente explicación.

Algo sé de UML (lo que he estudiado en la universidad), aunque se me haría difícil formular una pregunta sobre UML aquí, sin poder dibujar los "cuadraditos" y las relaciones entre ellos. Como hasta ahora no he trabajado 'a la POO', pues me apaño mejor con el modelo Entidad/Relación de las bases de datos.

Me ha quedado clarísima tu explicación, y abundando en la misma quería hacer otra pregunta:

Para modelar un objeto, por ejemplo "Producto" en este caso de la tienda, y para intentar hacerlo multiidioma tengo 2 relaciones:

- producto (id, precio, etc)
- producto_descripcion (id_producto, id_idioma, descripcion_corta, descripcion_larga, etc etc)

Me pregunto cual es la manera más "correcta" desde el punto de vista OO:

1) Tener 2 clases, Producto y DescripcionProducto (con los atributos y métodos de su tabla relacionada: getId, getPrecio en la primera, y getDescripcionCorta, getDescripcionLarga, etc lara la segunda clase)
2) Tener una única clase Producto que reuna todos esos métodos en una clase, y que trabaje con las dos tablas, relacionándolas con sus joins respectivas, etc

Hace unos meses estuve estudiando Symfony (sin demasiado éxito, era un poco exigente para mi nivel iniciado), y reconozco que estoy un poco influido por la manera que tenía de mapear las relaciones a objetos (a través del ORM Propel creo recordar), generando una clase por relación, y también las clases "ConjuntoDeX" o "Peer" que comentaba en mi primer post. Es decir, para las dos relaciones que menciono anteriormente, Symfony me hubiera creado 4 clases:

- Producto
- ProductoPeer (o conjunto de productos)
- DescripcionProducto
- DescripcionProductoPeer (conjunto de...)

Gracias por anticipado

[SergeMedina]

Yo crearía una clase Producto que reuniera todas las características de un producto, creo que es lo mas correcto.