Ver Mensaje Individual
  #3 (permalink)  
Antiguo 02/12/2008, 07:04
Avatar de enriqueplace
enriqueplace
 
Fecha de Ingreso: mayo-2005
Ubicación: Uruguay / Argentina
Mensajes: 1.102
Antigüedad: 19 años
Puntos: 32
Respuesta: Cuando usar objetos y cuando no?

Cita:
Me hefijado, que como desarrolladores apasionados siempre estamos en búsqueda de nuevas técnicas, de nuevas formas, maneras, etc. Y cuando nos topamos con algo nuevo creemos que SIEMPRE debemos usarlo.
Si hablamos de POO es algo antiguo, mucho, y no tiene nada de nuevo. Como paradigma, no es algo opcional que se use parcialmente, o lo usas o no lo usas, de lo contrario es un híbrido y no obtienes beneficios esperados.

Cita:
Pero no alcanzo a distinguir donde NO deberia usarlos; o abusar de ellos. Y para ello pongo el siguiente ejemplo a fin de que me orienten sobre la conveniencia de usar objetos o no:
Deberías usar el paradigma al 100%, no "más o menos". El problema es luego si tu diseño tiene "exceso de abstracciones" ("demasiados objetos") para resolver un problema simple.

Cita:
El punto es que de alguna manera, la unica accion repetitiva es el registro, la edicion y la eliminacion de registros, el resto son tareas propias de las reglas de negocio.
Depende cómo hagas el diseño de tu solución. Deberías tener claramente entidades distintas (Clientes, Usuarios, Proveedores, etc) y entre ellas tener reuso de las cosas comunes (Persistencia, por ejemplo). Una vez que tienes resueltos los problemas particulares con entidades bien definidas, luego es llamarlas y pedirles que hagan lo que tienen que hacer sin entrar en detalles ("principio de ocultación") y donde puedes hacerlas interactuar con otras entidades.


Cita:
Yo ya he generado una clase que cumple con esas tareas repetitivas, y no le veria caso generar una clase que tenga metodos como: agregarCliente(), eliminarCliente(), agregarUsuario(), eliminarUsuario().
¿Y cómo haces para diferenciar si es uno u otro a la hora de persistir la información?

Cita:
Sin embargo, tambien me queda la duda de que tanto deberia mezclar el diseño (html) con las reglas de negocio (php), es decir que tanto deberia mezclar codigo php con html.
Código HTML con PHP vas a tener que mezclar, no te queda otra, porque HTML no anda dinámicamente solo

Lo que tienes que hacer es dividir tu sistema en "3 capas" y en cada una de ellas resuelves un tema solo: presentación, dominio y persistencia (y en las tres usarás PHP, pero solo en la primera HTML).

Espero haber aportado algo de claridad.
__________________
Blog phpsenior.com Cursos a Distancia surforce.com