herencia en php

[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