Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I've been dabbling with the idea of creating my own CMS for the experience and because it would be fun to run my website off my own code base.

One of the decisions I keep coming back to is how best to validate incoming parameters for functions.

This is mostly in reference to simple data types since object validation would be quite a bit more complex.

At first I debated creating a naming convention that would contain information about what the parameters should be, (int, string, bool, etc) then I also figured I could create options to validate against. But then in every function I still need to run some sort of parameter validation that parses the parameter name to determine what the value can be then validate against it, granted this would be handled by passing the list of parameters to function but that still needs to happen and 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.

Is there any good way of handling this, or is it so low level that typically parameter validation is just done at the start of the function call anyway, so I should stick with doing that.

share|improve this question
    
Are these user defined functions? Because if they're just your own coded functions, there are well-established ways to validate them that you can find in almost any programming language book, or in a blog entry. –  Robert Harvey Sep 5 '12 at 18:41
    
Yeah these are user defined functions or methods. I was hoping to get some community advice on what those well-established ways are, most of my googling hasn't turned up a good blog entry, maybe I'm using the wrong phrasing, though I have seen the below AOP reference before. –  Aglystas Sep 5 '12 at 18:46
add comment

4 Answers

up vote 2 down vote accepted

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.

share|improve this answer
    
So in essence we will create a different object for each simple type that we can expect. So I could create a Value object that has the restraint of being non-negative and then use that as the parameter instead. –  Aglystas Sep 5 '12 at 20:04
1  
Wouldn't it be better to verify that you have the proper parameter types at compile time than at run time? That removes the validation from the function and there is no run-time overhead. I would take Jon's answer one step further and say that you are longing for a type-safe language (e.g. Java). An object-oriented type-safe language lets you define your own types so that you can do Jon's example of Area area(Length w, Length height). Type-safety and OO are wonderful things. –  GlenPeterson Sep 5 '12 at 20:41
    
I agree with Glen. Try Java. It isn't bad, really. It may be quite a change from PHP, but better in almost every way. –  Zan Lynx Sep 5 '12 at 22:06
    
@GlenPeterson: As a Haskeller, I do prefer static typing. The OP asked about PHP, so I answered from that perspective. PHP has object-oriented features and allows user-defined types. Java is not a credible alternative in this case. –  Jon Purdy Sep 5 '12 at 22:06
    
What do you mean when you say, "Java is not a credible alternative in this case?" Do you mean that Java has no good HTML front-end (aka JSP/JSF suck)? Yeah, that's an issue. Also, what is it with this list and Haskell. I hadn't even heard of Haskell until I started hanging out here, and now it seems everyone is into it. It seems a little theoretical to me. –  GlenPeterson Sep 5 '12 at 22:29
show 1 more comment

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.

share|improve this answer
    
Yeah, I've done a little research into that. Unfortunately I don't think PHP has any built-in method of AOP. IS there a specific technology or package that you can reference for me to see the practice in action. –  Aglystas Sep 5 '12 at 18:51
    
I would refer to this: stackoverflow.com/q/4738282/395975 –  smp7d Sep 5 '12 at 18:54
add comment

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.

share|improve this answer
    
Thanks, I'll take a look at it. –  Aglystas Sep 5 '12 at 18:53
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.