planificar clases php para crear blog

[trevol]

Hola amigos, deseo crear un blog en php y tenerlo hecho con clases para cada vez que quiera hacer otro solo tenga que llamar a los métodos adecuados después de crear base de datos(reciclar código). La cosa es que no se como planificar el proyecto sobre todo como dividirlo en clases. Alguien que haya pasado por la experiencia me podría orientar por favor. Gracias, no quiero que se me ayude mucho, pero algunos ejemplos estarían bien, ya se que no hay una respuesta única y que yo voy adaptar mi forma de trabajar al proyecto. Gracias.

[opzina]

puedes pensar algo bien sencillo como para luego poder escalarlo.

Quizás te ayude mucho hacer un brainstorm, ideas sueltas.

un blog básico, usuarios, post, categorías.

puedes crear la clase Persona, Post, Categoría y definir atributos y métodos.

[trevol]

Gracias opzina, el tipo de dudas que se me plantea es por ejemplo: creo la clase persona, la clase post, la clase categoria. o por ejemplo creo la clase persona, la clase post y la clase clase categoria en vez de una clase la pongo como atributo de la clase post. Entonces tengo dos clases en vez de tres.

[_Ruben_]

Iniciado por trevol

Gracias opzina, el tipo de dudas que se me plantea es por ejemplo: creo la clase persona, la clase post, la clase categoria. o por ejemplo creo la clase persona, la clase post y la clase clase categoria en vez de una clase la pongo como atributo de la clase post. Entonces tengo dos clases en vez de tres.

Las 2 clases y el atributo que planteas ahí es un error de diseño de clases, eso se aprende con práctica y más práctica.

Te recomiendo empezar por crear la estructura de la base de datos (bien hecha) y el resto te saldrá solo.

Ejemplo:
De la categoría debes guardar el id y el nombre (como mínimo). ¿Cómo guardas 2 datos en una sola variable (el atributo)? Se deduce que debes guardarlo en una tabla, y si lo guardas en una tabla (tabla categorias, por ejemplo) entonces debes crear una clase para las categorías.

[opzina]

Es verdad, empieza por la base de datos. Y empieza por algo sencillo.

Piensa en un blog básico, luego, si lo necesitas y si funciona, vas a poder ampliarlo y mejorarlo.

Por ejemplo:

Código PHP:

// Clase Categorias:
 
class Categoria {
 
//Atributos;
 
private $nombre;
private $slug;
private $descripcion;
 
 
//Metodos
 
public function __construct($categoria, $ficha, $detalles) 
{
$this->nombre = $categoria;
$this->slug = $ficha;
$this->descripcion = $detalles;
}
 
public function getCategoryName() 
{
return $this->nombre;
}
 
public function getCategorySlug() 
{
return $this->slug;
}
 
public function getCategoryDescription() 
{
return $this->descripcion;
}
 
} // FIn clase Categorias.
 
 
Esto es muy sencillo y no estamos cambiando el estado de las categorias y hay que relacionarlo a una base de datos y al blog en general....
 

[trevol]

De la categoría debes guardar el id y el nombre (como mínimo). ¿Cómo guardas 2 datos en una sola variable (el atributo)? Se deduce que debes guardarlo en una tabla, y si lo guardas en una tabla (tabla categorias, por ejemplo) entonces debes crear una clase para las categorías.

Pero yo creo que no es así, ya que categoría puede ser un campo de la clase post y asi me ahorro una clase. No creeis?

[Dany_s]

y con ese campo como obtenés el id o una descripción de la categoría? por ejemplo


por eso te dieron un ejemplo de una clase Categoria qur tiene id, slug u descripción y tu clase Post va a tener un atributo categorias que va a contener un objeto categoría o una colección de objetos Categoria según como lo definas.

Un post tiene una categoria (o varias), tiene un autor y comentarios.
Con eso ya identificás 4 objetos

[_Ruben_]

Iniciado por trevol

Pero yo creo que no es así, ya que categoría puede ser un campo de la clase post y asi me ahorro una clase. No creeis?

El objetivo no es tener el menor número de clases posibles, sino que esté bien diseñado y en el futuro hacer cambios sea muy fácil.

Imaginemos que en principio los post solo tendrán una categoría, puedes ponerlo en un campo en la tabla de post y ya está.

Pero el día de mañana quieres que los post tengan varias categorías, las categorías descripciones, también subcategorías, y todo lo que se te pueda ocurrir.

A nivel de base de datos implementar esos cambios teniendo un campo en la tabla post que identifica la categoría es muy costoso (piensa bien que cambios tendrías que hacer).

Pero si de entrada tienes una tabla categorías con una relación muchos a muchos con la tabla post introducir esos cambios es muy sencillo (piensa también que cambios tendrías que hacer).

Compara los cambios en un caso y en otro, verás que la diferencia es tanta que optarás por tener una tabla categorías.

[trevol]

Pero el día de mañana quieres que los post tengan varias categorías, las categorías descripciones, también subcategorías, y todo lo que se te pueda ocurrir.

En ese caso es mejor optar por una tabla categoría. Pero necesariamente tendría que hacer una clase categoría?

[trevol]

