Defensive programming

Earlier in the week, whilst implementing a domain registration API into another client project (and pulling my hair out), I thought back to a seminar from university. The module was Component Based Design and it was all about writing code in a standard way, helping to aid both the supplier (API creator) and the client (the person using the API). Although I didn’t realise it until now it actually played a large role in how I program today. There are two main approaches for this, Defensive Programming and Design By Contract.

Defensive programming is all about the supplier making sure that their code works when parameters passed in might not be what it expected. And also that the client passes in correct information. So in effect the code is validated on both sides. The immediate advantage of this technique is that is will severely reduce the number of bugs since the chances of incorrect information both passed in and validated are slim. The disadvantage of this is longer CPU time and execution. The computer simply needs to parse and run more lines of code. Not so much a problem in todays world where hardware is getting faster and cheaper, but years ago it might have caused people to stop and think. Defensive Programming is generally used when you do not know exactly how your function call will be executed, ensuring nothing bad will happen.

<?php
class MissionCritical
{
    /**
     * Insert some mission critical information into the database.
     *
     * @param int $id
     * @return boolean
     */
    private function insert($id) {
        return mysql_query("
            INSERT INTO `research`
                (`id`)
            VALUES
                (" . (int)$id . ")
        ");
    }
}

$missionCritical = new MissionCritical();
$missionCritical-> insert((int)10);

Here when we pass the data into the function, we ensure we pass in an integer. We also perform the same in the actual function.

Design By Contract is different in that the supplier and client know what each is doing, or at least doing what they say they are doing and trusting them to perform that role. The class may say that it validates all country codes to ensure 2 character ISO 3166-1 standards and that the client does not need to, for example, so the client will be able to pass in any value and know that the validation it outside of its scope. Again the pros and cons are immediately noticeable in that it saves processing time, but at the expense that there might possible be bugs and possible security issues. The snippet of code may look like:

<?php
class MissionCritical
{
    ...
}

$missionCritical = new MissionCritical();
$missionCritical-> insert(10); // Here we are not ensuring it is an int
                               // We know that `insert` is casting it

So, which is the better approach? Well, there isn’t one. Security is always a tradeoff. My general rule of thumb is that any code I write myself handles all data validation from the suppliers end―I really don’t want to have to validate in awkward places which would be better suited elsewhere. Since I am generally the supplier and client I am happy in knowing everything is secure. However when dealing with third party scripts that I cannot read (like the domain registration API I mentioned in the first paragraph) I like to ensure that any data going in is correct. So I like to take the best of both worlds, as I am sure most other programmers do.