¿Cuál sería el patrón de diseño apropiado para usar en esta estructura de clase PHP, dado que no hay herencia múltiple?

Question

tengo una clase abstracta llamada Node. Contiene un constructor que toma una fila de mi base de datos y crea una instancia de información básica. Todas las piezas de contenido en mi sitio web se extienden esta clase - Person, Event, Project, etc.

3 de estas clases se extienden son especiales - cuando se construyen, además de tirar de los valores de la base de datos, sino que también deben consultar un servicio web; si el servicio web proporciona valores que son diferentes de los dados en el DB, deben guardarse en el DB.

En un lenguaje capaz herencia múltiple, esto sería bastante sencillo; cualquiera de estas clases se extendería tanto Node, como APIData, o algo así. Sin MI, no estoy seguro de cómo manejar esto. Usar una interfaz no sería útil, ya que no proporciona implementaciones concretas.

El patrón decorador a veces se recomienda como un substituto para algunas características de MI, pero no tiene suficiente experiencia para determinar si esta es la opción apropiada. ¿Alguna sugerencia?

Answer 1

Dado que la clase APIData tomará functionallity de su clase Node, simplemente debe extenderla. Aquí hay un código de pseudo:

abstract class APIData extends Node { 

    public function __construct($data) { 
     parent::__construct($data); 
     $this->checkData(); 
    } 

    protected function checkData() { 
     // load data from webservice 
     $data = $this->loadData(); 

     // check if data is the same 
     foreach($data as $item => $value) { 
      if ($this->data[$item] != $value) { 
       // save in database 
      } 
     } 
    } 
} 

Answer 2

Los objetos deben ser tonto. Cuando construyo algo, no debería hacer otra cosa que no sea lo que le pido, es decir, construirme a usted mismo. No consulte los servicios web ni escriba en la base de datos. Si estuviera usando tus objetos como otro desarrollador en tu equipo, me sorprendería.

Esta es la razón por la que creo que está luchando por el patrón correcto, porque su objeto tiene varias preocupaciones.

creo que el mejor enfoque aquí sería la creación de un servicio que devuelve objetos, tales como un PersonService, EventService, etc., que hace lo siguiente:

• Obtener el registro de la base de datos
• Si que comprobar servicio web:
  • Recuperar datos de servicio web
  • Si existen cambios, salvo de vuelta a la base de datos
• registro paso a objeto contructor
• objeto Volver

Esto mantiene las preocupaciones de la llamada de servicio web en un lugar donde tiene sentido - es decir, el código que recupera los datos necesarios para construir y objetos de retorno, también conocido como un servicio (EDITAR: en realidad es más un DAO, pero entiendes la idea).

Answer 3

No debe necesariamente sentarse y elegir un patrón de diseño como en "bien, voy a aplicar un patrón decorador." En su lugar, debe diseñar su código de la manera en que se supone que debe funcionar, y el patrón de diseño se desarrollará como resultado de eso. Simplemente sucede que tenemos una gran cantidad de terminología que describe algunos patrones de diseño comunes y saber cómo se llaman puede hacer que sea más fácil describirlos.

En cualquier caso, sugeriría que se sube en vez de bajar.En lugar de extender Node y tratar de forzar APIData de alguna manera, puede tener un objeto separado que se compone de objetos Node y APIData y hace su trabajo individual a través de ellos.

Cuando PHP 5.4 sale con sus rasgos, será mucho más fácil.