How to use revalidation in ValueObject

Question

I am trying to combine some methods.

It seems like good practice never allows you to create a ValueObject that is not valid. The ValueObject constructor should be interrupted whenever the content provided is not good enough to create a valid ValueObject. In the examples that I have, an EmailAddress object can only be created when a value is present. So far so good.

Checking the value of the emailaddress provided, where I start to doubt the principles. I have four examples, but I can’t say which one should be considered best practice.

Example 1 is simple: just a build function, the required parameter is “value”, and a separate function checks that the code is clean. All verification code remains inside the class and will never be available to the outside world. The class has only one purpose: to keep the email address and make sure that it will never be invalid. But the code will never be reused - I create an object with it, but that’s it.

public function __construct ($value) { if ( $this->validate($value) ) { throw new \ValidationException('This is not an emailaddress.'); } $this->value = $value; } protected function validate ($value) { return is_string($value); // Wrong function, just an example } 

Example 2 makes the validate function a static function. A function will never change the state of a class, so this is the correct use of the static keyword, and the code in it will never be able to change anything in any instance created from a class that embeds a static function. But if I want to reuse the code, I can call a static function. However, it seems dirty to me.

 public function __construct ($value) { if ( $self::validate($value) ) { throw new \ValidationException('This is not an emailaddress.'); } $this->value = $value; } public static function validate ($value) { return is_string($value); // Wrong function, just an example } 

Example 3 represents another class hardcoded inside the body of my object. Another class is a verification class that contains verification code and thus creates a class that can be used whenever and wherever I need a verification class. The class itself is hardcoded, which also means that I am creating a dependency on this validation class, which should always be nearby and not injected through dependency injection. It can be said that having validator hard coding is as bad as the full code embedded in the object, but on the other hand: DI is important, and so you need to create a new class (extension or just rewrite) before just change the dependency.

 public function __construct ($value) { if ( $this->validate($value) ) { throw new \ValidationException('This is not an emailaddress.'); } $this->value = $value; } protected function validate ($value) { $validator = new \Validator(); return $validator->validate($value); } 

Example 4 uses the validation class again, but places it in the constructor. Thus, My ValueObject needs an existing and created validator class before creating the class, but you can easily overwrite the validator. But how good it is for a simple ValueObject class to have such a dependency in the constructor, since the only thing that really matters is value, I should not care about how and where to contact if the letter is correct, and providing the correct validator.

 public function __construct ($value, \Validator $validator) { if ( $validator->validate($value) ) { throw new \ValidationException('This is not an emailaddress.'); } $this->value = $value; } 

In the last example, which I began to think about, a default validator is provided, but meanwhile it allows you to make rewriting for the validator in the constructor through DI. But I began to doubt how good a simple ValueObject is when you overwrite the most important part: validation.

So, everyone has an answer on how to best write this class, is it right for something as simple as an email address, or something more complicated like a barcode or visa card or something, oh what you might think t violates DDD, DI, OOP, DRY, misuse of static, etc ...

Full code:

 class EmailAddress implements \ValueObject { protected $value = null; // --- --- --- Example 1 public function __construct ($value) { if ( $this->validate($value) ) { throw new \ValidationException('This is not an emailaddress.'); } $this->value = $value; } protected function validate ($value) { return is_string($value); // Wrong function, just an example } // --- --- --- Example 2 public function __construct ($value) { if ( $self::validate($value) ) { throw new \ValidationException('This is not an emailaddress.'); } $this->value = $value; } public static function validate ($value) { return is_string($value); // Wrong function, just an example } // --- --- --- Example 3 public function __construct ($value) { if ( $this->validate($value) ) { throw new \ValidationException('This is not an emailaddress.'); } $this->value = $value; } protected function validate ($value) { $validator = new \Validator(); return $validator->validate($value); } // --- --- --- Example 4 public function __construct ($value, \Validator $validator) { if ( $validator->validate($value) ) { throw new \ValidationException('This is not an emailaddress.'); } $this->value = $value; } } 

Answer 1

Example 4!

Why? Because it is verifiable, simple and simple.

Depending on what your validator is actually doing (in some cases, your validator can rely on an API call or a database call), it can be fully tested with mocks. Everything else is either impossible to verify in the circumstances that I just mentioned, or incredibly difficult to verify.

EDIT:. For those who are wondering how the dependency injection method helps with testing, consider the following CommentValidator class, which uses the Akismet standard spam checking library.

 class CommentValidator { public function checkLength($text) { // check for text greater than 140 chars return (isset($text{140})) ? false : true; } public function checkSpam($author, $email, $text, $link) { // Load array with comment data. $comment = array( 'author' => $author, 'email' => $email, 'website' => 'http://www.example.com/', 'body' => $text, 'permalink' => $link ); // Instantiate an instance of the class. $akismet = new Akismet('http://www.your-domain.com/', 'API_KEY', $comment); // Test for errors. if($akismet->errorsExist()) { // Returns true if any errors exist. if($akismet->isError('AKISMET_INVALID_KEY')) { return true; } elseif($akismet->isError('AKISMET_RESPONSE_FAILED')) { return true; } elseif($akismet->isError('AKISMET_SERVER_NOT_FOUND')) { return true; } } else { // No errors, check for spam. if ($akismet->isSpam()) { return true; } else { return false; } } } } 

And now, when you are setting up your unit tests, we have the CommentValidatorMock class that we use instead, we have setters that manually change the two outputs we can have, and we have 2 functions on top. d to display everything we want without having to go through the Akismet API.

 class CommentValidatorMock { public $lengthReturn = true; public $spamReturn = false; public function checkLength($text) { return $this->lengthReturn; } public function checkSpam($author, $email, $text, $link) { return $this->spamReturn; } public function setSpamReturn($val) { $this->spamReturn = $val; } public function setLengthReturn($val) { $this->lengthReturn = $val; } } 

If you are serious about unit testing, you need to use DI.

Answer 2

The first instinct is usually the best. You must use the first option. EmailAddress is a value object. It can be reused in other objects or value objects. I do not understand why you think that it cannot be reused. You can have a “shared library” of these shared value objects used in other limited contexts. Just be careful what you put there. They should be truly generic, if even conceptually possible.