Design by Contract (DBC) - Facade

Every method in a facade contains an implicit promise. So a client expects that the behavior does not change in a minor update. Basically, there are two types of possible changes:

• Changes in the method’s signature—for example, when the name of the method or the order of the parameters changes.
• Changes in the expected behavior of the method. While a renamed method causes an exception, a change of behavior is much harder to detect.

A contract is a formal and precise specification of a method (or another component). This consists of three parts: preconditions, post-conditions, and invariants. Practically, there is no approach to enforcing a contract in PHP. In other languages, there are DBC extensions like iContract for Java. For details, see iContract: Design by Contract in Java.

Example:

Imagine a signature like this for the method saveCustomer():

<?php
/**
 * @param string $idCustomer
 * @param string $email
 *
 * @return void
 */
public function saveCustomer($idCustomer, $email)
{
    ...
}

Based on the name, this method “saves a customer”. So the contract is as follows:

Additional information:

• The post-conditions are complete. Any other behavior is not expected here—for example, this method must not send an email to a customer to confirm the change.
• This method must not return anything. You could think of a boolean return value if the email cannot be changed. But then this method would do two things. Therefore, it’s a better approach to have another doesEmailExist($email) method for the pre-check.
• If the preconditions are not valid, the method must throw an exception. In this case, if the email address already exists, the EmailAlreadyExistsException exception is thrown.