herencia en php

[jak]

hola
3 clases pueden heredar de una clase sus metodos:
ejemplo

clase productos
void ingresar
void modificar
void eliminar
void consultar

estas 3 clases pueden heredar metodos de la clase productos?
clase categoria
clase detalle_pedidos
clase pedido

o tendria que heredar clase categoria de productos y luego clase cantidad_productos de categoria y asi sucesivamente...

mi ultima consulta:
si tengo esas 3 clases relacionadas como las que escribo mas arriba,y ahora creo otra clase que se llama verificar_password es obligacion que se relacione con las otras clases o pueden quedar clases sin relacionarse?

clase_categoria se relaciona 1 a muchos con la clase_productos y la clase productos se relaciona 1 a muchos con la clase detalle_pedidos y la clase pedidos se relaciona 1 a muchos con la clase_detalle_pedidos.pero mi nueva clase no se relacionara con ninguna de las mencionadas,a eso va mi pregunta si puede quedar una clase sin relacionarse.


gracias

[jak]

nadie sabe?:(

[Vaalegk]

bueno, en lo referente a la herencia tus clases pueden heredar de quien quieran (solo herencia simple) la pregunta aqui es:
las demas clases (categoria,detalle_pedidos,pedido) usaran la misma "funcionalidad" de "producto", conste que cuando me refiero a "funcionalidad" hablo de la implementacion, ejemplo, supongo que el metodo "ingresar" en "categoria" haria algo diferente que en "producto" con lo cual debes sobreescribir este metodo en la clase "categoria".
Mas bien la decision de que herredar se planifica de acuerdo a el comportamiento de los objetos(clases) que estas programando y sus necesidades.

Con lo referente a tu otra pregunta como dije anteriormente depende de ti la decision de quien heredar, en tu caso "verificar_password" necesita algo de las demas clases, es decir metodos, attributos?.

con lo describes al final de las relaciones,eso es "asociacion" es decir en tu clase A mantienes "referencias" a tu clase B pero A no "necesita" heredar de B.

[javier_enithost]

Hola a ambos :

Bueno, me gustaria annadir algo y especificar algo mas.

"Mas bien la decision de que herredar se planifica de acuerdo a el comportamiento de los objetos(clases) que estas programando y sus necesidades."

Exacto, o un poco mas especifico; la relacion de especificacion ( que es herencia ) entre clases esta dada por la naturaleza misma de las clases, o sea, es incorrecto un modelo de clases donde se herede un pescado de un perro por poner un ejemplo solo.

Sobre la cuestion de "necesita" de las demas clases es exactamente lo que dije, probablemente un pescado no pueda necesitar ningun atributo o metodo de la clase perro; mas bien ambos comparten atributos de la clase animal ( por poner solo un ejemplo ).

Saludos

[HerSAn]

James Rumbaugh en su libro de OMT comenta que no existen modelos correctos. Solo modelos mas adecuados para cada problema y esto es cierto ya que el proceso de abstracción esta vinculado con el de la percepción de nuestro entorno, y cada individuo lo percibe de manera diferente. Así que de esta forma nuestro amigo puede tener un modelo donde categoría, pedido y detalle_pedido heredan de producto, pero obviamente esto no es lo adecuado ya que cuando implemente su solución tendrá problemas como es el sobrescribir método y crear otros, al final tendrá un conjunto de clases que hacen mas de lo que deben y el mantenimiento de las misma se va ir haciendo mas complicado así que yo agregaría a la definición de Javier_enithost que "Mas bien la decisión de que heredar se planifica de acuerdo a el comportamiento de los objetos(clases) que estas programando, sus necesidades y del limite del problema."

El limite por que como bien comentaron podemos tener una jerarquía de clases como es la del mundo animal donde coexisten el perro y pescado y que comparten ciertos atributos, pero para fines de mi problema no lo requiero solamente me vasta con saber que son diferentes y con comportamiento distinto uno de otro.

El problema de nuestro amigo es fundamentalmente de conocimiento y experiencia en el uso de los elemento de la POO, pero la decisión como bien la plantearon esta en la naturaleza y propósito del objeto o lo que se conoce como responsabilidad y no es otras cosa que decidir que es lo que hace exactamente nuestra objeto y que necesita para hacer su trabajo.
Ahora como comentario adicional tu clase verifica password puede no estar relacionada directamente mediante una relación de asociación pero si de dependencia es decir que otra clase en algún punto hará uso de ella.
Ahora como ayuda a nuestro amigo, lo que debes de plantearte es como usa la clase pedido a producto, si te das cuenta un pedido no es del tipo producto asi que la herencia queda fuera, pero para saber un pedido cuantos productos tiene, necesita instancias de producto, así que la relación es mas bien de asociación y la de detalle_pedido de dependencia ya que necesita los detalles de producto. Ahora detalle_pedido puede heredar de pedido ya que es un caso particular de pedido.

[Webstudio]

Gente, escuchen a HerSan, que definitivamente sabe de lo que habla. :)

