Validation logic in Setter methods vs Validation classes/objects

[Hall_of_Famer]

While reading Antnee’s articles on some OOP techniques, I came across this thought about validation logic. In his article the validation logic is directly placed in setter methods, while sometimes I also see people creating validator objects which are used as service objects for the sole purpose of validating, especially in model layers.

So I wonder, have you considered this yet? What are the difference between the choice of putting validation logic in setter and in validator object? The latter seems to provide an additional layer of abstraction, but its arguable whether this layer of abstraction is beneficial or detrimental. In an earlier thread I made, there was a discussion of validation logic in domain models/services:

Domain model design and validation logic

Well one important design principle for domain/business layer is to use rich models, thus to put business logic inside domain models and make the application layer as thin as possible. The tricky thing here is, what classifies as domain/business logic, and what does not. On web development, this may not be easy to figure out, as you do not have classes like Car or Cat in which the business logic is straightforward. A car can be driven and stopped, so drive() and stop() are clearly a business log…

But now I want to expand the topic in a bit more broad way, just validation logic in a general sense. Do you prefer putting validation logic in the very class that needs validation itself with setters taking care of it, or to write separate validation logic for this. If you use both, what is a rule of thumb to determine when to use setters validation and when to use validation classes/objects?

[Jeff_Mott]

Similar discussion:

Are getters and setters bad for domain object model?

Yup, I think ahundiak is on the right track. Traditionally in OO, a class is responsible for keeping its private data in a valid state. If it was possible for a Post object to have a published date but not be in a published state, then that would be invalid. But there’s a trade-off. We would end up using exceptions for simple validation. For example: class User { // ... public function setEmail($email) { // Ensure this object is always valid if (!filter_var($em…

Are getters and setters bad for domain object model?

Yup, I think ahundiak is on the right track. Traditionally in OO, a class is responsible for keeping its private data in a valid state. If it was possible for a Post object to have a published date but not be in a published state, then that would be invalid. But there’s a trade-off. We would end up using exceptions for simple validation. For example: class User { // ... public function setEmail($email) { // Ensure this object is always valid if (!filter_var($em…

[Antnee]

I think it’s crucial that the validation is encapsulated within the object. However, it’s not unreasonable to provide a validation method if needs be, if you have a nice validation interface.

There are different levels of validation though. There is no such thing as an email type in PHP, there is only a string. Unless you have an email value object then you’ll be passing in a string into any method that needs an email address. In PHP7 we can type hint a string, but until then we have to do things like is_string()… Yuk!

Anyway, at some point you need to validate that the email address is actually an email address, and if you don’t want to validate in the object itself then you need to be absolutely sure that mistakes aren’t being made upstream. How many entry points are there to this object? If there’s just the one then sure, put the validation upstream, but if there are many then you’re going to be needing to validate all over the place. The only thing that really cares is the class on which you’re setting this property.

As with many things, there are loads of right answers, and only if you properly understand your domain will you be able to make the right decision. If you build it well and realise that you put it in the wrong place then you should be able to move it later easily.

Don’t be afraid to make mistakes. Try it the way you think is best, and if it’s wrong try it a different way. Just be sure to share your experiences as others may benefit from it too.