Programming Languages – Why Aren’t Design Patterns Added to Language Constructs?

Your code will break when, e.g. ducks quack with a different sounds. The boolean will only lead to other booleans into really hairy if-statements.

The strategy pattern is simple though. Take in this instance the quack method and place it into it's own class or interface. An interface in php would be a class that does not contain any implementation other than methods that are stubs (i.e. nothing happens when you call them).

class Quackable {
    function quack() {}
}

That way you can create several quackable implementations:

class DuckQuack extends Quackable {
    function quack() {
        return "Quack!";
    }
}

class SilentQuack extends Quackable {
    function quack() {
        return ""; 
            // The decoy duck can't quack. It is silent.
    }
}

And because we did it strategy pattern wise, we can add more types of "quackery":

class DoubleQuack extends Quackable {
    function quack() {
        return "Quackety-quack!"
    }
}

The same can be applied to fly and swim methods for the Duck class. The way you implement a Duck class with a quackable would be like this (the quackable interface is supplied through the constructor, which is sort of how dependency injection works):

class Duck {
    protected $quackable;

    // The constructor
    function __construct($quackable) {
        $this->quackable = quackable;
    }

    function quack() {
        echo $this->quackable->quack();
    }
}

Implementing the mallard duck and decoy duck will be simple since you only need to supply what kind of quacks the duck should do:

class MallardDuck extends Duck {
    function __construct() {
        parent::__construct(new DuckQuack());
           // we construct the mallard duck with a duck quack
    }
}

class DecoyDuck extends Duck {
    function __construct() {
        parent::__construct(new SilentQuack());
           // we construct the decoy duck with a silent quack
    }
}

Using it all is simple:

$duck1 = new MallardDuck();
$duck2 = new DecoyDuck();

$duck1.quack(); // echoes out "Quack!"
$duck2.quack(); // echoes out "" (because decoy ducks don't quack)

I hope this all makes sense to you.

Fail fast is a great design approach, and perhaps it can be counted as a pattern: http://en.wikipedia.org/wiki/Fail-fast

I've also found a number of principles to be useful:

• Consider exceptions as part of the interface to each function / modules - i.e. document them and where appropriate / if your language supports it then use checked exceptions.
• Never fudge a failure - if it failed, don't try to continue with some attempt to "assume" how to proceed. For example, special handling for null cases is often a code smell to me: if your method needs a non-null value, it should be throwing an exception immediately if it encounters a null (either NullPointerException or ideally a more descriptive IllegalArgumentException).
• Write unit tests for exceptional cases as well as normal ones - sometimes such tests can be tricky to set up but it is worth it when you want to be sure that your system is robust to failures
• Log at the point where the error was caught and handled (assuming the error was of sufficient severity to be logged) . The reason for this is that it implies you understood the cause and had an approach to handle the error, so you can make the log message meaningful.....
• Use exceptions only for truly unexpected conditions/failures. If your function "fails" in a way that is actually expected (e.g. polling to see if more input is available, and finding none) then it should return a normal response ("no input available"), not throw an exception
• Fail gracefully (credit to Steven Lowe!) - clean up before terminating if at all possible, typically by unwinding changes, rolling back transaction or freeing resources in a "finally" statement or equivalent. The clean-up should ideally happen at the same level at which the resources were committed for the sake of clarity and logical consistency.
• If you have to fail, fail loudly - an exception that no part of your code was able to handle (i.e. percolated to the top level without being caught + handled) should cause an immediate, loud and visible failure that directs your attention to it. I typically halt the program or task and write a full exception report to System.out.