y con ese campo como obtenés el id o una descripción de la categoría? por ejemplo

el id del post. Podría ser en el caso de que a cada post le correspondiera solo una categoría en caso de que no, posiblemente seria mejor optar por una tabla para las categorías.

[Dany_s]

Iniciado por trevol

el id del post. Podría ser en el caso de que a cada post le correspondiera solo una categoría en caso de que no, posiblemente seria mejor optar por una tabla para las categorías.

id del post? no entendí

Si querés hacer una lista de categorías para un menú de donde le vas a sacar? de los Post? que tiene que ver los Post con las categorías?

[_Ruben_]

Iniciado por trevol

En ese caso es mejor optar por una tabla categoría. Pero necesariamente tendría que hacer una clase categoría?

¿Como gestionas la información de cada categoría? Con una clase puesto que es un objeto independiente.

De todas formas, una tabla supone crear una clase, eso es de libro (excepto tablas de relaciones muchos a muchos).

[trevol]

¿Como gestionas la información de cada categoría? Con una clase puesto que es un objeto independiente.

pues con un método en la clase post. que sea mostrar categoria. Por ejemplo. o editar categoria por ejemplo. Todo sin salir de la clase post.

[Dany_s]

Vas a tener una clase que se va a encargar de 2 cosas: manejar la información de los post y de las categorías siendo que cada que cada clases debe tener una sola responsabilidad.


Fijate de hacerlo de las 2 formas y vas a sacar tus conclusiones sin siquiera leer sobre principios de oop

otra es que si queres que post se encargue de las categorias de esa forma evito crear una clase categoria entonces que post maneje tanto categoría como autor asi... asi evitas crear también la clase autor o usuario? porqué no pensaste así para el autor del post?

[_Ruben_]

Iniciado por trevol

pues con un método en la clase post. que sea mostrar categoria. Por ejemplo. o editar categoria por ejemplo. Todo sin salir de la clase post.

Por poder puedes gestionarlo todo con una clase pero eso no es correcto, está mal.

Yo podría usar la clase usuario y en ella gestionar todo: post, categorías, datos del usuario, etc etc ¿es correcto tener una sola clase que lo haga todo? Para nada.

Si no es correcto que la clase usuario gestione los post, ¿por qué si lo es que la clase post gestione las categorías?

Si haces un método para mostrar la categoría ¿cómo obtienes todas las categorías? Dirás que leyendo todos los post y obteniendo su categoría. Imaginemos que tienes 10 millones de post en 10 categorías ¿cuanto tardarías en obtenerlas? De la otra forma en lugar de recorrer 10 millones de registros recorres 10, una diferencia importante ¿no? Llegamos a la conclusión de que gestionar las categorías en la clase post no es escalable (definición de escalabilidad). Una solución no escalable es incorrecta.

No se trata de decir "es que yo voy a tener pocos post", si quieres hacer las cosas bien te servirá tanto para pocos post como para millones. No hay que evaluar el mejor caso, sino el peor.

Para que lo veas mejor, te lo pongo con pseudocódigo:

Código:

listaPost = Post->obtenerPosts()
for (i=0; i<listaPost->length; i++)
   listaPost->mostrarCategoria()

Este sería el ejemplo (aproximado, para nada real) para mostrar todas las categorías. Aun tendrías que almacenar las que se muestran para no mostrarlas 2 o más veces.

Código:

listaCategorias = Categorias->obtenerCategorías()
for (i=0; i<listaCategorias->length; i++)
   listaCategorias->mostrarCategoria()

Este haría lo mismo pero teniendo clase categoría, en este no tendrías que llevar un control de las que muestras o no.

¿Para que quieres mostrar todas las categorías? Puede que te interese mostrarlas para que el visitante de la web haga clic en una de ellas para leer solo los post de esa categoría.

Claro que podrías crear un método que devolviese solo las categorías sin repetirse. Bien, ¿cómo sería esa sentencia SQL? Algo así:

Código:

SELECT DISTINCT categoria FROM post

Vamos a evaluarla, si tienes 10 millones de post se comprobarán los 10 millones de registro en base de datos, cuantos más post más lenta será la sentencia.

Código:

SELECT categoria FROM categorias

Si tienes 10 categorías las devuelves todas, si tienes 100 también, al final las vas a tener que recuperar todas. Pero el número de post no afecta a la velocidad de la sentencia.

Claro que puedes hacer que el método de la clase post ejecute la segunda y no la primera porque si tienes la tabla categorías, bueno, entonces según evolucione y sea más complejo tu diseño de clases porque añades más cosas, acabarás viendo por ti mismo que es mejor separar post de categorías porque esa clase se esta volviendo muy grande y pesada. Pero entonces como ya tendrás todo tu código hecho de esa forma cambiarlo para incluir esa clase te llevará mucho tiempo, y al final optarás por seguir gestionando categorías en la clase post (porque te costaría mucho cambiarlo) aunque ya te hayas dado cuenta de que es mejor separar post de categorías.

[trevol]

Así explicado y en el hipotético caso de tener tantos post, es verdad que sería un error de diseño. es mejor hacer lo que dices para tener un diseño mas versatil y que no se haga lento con el tiempo.