Tell me more ×
Code Review Stack Exchange is a question and answer site for peer programmer code reviews. It's 100% free, no registration required.
up vote 1 down vote favorite

my question is based on this "principles"

  • do not throw exceptions in a constructor
  • single responsibility / seperation of conerns
  • use logic exceptions for broken contracts and runtime exceptions for everything else

so whats the best way to validate the contract and whos job is it?

lets assume there is a class "world" 

class world {
  public function __construct($sName, array $aSomething) {}
}

where do i go from here? should i validate the params and throw an exception in the constructor? should i inject an valdator?

public function __construct($sName, array $aSomething, Validator $oWorldValidator) {}

should i not validate the params and validate the object after creation?

$oWorld = new World(....);
$oWorldValidator->validate($oWorld);

should i discard the constructor and use static methods to create valid world object?

private function __construct() // do not use
public function createValidWorld(....) {} // validate and exceptions here

how important is the first rule? (no exceptions in constructor method) can the object be responsibe for its validation ? is seperation of concerns realy the same as single responsibility?

thx for your time and help.

share|improve this question
1  
Here is a very good SO post about this same problem: stackoverflow.com/questions/77639/… – c_maker May 21 '12 at 12:06
thx @c_maker do you know if php has any specific problems with throwing exceptions in the constructor method? – braunbaer May 21 '12 at 12:19
I do not know for sure, I have not done much php in the past. My gut feeling is that there should be no special considerations. – c_maker May 21 '12 at 12:24

1 Answer

up vote 0 down vote accepted

To the best of my knowledge, only destructors cause fatal errors if an exception is thrown, so you should be ok with throwing exceptions in a constructor if you wish. I have never heard of this principle before, but I think the idea behind it is that an object should always be successfully instantiated. I would take this to mean that you should have default arguments. So you should definately validate it, but if you wish to abide by these guidelines it should occur after it is instantiated and the default arguments should be used if the provided ones don't work. I honestly do not see any problems with the first "rule" and have been unknowingly following a version of it for some time.

Now the second "rule" is different. In this instance, validation should never occur in the constructor, because the constructor's only job is to instantiate itself. This isn't to say that you can't call a validation method in the constructor, only that the code should be separated based on its purpose. The pure version of this rule would argue that one method/function should never call another and should always be procedurally called where it is used, but I think most of us don't take it to that extreme.

So, to appease both the first and second rules I would instantiate my object first, then call my validation separately. Like you've done here.

$oWorld = new World(....);
$oWorldValidator->validate($oWorld);

As for the third "rule", I believe it merely means that you create your own exceptions for your code, and be able to handle the ones that PHP throws at you too.

Hope this helps, but take it with a grain of salt. These are my self-taught musings. I will also say that "rules" such as these should not be followed to the letter, but adapted to your own personal use. Asking for clarification is fine, but in the end, the ultimate decision on how to incorporate it is up to you.

share|improve this answer

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.