[javier_enithost]

Hola:

"James Rumbaugh en su libro de OMT comenta que no existen modelos correctos. Solo modelos mas adecuados para cada problema y esto es cierto ya que el proceso de abstracción esta vinculado con el de la percepción de nuestro entorno, y cada individuo lo percibe de manera diferente."

Estoy 100% de acuerdo con esto; dice en palabras resumidas que cada cual tiene su propia interpretancion de su entorno, es el tipico ejemplo de interpretaciones personales de una mancha de tinta el cual viene muy bien ejemplificado en uno de los libros de Grady Booch con un caricatura genail. De cualquier manera, esto no dice que cualquier propuesta de solucion sea correcta ni incorrecta .... pero independientemente de esto si existen REGLAS ELEMENTALES Y DEFINICIONES importantes que seguir a la hora de hacer el proceso de CLASIFICACION ( y ahi te corrijo HerSan, no es "proceso de abstraccion" ) que es el proceso mediante el cual se identifican las abstracciones afines con nuestra problematica a resolver.

La relacion de herencia ( especificacion en un sentido y generalizacion en otro ) esta dada por la propia naturaleza de las clases dentro de la persepcion del entorno del individuo que modela la solucion y nunca por la necesidad de que clases "hereden" metodos de otras, para esto esta el uso de tipos o interfaces.

"si te das cuenta un pedido no es del tipo producto asi que la herencia queda fuera" ...
aqui hay un problema fundamental, y es que un tipo y una clase no son la misma cosa.

Es muy usual definir tipo como un sinonimo de clase. Estos no son conceptos intercambiables aunque muchos teoricos prefieran considerarlo asi bajo criterios practicos. El propio Booch expresa que “Un tipo y una clase no son exactamente la misma cosa; algunos lenguajes distinguen ambos conceptos.
Por ejemplo, versiones actuales del lenguajes Trellis/Owl le permite a un objeto tener simultaneamente clase y tipo. En Smalltalk, por ejemplo, los objetos de las clases SmallInteger, LargeNegativeInteger, y LargePositiveInteger son todos del mismo tipo, Integer, aunque no de la misma clase.
Sin embargo, para la mayoria de nostros, separar los conceptos de tipo y clase es confuso y adiciona muy poco valor. Es suficiente decir que una clase implementa un tipo”.

** Tengo muy buen ejemplo de una jerarquia donde se identifican tipos y clases de manera diferentes.

Ahora, dejando a un lado la parte critica en su mejor sentido que es el de mejorar todos un poco cada dia; aqui aporto una ayudita a nuestro amigo jak y asi todos la revisan y dan sus opiniones:

Yo identifico un rol o un tipo que define este protocolo:

ROL: IManejable o como prefiera cada cual ( mejor conocido como una Interfaz )
void ingresar
void modificar
void eliminar
void consultar

Las clases productos, categorias, y pedido implementan el rol IManjeable por lo que responderan al contrato alli definido.
Ademas, la clase detalle_pedido pudiera heredar de la clase pedido por ser una especificacion y de esta forma esta tambien implementado dicho rol.

Espero sus comentarios,

Saludos

[leeja]

este es mi diagrama base...si lo pueden corregir haganlo saber en el foro...todo lo q han posteado esta en lo sierto...