The general solutions to this problem are type safety (so that values are valid by construction) and encapsulation (so that values cannot be invalidated after construction). If your inputs and outputs have meaningful types, then the constructors of those types can enforce the properties you want. If validation is centralised, you don’t have to repeat it.

Let’s talk in pseudocode for a moment. As a contrived example, consider a function area(w, h) that computes the area of a rectangle. If you type the function as:

int area(int w, int h)

Then there is no guarantee that any of the invariants hold:

• w and h are lengths

• Being lengths, they must be non-negative

• The result is an area

To enforce input constraints, you can always add validation to the function body:

int area(int w, int h) {
    assert(w >= 0);
    assert(h >= 0);
    return w * h;
}

Not only is this cumbersome, but it remains the responsibility of the caller to validate the result. If we use types that represent our units:

Area area(Length w, Length h) {
    return w * h;
}

Then nobody can give us a Volume when we expected a Length, and since a length cannot be negative, we don’t need to check for that.

PHP doesn’t enforce types statically, but you can prevent the construction of invalid objects by throwing exceptions from constructors that receive invalid inputs, and using immutable objects or accessors to prevent later invalidation.

Based on the comment “one of my goals is to remove the parameter validation from the function itself so that you can only have the actual function code that accomplishes the intended task without the additional code for validation”, you may want to look at using AOP for method validation. Hopefully the technologies you are using can support that paradigm.

In this case, your validator would be an aspect and would not pollute the business logic of your function. This should add the benefit of making your validation logic readily reusable and will help support unit testing.

I think you could use design by contract in the sense that the code of your CMS is not doing much of a validation, trusting to the input of the external layer. The external layer though should be strict, maybe even a bit paranoid about the input.

By external layer I mean the extension points of your cms e.g. the controller class that gets extended, the objects that accept extension through strategies or visitor etc. Of course, as already noted, you may use AOP (it is now available in PHP with getDocComment-like “hacks”)

Of course this may be a little of over-engineering, but that is what I would do.

Well… I would create a validator class. All input from the user would go through that. If validation fails, code returns.

Now, you could use a single Validator interface and create different validation rules or use just one Validator object which know all the validation rules you need.

Than, when you are sure that a ‘telephone number’ is really a ‘number’ and not a characters, than you call the function which has that as parameter.

Functions / methods should usually not check for parameter validity, however, in some situations you will still need to check a few things. If something goes wrong with a function, it should throw and exception.

So, you filter out user input as close to the user as possible and than you throw exceptions for unforeseen cases as deep as possible in your logic.

UPDATE: Also, you may consider for implementation the Observer Design Pattern, or maybe a Mediator if needed.