How to deal with some of the dependencies? I am very beginning in PHP and Design Patterns. I have been studying the beautiful book "Head first: Design pattern" and I have been working in some of the codes originally presented in Java in order to learn more about PHP-OOP. The code below presents a kind of Observer Pattern. It is working well, however there are still some design choices that bother me? Can one help me improve this piece of code.

Questions:


Am I using a good PHP practice?
The entire code seems to be based on the idea that there are three pieces of information that are relevant, namely $temperature, $humidity and $ pressure. However, it seems that this is not a good design, since I may eventually in the future need another piece of information such as for instance pluviometric index... Is there a good way to avoid this kind of dependency?
Is it a good choice the class currentConditionsDisplay to implement both Observer and DisplayElement? It seems to be another undesirable dependency.
Are there other kinds of undesirable dependencies?
Is a better design pattern to define currentConditionsDisplay as static?


Any help is very welcome.

&lt;?php

interface Observer{
    public function update($temp,$humidity,$pressure);
}


interface Subject{
    public function registerObserver(Observer $o);
    public function removeObserver(Observer $o);
    public function notifyObserver();
}

interface DisplayElement{
    public function display();
}

class WeatherData implements Subject{
    private $observers;
    private $temperature;
    private $humidity;
    private $pressure;

    public function __construct(){
        $this-&gt;observers=array();
    }
    public function registerObserver(Observer $o){
        array_push($this-&gt;observers,$o);
    }
    public function removeObserver(Observer $o) {
        unset($this-&gt;observers["$o"]);
    }
    public function notifyObserver(){
        foreach($this-&gt;observers as &amp;$o){
            $o-&gt;update($this-&gt;temperature,$this-&gt;humidity,$this-&gt;pressure);
        }
    }
    public function measurementsChanged(){
        $this-&gt;notifyObserver();
    }
    public function setMeasurements($temperature,$humidity,$pressure){
        $this-&gt;temperature=$temperature;
        $this-&gt;humidity=$humidity;
        $this-&gt;pressure=$pressure;
        $this-&gt;measurementsChanged();
    }
}

class CurrentConditionsDisplay implements Observer, DisplayElement{
    private $temperature;
    private $humidity;
    private $weatherData;

    public function __construct(Subject $weatherData){
        $this-&gt;weatherData=$weatherData;
        $weatherData-&gt;registerObserver($this); // $this reffers to the currentConditionsDisplay
    }

    public function display(){
        echo "Current conditions: "."$this-&gt;temperature"." F degrees and "."$this-&gt;humidity"." humidity";
    }

    public function update($temperature,$humidity,$pressure){
        $this-&gt;temperature=$temperature;
        $this-&gt;humidity=$humidity;
        $this-&gt;display();
    }
}

$weatherData=new WeatherData();

$currentConditionsDisplay=new currentConditionsDisplay($weatherData);

$weatherData-&gt;setMeasurements(80,60,30.45);

?&gt;
Your are using the observer-pattern in a right way. The pattern itself is probably one of the most important ones. In PHP it is not used that much though as applications have a rather quick life-cycle. Yet good to know the pattern of course. Some minor remarks about your code though:

All methods in an interface are public, no need to repeat yourself (in interfaces).
The name Observer and Subject indicate an use-case independent use. Yet your Observer are coupled to your Weather component. Better names would be WeatherDataObserver and WeatherDataSubject.
I'd consider it standard to have at least a whitespace between the function's header and the opening bracket: registerObserver(Observer $o) {
Not sure if your WeatherData is actually a service. For me the name WeatherData indicates a set of values, not necessarily the current values. I'd probably rename it to WeatherDataService. 
notifyObserver should not be public. I don't want anyone else to trigger (possibly false positives) notifications. Better remove it from the interface too.
measurementsChanged serves no purpose yet. Replace it with notifyObserver.

Your concerns are right. If I remember the book correct, they present an alternative approach on this pattern: instead of pushing the changed values to the observers, just inform them something has changed and let them pull the new values from the subject. This changes the signature of your observer to function update(Subject $weatherData) and in the update method of your CurrentConditionsDisplay you get the new values by: 

public function update(Subject $subject){
    $this-&gt;temperature = $subject-&gt;getTemperature();
    // and so on
}


Another approach would be some event'ed one. Send an event-object about what has changed. This pushed the changes to your observers and still avoids dependencies. This approach is a bit more work though. 
This is a pattern from java user-interfaces (or any views that can update themselves). In PHP you usually don't use this pattern to update user interfaces as PHP can't update the UI :). You'd access the WeatherData directly when rendering the view. Nothing really bad about this here though. 
Fine for me from what I can see.
No. Generally there are very very very few proper uses for static methods. Static methods are completely independent from others and object internal state. Successive calls to static methods should always have the same result (and should be side-effect free), no matter what happened in the application meanwhile. Usually this applies for simple helper functions only (e.g. abs or other math. helpers). Even this could be discussed though. CurrentConditionsDisplay has some internal state though, therefore static is a no-go.