CODEWITHSUNDEEP
phpoopdesign-patterns
rybosome
rybosome

Reputation: 5126

What would be the appropriate design pattern to use in this PHP class structure, given no multiple-inheritance?

I have an abstract class called Node. It contains a constructor that takes a row from my database, and instantiates basic information. All pieces of content on my website extend this class - Person, Event, Project, etc.

3 of these extending classes are special - when they are constructed, in addition to pulling values from the database, they also need to query a web-service; if the web-service provides values that are different from the ones given in the DB, they need to save to the DB.

In a multiple-inheritance capable language, this would be fairly simple; any one of these classes would extend both Node, and APIData, or something like that. Without MI, I'm not sure how to handle this. Using an interface would not be helpful, as that provides no concrete implementations.

The decorator pattern is sometimes recommended as a substitue for some features of MI, but I don't have enough experience to determine if this is the appropriate choice. Any suggestions?

Upvotes: 5

Views: 296

Answers (3)

Explosion Pills
Explosion Pills

Reputation: 191749

You shouldn't necessarily sit down and choose a design pattern as in "okay, I'm going to implement a decorator pattern." Instead, you should design your code the way it's supposed to work, and the design pattern will develop as a result of that. It just so happens we have a lot of existing terminology that describe some common design patterns and knowing what they're called can make it easier to describe them.

At any rate, I would suggest you go up rather than down. Instead of extending Node and trying to force APIData in there somehow, you can have a separate object that is composed of Node and APIData objects and does its individual work through them.

When PHP 5.4 comes out with its traits, this will be so much the easier.

Upvotes: 0

Sean Adkinson
Sean Adkinson

Reputation: 8605

Objects should be dumb. When I construct something, it shouldn't be doing anything other than what I ask it - i.e. construct yourself. Don't be querying webservices and writing to the database. If I was using your objects as another developer on your team, I would be shocked.

This is also why I think you are struggling for the correct pattern, because your object has multiple concerns.

I think the best approach here would be to create a service that returns objects, such as a PersonService, EventService, etc., that does the following:

  • Retrieve record from the database
  • If need to check webservice:
    • Retrieve data from webservice
    • If changes exist, save back to database
  • Pass record to object contructor
  • Return object

This keeps the concerns of the webservice call in a place where it makes sense - that is, the code that retrieves the necessary data to construct and return objects, aka a service (EDIT: actually more of a DAO, but you get the idea).

Upvotes: 3

Sascha Galley
Sascha Galley

Reputation: 16091

Since the APIData class will take functionallity from your Node class, you should simply extend it. Here is some pseudo code:

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
            }
        }
    }
}

Upvotes: 1

Related Questions