In property setters of classes should you return a true or false based if the property has been set? and then base your logs on which properties got set during the modification of the object?
i.e.
class confusedBooleanClass {
protected $property = 'string';
public function setProperty($property){
if(is_string($property)){
$this->property = $property;
return true;
}
return false;
}
}
whether you return a boolean value from functions/methods to say whether the function was sucessful or not is optional. Normally I return a boolean value to the function/method calling statement, if no other value is returned, so the calling script can proceed according to the returned value.
This is completely up to you what you return from setters. Many frameworks return $this from setters so that you can chain one method with another like so:
$obj->setName(‘dave’)->setLastName(‘Smith’)->setAge(‘20’);
If you still want/need to do some testing of values before setting it, you can just throw an exception if the value looks invalid.
Like this:
public function setName($name){
if(!is_string($name){
throw new InvalidArgumentException('name must be a string, it was: '.gettype($string));
}
$this->name= $name;
return $this;
}
An exception is the correct choice. It will prevent outside code from being responsible for the check after-wards not to mention a nasty cluttering of conditionals when calling setters.
Personally, I would advise doing all your data validation before passing the data to a class.
The idea of having a class is to make it as generic and re-usable as possible from one application to another without having to modify the class code at all.
If your class does the error checking/validation internally and returns errors messages you run the risk of any error messages the class outputs not being applicable in every application you use the class in.
Basically, if the data fails validation generate and display the error message in the application code and then not even pass it to the class.
The class should, imho, receive clean validated data.
Classes should be self containing. Having the outside layer be fully responsible for validating what an object expects introduces hidden points of failure. However, by using an exception the point of failure will be immediately known regardless of familiarity of the code within the class. If I ask someone to pass me the ketchup and they pass me a spoon I’m not going to attempt to pour the spoon on my hamburger. I’m going to make them aware that what they gave me is not what I expected.
I agree they should be self contained but I disagree having all the data validation done outside of the class intoduces hidden points of failure.
In my view, the onus is on the user of the class to know how the class works and what data it expects before using it and so validate the data before passing it to the class.
Otherwise, to me it’s a bit like handing over the keys to a car to someone who has never ever driven before and then expect the car to correct any mistakes that someone makes in order to avoid collisions as they are driving solo. In this analogy, that someone has to be trained and tested (validated) before issuing them with a driver’s licence.
Basically the car (class) expects someone who has been tested (validated) to drive a car to be driving it.
Hi…
The “give me the correct thing or I crash” behaviour is probably right in a language like C. I’ve coded like that. Double checking inside a function that parameters were correct leads to a lot of wasted code and needless return checking.
Exceptions change the game however. There is a rule called the Samurai principle, or “return victorious or don’t return at all”. In other words, if a method should complete a task just do it. If you cannot compete the task, then throw an exception. Don’t return a value that must be checked higher up.
yours, Marcus
At the end of the day, whether you do the data validation within the class or in the application code before calling the class method is much of a muchness (it probably doesn’t matter). The amount of code will be about the same.
But I prefer to do the validation in the application code so that you can customise any error messages or alternative actions if validation fails on an application by application basis. If validation fails, then I don’t even call the class method.
With PHP being a scripted language it is a lot easier to customise the class code for each new application if needed, but I would prefer not to do that. I prefer to make my classes as generic as possible so I don’t have to think about customising them to each new application where I use them.